[openstack-dev] Rackspace Plans Contributions to HEAT
zbitter at redhat.com
Mon Apr 8 16:53:39 UTC 2013
On 08/04/13 15:14, Alan Kavanagh wrote:
> Well then I guess we have very different methods how to address auto-scaling.....precluding that Heat will be the defacto I guess you have your views which are orthogonal to mine. My main point I thought was clear. I see you are set on using Heat and that is fine for specific scenarios, perhaps some white boarding session in Portland might progress the discussion as I think based on your response and from me digging into Heat and Cloudformation if a user deploys apps outside of Heat then a standalone way to do autoscaling is imperative.
I totally agree, which is why I wrote:
>> there's obvious value in having an API for autoscaling that can be used even by users that aren't using Heat templates.
What I *don't* see value in is writing an autoscaling API from scratch
when we have an existing service that works, but is coupled too tightly
into Heat. This is why I am in favour of decoupling the existing
implementation rather than writing a new implementation. That is,
however, a detail of the development process that should be irrelevant
to both operators and end users.
> Similarly, for services that are not provisioned through Heat you would do the autoscale independently (at least that's what makes sense imho).
In AWS, Autoscaling is a separate API. OpenStack is missing an
equivalent API, so when we wrote Heat we fudged it by implementing
autoscaling internally. Now that we have working code, it's time to make
this service available to non-Heat-users by splitting it out and making
it independent of Heat.
As far as I can tell, we're in violent agreement. I don't see anything
here to suggest that "we have very different methods how to address
> I do have one question though, do you then see that all applications provisioned and configured via Openstack must use Heat as it seemed yes from your response below?
No, absolutely not. Heat is one way of communicating with OpenStack
APIs. Horizon is another. The ReST API is another. Saying "you must use
Heat to access OpenStack" doesn't make any more sense than "you must use
Horizon to access OpenStack"... neither of those is on anybody's agenda.
There are multiple groups of stakeholders here, so to be as clear as
* Should end users _have_ to use Heat?
* Should private cloud operators _have_ to deploy Heat for end-user access?
* Should public cloud operators _have_ to deploy Heat for end-user access?
- No, unless the Foundation makes this a requirement for some sort of
* Should cloud operators _have_ to deploy Heat internally for managing
other OpenStack services (e.g. LBaaS)?
- Maybe, for some non-core services. It may make sense for plugins
that manage orchestration of other core services to use Heat to do it
rather than rolling their own orchestration.
The last item is the only one we disagree on. In my opinion,
orchestration is non-trivial, and since we have an OpenStack service for
doing it we are better off adding a dependency on it rather than a
less-well-tested reimplementation. There was a DBaaS project around a
while back that started with a complete clone of Nova because it needed
to create VMs... that kind of thing is just not maintainable (that
particular example has since been fixed). We are blessed with a great
community, but any resources used to maintain multiple implementations
of the same thing would be wasted resources.
> I guess I am trying to find out the simplest system to build to support such a service like auto-scale. We can talk face to face in Portland as this email thread is not progressing, face to face I believe will be simpler.
> P.s. I am supportive of Heat, I am just trying to still figure out to how this will make sense for our given deployments, so far I am still on the fence!
That's great, and we're not trying to force you. If there's a way that
Heat can provide more value to you, then let us know.
More information about the OpenStack-dev