We know we want to do Ironic but it is a probable longer term goal. For now we are pursuing limited but reusable integration of hardware into labs for end users.
Someday we should adopt the openstack 'Ironic' project to support allocation of bare-metal servers for internal projects. I know that analytics would love to have this option, and there are plenty of other test scenarios where this would save a lot of time dickering over hardware allocation and permissions.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Andrew | T95185 PoC bare-metal server allocation in labs -- bootstrap mode | |||
| Resolved | • chasemp | T118588 Get Ops bare metal test server | |||
| Resolved | Andrew | T120262 setup promethium in eqiad in support of T95185 | |||
| Resolved | Dzahn | T164395 (don't) decom promethium | |||
| Declined | Andrew | T121237 Create labs baremetal subnet? |
An alternative to this would be to provide hardware that's:
^ Would probably be far simpler to get off the ground than Ironic, but will have to be weighted against the fact that it's somewhat duct-tapey hand-rolled solution.
Problems to be solved:
Some big projects (video and mwoffliner, at least) on labs are using NFS simply because they need to deal with datasets a bit too large to fit onto instance storage. provisioning simple machines might be a good alternative here.
If the problem is instance storage, AFAIUI the current sizes are arbitrary and in addition, extra storage volumes can be added manually to individual instances (and existing ones resized?; cf. http://docs.openstack.org/openstack-ops/content/user_facing_block_storage.html).
So IMHO that path should be explored first unless the virtualization swallows so much performance that there is a user-visible significant difference.
However, for projects using Labs as a beta test before moving to production, a bare metal sandbox would certainly be interesting.
I'm going to test this with real hardware, and we can come up with an allocation process for it later.
Things to do to make it know it is labs:
Then puppet should do the rest.
the original request says: " would save a lot of time dickering over hardware allocation"
one of the follow-ups is immediately 'How will allocation work? Do we have a pool that rotates?"
that may be interpreted as a contradiction a bit
Another question relevant to services like Revscoring (T106867) is access from production to these semi-production services. Currently, the labs network is not accessible from production, and we might not want to open up all of labs. A separate vlan for semi-production services could potentially provide better isolation.
mwoffliner as it currently is is a good test case, I think. I've poked Kelson on IRC and will update.
Change 257663 had a related patch set uploaded (by Cmjohnson):
Adding dhcp entry for promethium bug: task T95185
Change 257805 had a related patch set uploaded (by Andrew Bogott):
Allow access to the labs puppetmaster from labs metal hosts.
Change 257805 merged by Andrew Bogott:
Allow access to the labs puppetmaster from labs metal hosts.
Change 258051 had a related patch set uploaded (by Andrew Bogott):
Allow hiera to override $::labsproject