Open Stack

On Jun 13, 2013, at 11:58 AM, Thomas Hervé <th at rackspace.com<mailto:th at rackspace.com>>
 wrote:



On Thu, Jun 13, 2013 at 2:44 AM, Angus Salkeld <asalkeld at redhat.com<mailto:asalkeld at redhat.com>> wrote:
On 12/06/13 22:42 +0000, Randall Burt wrote:

On Jun 12, 2013, at 5:06 PM, Christopher Armstrong <chris.armstrong at rackspace.com<mailto:chris.armstrong at rackspace.com><mailto:chris.armstrong at rackspace.com<mailto:chris.armstrong at rackspace.com>>>

wrote:

I believe the consensus is that the work on the new HOT format and underlying design changes is a prerequisite for the autoscaling work that Thomas and I are to do, so we'll definitely help with that. I'll let someone with a better understanding chime in about that.

I would like to have some more details around that dependency as well. Is there something specific we should be focused on around HOT that would facilitate easier Otter->Heat AS transition?


Seems odd that AS is dependant on the template format. I would have
thought that you could just make a native resource type for the new
autoscaler and we could start using it, then migrating the AWS style
one over too. I agree the AWS autoscaling resource might not be able to
make full use of the awesomeness of our new one but that's ok.

It's not about making it dependent on the template format, but rather making independent of any template. Right now resources and stack are pretty tied together, and I'm hoping the new DSL will separate things up a bit. Otter doesn't have a template system but drives resources directly via the API, and I think it'll be easier to see if it's possible once we move away from CFN, if it makes sense. We're still evaluating how that will work, though.

I'm not sure how we'd separate resources and stacks, or if it even makes sense to. The stack describes the relationships between resources and provides the essential framework around orchestration. Even today you can query a stack's resources. There certainly is a little work to do around exposing attributes/properties better there, but that's not a template thing.

WRT autoscale, it makes sense to me that the eventual goal would be to able to:

1. Via my template, define autoscale thresholds that kick off stack-updates. The template simply provides a mechanism to declare how I want to integrate autoscale with my infrastructure, no different that what we do for nova, swift, etc.

2. Use it independently of any template and provide my own thresholds and scaling rules via api calls and leverage my own custom scripts/images/orchestration logic.

Neither of these seem to have direct impact on the template structure other than any delta between today's scaling group's properties and attributes and what it will look like tomorrow.

--
THomas

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130613/67cd6e7b/attachment.html>