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