<div dir="ltr">help</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 8:00 PM, <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<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>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: SQLAlchemy-migrate needs a new maintainer (Thomas Goirand)<br>
2. [Openstack] Improve inject network configuration (Jae Sang Lee)<br>
3. Re: AMQP Version upgrade plans? (Russell Bryant)<br>
4. Re: Revert Pass instance host-id to Quantum using port<br>
bindings extension. (Andre Pech)<br>
5. Re: [Openstack] Improve inject network configuration<br>
(Russell Bryant)<br>
6. Re: SQLAlchemy-migrate needs a new maintainer (Jeremy Stanley)<br>
7. Re: SQLAlchemy-migrate needs a new maintainer (Monty Taylor)<br>
8. Re: Revert Pass instance host-id to Quantum using port<br>
bindings extension. (Kyle Mestery (kmestery))<br>
9. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Gareth)<br>
10. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Monty Taylor)<br>
11. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Monty Taylor)<br>
12. Re: SQLAlchemy-migrate needs a new maintainer (Boris Pavlovic)<br>
13. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Gareth)<br>
14. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Gareth)<br>
15. Re: [Openstack] Improve inject network configuration (Brian Lamar)<br>
16. Re: Revert Pass instance host-id to Quantum using port<br>
bindings extension. (Sumit Naiksatam)<br>
17. [Savanna] Savanna meeting minutes (Sergey Lukjanov)<br>
18. [Neutron] please review LBaaS agent scheduling (Oleg Bondarev)<br>
19. Re: Bug #1194026 (Nachi Ueno)<br>
20. Re: SQLAlchemy-migrate needs a new maintainer (Thierry Carrez)<br>
21. Nova service(s) prolem when using Mysql behind HAProxy<br>
(Chu Duc Minh)<br>
22. Re: [Openstack] Improve inject network configuration<br>
(Thierry Carrez)<br>
23. Re: [nova] volume affinity filter for nova scheduler<br>
(Robert Collins)<br>
24. Re: [Openstack] Improve inject network configuration<br>
(Robert Collins)<br>
25. Re: [Savanna-all] installation problem (Ruslan Kamaldinov)<br>
26. Re: [Neutron] Campus Network Blueprint (Zang MingJie)<br>
27. Re: [Savanna-all] installation problem (Ruslan Kamaldinov)<br>
28. Re: [TripleO] mid-cycle sprint? (Ghe Rivero)<br>
29. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Sean Dague)<br>
30. Re: SQLAlchemy-migrate needs a new maintainer (Sean Dague)<br>
31. Re: SQLAlchemy-migrate needs a new maintainer (Boris Pavlovic)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 12 Jul 2013 08:01:58 +0800<br>
From: Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:51DF4776.4040806@debian.org">51DF4776.4040806@debian.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 07/12/2013 07:29 AM, Monty Taylor wrote:<br>
> We've got the upstream pypi and rtfd credentials now, the project should<br>
> be moved in to openstack systems soon enough. I also went through and<br>
> cleaned up build and test stuff work work like our stuff works (if we're<br>
> going to be maintaining it, we might as well, you know, do it how we do<br>
> things)<br>
<br>
Cool! You definitively rox my friend.<br>
<br>
You might as well want to apply Fedora's patch (thanks to P?draig Brady)<br>
for SQLAlchemy 0.8:<br>
<a href="http://pkgs.fedoraproject.org/cgit/python-migrate.git/commit/?id=603ed1d1" target="_blank">http://pkgs.fedoraproject.org/cgit/python-migrate.git/commit/?id=603ed1d1</a><br>
<br>
which was the reason I started the discussion with Jan Dittberner. Jan<br>
wrote to me that there's more to >= 0.8 compat than just this patch, but<br>
I had not time to dig it through.<br>
<br>
Thomas<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 12 Jul 2013 09:53:31 +0900<br>
From: Jae Sang Lee <<a href="mailto:hyangii@gmail.com">hyangii@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [Openstack] Improve inject network<br>
configuration<br>
Message-ID:<br>
<<a href="mailto:CAKrFU7XGPHjj7HMAJuC_fkN26KS048bf41eiaJqbovG1Kibv5g@mail.gmail.com">CAKrFU7XGPHjj7HMAJuC_fkN26KS048bf41eiaJqbovG1Kibv5g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi, stackers.<br>
<br>
When creating vm using multi nics, User should power up the second<br>
interface on the instance manually for use second IP.<br>
<a href="http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html" target="_blank">http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html</a><br>
<br>
I intend to fix interfaces.template file, so It can be possible power up<br>
other interface during booting time automatically.<br>
<br>
I registered blueprint for this a month ago.(<br>
<a href="https://blueprints.launchpad.net/nova/+spec/better-network-injection" target="_blank">https://blueprints.launchpad.net/nova/+spec/better-network-injection</a>) But<br>
not yet approved.<br>
<br>
If you have permission to approve who read this mail, please approve my<br>
blueprint.<br>
<br>
<br>
Thanks.<br>
<br>
Jay Lee<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/0dab57f3/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/0dab57f3/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 11 Jul 2013 21:19:13 -0400<br>
From: Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] AMQP Version upgrade plans?<br>
Message-ID: <<a href="mailto:51DF5991.7000907@redhat.com">51DF5991.7000907@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 07/11/2013 12:06 PM, William Henry wrote:<br>
><br>
><br>
> ----- Original Message -----<br>
>> On 07/08/2013 10:51 AM, Ted Ross wrote:<br>
>>> If someone from the Qpid community were to work on integrating the new<br>
>>> AMQP 1.0 technology into OpenStack, where would be the right place to<br>
>>> start? Would it be to add a new transport to oslo.messaging?<br>
>><br>
>> I think so, yes. oslo.messaging is new, but it will deprecate the<br>
>> existing 'rpc' library in oslo-incubator. All projects will need to<br>
>> move to oslo.messaging, so for something new I would focus efforts there.<br>
><br>
> I think that one of the important points that Ted brought up is that AMQP 1.0 doesn't have the concepts of broker artifacts like exchanges etc.<br>
><br>
> A recent change I proposed to the existing impl_qpid.py which focuses more on addressing and not exchanges is a very important first step to solve several issues: a recent qpidd leak issue, transitioning to AMQP 1.0 (addressing), and possible HA solutions.<br>
><br>
> This is an area I'd really like to continue to help out in. I'm back from some vacation and would like to get stuck in soon.<br>
<br>
Regarding the qpid exchange leak, that issue is mitigated largely by the<br>
fact that the only time we declare a direct exchange is for replies to<br>
an rpc. In previous versions there was a new one of these for *every*<br>
method call, which made this problem really bad. In the current code,<br>
we only create a single one.<br>
<br>
However, we're still left with a leak. The fact that RabbitMQ supports<br>
auto-delete on exchanges and Qpid doesn't is what got us into this spot,<br>
since this code works just like the kombu driver with respect to all of<br>
this.<br>
<br>
As for migration to AMQP 1.0, how do these changes help? Supporting<br>
AMQP 1.0 requires an entirely new driver that uses Qpid Proton, right?<br>
How does changing addressing in the current Qpid driver (that will never<br>
do 1.0) help?<br>
<br>
I'm curious what you mean by "possible HA solutions". Can you elaborate?<br>
<br>
--<br>
Russell Bryant<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 11 Jul 2013 18:44:47 -0700<br>
From: Andre Pech <<a href="mailto:apech@aristanetworks.com">apech@aristanetworks.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Revert Pass instance host-id to Quantum<br>
using port bindings extension.<br>
Message-ID:<br>
<<a href="mailto:CAOWPBV49OxJ5OPFavPnv05rWjEB8RWPyE%2B2ctHCYz-Bn5DcLbQ@mail.gmail.com">CAOWPBV49OxJ5OPFavPnv05rWjEB8RWPyE+2ctHCYz-Bn5DcLbQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hey Aaron,<br>
<br>
As an interested party in the change, figured I'd take a stab at<br>
responding. I've talked with people at BigSwitch and Cisco about this<br>
change, so I know others are interested in this as well, but I'll let them<br>
give their perspective.<br>
<br>
At a high level, our goal at Arista is similar to what you mention. We want<br>
to integrate the provisioning of the physical network within Neutron in<br>
conjunction with the virtual network. We have no interest in controlling<br>
the virtual switch layer, and so we'd like to do this in a way that does<br>
not tie us to any particular virtual switching technology (should work just<br>
as well with OVS, LinuxBridge, or whatever future virtual switch technology<br>
a customer may choose to use). And it needs the chance to be "inline" - the<br>
provisioning of the physical network has to happen alongside the virtual<br>
network, so that failures to provision the physical network can be<br>
propogated to the user in the same way as a failure to set up the virtual<br>
network.<br>
<br>
The thing I like most about the current solution is that it's event-driven.<br>
There's no polling of the information out of band from nova (I'm not sure<br>
how accepted it would be to poll this info directly from neutron, which<br>
would then force you to do it from an outside system). It also doesn't<br>
require any coordination with agents running on the compute side (in line<br>
with the goal of working across multiple virtual switching technologies).<br>
<br>
I'd be really happy with another solution, but I'd be great to see those<br>
properties preserved. I have reservations about the alternatives you're<br>
proposing. Happy to hop on a call with other interested parties to come up<br>
with a better middleground that allows you to do the simplification you're<br>
proposing while still giving Neutron an explicit hook to learn about the<br>
host a VM was placed on.<br>
<br>
Andre<br>
<br>
<br>
On Thu, Jul 11, 2013 at 1:30 PM, Aaron Rosen <<a href="mailto:arosen@nicira.com">arosen@nicira.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> I think we should revert this patch that was added here (<br>
> <a href="https://review.openstack.org/#/c/29767/" target="_blank">https://review.openstack.org/#/c/29767/</a>). What this patch does is when<br>
> nova-compute calls into quantum to create the port it passes in the<br>
> hostname on which the instance was booted on. The idea of the patch was<br>
> that providing this information would "allow hardware device vendors<br>
> management stations to allow them to segment the network in a more precise<br>
> manager (for example automatically trunk the vlan on the physical switch<br>
> port connected to the compute node on which the vm instance was started)."<br>
><br>
> In my opinion I don't think this is the right approach. There are several<br>
> other ways to get this information of where a specific port lives. For<br>
> example, in the OVS plugin case the agent running on the nova-compute node<br>
> can update the port in quantum to provide this information. Alternatively,<br>
> quantum could query nova using the port.device_id to determine which server<br>
> the instance is on.<br>
><br>
> My motivation for removing this code is I now have the free cycles to work<br>
> on<br>
> <a href="https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port" target="_blank">https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port</a> discussed here (<br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html</a>)<br>
> . This was about moving the quantum port creation from the nova-compute<br>
> host to nova-api if a network-uuid is passed in. This will allow us to<br>
> remove all the quantum logic from the nova-compute nodes and<br>
> simplify orchestration.<br>
><br>
> Thoughts?<br>
><br>
> Best,<br>
><br>
> Aaron<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/c1cc5592/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/c1cc5592/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 11 Jul 2013 21:49:12 -0400<br>
From: Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Openstack] Improve inject network<br>
configuration<br>
Message-ID: <<a href="mailto:51DF6098.7010208@redhat.com">51DF6098.7010208@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 07/11/2013 08:53 PM, Jae Sang Lee wrote:<br>
> Hi, stackers.<br>
><br>
> When creating vm using multi nics, User should power up the second<br>
> interface on the instance manually for use second IP.<br>
> <a href="http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html" target="_blank">http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html</a><br>
><br>
> I intend to fix interfaces.template file, so It can be possible power up<br>
> other interface during booting time automatically.<br>
><br>
> I registered blueprint for this a month<br>
> ago.(<a href="https://blueprints.launchpad.net/nova/+spec/better-network-injection" target="_blank">https://blueprints.launchpad.net/nova/+spec/better-network-injection</a>)<br>
> But not yet approved.<br>
><br>
> If you have permission to approve who read this mail, please approve my<br>
> blueprint.<br>
<br>
Honestly, I think network injection is evil and I'd rather remove it<br>
completely. I'm certainly not too interested in trying to add more<br>
features to it.<br>
<br>
--<br>
Russell Bryant<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Fri, 12 Jul 2013 02:05:43 +0000<br>
From: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:20130712020542.GZ1472@yuggoth.org">20130712020542.GZ1472@yuggoth.org</a>><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
On 2013-07-12 08:01:58 +0800 (+0800), Thomas Goirand wrote:<br>
[...]<br>
> You might as well want to apply Fedora's patch (thanks to P?draig Brady)<br>
> for SQLAlchemy 0.8:<br>
> <a href="http://pkgs.fedoraproject.org/cgit/python-migrate.git/commit/?id=603ed1d1" target="_blank">http://pkgs.fedoraproject.org/cgit/python-migrate.git/commit/?id=603ed1d1</a><br>
><br>
> which was the reason I started the discussion with Jan Dittberner.<br>
[...]<br>
<br>
At this point any of you can simply propose it as a code review<br>
change to the stackforge/sqlalchemy-migrate project. Also, if anyone<br>
wants to volunteer as initial members of sqlalchemy-migrate-core...<br>
--<br>
Jeremy Stanley<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Thu, 11 Jul 2013 22:08:02 -0400<br>
From: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:51DF6502.6000103@inaugust.com">51DF6502.6000103@inaugust.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
<br>
On 07/11/2013 08:01 PM, Thomas Goirand wrote:<br>
> On 07/12/2013 07:29 AM, Monty Taylor wrote:<br>
>> We've got the upstream pypi and rtfd credentials now, the project should<br>
>> be moved in to openstack systems soon enough. I also went through and<br>
>> cleaned up build and test stuff work work like our stuff works (if we're<br>
>> going to be maintaining it, we might as well, you know, do it how we do<br>
>> things)<br>
><br>
> Cool! You definitively rox my friend.<br>
><br>
> You might as well want to apply Fedora's patch (thanks to P?draig Brady)<br>
> for SQLAlchemy 0.8:<br>
> <a href="http://pkgs.fedoraproject.org/cgit/python-migrate.git/commit/?id=603ed1d1" target="_blank">http://pkgs.fedoraproject.org/cgit/python-migrate.git/commit/?id=603ed1d1</a><br>
><br>
> which was the reason I started the discussion with Jan Dittberner. Jan<br>
> wrote to me that there's more to >= 0.8 compat than just this patch, but<br>
> I had not time to dig it through.<br>
<br>
Done.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Fri, 12 Jul 2013 02:27:34 +0000<br>
From: "Kyle Mestery (kmestery)" <<a href="mailto:kmestery@cisco.com">kmestery@cisco.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Revert Pass instance host-id to Quantum<br>
using port bindings extension.<br>
Message-ID:<br>
<<a href="mailto:CC6516285E165D48ACB2CF4D9266006C218DB7DB@xmb-aln-x05.cisco.com">CC6516285E165D48ACB2CF4D9266006C218DB7DB@xmb-aln-x05.cisco.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
I agree with Andre's concerns around the implications of polling in what Aaron is proposing, and in fact, this is one reason the existing change is so nice. The ML2 sub-team talked about this at a recent meeting, and we liked the approach which Yong had taken with the patch. But as Andre says, we're all for working to simplify things, keeping the goals he mentioned in mind.<br>
<br>
What are your thoughts Aaron?<br>
<br>
Thanks,<br>
Kyle<br>
<br>
On Jul 11, 2013, at 8:44 PM, Andre Pech <<a href="mailto:apech@aristanetworks.com">apech@aristanetworks.com</a>> wrote:<br>
<br>
> Hey Aaron,<br>
><br>
> As an interested party in the change, figured I'd take a stab at responding. I've talked with people at BigSwitch and Cisco about this change, so I know others are interested in this as well, but I'll let them give their perspective.<br>
><br>
> At a high level, our goal at Arista is similar to what you mention. We want to integrate the provisioning of the physical network within Neutron in conjunction with the virtual network. We have no interest in controlling the virtual switch layer, and so we'd like to do this in a way that does not tie us to any particular virtual switching technology (should work just as well with OVS, LinuxBridge, or whatever future virtual switch technology a customer may choose to use). And it needs the chance to be "inline" - the provisioning of the physical network has to happen alongside the virtual network, so that failures to provision the physical network can be propogated to the user in the same way as a failure to set up the virtual network.<br>
><br>
> The thing I like most about the current solution is that it's event-driven. There's no polling of the information out of band from nova (I'm not sure how accepted it would be to poll this info directly from neutron, which would then force you to do it from an outside system). It also doesn't require any coordination with agents running on the compute side (in line with the goal of working across multiple virtual switching technologies).<br>
><br>
> I'd be really happy with another solution, but I'd be great to see those properties preserved. I have reservations about the alternatives you're proposing. Happy to hop on a call with other interested parties to come up with a better middleground that allows you to do the simplification you're proposing while still giving Neutron an explicit hook to learn about the host a VM was placed on.<br>
><br>
> Andre<br>
><br>
><br>
> On Thu, Jul 11, 2013 at 1:30 PM, Aaron Rosen <<a href="mailto:arosen@nicira.com">arosen@nicira.com</a>> wrote:<br>
> Hi,<br>
><br>
> I think we should revert this patch that was added here (<a href="https://review.openstack.org/#/c/29767/" target="_blank">https://review.openstack.org/#/c/29767/</a>). What this patch does is when nova-compute calls into quantum to create the port it passes in the hostname on which the instance was booted on. The idea of the patch was that providing this information would "allow hardware device vendors management stations to allow them to segment the network in a more precise manager (for example automatically trunk the vlan on the physical switch port connected to the compute node on which the vm instance was started)."<br>
><br>
> In my opinion I don't think this is the right approach. There are several other ways to get this information of where a specific port lives. For example, in the OVS plugin case the agent running on the nova-compute node can update the port in quantum to provide this information. Alternatively, quantum could query nova using the port.device_id to determine which server the instance is on.<br>
><br>
> My motivation for removing this code is I now have the free cycles to work on <a href="https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port" target="_blank">https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port</a> discussed here (<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html</a>) . This was about moving the quantum port creation from the nova-compute host to nova-api if a network-uuid is passed in. This will allow us to remove all the quantum logic from the nova-compute nodes and simplify orchestration.<br>
><br>
> Thoughts?<br>
><br>
> Best,<br>
><br>
> Aaron<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>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Fri, 12 Jul 2013 11:38:01 +0800<br>
From: Gareth <<a href="mailto:academicgareth@gmail.com">academicgareth@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID:<br>
<CAAhuP_-OoFtOALXVbFmbxuKXkP8bkX8hzKAG2OviF=<a href="mailto:XCVZxstg@mail.gmail.com">XCVZxstg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I heard there's a talk about this issue in #openstack-infra last night<br>
(china standard time), what's the conclusion of that?<br>
<br>
BTW, how to find meeting log of #openstack-infra? I didn't find it in<br>
<a href="http://eavesdrop.openstack.org/" target="_blank">http://eavesdrop.openstack.org/</a><br>
<br>
<br>
On Thu, Jul 11, 2013 at 11:35 PM, Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>> wrote:<br>
<br>
> >> See for example <a href="https://bugs.launchpad.net/horizon/+bug/1196823" target="_blank">https://bugs.launchpad.net/horizon/+bug/1196823</a><br>
> > This is arguably a deficiency of mox, which (apparently?) doesn't let us<br>
> mock properties automatically.<br>
><br>
> I agree, but it is just one example. other test-only issues can happen as<br>
> well.<br>
><br>
> Similar problem: the *client packages are not self-contained, they<br>
> have pretty strict dependencies on other packages. One case I already<br>
> run into was a dependency on python-requests: newer python-*client<br>
> packages (rightfully) require requests >= 1.x. running those on a<br>
> system that has OpenStack services from Grizzly or Folsom installed<br>
> cause a conflict: there are one or two that require requests to be <<br>
> 1.0.<br>
><br>
> When you run gating on this scenario, I think the same flipping would<br>
> happen on e.g. requests as well, due to *client or the module being<br>
> installed in varying order.<br>
><br>
> Greetings,<br>
> Dirk<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>
Gareth<br>
<br>
*Cloud Computing, OpenStack, Fitness, Basketball*<br>
*OpenStack contributor*<br>
*Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>*<br>
*My promise: if you find any spelling or grammar mistakes in my email from<br>
Mar 1 2013, notify me *<br>
*and I'll donate $1 or ?1 to an open organization you specify.*<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/eb0636e5/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/eb0636e5/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Thu, 11 Jul 2013 23:42:08 -0400<br>
From: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID: <<a href="mailto:51DF7B10.5030207@inaugust.com">51DF7B10.5030207@inaugust.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
<br>
On 07/11/2013 10:28 AM, Sean Dague wrote:<br>
> On 07/11/2013 09:12 AM, Dirk M?ller wrote:<br>
>>> Let's submit a multi-project bug on launchpad, and be serious for<br>
>>> changing<br>
>>> these global requirements in following days<br>
>><br>
>> <a href="https://bugs.launchpad.net/keystone/+bug/1200214" target="_blank">https://bugs.launchpad.net/keystone/+bug/1200214</a><br>
><br>
> Great!<br>
><br>
> This is the first review we need to land to make progress:<br>
><br>
> <a href="https://review.openstack.org/#/c/36631/" target="_blank">https://review.openstack.org/#/c/36631/</a><br>
<br>
Landed.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Thu, 11 Jul 2013 23:54:31 -0400<br>
From: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID: <<a href="mailto:51DF7DF7.6000503@inaugust.com">51DF7DF7.6000503@inaugust.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
<br>
<br>
On 07/11/2013 11:38 PM, Gareth wrote:<br>
> I heard there's a talk about this issue in #openstack-infra last night<br>
> (china standard time), what's the conclusion of that?<br>
><br>
> BTW, how to find meeting log of #openstack-infra? I didn't find it<br>
> in <a href="http://eavesdrop.openstack.org/" target="_blank">http://eavesdrop.openstack.org/</a><br>
<br>
We don't log it currently. There is a wider conversation going on about<br>
which things we should log and which things we should not log ... but<br>
for the time being I've submitted this:<br>
<br>
<a href="https://review.openstack.org/36773" target="_blank">https://review.openstack.org/36773</a><br>
<br>
to add -infra. I think we talk about enough things that have<br>
ramifications on everyone in there that we should really capture it.<br>
> On Thu, Jul 11, 2013 at 11:35 PM, Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a><br>
> <mailto:<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>>> wrote:<br>
><br>
> >> See for example <a href="https://bugs.launchpad.net/horizon/+bug/1196823" target="_blank">https://bugs.launchpad.net/horizon/+bug/1196823</a><br>
> > This is arguably a deficiency of mox, which (apparently?) doesn't<br>
> let us mock properties automatically.<br>
><br>
> I agree, but it is just one example. other test-only issues can<br>
> happen as well.<br>
><br>
> Similar problem: the *client packages are not self-contained, they<br>
> have pretty strict dependencies on other packages. One case I already<br>
> run into was a dependency on python-requests: newer python-*client<br>
> packages (rightfully) require requests >= 1.x. running those on a<br>
> system that has OpenStack services from Grizzly or Folsom installed<br>
> cause a conflict: there are one or two that require requests to be <<br>
> 1.0.<br>
><br>
> When you run gating on this scenario, I think the same flipping would<br>
> happen on e.g. requests as well, due to *client or the module being<br>
> installed in varying order.<br>
><br>
> Greetings,<br>
> Dirk<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <mailto:<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>
> Gareth<br>
><br>
> /Cloud Computing, OpenStack, Fitness, Basketball/<br>
> /OpenStack contributor/<br>
> /Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>/<br>
> /My promise: if you find any spelling or grammar mistakes in my email<br>
> from Mar 1 2013, notify me /<br>
> /and I'll donate $1 or ?1 to an open organization you specify./<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>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Fri, 12 Jul 2013 08:11:11 +0400<br>
From: Boris Pavlovic <<a href="mailto:boris@pavlovic.ru">boris@pavlovic.ru</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:F06F766D-CE07-419A-8E96-C6CF9EA9C697@pavlovic.ru">F06F766D-CE07-419A-8E96-C6CF9EA9C697@pavlovic.ru</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi all,<br>
<br>
As we should keep sqlalchemy-migrate in openstack, to at least 1 year.<br>
We could take care about it, to avoid tons of monkey patches in oslo:)<br>
<br>
12.07.2013, ? 6:08, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> ???????(?):<br>
<br>
><br>
><br>
> On 07/11/2013 08:01 PM, Thomas Goirand wrote:<br>
>> On 07/12/2013 07:29 AM, Monty Taylor wrote:<br>
>>> We've got the upstream pypi and rtfd credentials now, the project should<br>
>>> be moved in to openstack systems soon enough. I also went through and<br>
>>> cleaned up build and test stuff work work like our stuff works (if we're<br>
>>> going to be maintaining it, we might as well, you know, do it how we do<br>
>>> things)<br>
>><br>
>> Cool! You definitively rox my friend.<br>
>><br>
>> You might as well want to apply Fedora's patch (thanks to P?draig Brady)<br>
>> for SQLAlchemy 0.8:<br>
>> <a href="http://pkgs.fedoraproject.org/cgit/python-migrate.git/commit/?id=603ed1d1" target="_blank">http://pkgs.fedoraproject.org/cgit/python-migrate.git/commit/?id=603ed1d1</a><br>
>><br>
>> which was the reason I started the discussion with Jan Dittberner. Jan<br>
>> wrote to me that there's more to >= 0.8 compat than just this patch, but<br>
>> I had not time to dig it through.<br>
><br>
> Done.<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>
Message: 13<br>
Date: Fri, 12 Jul 2013 12:11:53 +0800<br>
From: Gareth <<a href="mailto:academicgareth@gmail.com">academicgareth@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID:<br>
<CAAhuP_-E629UrffBfsdFgsMy2Y_8ckH=<a href="mailto:CBg-UR09%2Bu0x_i3zZg@mail.gmail.com">CBg-UR09+u0x_i3zZg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thanks, Monty<br>
<br>
but in my review <a href="https://review.openstack.org/#/c/36684/" target="_blank">https://review.openstack.org/#/c/36684/</a> , Doug said we<br>
will go without upper bound with those python-*clients<br>
and in this one <a href="https://review.openstack.org/#/c/36753/" target="_blank">https://review.openstack.org/#/c/36753/</a> , keystoneclient<br>
still keep '<0.4' and requirements test doesn't fail in keystoneclient (<br>
<a href="https://jenkins.openstack.org/job/gate-cinder-requirements/96/console" target="_blank">https://jenkins.openstack.org/job/gate-cinder-requirements/96/console</a> it<br>
failed on glanceclient)<br>
<br>
<br>
<br>
<br>
On Fri, Jul 12, 2013 at 11:54 AM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<br>
<br>
><br>
><br>
> On 07/11/2013 11:38 PM, Gareth wrote:<br>
> > I heard there's a talk about this issue in #openstack-infra last night<br>
> > (china standard time), what's the conclusion of that?<br>
> ><br>
> > BTW, how to find meeting log of #openstack-infra? I didn't find it<br>
> > in <a href="http://eavesdrop.openstack.org/" target="_blank">http://eavesdrop.openstack.org/</a><br>
><br>
> We don't log it currently. There is a wider conversation going on about<br>
> which things we should log and which things we should not log ... but<br>
> for the time being I've submitted this:<br>
><br>
> <a href="https://review.openstack.org/36773" target="_blank">https://review.openstack.org/36773</a><br>
><br>
> to add -infra. I think we talk about enough things that have<br>
> ramifications on everyone in there that we should really capture it.<br>
> > On Thu, Jul 11, 2013 at 11:35 PM, Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a><br>
> > <mailto:<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>>> wrote:<br>
> ><br>
> > >> See for example <a href="https://bugs.launchpad.net/horizon/+bug/1196823" target="_blank">https://bugs.launchpad.net/horizon/+bug/1196823</a><br>
> > > This is arguably a deficiency of mox, which (apparently?) doesn't<br>
> > let us mock properties automatically.<br>
> ><br>
> > I agree, but it is just one example. other test-only issues can<br>
> > happen as well.<br>
> ><br>
> > Similar problem: the *client packages are not self-contained, they<br>
> > have pretty strict dependencies on other packages. One case I already<br>
> > run into was a dependency on python-requests: newer python-*client<br>
> > packages (rightfully) require requests >= 1.x. running those on a<br>
> > system that has OpenStack services from Grizzly or Folsom installed<br>
> > cause a conflict: there are one or two that require requests to be <<br>
> > 1.0.<br>
> ><br>
> > When you run gating on this scenario, I think the same flipping would<br>
> > happen on e.g. requests as well, due to *client or the module being<br>
> > installed in varying order.<br>
> ><br>
> > Greetings,<br>
> > Dirk<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <mailto:<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>
> > Gareth<br>
> ><br>
> > /Cloud Computing, OpenStack, Fitness, Basketball/<br>
> > /OpenStack contributor/<br>
> > /Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>/<br>
> > /My promise: if you find any spelling or grammar mistakes in my email<br>
> > from Mar 1 2013, notify me /<br>
> > /and I'll donate $1 or ?1 to an open organization you specify./<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>
> ><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>
Gareth<br>
<br>
*Cloud Computing, OpenStack, Fitness, Basketball*<br>
*OpenStack contributor*<br>
*Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>*<br>
*My promise: if you find any spelling or grammar mistakes in my email from<br>
Mar 1 2013, notify me *<br>
*and I'll donate $1 or ?1 to an open organization you specify.*<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/cec07926/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/cec07926/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Fri, 12 Jul 2013 12:12:26 +0800<br>
From: Gareth <<a href="mailto:academicgareth@gmail.com">academicgareth@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID:<br>
<CAAhuP_-_opSjjLng2PFc=<a href="mailto:1qb8AuhcuV4uNcuUD039EDymw1L%2BQ@mail.gmail.com">1qb8AuhcuV4uNcuUD039EDymw1L+Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
so, what's the final conclusion about this issue?<br>
<br>
<br>
On Fri, Jul 12, 2013 at 12:11 PM, Gareth <<a href="mailto:academicgareth@gmail.com">academicgareth@gmail.com</a>> wrote:<br>
<br>
> Thanks, Monty<br>
><br>
> but in my review <a href="https://review.openstack.org/#/c/36684/" target="_blank">https://review.openstack.org/#/c/36684/</a> , Doug said we<br>
> will go without upper bound with those python-*clients<br>
> and in this one <a href="https://review.openstack.org/#/c/36753/" target="_blank">https://review.openstack.org/#/c/36753/</a> , keystoneclient<br>
> still keep '<0.4' and requirements test doesn't fail in keystoneclient (<br>
> <a href="https://jenkins.openstack.org/job/gate-cinder-requirements/96/console" target="_blank">https://jenkins.openstack.org/job/gate-cinder-requirements/96/console</a> it<br>
> failed on glanceclient)<br>
><br>
><br>
><br>
><br>
> On Fri, Jul 12, 2013 at 11:54 AM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>>wrote:<br>
><br>
>><br>
>><br>
>> On 07/11/2013 11:38 PM, Gareth wrote:<br>
>> > I heard there's a talk about this issue in #openstack-infra last night<br>
>> > (china standard time), what's the conclusion of that?<br>
>> ><br>
>> > BTW, how to find meeting log of #openstack-infra? I didn't find it<br>
>> > in <a href="http://eavesdrop.openstack.org/" target="_blank">http://eavesdrop.openstack.org/</a><br>
>><br>
>> We don't log it currently. There is a wider conversation going on about<br>
>> which things we should log and which things we should not log ... but<br>
>> for the time being I've submitted this:<br>
>><br>
>> <a href="https://review.openstack.org/36773" target="_blank">https://review.openstack.org/36773</a><br>
>><br>
>> to add -infra. I think we talk about enough things that have<br>
>> ramifications on everyone in there that we should really capture it.<br>
>> > On Thu, Jul 11, 2013 at 11:35 PM, Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a><br>
>> > <mailto:<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>>> wrote:<br>
>> ><br>
>> > >> See for example <a href="https://bugs.launchpad.net/horizon/+bug/1196823" target="_blank">https://bugs.launchpad.net/horizon/+bug/1196823</a><br>
>> > > This is arguably a deficiency of mox, which (apparently?) doesn't<br>
>> > let us mock properties automatically.<br>
>> ><br>
>> > I agree, but it is just one example. other test-only issues can<br>
>> > happen as well.<br>
>> ><br>
>> > Similar problem: the *client packages are not self-contained, they<br>
>> > have pretty strict dependencies on other packages. One case I<br>
>> already<br>
>> > run into was a dependency on python-requests: newer python-*client<br>
>> > packages (rightfully) require requests >= 1.x. running those on a<br>
>> > system that has OpenStack services from Grizzly or Folsom installed<br>
>> > cause a conflict: there are one or two that require requests to be <<br>
>> > 1.0.<br>
>> ><br>
>> > When you run gating on this scenario, I think the same flipping<br>
>> would<br>
>> > happen on e.g. requests as well, due to *client or the module being<br>
>> > installed in varying order.<br>
>> ><br>
>> > Greetings,<br>
>> > Dirk<br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > <mailto:<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>
>> > Gareth<br>
>> ><br>
>> > /Cloud Computing, OpenStack, Fitness, Basketball/<br>
>> > /OpenStack contributor/<br>
>> > /Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>/<br>
>> > /My promise: if you find any spelling or grammar mistakes in my email<br>
>> > from Mar 1 2013, notify me /<br>
>> > /and I'll donate $1 or ?1 to an open organization you specify./<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>
>> ><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>
> Gareth<br>
><br>
> *Cloud Computing, OpenStack, Fitness, Basketball*<br>
> *OpenStack contributor*<br>
> *Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>*<br>
> *My promise: if you find any spelling or grammar mistakes in my email<br>
> from Mar 1 2013, notify me *<br>
> *and I'll donate $1 or ?1 to an open organization you specify.*<br>
><br>
<br>
<br>
<br>
--<br>
Gareth<br>
<br>
*Cloud Computing, OpenStack, Fitness, Basketball*<br>
*OpenStack contributor*<br>
*Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>*<br>
*My promise: if you find any spelling or grammar mistakes in my email from<br>
Mar 1 2013, notify me *<br>
*and I'll donate $1 or ?1 to an open organization you specify.*<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/70647ed8/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/70647ed8/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Fri, 12 Jul 2013 01:10:48 -0400<br>
From: Brian Lamar <<a href="mailto:brian.lamar@rackspace.com">brian.lamar@rackspace.com</a>><br>
To: Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Openstack] Improve inject network<br>
configuration<br>
Message-ID: <<a href="mailto:51DF8FD8.7080808@rackspace.com">51DF8FD8.7080808@rackspace.com</a>><br>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed<br>
<br>
<br>
<br>
Russell Bryant wrote:<br>
> On 07/11/2013 08:53 PM, Jae Sang Lee wrote:<br>
>> Hi, stackers.<br>
>><br>
>> When creating vm using multi nics, User should power up the second<br>
>> interface on the instance manually for use second IP.<br>
>> <a href="http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html" target="_blank">http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html</a><br>
>><br>
>><br>
>> I intend to fix interfaces.template file, so It can be possible power up<br>
>> other interface during booting time automatically.<br>
>><br>
>> I registered blueprint for this a month<br>
>> ago.(<a href="https://blueprints.launchpad.net/nova/+spec/better-network-injection" target="_blank">https://blueprints.launchpad.net/nova/+spec/better-network-injection</a>)<br>
>><br>
>> But not yet approved.<br>
>><br>
>> If you have permission to approve who read this mail, please approve my<br>
>> blueprint.<br>
><br>
> Honestly, I think network injection is evil and I'd rather remove it<br>
> completely. I'm certainly not too interested in trying to add more<br>
> features to it.<br>
><br>
<br>
Can you elaborate on this a little more? Do you not like file injection<br>
or dynamic network allocation?<br>
<br>
Can you provide alternative strategies that could be applied to solve<br>
the issue of dynamically brining up interfaces or do you think this is<br>
out of the project scope (controlling the internals of VMs)?<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Thu, 11 Jul 2013 22:16:11 -0700<br>
From: Sumit Naiksatam <<a href="mailto:sumitnaiksatam@gmail.com">sumitnaiksatam@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Revert Pass instance host-id to Quantum<br>
using port bindings extension.<br>
Message-ID:<br>
<<a href="mailto:CAMWrLvj6NMz2cmrzsecz%2B8p01SX5wdv0ueX_-%2BmFnruUvWGDuQ@mail.gmail.com">CAMWrLvj6NMz2cmrzsecz+8p01SX5wdv0ueX_-+mFnruUvWGDuQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
I agree with Andre and Kyle here. I am not sure that the polling<br>
option is even going to work for certain use cases where the host_id<br>
information is required when creating the port (for instance, to<br>
decide the VIF type).<br>
<br>
Thanks,<br>
~Sumit.<br>
<br>
On Thu, Jul 11, 2013 at 7:27 PM, Kyle Mestery (kmestery)<br>
<<a href="mailto:kmestery@cisco.com">kmestery@cisco.com</a>> wrote:<br>
> I agree with Andre's concerns around the implications of polling in what Aaron is proposing, and in fact, this is one reason the existing change is so nice. The ML2 sub-team talked about this at a recent meeting, and we liked the approach which Yong had taken with the patch. But as Andre says, we're all for working to simplify things, keeping the goals he mentioned in mind.<br>
><br>
> What are your thoughts Aaron?<br>
><br>
> Thanks,<br>
> Kyle<br>
><br>
> On Jul 11, 2013, at 8:44 PM, Andre Pech <<a href="mailto:apech@aristanetworks.com">apech@aristanetworks.com</a>> wrote:<br>
><br>
>> Hey Aaron,<br>
>><br>
>> As an interested party in the change, figured I'd take a stab at responding. I've talked with people at BigSwitch and Cisco about this change, so I know others are interested in this as well, but I'll let them give their perspective.<br>
>><br>
>> At a high level, our goal at Arista is similar to what you mention. We want to integrate the provisioning of the physical network within Neutron in conjunction with the virtual network. We have no interest in controlling the virtual switch layer, and so we'd like to do this in a way that does not tie us to any particular virtual switching technology (should work just as well with OVS, LinuxBridge, or whatever future virtual switch technology a customer may choose to use). And it needs the chance to be "inline" - the provisioning of the physical network has to happen alongside the virtual network, so that failures to provision the physical network can be propogated to the user in the same way as a failure to set up the virtual network.<br>
>><br>
>> The thing I like most about the current solution is that it's event-driven. There's no polling of the information out of band from nova (I'm not sure how accepted it would be to poll this info directly from neutron, which would then force you to do it from an outside system). It also doesn't require any coordination with agents running on the compute side (in line with the goal of working across multiple virtual switching technologies).<br>
>><br>
>> I'd be really happy with another solution, but I'd be great to see those properties preserved. I have reservations about the alternatives you're proposing. Happy to hop on a call with other interested parties to come up with a better middleground that allows you to do the simplification you're proposing while still giving Neutron an explicit hook to learn about the host a VM was placed on.<br>
>><br>
>> Andre<br>
>><br>
>><br>
>> On Thu, Jul 11, 2013 at 1:30 PM, Aaron Rosen <<a href="mailto:arosen@nicira.com">arosen@nicira.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>> I think we should revert this patch that was added here (<a href="https://review.openstack.org/#/c/29767/" target="_blank">https://review.openstack.org/#/c/29767/</a>). What this patch does is when nova-compute calls into quantum to create the port it passes in the hostname on which the instance was booted on. The idea of the patch was that providing this information would "allow hardware device vendors management stations to allow them to segment the network in a more precise manager (for example automatically trunk the vlan on the physical switch port connected to the compute node on which the vm instance was started)."<br>
>><br>
>> In my opinion I don't think this is the right approach. There are several other ways to get this information of where a specific port lives. For example, in the OVS plugin case the agent running on the nova-compute node can update the port in quantum to provide this information. Alternatively, quantum could query nova using the port.device_id to determine which server the instance is on.<br>
>><br>
>> My motivation for removing this code is I now have the free cycles to work on <a href="https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port" target="_blank">https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port</a> discussed here (<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html</a>) . This was about moving the quantum port creation from the nova-compute host to nova-api if a network-uuid is passed in. This will allow us to remove all the quantum logic from the nova-compute nodes and simplify orchestration.<br>
>><br>
>> Thoughts?<br>
>><br>
>> Best,<br>
>><br>
>> Aaron<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>
><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>
Message: 17<br>
Date: Fri, 12 Jul 2013 11:14:11 +0400<br>
From: Sergey Lukjanov <<a href="mailto:slukjanov@mirantis.com">slukjanov@mirantis.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: "<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>"<br>
<<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>><br>
Subject: [openstack-dev] [Savanna] Savanna meeting minutes<br>
Message-ID: <<a href="mailto:48F6408C-3F80-4144-A1A4-0F45D77EDE42@mirantis.com">48F6408C-3F80-4144-A1A4-0F45D77EDE42@mirantis.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Thanks everyone who have joined today's Savanna meeting.<br>
<br>
Here are the logs from the last meeting (July, 11):<br>
<br>
Minutes: <a href="http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-11-18.05.html" target="_blank">http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-11-18.05.html</a><br>
Minutes (text): <a href="http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-11-18.05.txt" target="_blank">http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-11-18.05.txt</a><br>
Log: <a href="http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-11-18.05.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-11-18.05.log.html</a><br>
<br>
Sincerely yours,<br>
Sergey Lukjanov<br>
Savanna Technical Lead<br>
Mirantis Inc.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Fri, 12 Jul 2013 11:36:21 +0400<br>
From: Oleg Bondarev <<a href="mailto:obondarev@mirantis.com">obondarev@mirantis.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [Neutron] please review LBaaS agent<br>
scheduling<br>
Message-ID:<br>
<CAO_ZGNFPN3k5AF5vLdQ1JObTX=<a href="mailto:dmw0-WvxSc%2B5eerCMzDXjVgw@mail.gmail.com">dmw0-WvxSc+5eerCMzDXjVgw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi folks,<br>
While havana 2 is approaching I can't get a review from core devs for more<br>
than 2 weeks. That fact makes me a little nervous :) Could anyone please<br>
review?<br>
<a href="https://review.openstack.org/#/c/32137/" target="_blank">https://review.openstack.org/#/c/32137/</a><br>
<br>
Thanks,<br>
Oleg<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/ceac09d6/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/ceac09d6/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Thu, 11 Jul 2013 16:19:15 -0700<br>
From: Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
To: Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>><br>
Cc: Gary Kotton <<a href="mailto:gary.kotton@gmail.com">gary.kotton@gmail.com</a>>, Sumit Naiksatam<br>
<<a href="mailto:sumit.naiksatam@bigswitch.com">sumit.naiksatam@bigswitch.com</a>>, OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, yong sheng gong<br>
<<a href="mailto:gongysh@unitedstack.com">gongysh@unitedstack.com</a>>, Nachi Ueno <<a href="mailto:nachi@nttmcl.com">nachi@nttmcl.com</a>>, Robert<br>
Kukura <<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a>><br>
Subject: Re: [openstack-dev] Bug #1194026<br>
Message-ID:<br>
<CABJepwjLKiSe_QsSS3yyv8M=p0wpy86gJsAY0K9gPJTk8HL=<a href="mailto:Kg@mail.gmail.com">Kg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi folks<br>
<br>
I think I found possible cause of this problems.<br>
<br>
so we expected all RPC call is executed serialized way on l3-agent<br>
However it is executed in random order.<br>
<br>
<a href="http://paste.openstack.org/show/40156/" target="_blank">http://paste.openstack.org/show/40156/</a><br>
line starts from **** Get is RPC message log.<br>
line starts from [[[[[ Process is when l3-agent start processing rpc messages.<br>
(I added rpc message number for debugging)<br>
<br>
<a href="https://bugs.launchpad.net/neutron/+bug/1194026" target="_blank">https://bugs.launchpad.net/neutron/+bug/1194026</a><br>
<br>
Here is my proposal for fixing code.<br>
<br>
- Server side simply notifies when something updated.<br>
- Client will update updated flag in the client when it get updated<br>
- some looping call will check the flag,<br>
if the flag is true, it will full sync with servers<br>
<br>
If this is OK, I'll start write it.<br>
<br>
Thanks<br>
Nachi<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
2013/7/11 Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>>:<br>
> Adding openstack-dev to this discussion thread.<br>
> Looks like the test is going to be skipped at the moment, but we probably<br>
> need to consider raising the priority of this issue and assign our cores<br>
> with more experience with tempest/gating on this.<br>
><br>
> salvatore<br>
><br>
><br>
> On 9 July 2013 22:48, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br>
>><br>
>> My suggestion is that the quantum exercise script be disabled for now if<br>
>> that will allow the tempest test to run, since the tempest test is more<br>
>> useful (it does an ssh check to ensure that the metadata service has<br>
>> configured the VM). Doing so would allow useful gating while we look at<br>
>> resolving the timing bug.<br>
>><br>
>><br>
>> m.<br>
>><br>
>> On Jul 9, 2013, at 5:42 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
>><br>
>> > Hi Maru<br>
>> ><br>
>> > The gating test will not fail everytime. Sometimes, both of tests<br>
>> > works, sometimes not.<br>
>> > In this test, execise.sh works and tempest don't works.<br>
>> > I'm still not sure is there any dependencies in this failure or not.<br>
>> ><br>
>> > So I'm assuming this is kind of timing issue..<br>
>> ><br>
>> > hmm this kind of bug is hard to fix..<br>
>> ><br>
>> ><br>
>> > 2013/7/9 Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>>:<br>
>> >> If there is a conflict between the exercise test and the tempest test,<br>
>> >> does the tempest test pass if the exercise script isn't run beforehand?<br>
>> >><br>
>> >><br>
>> >> m.<br>
>> >><br>
>> >> On Jul 9, 2013, at 5:20 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
>> >><br>
>> >>> Hi<br>
>> >>><br>
>> >>> I checked briefly, and it looks some timing bug of l3-agent.<br>
>> >>> I added note on the bug report.<br>
>> >>> <a href="https://bugs.launchpad.net/neutron/+bug/1194026" target="_blank">https://bugs.launchpad.net/neutron/+bug/1194026</a><br>
>> >>><br>
>> >>> 2013/7/9 Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>>:<br>
>> >>>> Sean Dague singled it out as the biggest cause for gate failures, and<br>
>> >>>> invited us to have a look at it.<br>
>> >>>> I've raised its importance to high, but I don't have the cycles to<br>
>> >>>> look at<br>
>> >>>> it in the short term.<br>
>> >>>> It would be really if somebody from the core team finds some time to<br>
>> >>>> triage<br>
>> >>>> it.<br>
>> >>>><br>
>> >>>> Salvatore<br>
>> >><br>
>><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Fri, 12 Jul 2013 10:29:29 +0200<br>
From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:51DFBE69.5070103@openstack.org">51DFBE69.5070103@openstack.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Monty Taylor wrote:<br>
> This brings us to the most important question:<br>
><br>
> Who wants to be on the core team?<br>
<br>
That's the important question indeed. Accepting it (permanently or<br>
temporarily) under stackforge is an easy decision. But it's useless<br>
unless we have a set of people sufficiently interested in it not<br>
bitrotting to volunteer to maintain it...<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Fri, 12 Jul 2013 15:35:55 +0700<br>
From: Chu Duc Minh <<a href="mailto:chu.ducminh@gmail.com">chu.ducminh@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] Nova service(s) prolem when using Mysql<br>
behind HAProxy<br>
Message-ID:<br>
<<a href="mailto:CAGP-ymNheF70mV4xbrCST01vDb0DrsO_s45hZaPy9ABYKTrMzA@mail.gmail.com">CAGP-ymNheF70mV4xbrCST01vDb0DrsO_s45hZaPy9ABYKTrMzA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi, when using Mysql behind Haproxy, i have a problem on reboot when some<br>
nova services start after Haproxy service, but before Mysql service.<br>
These service failed: (i re-checked for sure in /var/log/boot.log)<br>
* Starting Nova cert<br>
[fail]<br>
* Starting Nova conductor<br>
[fail]<br>
* Starting Nova scheduler<br>
[fail]<br>
* Starting Cinder scheduler server<br>
[fail]<br>
<br>
I must login to server and re-start these services manually.<br>
<br>
When check log of Nova-cert, I saw:<br>
<br>
*2013-07-12 15:20:05.020 2490 CRITICAL nova [-] (OperationalError) (2013,<br>
"Lost connection to MySQL server at 'reading initial communic<br>
ation packet', system error: 0") None None*<br>
2013-07-12 15:20:05.020 2490 TRACE nova Traceback (most recent call last):<br>
2013-07-12 15:20:05.020 2490 TRACE nova File "/usr/bin/nova-cert", line<br>
51, in <module><br>
2013-07-12 15:20:05.020 2490 TRACE nova service.wait()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/service.py", line 689, in wait<br>
2013-07-12 15:20:05.020 2490 TRACE nova _launcher.wait()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/service.py", line 209, in wait<br>
2013-07-12 15:20:05.020 2490 TRACE nova super(ServiceLauncher,<br>
self).wait()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/service.py", line 179, in wait<br>
2013-07-12 15:20:05.020 2490 TRACE nova service.wait()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 168, in<br>
wait<br>
2013-07-12 15:20:05.020 2490 TRACE nova return self._exit_event.wait()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/eventlet/event.py", line 116, in wait<br>
2013-07-12 15:20:05.020 2490 TRACE nova return hubs.get_hub().switch()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 187, in switch<br>
2013-07-12 15:20:05.020 2490 TRACE nova return self.greenlet.switch()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 194, in<br>
main<br>
2013-07-12 15:20:05.020 2490 TRACE nova result = function(*args,<br>
**kwargs)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/service.py", line 147, in run_server<br>
2013-07-12 15:20:05.020 2490 TRACE nova server.start()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/service.py", line 434, in start<br>
2013-07-12 15:20:05.020 2490 TRACE nova self.host, self.binary)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/conductor/api.py", line 261, in<br>
service_get_by_a<br>
rgs<br>
2013-07-12 15:20:05.020 2490 TRACE nova binary=binary)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/utils.py", line 1348, in wrapper<br>
2013-07-12 15:20:05.020 2490 TRACE nova return func(*args, **kwargs)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/common.py",<br>
line 424, in in<br>
ner<br>
2013-07-12 15:20:05.020 2490 TRACE nova return<br>
catch_client_exception(exceptions, func, *args, **kwargs)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/common.py",<br>
line 407, in ca<br>
tch_client_exception<br>
2013-07-12 15:20:05.020 2490 TRACE nova return func(*args, **kwargs)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/conductor/manager.py", line 325, in<br>
service_get_<br>
all_by<br>
2013-07-12 15:20:05.020 2490 TRACE nova result =<br>
self.db.service_get_by_args(context, host, binary)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/db/api.py", line 155, in<br>
service_get_by_args<br>
2013-07-12 15:20:05.020 2490 TRACE nova return<br>
IMPL.service_get_by_args(context, host, binary)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 96, in<br>
wrapper<br>
2013-07-12 15:20:05.020 2490 TRACE nova return f(*args, **kwargs)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 409, in<br>
service_get_by_args<br>
2013-07-12 15:20:05.020 2490 TRACE nova result = model_query(context,<br>
models.Service).\<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 177, in<br>
model_query<br>
2013-07-12 15:20:05.020 2490 TRACE nova session = kwargs.get('session')<br>
or get_session()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/openstack/common/db/sqlalchemy/session.py",<br>
line 325, in get_session<br>
2013-07-12 15:20:05.020 2490 TRACE nova engine = get_engine()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/openstack/common/db/sqlalchemy/session.py",<br>
line 446, in get_engine<br>
2013-07-12 15:20:05.020 2490 TRACE nova _ENGINE =<br>
create_engine(CONF.sql_connection)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/nova/openstack/common/db/sqlalchemy/session.py",<br>
line 562, in create_engine<br>
2013-07-12 15:20:05.020 2490 TRACE nova engine.connect()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2471, in<br>
connect<br>
2013-07-12 15:20:05.020 2490 TRACE nova return<br>
self._connection_cls(self, **kwargs)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 878, in<br>
__init__<br>
2013-07-12 15:20:05.020 2490 TRACE nova self.__connection = connection<br>
or engine.raw_connection()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2557, in<br>
raw_connection<br>
2013-07-12 15:20:05.020 2490 TRACE nova return<br>
self.pool.unique_connection()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 184, in<br>
unique_connection<br>
2013-07-12 15:20:05.020 2490 TRACE nova return<br>
_ConnectionFairy(self).checkout()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 401, in __init__<br>
2013-07-12 15:20:05.020 2490 TRACE nova rec = self._connection_record =<br>
pool._do_get()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 746, in _do_get<br>
2013-07-12 15:20:05.020 2490 TRACE nova con = self._create_connection()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 189, in<br>
_create_connection<br>
2013-07-12 15:20:05.020 2490 TRACE nova return _ConnectionRecord(self)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 282, in __init__<br>
2013-07-12 15:20:05.020 2490 TRACE nova self.connection =<br>
self.__connect()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 344, in<br>
__connect<br>
2013-07-12 15:20:05.020 2490 TRACE nova connection =<br>
self.__pool._creator()<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/strategies.py", line<br>
80, in connect<br>
2013-07-12 15:20:05.020 2490 TRACE nova return dialect.connect(*cargs,<br>
**cparams)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 281,<br>
in connect<br>
2013-07-12 15:20:05.020 2490 TRACE nova return<br>
self.dbapi.connect(*cargs, **cparams)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/MySQLdb/__init__.py", line 81, in Connect<br>
2013-07-12 15:20:05.020 2490 TRACE nova return Connection(*args,<br>
**kwargs)<br>
2013-07-12 15:20:05.020 2490 TRACE nova File<br>
"/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 187, in<br>
__init__<br>
2013-07-12 15:20:05.020 2490 TRACE nova super(Connection,<br>
self).__init__(*args, **kwargs2)<br>
*2013-07-12 15:20:05.020 2490 TRACE nova OperationalError:<br>
(OperationalError) (2013, "Lost connection to MySQL server at 'reading<br>
initial communication packet', system error: 0") None None<br>
*<br>
<br>
Do you know a quick fix for this problem?<br>
(I also send this email to report the problem)<br>
<br>
Thanks you!<br>
<br>
PS: I'm runing mysql, haproxy, nova-* services, cinder-* services on the<br>
same server, using Ubuntu 12.04.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/6667b737/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/6667b737/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Fri, 12 Jul 2013 10:43:01 +0200<br>
From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Openstack] Improve inject network<br>
configuration<br>
Message-ID: <<a href="mailto:51DFC195.5070908@openstack.org">51DFC195.5070908@openstack.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Brian Lamar wrote:<br>
>> Honestly, I think network injection is evil and I'd rather remove it<br>
>> completely. I'm certainly not too interested in trying to add more<br>
>> features to it.<br>
><br>
> Can you elaborate on this a little more? Do you not like file injection<br>
> or dynamic network allocation?<br>
<br>
It's an old discussion... in summary:<br>
<br>
Nova inserting stuff pre-booting into the VM it runs = evil, brittle and<br>
the source of countless past vulnerabilities<br>
<br>
VMs auto-configuring at boot-time using cloud-init based on data<br>
provided through generic input channels (config drive, metadata<br>
servers...) = good<br>
<br>
So this is not about disliking the ability to insert files or specify<br>
network parameters for a VM, it's about who is in charge of actually<br>
creating files and network configurations. Nova shouldn't have to learn<br>
about the specificities of the VM image it runs, nor should it have to<br>
mount VM filesystems before booting them. The VM itself should take care<br>
of the translation based on standardized input (if it wants to).<br>
<br>
> Can you provide alternative strategies that could be applied to solve<br>
> the issue of dynamically brining up interfaces or do you think this is<br>
> out of the project scope (controlling the internals of VMs)?<br>
<br>
Config-drive should pass that config to the VM, and cloud-init on the VM<br>
should pick it up.<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Fri, 12 Jul 2013 20:57:06 +1200<br>
From: Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] volume affinity filter for nova<br>
scheduler<br>
Message-ID:<br>
<<a href="mailto:CAJ3HoZ0PGkhRv5%2Bcsf9BskYxYQ4vJSPp7vAaLxj_L3hS9wjGTw@mail.gmail.com">CAJ3HoZ0PGkhRv5+csf9BskYxYQ4vJSPp7vAaLxj_L3hS9wjGTw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 11 July 2013 02:39, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
<br>
>> We'll probably need something like this for Ironic with persistent<br>
>> volumes on machines - yes its a rare case, but when it matters, it<br>
>> matters a great deal.<br>
><br>
> I believe you, but I guess I'd like to better understand how this works<br>
> to make sure what gets added actually solves your use case. Is there<br>
> already support for Cinder managed persistent volumes that live on<br>
> baremetal nodes?<br>
<br>
There isn't, but we discussed it with Cinder folk in Portland.<br>
<br>
Basic intent is this:<br>
- we have a cinder 'Ironic' backend.<br>
- volume requests for the Ironic backend are lazy provisioned: they<br>
just allocate a UUID on creation<br>
- nova-bm/Ironic will store a volume <-> node mapping<br>
- 'nova boot' without a volume spec will only select nodes with no<br>
volumes associated to them.<br>
- 'nova boot' with a volume spec will find an existing node with<br>
those volumes mapped to it, or if none exists create the volume<br>
mapping just-in-time<br>
- the deployment ramdisk would setup the volume on the hardware<br>
[using hardware RAID]<br>
- where there isn't hardware RAID we'd let the instance take care<br>
of how to setup the persistent storage - because we don't have a<br>
translation layer in place we can't assume lvm or windows volume<br>
manager or veritas or.....<br>
<br>
The obvious gap between intent and implementation here is that choices<br>
about nodes happen in the nova scheduler, so we need the scheduler to<br>
be able to honour four cases:<br>
- baremetal flavor with no volumes requested, gets a baremetal node<br>
with no volumes mapped<br>
- baremetal flavor with volumes requested, just one baremetal node<br>
with any of those volumes exist -> that node<br>
- baremetal flavor with volumes requested, > one baremetal node with<br>
any of those volumes exist -> error<br>
- baremetal flavor with volumes requested, no nodes with any of those<br>
volumes -> pick any node that has enough disks to supply the volume<br>
definitions<br>
<br>
Writing this it seems like the nova scheduler may be a tricky fit;<br>
perhaps we should - again- reevaluate just how this all glues<br>
together?<br>
<br>
-Rob<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Cloud Services<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Fri, 12 Jul 2013 21:21:33 +1200<br>
From: Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Chris Jones <<a href="mailto:cmsj@tenshu.net">cmsj@tenshu.net</a>><br>
Subject: Re: [openstack-dev] [Openstack] Improve inject network<br>
configuration<br>
Message-ID:<br>
<CAJ3HoZ1Pmp_Y2un5aP9=96P=_Kysj51PK_f9kJOFw-X9kqpJ=<a href="mailto:g@mail.gmail.com">g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 12 July 2013 20:43, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
> Brian Lamar wrote:<br>
>>> Honestly, I think network injection is evil and I'd rather remove it<br>
>>> completely. I'm certainly not too interested in trying to add more<br>
>>> features to it.<br>
>><br>
>> Can you elaborate on this a little more? Do you not like file injection<br>
>> or dynamic network allocation?<br>
><br>
> It's an old discussion... in summary:<br>
><br>
> Nova inserting stuff pre-booting into the VM it runs = evil, brittle and<br>
> the source of countless past vulnerabilities<br>
><br>
> VMs auto-configuring at boot-time using cloud-init based on data<br>
> provided through generic input channels (config drive, metadata<br>
> servers...) = good<br>
><br>
> So this is not about disliking the ability to insert files or specify<br>
> network parameters for a VM, it's about who is in charge of actually<br>
> creating files and network configurations. Nova shouldn't have to learn<br>
> about the specificities of the VM image it runs, nor should it have to<br>
> mount VM filesystems before booting them. The VM itself should take care<br>
> of the translation based on standardized input (if it wants to).<br>
><br>
>> Can you provide alternative strategies that could be applied to solve<br>
>> the issue of dynamically brining up interfaces or do you think this is<br>
>> out of the project scope (controlling the internals of VMs)?<br>
><br>
> Config-drive should pass that config to the VM, and cloud-init on the VM<br>
> should pick it up.<br>
<br>
Or the instance should just auto-adjust. Chris Jones wrote some code<br>
for that for tripleo, but we can't use it until we can disable file<br>
injection... and I can't find where we stashed it.<br>
<br>
Chris?<br>
<br>
-Rob<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Cloud Services<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Fri, 12 Jul 2013 13:25:45 +0400<br>
From: Ruslan Kamaldinov <<a href="mailto:rkamaldinov@mirantis.com">rkamaldinov@mirantis.com</a>><br>
To: Arindam Choudhury <<a href="mailto:arindam@live.com">arindam@live.com</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
"=?utf-8?Q?savanna-all=<a href="http://40lists.launchpad.net?=" target="_blank">40lists.launchpad.net?=</a>"<br>
<<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>><br>
Subject: Re: [openstack-dev] [Savanna-all] installation problem<br>
Message-ID: <<a href="mailto:7A1D6495A3C844C3A7DC02BC904504CC@mirantis.com">7A1D6495A3C844C3A7DC02BC904504CC@mirantis.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
It seems that you're using the latest code from Savanna v0.2, but following instructions from Savanna v0.1.<br>
Please follow these docs: <a href="https://savanna.readthedocs.org/en/latest/" target="_blank">https://savanna.readthedocs.org/en/latest/</a><br>
<br>
<br>
Ruslan<br>
<br>
<br>
On Friday, July 12, 2013 at 1:19 PM, Arindam Choudhury wrote:<br>
<br>
> Hi,<br>
><br>
> While installing savanna I am getting this error:<br>
><br>
> [arindam@sl-3 savanna]$ tox -evenv -- bin/savanna-db-manage --config-file etc/savanna/savanna.conf reset-db --with-gen-templates<br>
> GLOB sdist-make: /home/arindam/savanna/setup.py<br>
> venv inst-nodeps: /home/arindam/savanna/.tox/dist/savanna-0.2.a12.gf85d74f.zip<br>
> venv runtests: commands[0] | bin/savanna-db-manage --config-file etc/savanna/savanna.conf reset-db --with-gen-templates<br>
> ERROR: InvocationError: could not find executable 'bin/savanna-db-manage'<br>
> _________________________________________________________________ summary __________________________________________________________________<br>
> ERROR: venv: commands failed<br>
><br>
><br>
> Regards,<br>
> Arindam<br>
> --<br>
> Mailing list: <a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a><br>
> Post to : <a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a> (mailto:<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>)<br>
> Unsubscribe : <a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a><br>
> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
><br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/a1145087/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/a1145087/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Fri, 12 Jul 2013 18:08:16 +0800<br>
From: Zang MingJie <<a href="mailto:zealot0630@gmail.com">zealot0630@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Neutron] Campus Network Blueprint<br>
Message-ID:<br>
<<a href="mailto:CAOrge3rq41XVqVzsGzRRXEiHfr0HipzdGp1YaDLYPmdMC_OfQw@mail.gmail.com">CAOrge3rq41XVqVzsGzRRXEiHfr0HipzdGp1YaDLYPmdMC_OfQw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi Filipe:<br>
<br>
I disagree your ml2-external-port BP<br>
<br>
It is unsuitable to connect multiple l2 networks directly, there may<br>
be ip conflict, dhcp conflict and other problems. although neutron<br>
dhcp agent won't respond dhcp request from unknown source, an external<br>
dhcp may respond vm dhcp request. If we move an external port form a<br>
network to another network, how can we ensure that the arp cache is<br>
cleared.<br>
<br>
And it will aslo make l2-population bp (<br>
<a href="https://blueprints.launchpad.net/quantum/+spec/l2-population" target="_blank">https://blueprints.launchpad.net/quantum/+spec/l2-population</a> ) more<br>
difficault. Our l2 forwarding works better if the device knows the<br>
whole topology of the network, but the external part is totally<br>
unknown.<br>
<br>
So, I suggest a layer-3 solution, where the out world connects to vms<br>
via l3 agent.<br>
<br>
<br>
Thank you for sharing the idea<br>
Regards<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Fri, 12 Jul 2013 14:55:34 +0400<br>
From: Ruslan Kamaldinov <<a href="mailto:rkamaldinov@mirantis.com">rkamaldinov@mirantis.com</a>><br>
To: Arindam Choudhury <<a href="mailto:arindam@live.com">arindam@live.com</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
"=?utf-8?Q?savanna-all=<a href="http://40lists.launchpad.net?=" target="_blank">40lists.launchpad.net?=</a>"<br>
<<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>><br>
Subject: Re: [openstack-dev] [Savanna-all] installation problem<br>
Message-ID: <<a href="mailto:D4ACBD62BD224123BAEBB337B786DDCB@mirantis.com">D4ACBD62BD224123BAEBB337B786DDCB@mirantis.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
That's ok. You need to specify tenant id and provide auth token in headers.<br>
You can find detailed how-tos here <a href="https://savanna.readthedocs.org/en/latest/devref/quickstart.html" target="_blank">https://savanna.readthedocs.org/en/latest/devref/quickstart.html</a><br>
<br>
<br>
btw, please use openstack-dev mail-list for Savanna-related questions. Just prefix mail subject with [Savanna].<br>
<br>
Ruslan<br>
<br>
<br>
On Friday, July 12, 2013 at 1:59 PM, Arindam Choudhury wrote:<br>
<br>
> Hi,<br>
><br>
> The new document works great except this command $ sudo pip install savannadashboard.<br>
><br>
> I changed the savanna config to:<br>
> [DEFAULT]<br>
><br>
> # REST API config<br>
> port=8386<br>
> allow_cluster_ops=true<br>
><br>
> # Address and credentials that will be used to check auth tokens<br>
> os_auth_host=192.168.122.11<br>
> os_auth_port=35357<br>
> os_admin_username=admin<br>
> os_admin_password=openstack<br>
> os_admin_tenant_name=admin<br>
><br>
> # (Optional) Name of log file to output to. If not set,<br>
> # logging will go to stdout. (string value)<br>
> log_file=/home/arindam/savanna.log<br>
><br>
> [cluster_node]<br>
><br>
> # An existing user on Hadoop image (string value)<br>
> #username=root<br>
><br>
> # User's password (string value)<br>
> #password=swordfish<br>
><br>
> # When set to false, Savanna uses only internal IP of VMs.<br>
> # When set to true, Savanna expects OpenStack to auto-assign<br>
> # floating IPs to cluster nodes. Internal IPs will be used for<br>
> # inter-cluster communication, while floating ones will be<br>
> # used by Savanna to configure nodes. Also floating IPs will<br>
> # be exposed in service URLs (boolean value)<br>
> use_floating_ips=true<br>
><br>
> [sqlalchemy]<br>
><br>
> # URL for sqlalchemy database (string value)<br>
> database_uri=sqlite:////tmp/savanna-server.db<br>
><br>
><br>
> and I changed config of dashboard as specified.<br>
><br>
> but I can not access the savanna dashboard:<br>
><br>
> [arindam@sl-3 ~]$ curl <a href="http://localhost:8386/v1.0" target="_blank">http://localhost:8386/v1.0</a><br>
> <html><br>
> <head><br>
> <title>401 Unauthorized</title><br>
> </head><br>
> <body><br>
> <h1>401 Unauthorized</h1><br>
> This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.<br /><br /><br>
> Authentication required<br>
><br>
><br>
> </body><br>
> </html><br>
><br>
><br>
> From: <a href="mailto:arindam@live.com">arindam@live.com</a> (mailto:<a href="mailto:arindam@live.com">arindam@live.com</a>)<br>
> To: <a href="mailto:rkamaldinov@mirantis.com">rkamaldinov@mirantis.com</a> (mailto:<a href="mailto:rkamaldinov@mirantis.com">rkamaldinov@mirantis.com</a>)<br>
> Subject: RE: [Savanna-all] installation problem<br>
> Date: Fri, 12 Jul 2013 11:33:24 +0200<br>
><br>
> Thanks.<br>
><br>
> Date: Fri, 12 Jul 2013 13:25:45 +0400<br>
> From: <a href="mailto:rkamaldinov@mirantis.com">rkamaldinov@mirantis.com</a> (mailto:<a href="mailto:rkamaldinov@mirantis.com">rkamaldinov@mirantis.com</a>)<br>
> To: <a href="mailto:arindam@live.com">arindam@live.com</a> (mailto:<a href="mailto:arindam@live.com">arindam@live.com</a>)<br>
> CC: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a> (mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>); <a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a> (mailto:<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>)<br>
> Subject: Re: [Savanna-all] installation problem<br>
><br>
> It seems that you're using the latest code from Savanna v0.2, but following instructions from Savanna v0.1.<br>
> Please follow these docs: <a href="https://savanna.readthedocs.org/en/latest/" target="_blank">https://savanna.readthedocs.org/en/latest/</a><br>
><br>
><br>
> Ruslan<br>
><br>
> On Friday, July 12, 2013 at 1:19 PM, Arindam Choudhury wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > While installing savanna I am getting this error:<br>
> ><br>
> > [arindam@sl-3 savanna]$ tox -evenv -- bin/savanna-db-manage --config-file etc/savanna/savanna.conf reset-db --with-gen-templates<br>
> > GLOB sdist-make: /home/arindam/savanna/setup.py<br>
> > venv inst-nodeps: /home/arindam/savanna/.tox/dist/savanna-0.2.a12.gf85d74f.zip<br>
> > venv runtests: commands[0] | bin/savanna-db-manage --config-file etc/savanna/savanna.conf reset-db --with-gen-templates<br>
> > ERROR: InvocationError: could not find executable 'bin/savanna-db-manage'<br>
> > _________________________________________________________________ summary __________________________________________________________________<br>
> > ERROR: venv: commands failed<br>
> ><br>
> ><br>
> > Regards,<br>
> > Arindam<br>
> > --<br>
> > Mailing list: <a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a><br>
> > Post to : <a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a> (mailto:<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>)<br>
> > Unsubscribe : <a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a><br>
> > More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
> ><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Mailing list: <a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a><br>
> Post to : <a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a> (mailto:<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>)<br>
> Unsubscribe : <a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a><br>
> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
><br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/5ceaf3b5/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/5ceaf3b5/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Fri, 12 Jul 2013 13:21:09 +0200<br>
From: Ghe Rivero <<a href="mailto:ghe@debian.org">ghe@debian.org</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [TripleO] mid-cycle sprint?<br>
Message-ID:<br>
<<a href="mailto:CAOdXvV408HGV4dipBws4OWtn6yJFeRumemZxt_LwqXuwn0x4EA@mail.gmail.com">CAOdXvV408HGV4dipBws4OWtn6yJFeRumemZxt_LwqXuwn0x4EA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Thu, Jul 11, 2013 at 9:43 AM, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
<br>
> Excerpts from Robert Collins's message of 2013-07-10 20:54:26 -0700:<br>
> > Clint suggested we do a mid-cycle sprint at the weekly meeting a<br>
> > fortnight ago, but ETIME and stuff - so I'm following up.<br>
> ><br>
> > HP would be delighted to host a get-together of TripleO contributors<br>
> > [or 'I will be contributing soon, honest'] folk.<br>
> ><br>
> > We're proposing a late August / early Sept time - a couple weeks<br>
> > before H3, so we can be dealing with features that have landed //<br>
> > ensuring necessary features *do* land.<br>
> ><br>
> > That would give a start date of the 19th or 26th August. Probable<br>
> > venue of either Sunnyvale, CA or Seattle.<br>
><br>
> Wife booked a trip out of town August 27 - Sep 2 so that time frame is<br>
> unavailable to me.<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>
I'll be in DebConf13 (Switzerland) the week of August 11th-17th so I prefer<br>
the week of the 19th.<br>
<br>
Ghe Rivero<br>
<br>
<br>
<br>
--<br>
Pinky: "Gee, Brain, what do you want to do tonight?"<br>
The Brain: "The same thing we do every night, Pinky?try to take over the<br>
world!"<br>
<br>
.''`. Pienso, Luego Incordio<br>
: :' :<br>
`. `'<br>
`- <a href="http://www.debian.org" target="_blank">www.debian.org</a> <a href="http://www.openstack.com" target="_blank">www.openstack.com</a><br>
<br>
GPG Key: 26F020F7<br>
GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/5293f10b/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/5293f10b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Fri, 12 Jul 2013 07:25:35 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: Gareth <<a href="mailto:academicgareth@gmail.com">academicgareth@gmail.com</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID: <<a href="mailto:51DFE7AF.2070209@dague.net">51DFE7AF.2070209@dague.net</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
We are working towards uncapping all the clients, with the exception of<br>
neutron client, because they need to make some incompatible changes on<br>
their next major release.<br>
<br>
On 07/12/2013 12:12 AM, Gareth wrote:<br>
> so, what's the final conclusion about this issue?<br>
><br>
><br>
> On Fri, Jul 12, 2013 at 12:11 PM, Gareth <<a href="mailto:academicgareth@gmail.com">academicgareth@gmail.com</a><br>
> <mailto:<a href="mailto:academicgareth@gmail.com">academicgareth@gmail.com</a>>> wrote:<br>
><br>
> Thanks, Monty<br>
><br>
> but in my review <a href="https://review.openstack.org/#/c/36684/" target="_blank">https://review.openstack.org/#/c/36684/</a> , Doug said<br>
> we will go without upper bound with those python-*clients<br>
> and in this one <a href="https://review.openstack.org/#/c/36753/" target="_blank">https://review.openstack.org/#/c/36753/</a> ,<br>
> keystoneclient still keep '<0.4' and requirements test doesn't fail<br>
> in keystoneclient<br>
> (<a href="https://jenkins.openstack.org/job/gate-cinder-requirements/96/console" target="_blank">https://jenkins.openstack.org/job/gate-cinder-requirements/96/console</a><br>
> it failed on glanceclient)<br>
><br>
><br>
><br>
><br>
> On Fri, Jul 12, 2013 at 11:54 AM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a><br>
> <mailto:<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>>> wrote:<br>
><br>
><br>
><br>
> On 07/11/2013 11:38 PM, Gareth wrote:<br>
> > I heard there's a talk about this issue in #openstack-infra<br>
> last night<br>
> > (china standard time), what's the conclusion of that?<br>
> ><br>
> > BTW, how to find meeting log of #openstack-infra? I didn't<br>
> find it<br>
> > in <a href="http://eavesdrop.openstack.org/" target="_blank">http://eavesdrop.openstack.org/</a><br>
><br>
> We don't log it currently. There is a wider conversation going<br>
> on about<br>
> which things we should log and which things we should not log<br>
> ... but<br>
> for the time being I've submitted this:<br>
><br>
> <a href="https://review.openstack.org/36773" target="_blank">https://review.openstack.org/36773</a><br>
><br>
> to add -infra. I think we talk about enough things that have<br>
> ramifications on everyone in there that we should really capture it.<br>
> > On Thu, Jul 11, 2013 at 11:35 PM, Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a><br>
> <mailto:<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>><br>
> > <mailto:<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a> <mailto:<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>>>> wrote:<br>
> ><br>
> > >> See for example<br>
> <a href="https://bugs.launchpad.net/horizon/+bug/1196823" target="_blank">https://bugs.launchpad.net/horizon/+bug/1196823</a><br>
> > > This is arguably a deficiency of mox, which<br>
> (apparently?) doesn't<br>
> > let us mock properties automatically.<br>
> ><br>
> > I agree, but it is just one example. other test-only<br>
> issues can<br>
> > happen as well.<br>
> ><br>
> > Similar problem: the *client packages are not<br>
> self-contained, they<br>
> > have pretty strict dependencies on other packages. One<br>
> case I already<br>
> > run into was a dependency on python-requests: newer<br>
> python-*client<br>
> > packages (rightfully) require requests >= 1.x. running<br>
> those on a<br>
> > system that has OpenStack services from Grizzly or Folsom<br>
> installed<br>
> > cause a conflict: there are one or two that require<br>
> requests to be <<br>
> > 1.0.<br>
> ><br>
> > When you run gating on this scenario, I think the same<br>
> flipping would<br>
> > happen on e.g. requests as well, due to *client or the<br>
> module being<br>
> > installed in varying order.<br>
> ><br>
> > Greetings,<br>
> > Dirk<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> > <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <mailto:<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>
> > Gareth<br>
> ><br>
> > /Cloud Computing, OpenStack, Fitness, Basketball/<br>
> > /OpenStack contributor/<br>
> > /Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>/<br>
> > /My promise: if you find any spelling or grammar mistakes in my email<br>
> > from Mar 1 2013, notify me /<br>
> > /and I'll donate $1 or ?1 to an open organization you specify./<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <mailto:<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>
> <mailto:<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>
> Gareth<br>
><br>
> /Cloud Computing, OpenStack, Fitness, Basketball/<br>
> /OpenStack contributor/<br>
> /Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>/<br>
> /My promise: if you find any spelling or grammar mistakes in my<br>
> email from Mar 1 2013, notify me /<br>
> /and I'll donate $1 or ?1 to an open organization you specify./<br>
><br>
><br>
><br>
><br>
> --<br>
> Gareth<br>
><br>
> /Cloud Computing, OpenStack, Fitness, Basketball/<br>
> /OpenStack contributor/<br>
> /Company: UnitedStack <<a href="http://www.ustack.com" target="_blank">http://www.ustack.com</a>>/<br>
> /My promise: if you find any spelling or grammar mistakes in my email<br>
> from Mar 1 2013, notify me /<br>
> /and I'll donate $1 or ?1 to an open organization you specify./<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>
><br>
<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Fri, 12 Jul 2013 07:31:31 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:51DFE913.3070006@dague.net">51DFE913.3070006@dague.net</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 07/12/2013 04:29 AM, Thierry Carrez wrote:<br>
> Monty Taylor wrote:<br>
>> This brings us to the most important question:<br>
>><br>
>> Who wants to be on the core team?<br>
><br>
> That's the important question indeed. Accepting it (permanently or<br>
> temporarily) under stackforge is an easy decision. But it's useless<br>
> unless we have a set of people sufficiently interested in it not<br>
> bitrotting to volunteer to maintain it...<br>
<br>
I'd recommend the nova-db subteam folks, like: jog0, dripton, boris-42<br>
as good people to be +2 on this.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Fri, 12 Jul 2013 15:37:54 +0400<br>
From: Boris Pavlovic <<a href="mailto:boris@pavlovic.me">boris@pavlovic.me</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID:<br>
<<a href="mailto:CAD85om2%2BhfVNnRbn7WgZGbkRabZUFb2_KYdnKCqxhJZCTHNyZQ@mail.gmail.com">CAD85om2+hfVNnRbn7WgZGbkRabZUFb2_KYdnKCqxhJZCTHNyZQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi Sean,<br>
<br>
I agree to help with sqlalchemy-migrate until we remove it.<br>
But probably there should be one more person mikal<br>
<br>
Best regards,<br>
Boris Pavlovic<br>
<br>
<br>
On Fri, Jul 12, 2013 at 3:31 PM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
<br>
> On 07/12/2013 04:29 AM, Thierry Carrez wrote:<br>
><br>
>> Monty Taylor wrote:<br>
>><br>
>>> This brings us to the most important question:<br>
>>><br>
>>> Who wants to be on the core team?<br>
>>><br>
>><br>
>> That's the important question indeed. Accepting it (permanently or<br>
>> temporarily) under stackforge is an easy decision. But it's useless<br>
>> unless we have a set of people sufficiently interested in it not<br>
>> bitrotting to volunteer to maintain it...<br>
>><br>
><br>
> I'd recommend the nova-db subteam folks, like: jog0, dripton, boris-42 as<br>
> good people to be +2 on this.<br>
><br>
> -Sean<br>
><br>
> --<br>
> Sean Dague<br>
> <a href="http://dague.net" target="_blank">http://dague.net</a><br>
><br>
><br>
> ______________________________**_________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.**org <<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><<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/77998c5b/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/77998c5b/attachment-0001.html</a>><br>
<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>
<br>
<br>
End of OpenStack-dev Digest, Vol 15, Issue 22<br>
*********************************************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Wentian Jiang<div>UnitedStack Inc.</div></div>
</div>