Open Stack

On 11/21/2016 03:36 PM, Zane Bitter wrote:
> On 18/11/16 16:56, Clint Byrum wrote:
>> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>>> 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,
> 
> (Roughly one third, according to the user survey.) We have a mechanism
> to resolve that though (defcore), and I'm confident that that will
> happen in due course. I'm less confident that we have any mechanism for
> resolving these other questions.
> 
> Perhaps we could use defcore-required Tempest tests to drive alignment
> on some of those too. But we'd have to decide what we want to align on
> first.
> 
>> and b)
>> you already have provider templates to deal with the inconsistencies
>> across clouds.
> 
> Indeed, and environment files and conditionals as well.
> 
>> 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
> 
> Oh, great! I knew it had been on the agenda for a while but I didn't
> know if it had actually happened or not, so I had a quick glance at
> http://docs.openstack.org/infra/shade/model.html and there was no mention.

Yah - the model documentation is new, and we're going through resource
by resource to make sure we've published exactly what attributes of what
resources we can commit to making sure are there, and which ones may or
may not be there based on underlying cloud differences.

>> 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.
> 
> I'd prefer that we treat Neutron as a way to construct a consistent set
> of abstractions that users can rely on to construct what they need,
> rather than a way to expose the implementation decisions of the operator
> to the user.
> 
> (Ditto for all OpenStack projects, actually.)

ZOMG yes.

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