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 127.0.0.1, >>>>> 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. > 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? -Devananda __________________________________________________________________________ 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