Mark Bergsma offered to repurpose the old app servers for CI purposes ( T84940 ). Can we figure out in OpenStack how to get that hardware to be dedicated to a specific labs project (ex: contintcloud) that will be used to spawn disposable VM?
Maybe it is overkill and we can just reuse the shared hardware.
See also:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | hashar | T60772 common gating job for mediawiki core and extensions | |||
| Resolved | hashar | T69216 Have unit tests of all wmf deployed extensions pass when installed together, in both PHP-Zend and HHVM (tracking) | |||
| Invalid | Ryasmeen | T90647 Create Jenkins builds for Editing across repositories (MobileFrontend, VisualEditor etc) | |||
| Declined | None | T50407 Jenkins: Setup Vagrant for some jobs (tracking) | |||
| Declined | None | T45266 Write and implement tests for Wikimedia's Apache configuration (redirects.conf, etc.) | |||
| Resolved | hashar | T47499 [EPIC] Run CI jobs in disposable VMs | |||
| Declined | None | T84989 Support dedicating a specific virt node to a specific nova project |
I renamed this because 'baremetal' refers to a particular use case which this isn't :)
Lowering priority, at the start I guess we can afford having our small disposable instances to roam on the current compute servers. Still interesting to investigate at one point so we can allocate the CI vm to dedicated hardware.
Just now chase and I have confirmed that the proper mechanism to direct particular VMs to particular hosts (host aggregates) does not work in icehouse.
We'll have another go once the cluster is upgrade to Juno or Kilo.
I once filled a bug (T59833) to get the bastion instances to be on different hosts, though that is probably a slightly different feature.
@RyanLane wrote on T59833#637230:
When Labs upgrades to the Icehouse release they should use the new scheduler feature to ensure they can't live on the same host.
Quickly browsing the Icehouse doc http://docs.openstack.org/icehouse/config-reference/content/section_compute-scheduler.html there is a concept of filters between the instance allocation request and the host. From the doc:
ServerGroupAffinityFilter ensures that an instance is scheduled on to a host from a set of group hosts. To take advantage of this filter, the requester must create a server group with an affinity policy, and pass a scheduler hint, using group as the key and the server group UUID as the value. Using the nova command-line tool, use the --hint flag. For example:
$ nova server-group-create --policy affinity group-1 $ nova boot --image IMAGE_ID --flavor 1 --hint group=SERVER_GROUP_UUID server-1
The page also documents the "Host aggregates", it lists a required nova.conf to set scheduler_default_filters to contain AggregateInstanceExtraSpecsFilter . But I guess you guys have seen that already :(
If CI starts to cause troubles to other projects on labs, we will have to look at dedicated hardware for it. There is not much need for such a feature right now, so lowest priority and stalled.
I'm not sure what it would help. In general when there are resource issues it's not with virt capacity but with other things that are cloud-wide.