Open Stack

On 11/18/2016 04:56 PM, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>> On 17/11/16 19:01, Monty Taylor wrote:
>>> On 11/17/2016 05:24 PM, Zane Bitter wrote:
>>>> On 15/11/16 09:56, Monty Taylor wrote:
>>>>> Hey everybody!
>>>>>
>>>>> At this past OpenStack Summit the results of the Interop Challenge were
>>>>> shown on stage. It was pretty awesome - 17 different people from 17
>>>>> different clouds ran the same workload. And it worked!
>>>>>
>>>>> However, one of the reasons it worked is because they all used the
>>>>> Ansible modules we wrote that are based on the shade library that
>>>>> contains the business logic needed to hide vendor differences in clouds.
>>>>> That means that there IS a fantastic OpenStack interoperability story -
>>>>> but only if you program in Python. That's less awesome.
>>>>
>>>> So I don't want to criticise this effort, because I'm sure that it's
>>>> very valuable and worthy &c.
>>>>
>>>> But it does make me sad that we've so thoroughly given up on the concept
>>>> of making the OpenStack APIs themselves interoperable that we're
>>>> building an API for our APIs (Yo dawg!) to work around it.
>>>
>>> Tell me about it. I share your sadness. In fact, that sadness has been
>>> my main state for several years now.
>>>
>>>> The problem is that to take advantage of the interoperability benefits
>>>> you'll be locked in to a single orchestration tool (Ansible/shade). If
>>>> you have a particular reason to use another tool (possibly, ahem, the
>>>> one that is an official part of OpenStack and already available in 2/3
>>>> of OpenStack clouds... but also Puppet, JuJu, &c.) then you'll have to
>>>> choose between whatever feature you wanted there and interoperability.
>>>> That's taking "there IS a fantastic OpenStack interoperability story -
>>>> but only if you program in Python" and kicking the can one step down the
>>>> road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
>>>> underlying APIs then *everyone* benefits.
>>>
>>> I seem to have communicated something very poorly if that's the take
>>> away you've gotten. Today, if you want cross-cloud interop, you pretty
>>> much need to use shade/ansible. That's not cool - because it's limiting
>>> to people wanting to work in python and people wanting to orchestrate in
>>> ansible. It should absolutely not be necessary to want to use those
>>> tools to get the interop story.
>>>
>>> So one of the main reasons to do this is precisely to provide that story
>>> to everyone - whether they're doing Juju and go, or puppet and ruby, or
>>> just programming in Fog or whatnot.
>>
>> So, say that I want to create my servers in Heat so that I can use Heat 
>> software deployments for orchestration. How would I go about e.g. making 
>> sure that the servers are always connected to the networks I expect on a 
>> variety of different clouds? Would Oaktree figure out the networks and 
>> pass them in to the stack when creating it? (I don't believe shade has 
>> Heat support yet, but we should definitely add it & I don't foresee any 
>> great obstacle.) Or would Heat have to add Oaktree resource types?
>>
> 
> If you're wanting to use Heat, you are a) already cutting off a large
> quantity of interoperable clouds because many do not have Heat, and b)
> you already have provider templates to deal with the inconsistencies
> across clouds.
> 
> And Shade has had Heat support in some for or another for a long time:
> 
> 9922cfbb        (Monty Taylor   2015-12-03 18:12:32 -0500 32)import heatclient.client

Yah - we have the heat support. That said - so far shade is not in the
business of modifying your heat templates. (and I think we should likely
stay out of that business)

> To answer your other question, I don't think that's actually desirable or
> realistic for interop expectations. If networking were one-size-fits-all
> we wouldn't even need Neutron (we had a one-size-fits-all solution, it was
> nova-network). We have Neutron so you can construct what you need inside
> the cloud. Shade just normalizes the "how do I get to the instances from
> outside the cloud" part, which has several different variants.
>
>> It sounds to me like the former approach would require all of the same 
>> work in the template that you'd need to handle it now (using 
>> conditionals), and the only real difference is that instead of providing 
>> your own environment file for each cloud you do a bit of oaktree 
>> integration and that figures it out for you instead.
>>
>> Adding Oaktree resource types to Heat to paper over isn't really a 
>> solution from my point of view.
>>
> 
> Agreed, Heat, to me, sits behind Oaktree and Shade, not in front of it.
> Mostly just to avoid needing to grok Keystone and all of its glory.

Well - I think at some point in the future we can/should revisit this,
but I agree that right now it's not a thing that should be on heat's
radar. If oaktree installations became at least as common as heat
installations, then one could imagine heat oaktree resources that one
would right so that a heat template would not have to have any 'here are
the different ways networks work' logic in them. It presupposes MANY
things before that makes sense though, and I think would be
cart-before-the-horse in a large way.

Which is to say - I agree ... for now. I could see a future where I
disagree, and also see a future where I continue to agree, and we'll
just have to see. :)