Open Stack

No I am not stating that, what I am saying is that for infr services that are provisioned via Openstack you do not need to have another API and another system to deal with that. I believe Openstack has a good enough Framework for folks to build their own logic for auto-scaling an infrastructure service that si deployed and managed via Openstack and that auto-scaling of a given infra service does NOT need to go through HEAT. I do see a lot of value and sue in Heat for when "applications" that are provisioned through say a PaaS layer on top of Openstack can definitely use HEAT API to do orchestration/auto-scaling etc through that API. 

My point is you don’t need to build "yet another component" in Openstack to do something like auto-scaling and "mandate that this API" must be used to auto-scale for a given service. Lets be honest here, we need to provide a good framework and have sufficient input (notifications/triggering etc) provided by OS, but NOT state then auto-scale is done through HEAT for openstack infra inherest services like LB, that is ......well not very sensible. Of course I cant stop people from doing that, but most people will not use it!

BR
Alan

-----Original Message-----
From: Zane Bitter [mailto:zbitter at redhat.com] 
Sent: April-05-13 5:23 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Rackspace Plans Contributions to HEAT

On 04/04/13 17:43, Alan Kavanagh wrote:
> Adrian
>
> I can see understand your point but we need to separate the case for 
> Auto-Scaling into two cases as follows: (1) for Network Services that 
> are inherent and part of the Openstack IaaS system (for example LB) 
> and
> (2) for application that sit on top and can be provisioned through the 
> HEAT API for example (this I can see as a good use of HEAT).
>
> For the Auto-Scale system yes I believe we have the same view here, 
> where we want a simple system and NOT multiple control systems, that 
> makes sense and something I would want to see and build. The Central 
> Control makes sense as a good starting point, my big gripe is whether 
> we need to call the HEAT API to provision a service that is inherent 
> as a network service type offered in OS, that to me does not have good logic.
> So that’s where I feel I can bring some good fruit to the table for 
> discussion as want we definitely do not want to do is have cross 
> dependencies on how to auto-scale some services like the LB by having 
> to call HEAT.

You appear to be under the impression that there exists a standalone autoscaling API in OpenStack and that we plan to tightly integrate it with Heat (which is still not an acronym, BTW).

This is the exact opposite of reality.

- ZB

