Re: [openstack-dev] [Heat][Summit] Input wanted - real world heat spec

2014-04-24 Thread Chris Armstrong
On April 23, 2014 at 7:47:37 PM, Robert Collins 
(robe...@robertcollins.net) wrote:
Hi, we've got this summit session planned -
http://summit.openstack.org/cfp/details/428 which is really about
https://etherpad.openstack.org/p/heat-workflow-vs-convergence

We'd love feedback and questions - this is a significant amount of
work, but work I (and many others based on responses so far) believe
it is needed to really take Heat to users and ops teams.

Right now we're looking for both high and low level design and input.

One thing I’m curious about is whether we would gain benefit from explicitly 
managing resources as state machines. I’m not very familiar with TaskFlow, but 
my impression is that it basically knows how to run a defined workflow through 
multiple steps until completion. Heat resources will, with this change, become 
objects that need to react to inputs at any point in time, so I wonder if it’s 
better to model them as a finite state machine instead of just with workflows.

Granted, I’m pretty unfamiliar with TaskFlow, so I may be off the mark here. I 
would like to point out that a new very simple but concise FSM-modeling library 
was recently released called “Machinist”, and it may be worth taking a look at: 
https://github.com/hybridcluster/machinist

--

--
Christopher Armstrong
IRC: radix


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


Re: [openstack-dev] [heat][neutron] OS::Heat::AutoScalingGroup and OS::Neutron::PoolMember?

2014-03-12 Thread Chris Armstrong
Hi Kevin,

The design of OS::Heat::AutoScalingGroup should not require explicit support 
for load balancers. The design is meant to allow you to create a resource that 
wraps up both a OS::Heat::Server and a PoolMember in a template and use it via 
a Stack resource.

(Note that Mike was talking about the new OS::Heat::AutoScalingGroup resource, 
not AWS::AutoScaling::AutoScalingGroup).

So, while I haven’t tested this case with PoolMember specifically, and there 
may still be bugs, no more feature implementation should be necessary (I hope).

--
Christopher Armstrong
IRC: radix



On March 12, 2014 at 1:52:53 PM, Fox, Kevin M 
(kevin@pnnl.gov) wrote:

I submitted a blueprint a while back that I think is relevant:

https://blueprints.launchpad.net/heat/+spec/elasticloadbalancing-lbaas

Currently heat autoscaling doesn't interact with Neutron lbaas and the 
configurable bits aren't configurable enough to allow it without code changes 
as far as I can tell.

I think its only a few days of work, but the OpenStack CLA is preventing me 
from contributing. :/

Thanks,
Kevin


From: Mike Spreitzer [mspre...@us.ibm.com]
Sent: Wednesday, March 12, 2014 11:34 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [heat][neutron] OS::Heat::AutoScalingGroup and 
OS::Neutron::PoolMember?

Has anybody exercised the case of OS::Heat::AutoScalingGroup scaling a nested 
stack that includes a OS::Neutron::PoolMember?  Should I expect this to work?

Thanks,
Mike
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev