[openstack-dev] [ironic] using ironic as a replacement for existing datacenter baremetal provisioning

Andrew Laski andrew at lascii.com
Tue Jun 7 19:24:53 UTC 2016

On Tue, Jun 7, 2016, at 02:34 PM, Joshua Harlow wrote:
> Devananda van der Veen wrote:
> > On 06/07/2016 09:55 AM, Joshua Harlow wrote:
> >> Joshua Harlow wrote:
> >>> Clint Byrum wrote:
> >>>> Excerpts from Joshua Harlow's message of 2016-06-07 08:46:28 -0700:
> >>>>> Clint Byrum wrote:
> >>>>>> Excerpts from Kris G. Lindgren's message of 2016-06-06 20:44:26 +0000:
> >>>>>>> Hi ironic folks,
> >>>>>>> As I'm trying to explore how GoDaddy can use ironic I've created
> >>>>>>> the following in an attempt to document some of my concerns, and
> >>>>>>> I'm wondering if you folks could help myself identity ongoing work
> >>>>>>> to solve these (or alternatives?)
> >>>>>> Hi Kris. I've been using Ironic in various forms for a while, and I can
> >>>>>> answer a few of these things.
> >>>>>>
> >>>>>>> List of concerns with ironic:
> >>>>>>>
> >>>>>>> 1.)Nova<->  ironic interactions are generally seem terrible?
> >>>>>> I don't know if I'd call it terrible, but there's friction. Things that
> >>>>>> are unchangable on hardware are just software configs in vms (like mac
> >>>>>> addresses, overlays, etc), and things that make no sense in VMs are
> >>>>>> pretty standard on servers (trunked vlans, bonding, etc).
> >>>>>>
> >>>>>> One way we've gotten around it is by using Ironic standalone via
> >>>>>> Bifrost[1]. This deploys Ironic in wide open auth mode on,
> >>>>>> and includes playbooks to build config drives and deploy images in a
> >>>>>> fairly rudimentary way without Nova.
> >>>>>>
> >>>>>> I call this the "better than Cobbler" way of getting a toe into the
> >>>>>> Ironic waters.
> >>>>>>
> >>>>>> [1] https://github.com/openstack/bifrost
> >>>>> Out of curiosity, why ansible vs turning
> >>>>> https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py
> >>>>> (or something like it) into a tiny-wsgi-app (pick useful name here) that
> >>>>> has its own REST api (that looks pretty similar to the public functions
> >>>>> in that driver file)?
> >>>> That's an interesting idea. I think a reason Bifrost doesn't just import
> >>>> nova virt drivers is that they're likely _not_ a supported public API
> >>>> (despite not having _'s at the front). Also, a lot of the reason Bifrost
> >>>> exists is to enable users to get the benefits of all the baremetal
> >>>> abstraction work done in Ironic without having to fully embrace all of
> >>>> OpenStack's core. So while you could get a little bit of the stuff from
> >>>> nova (like config drive building), you'd still need to handle network
> >>>> address assignment, image management, etc. etc., and pretty soon you
> >>>> start having to run a tiny glance and a tiny neutron. The Bifrost way
> >>>> is the opposite: I just want a tiny Ironic, and _nothing_ else.
> >>>>
> >>> Ya, I'm just thinking that at a certain point
> >
> > You've got two statements in here, which I'm going to reply to separately:
> >
> >> Oops forgot to fill this out, was just thinking that at a certain point it might
> >> be easier to figure out how to extract that API (meh, if its public or private)
> >
> > The nova-core team has repeatedly stated that they do not have plans to support
> > the nova virt driver API as a stable or externally-consumable python API.
> > Changing that would affect a lot more than Ironic (eg. defcore). A change like
> > that is not just about what is easier for developers, but also what is better
> > for the community.
> >
> Right, I'm starting to come to the belief that what is better for the 
> community is to change this; because from what I can tell (from my view 
> of the world) that tying all the things to nova has really been 
> detrimental (to a degree) to the whole progression of the cloud as a
> whole.

When I have heard the statement made about the virt driver API it has
simply been that it is not stable and there are no plans at this point
to make it stable. My own opinion is that it is sometimes painful to use
from within Nova and I do not wish to expose that pain to others. There
are changes I would like to see made before it could be considered
externally consumable.

> It's an opinionated thing to say, yes I understand that, but there 
> becomes a point where I feel we need to re-evaluate what people really 
> care about from openstack (because I start to believe that treating the 
> whole thing as a single product, well that went out the window a long 
> time ago, with the creation of the big-tent by the TC, with the creation 
> of mesos, k8s and others by other companies not in openstack...); and 
> really what's left after that is a bunch of services that to survive (as 
> a useful set of services) must accept that there is more than just 
> openstack in the wider world (ie, kubernetes, mesos, 
> the-next-best-thing...) and if we don't start embracing those other 
> communities (and no that doesn't mean be an `integration engine` on-top 
> or around them) then we are pretty much obsoleting ourselves.
> Ya, I know this is a hot (and touchy) topic, and probably other people 
> don't agree, that's ok... I don't mind the flames, ha (mmmm spicy).
> >> and just have someone make an executive decision around ironic being a
> >> stand-alone thing or not (and a capable stand-alone thing, not a
> >> sorta-standalone-thing).
> >
> > We already decided to support Ironic as a stand-alone service. So, could you
> > clarify what you mean when you call it a "sorta-standalone-thing"? In what ways
> > do you think it's *not* functional? Do you have specific recommendations on what
> > we can improve, based on experience using either Ironic or Bifrost?
> I'll work on this list, as some folks that are trying start to try to 
> connect ironic (IMHO without nova, because well kubernetes is enough 
> like nova that there isn't a need for 2-layers of nova-like-systems at 
> that point) into kubernetes as a 'resource provider'. I'm sure 
> attempting to do that will expose a bunch of specific recommendations 
> soon enough.
> >
> >
> > -Devananda
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list