[openstack-dev] [Quantum][LBaaS] Test run of LBaaS service
Trinath Somanchi
trinath.somanchi at gmail.com
Tue Feb 19 09:13:55 UTC 2013
Hi Salvatore -
Thanks for the reply.
With respect to your comment,
>
> 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).
I mean to say about the integration, i think the current code is developed
from Folsom code base as a basic start point,
So I feel I can integrate the LBaaS code base into Quantum Folsom code base.
Though you haven't tried the same, can you give me some inputs for a trial
run on the same, for this integration to be successful.
Also,
>
> 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.
Can you kindly please guide me on how to download the same,
I tried this way,
root at NewFolsomController:~/lbaas# git pull
https://review.openstack.org/openstack/quantum refs/changes/79/20579/13
fatal: Not a git repository (or any of the parent directories): .git
Is there any procedure to pull/chect-out the code base.
Kindly help me in this regard.
Thanks in advance.
-
Trinath
On Tue, Feb 19, 2013 at 2:21 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
>
--
Regards,
----------------------------------------------
Trinath Somanchi,
+91 9866 235 130
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130219/f5cfd45a/attachment.html>
More information about the OpenStack-dev
mailing list