Open Stack

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.

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

- ZB

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