<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 5:18 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 20/11/13 23:49, Christopher Armstrong wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Wed, Nov 20, 2013 at 2:07 PM, Zane Bitter <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a><br></div><div class="im">
<mailto:<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>>> wrote:<br>
<br>
On 20/11/13 16:07, Christopher Armstrong wrote:<br>
<br>
On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a><br>
<mailto:<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>><br></div><div class="im">
<mailto:<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a> <mailto:<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>>>> wrote:<br>
<br>
On 19/11/13 19:14, Christopher Armstrong wrote:<br>
<br></div><div class="im">
thought we had a workable solution with the "LoadBalancerMember"<br>
idea,<br>
which you would use in a way somewhat similar to<br>
CinderVolumeAttachment<br>
in the above example, to hook servers up to load balancers.<br>
<br>
<br>
I haven't seen this proposal at all. Do you have a link? How does it<br>
handle the problem of wanting to notify an arbitrary service (i.e.<br>
not necessarily a load balancer)?<br>
<br>
<br>
It's been described in the autoscaling wiki page for a while, and I<br>
thought the LBMember idea was discussed at the summit, but I wasn't<br>
there to verify that :)<br>
<br>
<a href="https://wiki.openstack.org/wiki/Heat/AutoScaling#LBMember.3F" target="_blank">https://wiki.openstack.org/<u></u>wiki/Heat/AutoScaling#<u></u>LBMember.3F</a><br>
<br>
Basically, the LoadBalancerMember resource (which is very similar to the<br>
CinderVolumeAttachment) would be responsible for removing and adding IPs<br>
from/to the load balancer (which is actually a direct mapping to the way<br>
the various LB APIs work). Since this resource lives with the server<br>
resource inside the scaling unit, we don't really need to get anything<br>
_out_ of that stack, only pass _in_ the load balancer ID.<br>
</div></blockquote>
<br>
I see a couple of problems with this approach:<br>
<br>
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).<br>
</blockquote><div><br></div><div>We can provide a standard resource/template for this, LoadBalancedServer, to make the common case trivial and only require the user to pass parameters, not a whole template.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) It relies on a plugin being present for any type of thing you might want to notify.</blockquote><div><br></div><div>I don't understand this point. What do you mean by a plugin? I was assuming OS::Neutron::PoolMember (not LoadBalancerMember -- I went and looked up the actual name) would become a standard Heat resource, not a third-party thing (though third parties could provide their own through the usual heat extension mechanisms).</div>
<div><br></div><div>(fwiw the rackspace load balancer API works identically, so it seems a pretty standard design).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.)<div class="HOEnZb">
<div class="h5"><br></div></div></blockquote><div><br></div><div>I think the main benefit of PoolMember is:</div><div><br></div><div>1) it matches with the Neutron LBaaS API perfectly, just like all the rest of our resources, which represent individual REST objects. </div>
<div> </div><div>2) it's already understandable. I don't understand the idea behind notifications or how they would work to solve our problems. You can keep saying that the notifications idea will solve our problems, but I can't figure out how it would solve our problem unless someone actually explains it :)</div>
<div><br></div></div><div><br></div>-- <br><div dir="ltr"><div>IRC: radix</div>Christopher Armstrong<div>Rackspace</div></div>
</div></div>