>
> The “Policy Engine” is where most folks will build and customise their 
> own to endorse specific feature and SLA sets.
>
> Alan
>
> *From:*Adrian Otto [mailto:adrian.otto at rackspace.com]
> *Sent:* April-04-13 1:38 AM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] Rackspace Plans Contributions to HEAT
>
> Alan,
>
> We want a useful Auto-Scale solution in Openstack, and recognize that 
> Heat has some capability already that could be leveraged. Whether 
> Auto-Scale is offered as a standalone service, by Heat, or (more 
> likely) a combination of both is open for discussion. Duncan's team is 
> focused exclusively on Auto-Scale, whereas our second team is 
> concerned with the first three focus areas I mentioned. So I will look 
> to Duncan to gather input from you on Auto-Scale.
>
> My take:
>
>
> Auto-scale is a control system. I believe that control systems should 
> be simple, and well coordinated. We should be careful not to end up 
> with multiple different control systems scattered about, especially in 
> a complex system like ours where the controls may actually conflict 
> with each other. Possible solutions include using centralized control, 
> or perhaps well coordinated federated control. Central control is 
> simpler, so I prefer that as a starting point. We could iterate toward 
> something more elaborate as needed.
>
> The central control point may be what you referred to as a "policy 
> engine" and could live in an "Auto-Scale Service" or it could be a 
> feature of Heat. Regardless, we can leverage Heat for workflows  like 
> Adding and Removing Nova instances (recursively, or from an external 
> control point) rather than calling those services directly. Such 
> workflows will typically involve interacting with multiple service APIs.
> Resist the temptation to bypass Heat in the case of following a 
> workflow. We can make Heat really good for handling that stuff.
>
> Adrian Otto
>
>
> On Apr 3, 2013, at 8:20 PM, "Alan Kavanagh" 
> <alan.kavanagh at ericsson.com <mailto:alan.kavanagh at ericsson.com>> wrote:
>
>     This is good news I have to say. Though I have some questions that
>     got me irked in reading bullet 4 below on Auto-Scale so im going to
>     throw this out for discussion.
>
>     Are we now stating that the HEAT will take care of Auto-Scaling of
>     all Openstack Services? If you consider network services managed and
>     deployed under Quantum, and if you have Ceilometer collecting event
>     notifications then some given “policy engine” would know when to
>     call Quantum & || Nova + etc to provision additional resources as
>     needed, you do not need to go through HEAT for this. I do see cases
>     where an application that is deployed via HEAT would make sense, but
>     for services that are inherent and part of the Infrastructure such
>     as LB or FW etc I do not see what HEAT would need to handle the
>     scaling for these services?
>
>     Agree that Event Trigger and Notification Events must be added to LB
>     in order for this to Scale accordingly, I am sure this will come
>     soon ;-) in the LBaaS API.
>
>     BR
>
>     Alan
>
>     *From:*Duncan Mcgreggor [mailto:duncan.mcgreggor at RACKSPACE.COM]
>     *Sent:* April-02-13 7:04 PM
>     *To:* OpenStack Development Mailing List
>     *Subject:* Re: [openstack-dev] Rackspace Plans Contributions to 
> HEAT
>
>     On 4/2/13 3:47 PM, Adrian Otto wrote:
>
>         Hello,
>
>         Rackspace has resourced two dedicated development teams for the
>         sole purpose of contributing new features and capabilities to
>         OpenStack's HEAT project. We are very excited, and would like to
>         share with you what we plan to design and contribute together
>         with you:
>
>         *1) Open API & DSL *- This allows templates to be agnostic to
>         the underlying cloud and encourages community contribution for
>         the betterment of all users across all cloud providers. We want
>         a solution that does not depend on semantics from any single
>         service provider. We think there is a way for HEAT to work
>         equally well with CloudFormation templates, and a completely
>         open template format as well.
>
>         *2) Declarative Model* - Although CloudFormation Templates were
>         designed to be declarative, in practice the templates are very
>         imperative artifacts (for example, those that embed shell
>         scripts). Templates that are expressed using a declarative
>         approach are compact, simple, and portable between clouds that
>         have different services available. We want the cloud
>         implementation specific details to be handled by modules, not
>         wired into the templates. Declarative modeling encourages broad
>         contribution from the user base to improve the overall community
>         library of available solutions. While modeling may be easy to
>         implement, they are more difficult to expand to support generic
>         cloud portable use cases.
>
>         *3) Modular Implementation* - We want HEAT to be modular in a
>         way that's consistent with the level of modularity offered in
>         Nova, Quantum, Cinder and others where a common, extendable API
>         is offered and a variety of extensions may be added for various
>         back-end services and features. We want to keep the architecture
>         as simple as possible while allowing individual cloud operators
>         to add features and capabilities in a way that keeps templates
>         crisp and portable.
>
>         *4) Auto-Scale Implementation* - The solution will allow
>         deployments to scale up and down dynamically based on demand. We
>         want to design and implement this with you. We have considerable
>         experience and resources to bring with us. We have a dedicated
>         team to contribute solutions here.
>
>     Just to clarify the autoscale bit: we are well aware that there is
>     currently autoscale support in Heat right now, and there's no intent
>     (nor desire!) to reimplement any of that, nor throw anything over
>     the wall ;-)
>
>     We had some great chats at PyCon with some folks about Heat and are
>     really looking forward to ODS to dive in more deeply and get to know
>     the current status, project priorities, etc. We've been lurking on
>     IRC and started attending the weekly meetings recently.
>
>     There does seem to be some missing integration for monitoring and
>     LBaaS (no surprises there for anyone, as that is all currently under
>     active development), and this is where we want to focus our initial
>     efforts. Well, here as well as advocating for consensus around an
>     autoscale API suitable for consumption by
>     integrators/devops/application devs/etc. We've created a blueprint
>     in LP and proposed a session for discussing some of these things
>     (focused on defining where folks think we are with regard to an AS
>     API and where we want to go with that).
>
>     I've got a blog post pending with some more thoughts about this, and
>     that should be up soon. I'll reply with a link when it has been
>     published...
>
>     d
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev