Open Stack

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

Yes, exactly.

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 
auto-scaling".
>
>
> 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 
possible:

* Should end users _have_ to use Heat?
  - No.

* Should private cloud operators _have_ to deploy Heat for end-user access?
  - No.

* Should public cloud operators _have_ to deploy Heat for end-user access?
  - No, unless the Foundation makes this a requirement for some sort of 
Trademark program.

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

cheers,
Zane.