Open Stack

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

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).

>
>>> That seems almost easier than building a bunch of ansible scripts that
>>> appear (at a glance) to do similar things; and u get the benefit of
>>> using a actual programming language vs a
>>> half-programming-ansible-yaml-language...
>>>
>>> A realization I'm having is that I'm really not a fan of using ansible
>>> as a half-programming-ansible-yaml-language, which it seems like people
>>> start to try to do after a while (because at some point you need
>>> something like if statements, then things like [1] get created), no
>>> offense to the authors, but I guess this is my personal preference (it's
>>> also one of the reasons taskflow directly is a lib. in python, because
>>> <meh>, people don't need to learn a new language).
>>>
>>
>> We use python in Ansible all the time:
>>
>> http://git.openstack.org/cgit/openstack/bifrost/tree/playbooks/library
>>
>> The reason to use Ansible is that it has already implemented all of
>> the idempotency and error handling and UI needs that one might need for
>> running workflows.
>>
>> I've tried multiple times to understand taskflow, and to me, Ansible is
>> the anti-taskflow. It's easy to pick up, easy to read the workflows,
>> doesn't require deep surgery on your code to use (just execute
>> ansible-playbook), and is full of modules to support nearly anything
>> your deployment may need.
>
> Actually they are pretty similar (to a degree), taskflow is pretty much
> the same/similar thing ansible is using internally, a graph structure
> (last time I checked) that gets ran in parallel or in serial using a
> executor concept[1].
>
> Said surgery is only required if you want a deep integration, nothing is
> stopping folks from using taskflow in the same manner as running a bunch
> of task == similar to ansible style (taskflow also doesn't need to have
> its own module concepts as pypi modules primarily just work because it's
> python).
>
> But ya, anyway... can't win over everyone ;)
>
> [1] https://github.com/ansible/ansible/tree/devel/lib/ansible/executor
>
>>
>> __________________________________________________________________________
>>
>> 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