On Wed, Apr 06, 2016 at 06:33:06PM +0300, Igor Belikov wrote: > Hey Stackers, > > In Fuel we use bare metal testing for deployment tests. This is essentially a > core component of Fuel CI and as much as we like having it around we’d rather > spend time and resources integrating with upstream instead of growing and > polishing third-party testing solutions. > > On one of the previous Infra team meetings we discussed the possibility of > bringing testing on bare metal nodes to openstack-infra[1]. This is not a new > topic, similar question was brought up by Magnum some time ago[2] and there > might other times this was discussed. We use bare metal testing for Fuel, I > assume that Magnum still wants to use it, TripleO would probably also fit in > the picture in some way (though I’m not familiar with current scheme of > TripleO CI) - hope this is enough to consider implementation of generic way > to use baremetal nodes in CI. > > The most obvious way to do this seems to be using existing OpenStack service > for bare metal provisioning - Ironic. Ironic fits pretty well in existing > Infra workflow, Ironic usage (in form of Rackspace's OnMetal) was previously > discussed in Magnum thread[2] with the main technical issue being inability > to use custom glance images to boot instances. AFAIK the situation didn't > change much with OnMetal, but Ironic perfectly supports booting from glance > images created by diskimage-builder - which is exactly the way Nodepool > currently works for virtual machines. > > With the work currently going on InfraCloud there's a possibility to properly > design and implement bare metal testing, Zuul v3 spec[3] also brings a number > of relevant changes to Nodepool. So, summing up some points of possible > implementation: > * Multiple pools of bare metal nodes under Ironic management are available as > a part of InfraCloud > * Ironic acts as an additional hypervisor for Nova, providing the ability to > use bare metal nodes by booting an instance with a specific flavor > * Nodepool manages booting bare metal instances using the images generated > with diskimage-builder and stored in Glance > * Nodepool also manages redeployment of bare metal nodes - redeploying a > glance image on a bare metal node takes only a few minutes, but time may > depend on a set of cleaning steps used to redeploy a node > * Bare metal instances are exposed to Jenkins (or a different worker in case > of Zuul v3) by Nodepool > > I suppose there are security issues when we talk about running custom code on > bare metal slaves, but I'm not sure I understand the difference from running > custom code on a virtual machine if bare metal nodes are isolated, don't > contain any sensitive data and follow a regular redeployment procedure. > > I'd like to add that we're ready to start donating hardware from the Fuel CI > pool (2 pools in different locations, to be accurate) to see this initiative > taking off. > > Please, share your thoughts and opinions. > Personally, I don't see this happening in the short term. Currently infracloud is down (moving data centers) and zuulv3 still has work that needs to be completed. While baremetal is a nice to have, I don't see us using infracloud to do this right now. At our recent -infra midcycle, we talked about not wanting infracloud become a dominate cloud for nodepool. Meaning, we'd be bringing it up and down at specific intervals for tasks like upgrading to the current release.
I agree that zuulv3 has a lot of potential (and super excited to see it come online) but we also need to work on ansible playbooks to make all this happen. TL;DR I see bare metal happing someday, not sure 2016 is in the cards. My personal opinion. [4] http://docs.openstack.org/infra/system-config/infra-cloud.html > [1]http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-29-19.03.log.html > [2]http://lists.openstack.org/pipermail/openstack-infra/2015-September/003138.html > [3]http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html > -- > Igor Belikov > Fuel CI Engineer > ibeli...@mirantis.com > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
