Open Stack

Hi Salvatore,

Per yesterday's meeting it was decided that we'll rework patches to adopt
haproxy-on-the-host approach, rather than on VM.
It's temporary and much simplified solution just to make things work for
grizzly.
Therefore there's no point in reviewing and trying those patches.

Thanks,
Eugene.

On Tue, Feb 19, 2013 at 12:51 PM, Salvatore Orlando <sorlando at nicira.com>wrote:

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