Hi Salvatore,<div><br></div><div>Per yesterday's meeting it was decided that we'll rework patches to adopt haproxy-on-the-host approach, rather than on VM.</div><div>It's temporary and much simplified solution just to make things work for grizzly.</div>
<div>Therefore there's no point in reviewing and trying those patches.</div><div><br></div><div>Thanks,</div><div>Eugene.<br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 12:51 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eugene,<br>
<br>
Thanks for putting this together.<br>
Even if sidelined by other work items, I am assisting Mark and Dan in<br>
the process of reviewing the various LBaaS patches.<br>
<br>
Some comments inline.<br>
<br>
Regards,<br>
Salvatore<br>
<div class="im"><br>
On 19 February 2013 06:15, Trinath Somanchi <<a href="mailto:trinath.somanchi@gmail.com">trinath.somanchi@gmail.com</a>> wrote:<br>
> Hi -<br>
><br>
> Very much excited for the help on testing of LBaaS.<br>
><br>
> Can you guide me/the enthusiasts on how to test the LBaaS, and Which code<br>
> base to download. Because I find, more branches about LBaaS.<br>
<br>
</div>There are several patches on gerrit, as we decided to split them to<br>
simplify review.<br>
You should use all of them. LBaaS API support, as well as the CLI, is<br>
instead already merged in master branches (quantum and<br>
python-quantumclient)<br>
<div class="im"><br>
><br>
> I Have the folsom code installed with me. Can any one guide me on how to<br>
> integrate and test LBaaS in the folsom setup I have.<br>
<br>
</div>You'll have to run code from master, and cherry-pick onto it the LBaaS<br>
patches from gerrit.<br>
<div class="im"><br>
><br>
> Please help me integrate the LBaaS into the folsom installation.<br>
<br>
</div>I don't think you can - at least we haven't tried (and probably we<br>
won't, unless LBaaS goes into the backport roadmap).<br>
<div class="im"><br>
><br>
> thanks in advance.<br>
><br>
><br>
><br>
><br>
> On Tue, Feb 19, 2013 at 12:45 AM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> Hi Dan, Mark, folks,<br>
>><br>
>> I know you have been working on reviewing and testing of LBaaS patches and<br>
>> run into several problems preventing the service to provide complete<br>
>> solution.<br>
>> We're currently putting all our efforts into integration testing. Please<br>
>> find the updated instruction on how to setup/run the service:<br>
>><br>
>> Let me step through the list of problems that Dan has identified:<br>
>> 1. Strict key checking.<br>
>> By default ssh and scp use strict key checking, so once host fingerprint<br>
>> is changed for the known host, ssh/scp switch into interactive mode and ask<br>
>> if it is ok.<br>
>> We've fixed it via ssh/scp option that disables strict key checking.<br>
<br>
</div>During yesterday's meeting, and on gerrit as well, I was told that the<br>
requirement for SSH (and hence also the paramiko dependency) were<br>
going, and were being replaced by a RPC mechanism similar to Quantum's<br>
DHCP/L3 agents.<br>
Is this information incorrect?<br>
<div class="im"><br>
>><br>
>> 2. "VM getting deleted, but then lbaas code not realizing it was deleted"<br>
>> There was I bug in the code, which incorrectly updated device status in<br>
>> case of error and didn't delete it from DB.<br>
>> We've fixed it.<br>
>><br>
<br>
</div>This is good. Another thing I was not sure is whether we're keeping<br>
isolated VMs or running haproxy in isolated namespaces instead. It<br>
seems we're keeping the VMs approach. Do we still have a fixed pool of<br>
VMs?<br>
<div class="im"><br>
>> 3. File permissions on key file<br>
>> Key file is used in ssh/scp that are being run with "sudo ip netns exec<br>
>> <ns> ssh -i keyfile_path ..."<br>
>> I guess ssh/scp are getting sudo priviledges in this case, so I wonder,<br>
>> what issues could be experienced here.<br>
>><br>
>> 4. Keypair injection not working<br>
>> We also has hit this issue several times without stable repro, e.g.<br>
>> sometimes it worked and sometimes it didn't.<br>
>> Currently it's our primary concern, which however could be solved by<br>
>> injecting keys into the image manually.<br>
>><br>
>> As an alternative we tried to use pexpect library to access VM via<br>
>> login/password in pseudo-interactive mode but later decided that using key<br>
>> pairs is a more reliable way to access VM.<br>
>><br>
>> 5. Security groups<br>
>> As far as I uderstood the concern - it's possible that security group that<br>
>> agent is using to access balancer VM could prohibit icmp packets that we use<br>
>> for liveliness check.<br>
>> So it was changed to netcat making probe on 22 port.<br>
>><br>
>> Latest code with all these fixes was just posted on review (HAProxy<br>
>> driver) <a href="https://review.openstack.org/#/c/20985/" target="_blank">https://review.openstack.org/#/c/20985/</a><br>
<br>
</div>This is true if the management traffic between agents/load balancer<br>
VMs goes over tenant network.<br>
Ideally I would avoid this situation in the first place, but this is<br>
probably cumbersome with the VM approach.<br>
Looking for a probe on port 22 will tell you if the port is closed or<br>
not. What would be the behaviour is the port is unreachable?<br>
<br>
The 'default' security group, which is applied to every single VMs,<br>
regardless of the nature of the network, does not allow SSH traffic.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
>><br>
>> Thanks,<br>
>> Eugene.<br>
>><br>
>> _______________________________________________<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" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Regards,<br>
> ----------------------------------------------<br>
> Trinath Somanchi,<br>
> +91 9866 235 130<br>
><br>
> _______________________________________________<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" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<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" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>