Open Stack

Jim Rollenhagen wrote:
>>>>>>> 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
>> 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) 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).
>
> So, I've been thinking about this quite a bit. We've also talked about
> doing a v2 API (as evil as that may be) in Ironic here and there. We've
> had lots of lessons learned from the v1 API, mostly that our API is
> absolutely terrible for humans. I'd love to fix that (whether that
> requires a v2 API or not is unclear, so don't focus on that).
>
> I've noticed that people keep talking about the Nova driver API
> not being public/stable/whatever in this thread - let's ignore that and
> think bigger.
>
> So, there's two large use cases for ironic that we support today:
>
> * Ironic as a backend to nova. Operators still need to interact with the
>    Ironic API for management, troubleshooting, and fixing issues that
>    computers do not handle today.
>
> * Ironic standalone - by this I mean ironic without nova. The primary
>    deployment method here is using Bifrost, and I also call it the
>    "better than cobbler" case. I'm not sure if people are using this
>    without bifrost, or with other non-nova services, today. Users in this
>    model, as I understand things, do not interact with the Ironic API
>    directly (except maybe for troubleshooting).
>
> There's other use cases I would like to support:
>
> * Ironic standalone, without Bifrost. I would love for a deployer to be
>    able to stand up Ironic as an end-user facing API, probably with
>    Keystone, maybe with Neutron/Glance/Swift if needed. This would
>    require a ton of discussion and work (e.g. ironic has no concept of
>    tenants/projects today, we might want a scheduler, a concept of an
>    instance, etc) and would be a very long road. The ideal solution to
>    this is to break out the Compute API and scheduler to be separate from
>    Nova, but that's an even longer road, so let's pretend I didn't say
>    that and not devolve this thread into that conversation (yet).
>

That'd be nice, that is more of what I was thinking when I think of 
'standalone' in that it's standalone from the aspect of not needing to 
go through another compute layer [nova] to get to the bottom compute 
layer [ironic], whereas bifrost (from my small understanding of it) also 
discards the rest of the openstack services (and therefore also 
discarding the non-zero amount of functionality they provide).

> * Ironic as a backend to other things. Josh pointed out kubernetes
>    somewhere, I'd love to be an official backend there. Heat today goes
>    through Nova to get an ironic instance, it seems reasonable to have
>    heat talk directly to ironic. Things like that. The amount of work
>    here might depend on the application using ironic (e.g. I think k8s
>    has it's own scheduler, heat does not, right?).

Correct, I'm a big fan of this, and I think openstack as a community 
needs more of it... We as a community IMHO need to embrace and be best 
buddies (pick other word here) with other projects that are outside of 
openstack that are in what I would call the 'cloud family' because it's 
not one vs the other, or us vs them, but I view it more as a melding of 
all of them into a 'cloud stew' that really offers and provides (and 
ensures?) the sustainable future for all projects in this 
big-ole-cloud-family.

For example, let's take a theoretical thing and play with it...

The nova-scheduler work that's been ongoing for a while; now let's say 
theoretically that we explored using mesos here and found that well it 
works and the community there is willing (and able) to help make it be 
the thing that does scheduling for our community. <now what?> If we take 
the path of well jeez a community in the 'cloud family' wants to help 
and we can both benefit, well that sounds like a win win, does it mean 
we may have to make a set of compromises in our community, sure it does, 
may this piss some people off, probably, but is it/could it be a overall 
big win, likely...

I'm pretty sure said theoretical things can be played out over and over 
with various other groups/communities, but I've never heard of them 
being theorized and really discussed (honestly a whole topic can be why, 
what went wrong when we tried, how can we do better, did we just not do 
outreach or did we piss people off or ... idk).

>
> So all that said, I think there is one big step we can take in the
> short-term that works for all of these use cases: make our API better.
> Make it simpler. Take a bunch of the logic in the Nova driver, and put
> it in our API instead. spawn() becomes /v1/nodes/foo/deploy or
> something, etc (I won't let us bikeshed those specifics in this thread).
> Just doing that allows us to remove a bunch of code from a number of
> places (nova, bifrost, shade, tempest(?)) and make those simpler. It
> allows direct API users to more easily deploy things, making one API
> call instead of a bunch (we could even create Neutron ports and such for
> them). It allows k8s and friends to write less code. Oh, let's also stop
> directly exposing state machine transitions as API actions, that's
> crazy, kthx.
>
> I think this is what Josh is trying to get at, except maybe with a
> separate API service in between, which doesn't sound very desirable to
> me.
>
> Thoughts on this?
>
> Additionally, in the somewhat-short term, I'd like us to try to
> enumerate the major use cases we're trying to solve, and make those use
> cases ridiculously simple to deploy. Ironic is quickly becoming a
> tangled mess of configuration options and tweaking surrounding services
> (nova, neutron) to deploy it. Once it's figured out, it works very well.
> However, it's incredibly difficult to figure out how to get there.
>
> Ultimately, I'd like someone that wants to deploy ironic in a common use
> case, with off-the-shelf hardware, to be able to get a POC up and
> running in a matter of hours, not days or weeks.

Sounds super.

>
> Who's in? :)
>
> // jim
>
> __________________________________________________________________________
> 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