<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
p.p1, li.p1, div.p1
{mso-style-name:p1;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-CA" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Adrian<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The “Policy Engine” is where most folks will build and customise their own to endorse specific feature and SLA sets.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Alan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Adrian Otto [mailto:adrian.otto@rackspace.com]
<br>
<b>Sent:</b> April-04-13 1:38 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] Rackspace Plans Contributions to HEAT<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Alan,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<br>
<br>
My take:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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.<o:p></o:p></p>
<div>
<p class="MsoNormal">Adrian Otto<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Apr 3, 2013, at 8:20 PM, "Alan Kavanagh" <<a href="mailto:alan.kavanagh@ericsson.com">alan.kavanagh@ericsson.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">BR</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Alan</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Duncan Mcgreggor [<a href="mailto:duncan.mcgreggor@RACKSPACE.COM">mailto:duncan.mcgreggor@RACKSPACE.COM</a>]
<br>
<b>Sent:</b> April-02-13 7:04 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] Rackspace Plans Contributions to HEAT</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On 4/2/13 3:47 PM, Adrian Otto wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Hello,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<div>
<p class="p1"><strong>1) Open API & DSL </strong>- 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.<o:p></o:p></p>
<p class="p1"><strong>2) Declarative Model</strong> - 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. <o:p></o:p></p>
<p class="p1"><strong>3) Modular Implementation</strong> - 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.<o:p></o:p></p>
<p class="p1"><strong>4) Auto-Scale Implementation</strong> - 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.<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal">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 ;-)<br>
<br>
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.<br>
<br>
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).<br>
<br>
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...<br>
<br>
d<o:p></o:p></p>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="color:windowtext">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
</body>
</html>