On Thu, Nov 21, 2013 at 12:18 PM, Zane Bitter <zbit...@redhat.com> wrote: > On 20/11/13 23:49, Christopher Armstrong wrote:
>> https://wiki.openstack.org/wiki/Heat/AutoScaling#LBMember.3F >> >> Basically, the LoadBalancerMember resource (which is very similar to the >> CinderVolumeAttachment) would be responsible for removing and adding IPs >> from/to the load balancer (which is actually a direct mapping to the way >> the various LB APIs work). Since this resource lives with the server >> resource inside the scaling unit, we don't really need to get anything >> _out_ of that stack, only pass _in_ the load balancer ID. > > > I see a couple of problems with this approach: > > 1) It makes the default case hard. There's no way to just specify a server > and hook it up to a load balancer like you can at the moment. Instead, you > _have_ to create a template (or template snippet - not really any better) to > add this extra resource in, even for what should be the most basic, default > case (scale servers behind a load balancer). First, the design we had implied that we had a template all the time. Now that changed, it does make things a bit harder than the LoadBalancerNames list, but it's still fairly simple to me, and brings a lot of flexibility. Personally, my idea was to build a generic API, and then build helpers on top of it to make common cases easier. It seems it's not a shared view, but I don't see how we can do both at once. > 2) It relies on a plugin being present for any type of thing you might want > to notify. > > At summit and - to the best of my recollection - before, we talked about > scaling a generic group of resources and passing notifications to a generic > controller, with the types of both defined by the user. I was expecting you > to propose something based on webhooks, which is why I was surprised not to > see anything about it in the API. (I'm not prejudging that that is the way > to go... I'm actually wondering if Marconi has a role to play here.) We definitely talked about notifications between resources. But, putting it in the way of the autoscaling API would postpone things quite a bit, whereas we don't really need it for the first phase. If we use the member concept, we can provide a first integration step, where the only missing thing would be rolling updates. -- Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
