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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
