Re: [openstack-dev] [release][requirements][FFE] Release ovsdbapp 0.9.1
On Fri, Feb 2, 2018 at 4:30 PM, Matthew Thode wrote: > On 18-02-02 15:59:42, Terry Wilson wrote: >> ovsdbapp 0.9.1 (review https://review.openstack.org/#/c/539489/) has a >> gate-fixing one-line fix (https://review.openstack.org/#/c/537241). >> Can I get a FFE for bumping the requirements to ovsdbapp 0.9.1 once >> the package is built? >> > > Is this just for upper-constraints.txt or for global-requirements.txt as > well? A global-requirements.txt probably makes more sense since 0.9.0 introduced the issue. I don't see any reason why someone would want to install it over 0.9.1. It's literally a one-line difference between the two. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][requirements][FFE] Release ovsdbapp 0.9.1
ovsdbapp 0.9.1 (review https://review.openstack.org/#/c/539489/) has a gate-fixing one-line fix (https://review.openstack.org/#/c/537241). Can I get a FFE for bumping the requirements to ovsdbapp 0.9.1 once the package is built? Terry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Denver Team Dinner
+1 On Tue, Sep 12, 2017 at 6:23 PM, Miguel Lavalle wrote: > Dear Neutrinos, > > Our social event will take place on Thursday September 12th at 7:30pm. The > venue is going to be https://www.famousdaves.com/Denver-Stapleton. It is > located 0.4 miles from the Renaissance Hotel, which translates to an easy 9 > minutes walk. > > I have a reservation for a group of 30 people under my name. Please respond > to this message with your attendance confirmation by Wednesday night, so I > can get a more accurate head count. > > Looking forward to see y'all Thursday night > > Best regards > > Miguel > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday
+1 On Mon, Feb 20, 2017 at 12:57 PM, Lihi Wish wrote: > +1 > > On Feb 20, 2017 1:13 PM, "Omer Anson" wrote: >> >> +1 >> >> On 20 February 2017 at 19:34, Bhatia, Manjeet S >> wrote: >>> >>> +1 >>> >>> >>> >>> From: Kevin Benton [mailto:ke...@benton.pub] >>> Sent: Friday, February 17, 2017 11:19 AM >>> To: openstack-dev@lists.openstack.org >>> Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on >>> Thursday >>> >>> >>> >>> Hi all, >>> >>> >>> >>> I'm organizing a Neutron social event for Thursday evening in Atlanta >>> somewhere near the venue for dinner/drinks. If you're interested, please >>> reply to this email with a "+1" so I can get a general count for a >>> reservation. >>> >>> >>> >>> Cheers, >>> >>> Kevin Benton >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday
+1 On Feb 17, 2017 1:22 PM, "Kevin Benton" wrote: > Hi all, > > I'm organizing a Neutron social event for Thursday evening in Atlanta > somewhere near the venue for dinner/drinks. If you're interested, please > reply to this email with a "+1" so I can get a general count for a > reservation. > > Cheers, > Kevin Benton > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][python3] use of six.iteritems()
On Sep 13, 2016 10:42 PM, "Kevin Benton" wrote: > > >All performance matters. All memory consumption matters. Being wasteful over a purely aesthetic few extra characters of code is silly. > > Isn't the logical conclusion of this to write everything in a different language? :) I'm up for it if you are. :D __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][python3] use of six.iteritems()
On Tue, Sep 13, 2016 at 6:31 PM, Jay Pipes wrote: > On 09/13/2016 01:40 PM, Terry Wilson wrote: >> >> On Thu, Jun 11, 2015 at 8:33 AM, Sean Dague wrote: >>> >>> On 06/11/2015 09:02 AM, Jay Pipes wrote: >>>> >>>> On 06/11/2015 01:16 AM, Robert Collins wrote: >>>>> >>>>> But again - where in OpenStack does this matter the slightest? >>>> >>>> >>>> Precisely. I can't think of a single case where we are iterating over >>>> anywhere near the number of dictionary items that we would see any >>>> impact whatsoever. >> >> >> In neutron, the ovsdb native code iterates over fairly large >> dictionaries since the underlying OVS library stores OVSDB tables >> completely in memory as dicts. I just looked at the code I wrote and >> it currently uses values() and I now want to switch it to >> six.itervalues() :p. >> >>>> Best, >>>> -jay >>> >>> >>> +1. >>> >>> This is a massive premature optimization which just makes all the code >>> gorpy for no real reason. >> >> >> Premature optimization is about wasting a bunch of time trying to >> optimize code before you know you need to, not about following the >> accepted almost-always-faster/always-less-memory-using solution that >> already exists. Memory-wise it's the difference between a constant >> 88-byte iterator and the storage for an additional list of tuples. And >> if Raymond Hettinger, in a talk called "Transforming Code Into >> Beautiful Idiomatic Python" specifically mentions that people should >> always use iteritems >> (https://www.youtube.com/watch?v=OSGv2VnC0go&feature=youtu.be&t=21m24s), >> I tend to believe him. Sure, it'd be much better if Python 3 and >> Python 2 both returned iterators for items(), values(), keys(), etc., >> but it doesn't. Wasting memory for purely aesthetic reasons (they're >> even both the same number of lines) is just a bad idea, IMNSHO. > > > Is it wasted time to respond to a mailing list post from 18 months ago? > > -jay Ha! Absolutely it is. Someone posted a Neutron patch haphazardly converting all of of the six.iteritems() calls to items() and it struck a nerve. I searched for the thread in gmail not noticing the date. My apologies! :) Terry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][python3] use of six.iteritems()
On Thu, Jun 11, 2015 at 8:33 AM, Sean Dague wrote: > On 06/11/2015 09:02 AM, Jay Pipes wrote: >> On 06/11/2015 01:16 AM, Robert Collins wrote: >>> But again - where in OpenStack does this matter the slightest? >> >> Precisely. I can't think of a single case where we are iterating over >> anywhere near the number of dictionary items that we would see any >> impact whatsoever. In neutron, the ovsdb native code iterates over fairly large dictionaries since the underlying OVS library stores OVSDB tables completely in memory as dicts. I just looked at the code I wrote and it currently uses values() and I now want to switch it to six.itervalues() :p. >> Best, >> -jay > > +1. > > This is a massive premature optimization which just makes all the code > gorpy for no real reason. Premature optimization is about wasting a bunch of time trying to optimize code before you know you need to, not about following the accepted almost-always-faster/always-less-memory-using solution that already exists. Memory-wise it's the difference between a constant 88-byte iterator and the storage for an additional list of tuples. And if Raymond Hettinger, in a talk called "Transforming Code Into Beautiful Idiomatic Python" specifically mentions that people should always use iteritems (https://www.youtube.com/watch?v=OSGv2VnC0go&feature=youtu.be&t=21m24s), I tend to believe him. Sure, it'd be much better if Python 3 and Python 2 both returned iterators for items(), values(), keys(), etc., but it doesn't. Wasting memory for purely aesthetic reasons (they're even both the same number of lines) is just a bad idea, IMNSHO. Terry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][python3] use of six.iteritems()
On Wed, Jun 10, 2015 at 4:41 AM, Robert Collins wrote: > On 10 June 2015 at 21:30, Ihar Hrachyshka wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On 06/10/2015 02:15 AM, Robert Collins wrote: >>> I'm very glad folk are working on Python3 ports. >>> >>> I'd like to call attention to one little wart in that process: I >>> get the feeling that folk are applying a massive regex to find >>> things like d.iteritems() and convert that to six.iteritems(d). >>> >>> I'd very much prefer that such a regex approach move things to >>> d.items(), which is much easier to read. >>> >>> Here's why. Firstly, very very very few of our dict iterations are >>> going to be performance sensitive in the way that iteritems() >>> matters. Secondly, no really - unless you're doing HUGE dicts, it >>> doesn't matter. Thirdly. Really, it doesn't. >>> >> >> Does it hurt though? ;) > > Yes. > > Its: harder to read. Its going to have to be removed eventually anyway > (when we stop supporting 2.7). Its marginally slower on 3.x (it has a > function and an iterator wrapping the actual thing). Its unidiomatic, > and we get lots of programmers that are new to Python; we should be > giving them as beautiful code as we can to help them learn. If someone is so new they can't handle six.iteritems, they should stay away from Neutron code. It'll eat them. >>> At 1 million items the overhead is 54ms[1]. If we're doing inner >>> loops on million item dictionaries anywhere in OpenStack today, we >>> have a problem. We might want to in e.g. the scheduler... if it >>> held in-memory state on a million hypervisors at once, because I >>> don't really to to imagine it pulling a million rows from a DB on >>> every action. But then, we'd be looking at a whole 54ms. I think we >>> could survive, if we did that (which we don't). >>> >>> So - please, no six.iteritems(). Huge -1 from me. The "I like looking at d.items() more than I like looking at six.iteritems(d) so make everything (even slightly) less efficient" argument is insane to me. All performance matters. All memory consumption matters. Being wasteful over a purely aesthetic few extra characters of code is silly. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core
On Tue, Jul 26, 2016 at 10:04 AM, Jakub Libosvar wrote: > On 26/07/16 16:56, Assaf Muller wrote: >> >> We've hit critical mass from cores interesting in the testing area. >> >> Welcome Jakub to the core reviewer team. May you enjoy staring at the >> Gerrit interface and getting yelled at by people... It's a glamorous >> life. > > > Thanks everyone for support! I'll try to do my best :) Congrats! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ovs] The way we deal with MTU
> So basically, as long as we try to plug ports with different MTUs into the > same bridge, we are utilizing a bug in Open vSwitch, that may break us any > time. > > I guess our alternatives are: > - either redesign bridge setup for openvswitch to e.g. maintain a bridge per > network; > - or talk to ovs folks on whether they may support that for us. > > I understand the former option is too scary. It opens lots of questions, > including upgrade impact since it will obviously introduce a dataplane > downtime. That would be a huge shift in paradigm, probably too huge to > swallow. The latter option may not fly with vswitch folks. Any better ideas? I know I've heard from people who'd like to be able to support both DPDK and non-DPDK workloads on the same node. The current implementation with a single br-int (and thus datapath) makes that impossible to pull of with good performance. So there may be other reasons to consider introducing multiple isolated bridges: MTUs, datapath_types, etc. Terry On Mon, Jun 13, 2016 at 11:49 AM, Ihar Hrachyshka wrote: > Hi all, > > in Mitaka, we introduced a bunch of changes to the way we handle MTU in > Neutron/Nova, making sure that the whole instance data path, starting from > instance internal interface, thru hybrid bridge, into the br-int; as well as > router data path (qr) have proper MTU value set on all participating devices. > On hypervisor side, both Nova and Neutron take part in it, setting it with > ip-link tool based on what Neutron plugin calculates for us. So far so good. > > Turns out that for OVS, it does not work as expected in regards to br-int. > There was a bug reported lately: https://launchpad.net/bugs/1590397 > > Briefly, when we try to set MTU on a device that is plugged into a bridge, > and if the bridge already has another port with lower MTU, the bridge itself > inherits MTU from that latter port, and Linux kernel (?) does not allow to > set MTU on the first device at all, making ip link calls ineffective. > > AFAIU this behaviour is consistent with Linux bridging rules: you can’t have > ports of different MTU plugged into the same bridge. > > Now, that’s a huge problem for Neutron, because we plug ports that belong to > different networks (and that hence may have different MTUs) into the same > br-int bridge. > > So I played with the code locally a bit and spotted that currently, we set > MTU for router ports before we move their devices into router namespaces. And > once the device is in a namespace, ip-link actually works. So I wrote a fix > with a functional test that proves the point: > https://review.openstack.org/#/c/327651/ The fix was validated by the > reporter of the original bug and seems to fix the issue for him. > > It’s suspicious that it works from inside a namespace but not when the device > is still in the root namespace. So I reached out to Jiri Benc from our local > Open vSwitch team, and here is a quote: > > === > > "It's a bug in ovs-vswitchd. It doesn't see the interface that's in > other netns and thus cannot enforce the correct MTU. > > We'll hopefully fix it and disallow incorrect MTU setting even across > namespaces. However, it requires significant effort and rework of ovs > name space handling. > > You should not depend on the current buggy behavior. Don't set MTU of > the internal interfaces higher than the rest of the bridge, it's not > supported. Hacking this around by moving the interface to a netns is > exploiting of a bug. > > We can certainly discuss whether this limitation could be relaxed. > Honestly, I don't know, it's for a discussion upstream. But as of now, > it's not supported and you should not do it.” > > So basically, as long as we try to plug ports with different MTUs into the > same bridge, we are utilizing a bug in Open vSwitch, that may break us any > time. > > I guess our alternatives are: > - either redesign bridge setup for openvswitch to e.g. maintain a bridge per > network; > - or talk to ovs folks on whether they may support that for us. > > I understand the former option is too scary. It opens lots of questions, > including upgrade impact since it will obviously introduce a dataplane > downtime. That would be a huge shift in paradigm, probably too huge to > swallow. The latter option may not fly with vswitch folks. Any better ideas? > > It’s also not clear whether we want to proceed with my immediate fix. Advices > are welcome. > > Thanks, > Ihar > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.or
Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?
> Right now I'm leaning toward "parent always does nothing" + PluginWorker. > Everything is forked, no special case for workers==0, and explicit > designation of the "only one" case. Of course, it's still early in the day > and I haven't had any coffee. I have updated the patch (https://review.openstack.org/#/c/189391/) to implement the above. I have it marked WIP because it doesn't have any tests and it modifies ServicePluginBase to have a call to get_processes(), but almost no service plugins actually inherit from it even though they implement its interface. The get_processes stuff in general could be fleshed out a bit as well. I just wanted to get something up for the purposes of discussion, so anyone interested in this particular problem should take a look and discuss. :) Terry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?
There are two classes of behavior that need to be handled:
1) There are things that can only be done after forking like setting up
connections or spawning threads.
2) Some things should only be done once regardless of number of forks, like
syncing.
Even when you just want something to happen once, there is a good chance you
may need that to happen post-fork. For example, syncing between OVSDB and
neutron databases requires a socket connection and we don't want to have it
going on 16 times.
Case 1 is a little complex due to how we launch api/rpc worker threads. The
obvious place to notify that a fork is complete is in the
RpcWorker/WorkerService start() methods, since they are the only code outside
of openstack.common.service that is really called post-fork. The problem is the
case where api_workers==rpc_workers==0. In this case, the parent process calls
start() on both, so you end up with two calls to your post-fork initialization
and only one process. It is easy enough to pass whether or not start() should
call the initialization, or whether we hold off and let the main process do it
before calling waitall()--it's just a bit ugly (see my patch:
https://review.openstack.org/#/c/189391/).
Another option to handle case 1 would be to kill the case where you have a
single process handling both workers. Always have the parent do nothing, and
fork a process for each api/rpc worker treating workers=0 as workers=1. Then,
start() can safely be used without hacking around the special case.
Case 2 the problem is "which process is *the one*?" The fork() call happens in
the weird bastardized eventlet-threading hybrid openstack.common ThreadGroup
stuff, so who knows what order things are really happening. The easiest thing
to detect as unique is the parent process through some plugin pre-fork call
that stores the parent's pid. The problem with using the parent process for the
'do it once' case is that we have to be able to guarantee that all the forking
is really done, and it happens eventlety. Maybe an accumulator that fires off
an event when api_workers + rpc_workers fork() events received? Anyway, it's
messy.
Another option for 2 would be to let the plugin specify that it needs its own
worker process. If so, spawn it call PluginWorker.start() which initializes
after-fork. Seems like it could be cleaner.
Right now I'm leaning toward "parent always does nothing" + PluginWorker.
Everything is forked, no special case for workers==0, and explicit designation
of the "only one" case. Of course, it's still early in the day and I haven't
had any coffee.
Terry
- Original Message -
> This depends on what initialize is supposed to be doing. If it's just a
> one-time sync with a back-end, then I think calling it once in each child
> process might not be what we want.
>
> I left a comment on Terry's patch. I think we should just use the callback
> manager to have a pre-fork and post-fork even to let drivers/plugins do
> whatever is appropriate for them.
>
> On Mon, Jun 8, 2015 at 1:00 PM, Robert Kukura < kuk...@noironetworks.com >
> wrote:
>
>
>
> From a driver's perspective, it would be simpler, and I think sufficient, to
> change ML2 to call initialize() on drivers after the forking, rather than
> requiring drivers to know about forking.
>
> -Bob
>
>
> On 6/8/15 2:59 PM, Armando M. wrote:
>
>
>
> Interestingly, [1] was filed a few moments ago:
>
> [1] https://bugs.launchpad.net/neutron/+bug/1463129
>
> On 2 June 2015 at 22:48, Salvatore Orlando < sorla...@nicira.com > wrote:
>
>
>
> I'm not sure if you can test this behaviour on your own because it requires
> the VMware plugin and the eventlet handling of backend response.
>
> But the issue was manifesting and had to be fixed with this mega-hack [1].
> The issue was not about several workers executing the same code - the
> loopingcall was always started on a single thread. The issue I witnessed was
> that the other API workers just hang.
>
> There's probably something we need to understand about how eventlet can work
> safely with a os.fork (I just think they're not really made to work
> together!).
> Regardless, I did not spent too much time on it, because I thought that the
> multiple workers code might have been rewritten anyway by the pecan switch
> activities you're doing.
>
> Salvatore
>
>
> [1] https://review.openstack.org/#/c/180145/
>
> On 3 June 2015 at 02:20, Kevin Benton < blak...@gmail.com > wrote:
>
>
>
> Sorry about the long delay.
>
> > Even the LOG.error("KEVIN PID=%s network response: %s" % (os.getpid(),
> > r.text)) line? Surely the server would have forked before that line was
> > executed - so what could prevent it from executing once in each forked
> > process, and hence generating multiple logs?
>
> Yes, just once. I wasn't able to reproduce the behavior you ran into. Maybe
> eventlet has some protection for this? Can you provide small sample code for
> the logging driver that does r
Re: [openstack-dev] [nova] release request for python-novaclient
- Original Message - > On Feb 19, 2015, at 11:52, Terry Wilson wrote: > > > Unfortunately, the new novaclient release ended up completely breaking the > > neutron gate. The v1_1 deprecation broke our (voting) pylint test: > > https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console > > > > 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > > (no-name-in-module) > > 2015-02-19 18:37:06.932 | No name 'contrib' in module > > 'novaclient.v1_1'(no-name-in-module) > > 2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > > (no-name-in-module) > > Hi Terry, > > Sorry to hear about this. I looked into this and the problem is pylint can't > parse the backward-compatibility we have for the v1_1 deprecation: > > https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm > > The actual code should work but pylint static checking will fail to follow > it. So far, the options I see to handle it are to either patch > s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific pylint > check that's failing (if it's not too broad). > > Do you find either of these options acceptable, or have another idea? We've currently just disabled the pylint gate tests, and I've posted a patch for neutron to resolve the issue. Looks like there was a similar patch already up for review as well, though it only catches one of our uses of novaclient. There's still a bit of an issue that there is no version-neutral way to import the 'contrib' stuff like there is for 'client'. So: from novaclient.v1_1.contrib import server_external_events has to become from novaclient.v2.contrib import server_external_events which doesn't work on previous versions of novaclient. It's possible to hack around it using importutils, but it's pretty ugly. Terry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] release request for python-novaclient
> Sorry, I dropped the ball here. This is now released. Unfortunately, the new novaclient release ended up completely breaking the neutron gate. The v1_1 deprecation broke our (voting) pylint test: https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' (no-name-in-module) 2015-02-19 18:37:06.932 | No name 'contrib' in module 'novaclient.v1_1'(no-name-in-module) 2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' (no-name-in-module) Terry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture
- Original Message - > What's the progress by Terry Wilson? > If not much, I'm willing to file blueprint/spec and drive it. > > thanks, I've been working on some proof-of-concept code to help flesh out ideas for writing the spec. I'd talked to Maru and he mentioned that he didn't think that the official OVS python library was a good base for this (the one that ryu uses). I don't remember what all of the reasons were, though. It isn't particularly well documented, but that can always be remedied. Does anyone else have any experience with the official OVS python API who could speak to its quality/stability/usefulness? It looked fairly full-featured. Terry > On Wed, Jun 18, 2014 at 07:00:59PM +0900, > Isaku Yamahata wrote: > > > Hi. Ryu provides ovs_vsctl.py library which is python equivalent to > > ovs-vsctl command. It speaks OVSDB protocl. > > https://github.com/osrg/ryu/blob/master/ryu/lib/ovs/vsctl.py > > > > So with the library, it's mostly mechanical change to convert > > ovs_lib.py, I think. > > I'm not aware other similar library written in python. Most of ryu's library is implemented on top of the official OVS python stuff: https://github.com/openvswitch/ovs/tree/master/python/ovs Terry ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] bug/129135 VXLAN kernel version checking
>> A question about the fix from https://review.openstack.org/#/c/82931 > Also, how does this work for RHEL-based distros where they tend to backport > new kernel features? For instance vxlan support was added in the kernel for > RHEL6.5 which is 2.6.32-based... That changeset looks like it breaks Neutron > for ovs + vxlan on RHEL distros. > Nate The simple answer is that it doesn't work at all on RHEL. RHEL has backported upstream VXLAN support to the 2.6.32 kernel they use. It is fundamentally unsound to be checking kernel version numbers at runtime. Checking kernel version numbers in upstream code at runtime is just a fundamentally flawed thing to do. The only way those numbers mean anything is if they are in downstream packaging dependencies. There is also a lot of cruft that comes along with having to test all kinds of different things to ensure that the flawed check "works". It quickly gets very messy. It is almost universally accepted that if you want to test whether support exists for a feature, instead of trying to track version numbers across who knows how many options, you try to use the feature and then fail/fallback gracefully. I have a patch here https://review.openstack.org/#/c/88121/ which rips out all of the version checking and instead, at runtime when vxlan support is enabled, tries to create a temporary bridge/vxlan port and exits the openvswitch agent with a useful error message. With that said, I'm not a huge fan of modifying system state at startup just to test this. IMHO it might be better to just remove the check at startup altogether and error out with an informative message during the normal course when a VXLAN port cannot be created. Anyway, if people could take a look at the review: https://review.openstack.org/#/c/88121/ And perhaps have some discussion here, on list, about what we think is the best way to move forward with this, I'd be happy. :) Terry ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] tempest failure: No more IP addresses available on network
> Hi, > > I just noticed several number of neutron check > (tempest-devstack-vm-neutron-isolated) fails with the same error: > "No more IP addresses available on network". > This errors suddenly starts to occur from yesterday. > > I checked there is any commit merge around the time when this failure > started, > but there is no commit around the time. > I am not sure it is a temporary issue. > > I files a bug in neutron: https://bugs.launchpad.net/neutron/+bug/1243726 > > It is late in my timezone. I hope someone jumps into this issue. > > > logstash stats is here: > http://logstash.openstack.org/index.html#eyJzZWFyY2giOiJcIklwQWRkcmVzc0dlbmVyYXRpb25GYWlsdXJlQ2xpZW50OiBObyBtb3JlIElQIGFkZHJlc3NlcyBhdmFpbGFibGUgb24gbmV0d29yayBcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4MjUzNzk0OTgxMH0= > > Thanks, > Akihiro Yes. This is still happening on my patch (and many others) as well. Terry ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
