Open Stack

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