[openstack-dev] Rackspace Plans Contributions to HEAT
Zane Bitter
zbitter at redhat.com
Fri Apr 5 20:20:43 UTC 2013
On 05/04/13 17:51, Alan Kavanagh wrote:
> 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
OK, let me explain what I'm talking about here, because I have literally
no idea whatsoever what you are talking about.
Autoscaling is a service that spins up and down identical Nova instances
in response to events, which may be triggered by metrics.
Period.
Heat (which is not an acronym) supports an Autoscaling resource type
now. This is cool in that it exists, but lame in that it means that a
user has to use Heat in order to take advantage of autoscaling. As I
said earlier in the thread:
> there's obvious value in having an API for autoscaling that can be used even by users that aren't using Heat templates. It seems to me that the logical course of action would be to start by splitting out the existing code in Heat into a separate service, making sure the interface between the two is clean, and turning that into an API.
Hence my confusion about your objection to the close coupling of
autoscaling and Heat, since the content of the proposal you are so
"irked" about was, in fact, to decouple them. Now, you _appear_ to be
saying that you want to write your own autoscaling service, and that you
think every other OpenStack user should have to as well. On the face of
it, this is insane. I'm going to assume that we must be talking about
completely different things.
Here is my best guess as to what has happened:
- Despite your comments that you are approaching the issue as "an
openstack consumer and user", you are in fact looking at it from the
perspective of an OpenStack cloud operator.
- You took a vague but harmless comment that actually referred to the
fact that Heat doesn't yet support a LoadBalancer resource that talks to
the LBaaS API (because that API doesn't exist yet!), and wrongly
interpreted it as meaning that the LBaaS API would have a hard
dependency on Heat.
- This led to various non sequiturs about scaling of Load Balancers,
shouting, &c.
Now, I happen to disagree 100% with your position on this, and for much
the same reasons as others in the thread have. The LBaaS will no doubt
(like most OpenStack APIs) support pluggable backends, since many
operators will have e.g. hardware load balancers they need to control.
If there is a backend that depends on spinning up Nova instances then to
my mind the obvious way to implement that is by calling either Heat or
an autoscaling service that has split out of Heat. There is no value in
reimplementing that code just for the sake of it. Heat is now an
official OpenStack project, and as such it makes perfect sense for other
OpenStack projects to have dependencies on it.
That's not really the important part, though. The important point is
that what you appear to be complaining about has no relationship to
anything anybody is actually suggesting.
cheers,
Zane.
>
> -----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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list