Re: [openstack-dev] [all] cross project communication: Return request-id to caller
Doesn’t this overlap with the work done for the OSProfiler ? More comments inline. Miguel Ángel Ajo On Wednesday, 3 de June de 2015 at 11:43, Kekane, Abhishek wrote: > Hi Devs, > > So for I have got following responses on the proposed solutions: > > Solution 1: Return tuple containing headers and body from - 3 +1 > Solution 2: Use thread local storage to store 'x-openstack-request-id' > returned from headers - 0 +1 > Solution 3: Unique request-id across OpenStack Services - 1 +1 > > I’d vote for Solution 3, without involving keystone (first caller with no req-id generates one randomly), the req-id contains a call/hop count, which is incremented on every new call... > > > > > Requesting community people, cross-project members and PTL's to go through > this mailing thread [1] and give your suggestions/opinions about the > solutions proposed so that It will be easy to finalize the solution. > > [1] http://lists.openstack.org/pipermail/openstack-dev/2015-May/064842.html > > Thanks & Regards, > > Abhishek Kekane > > -Original Message- > From: Nikhil Komawar [mailto:nik.koma...@gmail.com] > Sent: 28 May 2015 12:34 > To: openstack-dev@lists.openstack.org > (mailto:openstack-dev@lists.openstack.org) > Subject: Re: [openstack-dev] [all] cross project communication: Return > request-id to caller > > Did you get to talk with anyone in the LogWG ( > https://wiki.openstack.org/wiki/LogWorkingGroup )? In wonder what kind of > recommendations, standards we can come up with while adopting a cross project > solution. If our logs follow certain prefix and or suffix style across > projects, that would help a long way. > > Personally: +1 on Solution 1 > > On 5/28/15 2:14 AM, Kekane, Abhishek wrote: > > > > Hi Devs, > > > > > > Thank you for your opinions/thoughts. > > > > However I would like to suggest that please give +1 against the > > solution which you will like to propose so that at the end it will be > > helpful for us to consolidate the voting against each solution and > > make some decision. > > > > > > Thanks in advance. > > > > > > Abhishek Kekane > > > > > > > > *From:*Joe Gordon [mailto:joe.gord...@gmail.com] > > *Sent:* 28 May 2015 00:31 > > *To:* OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] [all] cross project communication: > > Return request-id to caller > > > > > > > > > > On Wed, May 27, 2015 at 12:06 AM, Kekane, Abhishek > > mailto:abhishek.kek...@nttdata.com>> wrote: > > > > Hi Devs, > > > > > > Each OpenStack service sends a request ID header with HTTP responses. > > This request ID can be useful for tracking down problems in the logs. > > However, when operation crosses service boundaries, this tracking can > > become difficult, as each service has its own request ID. Request ID > > is not returned to the caller, so it is not easy to track the request. > > This becomes especially problematic when requests are coming in > > parallel. For example, glance will call cinder for creating image, but > > that cinder instance may be handling several other requests at the > > same time. By using same request ID in the log, user can easily find > > the cinder request ID that is same as glance request ID in the g-api > > log. It will help operators/developers to analyse logs effectively. > > > > > > Thank you for writing this up. > > > > > > > > To address this issue we have come up with following solutions: > > > > > > Solution 1: Return tuple containing headers and body from > > respective clients (also favoured by Joe Gordon) > > > > Reference: > > > > https://review.openstack.org/#/c/156508/6/specs/log-request-id-mapping > > s.rst > > > > > > Pros: > > > > 1. Maintains backward compatibility > > > > 2. Effective debugging/analysing of the problem as both calling > > service request-id and called service request-id are logged in > > same log message > > > > 3. Build a full call graph > > > > 4. End user will able to know the request-id of the request and > > can approach service provider to know the cause of failure of > > particular request. > > > > > > Cons: > > > > 1. The changes need to be done first in cross-projects before > > making changes in clients > > >
Re: [openstack-dev] [Neutron] virtual machine can not get DHCP lease due packet has no checksum
Ooook, fully understood now. Thanks Ihar & Ian for the clarification :) Miguel Ángel Ajo On Tuesday, 2 de June de 2015 at 13:33, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 06/02/2015 10:10 AM, Miguel Ángel Ajo wrote: > > The backport seems reasonable IMO. > > > > Is this tested in a multihost environment?. > > > > I ask, because given the Ian explanation (which probably I got > > wrong), the issue is in the NET->NIC->VM path while the patch fixes > > the path in the network node (this is ran in the dhcp agent). > > dhcp->NIC->NET. > > > > > If a packet goes out of your real NIC, then it gets a proper checksum > attached. So the issue is single host only. > > Ihar > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVbZSjAAoJEC5aWaUY1u57nWQIAImV2DxUIK1f1NPvuKkm/Del > lfi90sDNSo8sIOmkLzey8n/1Dyrb9QTzZlb5XpJlG+HLmuRa+AwaWuyNswKJvHEu > MlMBNPawdimlmyn0uLs+QwQOjL31HOb4SD76DOHGc8X2LVOz4PXf0KO2s0PbjU2v > bfm+Yo+lhC7ZMAeebEcjNO6s28TSzRhOzQ7H1ItlPcJFrchcYCRJ1l2vdmcL69DO > FzndWaAQ1R8xGKy2giOt4dc2x/cEad3ZTI/v573aOTJg3UWfHp6GbFfwkuWZzHbW > U+UAezEogg3P++cv0eEwnQEeNhyN/eO2aV928kpPgJaw4T/6HFBGmp+yhOINXjQ= > =fQ24 > -END PGP SIGNATURE- > > __ 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] virtual machine can not get DHCP lease due packet has no checksum
The backport seems reasonable IMO. Is this tested in a multihost environment?. I ask, because given the Ian explanation (which probably I got wrong), the issue is in the NET->NIC->VM path while the patch fixes the path in the network node (this is ran in the dhcp agent). dhcp->NIC->NET. Best, Miguel Ángel Ajo On Tuesday, 2 de June de 2015 at 9:32, Ian Wells wrote: > The fix should work fine. It is technically a workaround for the way > checksums work in virtualised systems, and the unfortunate fact that some > DHCP clients check checksums on packets where the hardware has checksum > offload enabled. (This doesn't work due to an optimisation in the way QEMU > treats packet checksums. You'll see the problem if your machine is running > the VM on the same host as its DHCP server and the VM has a vulnerable > client.) > > I haven't tried it myself but I have confidence in it and would recommend a > backport. > -- > Ian. > > On 1 June 2015 at 21:32, Kevin Benton (mailto:blak...@gmail.com)> wrote: > > I would propose a back-port of it and then continue the discussion on the > > patch. I don't see any major blockers for back-porting it. > > > > On Mon, Jun 1, 2015 at 7:01 PM, Tidwell, Ryan > (mailto:ryan.tidw...@hp.com)> wrote: > > > Not seeing this on Kilo, we're seeing this on Juno builds (that's > > > expected). I'm interested in a Juno backport, but mainly wanted to be > > > see if others had confidence in the fix. The discussion in the bug > > > report also seemed to indicate there were other alternative solutions > > > others might be looking into that didn't involve an iptables rule. > > > > > > -Ryan > > > > > > -Original Message- > > > From: Mark McClain [mailto:m...@mcclain.xyz] > > > Sent: Monday, June 01, 2015 6:47 PM > > > To: OpenStack Development Mailing List (not for usage questions) > > > Subject: Re: [openstack-dev] [Neutron] virtual machine can not get DHCP > > > lease due packet has no checksum > > > > > > > > > > On Jun 1, 2015, at 7:26 PM, Tidwell, Ryan > > > (mailto:ryan.tidw...@hp.com)> wrote: > > > > > > > > I see a fix for https://bugs.launchpad.net/neutron/+bug/1244589 merged > > > > during Kilo. I'm wondering if we think we have identified a root cause > > > > and have merged an appropriate long-term fix, or if > > > > https://review.openstack.org/148718 was merged just so there's at least > > > > a fix available while we investigate other alternatives. Does anyone > > > > have an update to provide? > > > > > > > > -Ryan > > > > > > The fix works in environments we’ve tested in. Are you still seeing > > > problems? > > > > > > mark > > > __ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > (http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > -- > > Kevin Benton > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > (http://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 > (mailto: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] [fwaas] - Collecting use cases for PI improvements
Hi! ;) On Thursday, 28 de May de 2015 at 9:03, Gal Sagie wrote: > Hello All, > > The session talk was mainly about merging the Security Group API and the > FWaaS API to the same one or to keep them separate, > Which i don't think we reached agreement (or did we? :) ) I can’t tell either ;) > > I personally think (And few people approached us in the summit to express > that they feel the same) that we need to allow the user the full set of > features > to be able to configure both on the "perimeter" firewall and on the VM port, > we can make the UI easier to apply a set of the features (similar to security > groups for example) > on the VM ports but i feel merging the API's would make things easier in the > long run (and then you can apply it either on the VM port or the router ports > and of course > choose to apply only a simpler subset of the features) I guess, the complexity here lies in deprecating the security group API while offering a migration path, probably proxying security group calls to FWaaS?, for full deprecation I guess you may need to coordinate with nova. FWaaS also lacks the ability to reference groups in rules, or is it capable of such thing? (ingress all from ‘sg-id’) Also you may want to make the FirewallDriver used for security groups part of FWaaS, and reuse/redesign the messaging mechanisms. I have mixed feelings about it, but I guess it could be a reasonable path so all the Firewall things are in one place, and not two. > > > There are many security use cases that are detected and handled better on the > Hypervisor / VM level which the current > security groups API doesn’t cover. > > For the staying compatible with Amazon argument, i understand and think its > important point, but there are already differences between different cloud > providers (For example if you take Azure its "Security Group" features > include actions) and i don’t think we need to hold off features and > innovation because others aren’t doing it. I agree, that we shouldn’t stop innovation even if others aren’t doing it, otherwise we’re putting a ceiling on our capabilities, and we’re always going to be behind proprietary/closed source public clouds... > > > We have already suggested and implemented (in review) easy way to extend new > rule classes for security groups [1], [2] > And have implemented one use case for this [3], [4] (brute force prevention) > (which we done a nice > research/analytic to create templates for common protocols login > rates/retries and how to detected brute force probabilities - > can extend in private if anyone is interested but everything can be seen in > the code) > > I also feel that auditing visibility is important for security groups and i > have a joint (with Roey Chen from VMware) API spec [5] > and reference implementation spec [6] to extend security groups auditing > capabilities > That came up into the “ovs sg ludicrous speed” talk, we may need auditing actions support in OvS at some point. Miguel Ángel Ajo, > None the less, would love to help and contribute code in any effort around > this area and would like to see this move forward, i believe we have > an opportunity to give added value to the users with this. > > Thanks > Gal. > > [1] https://review.openstack.org/#/c/169784/ > [2] https://review.openstack.org/#/c/154535/ > [3] https://review.openstack.org/#/c/151247/ > [4] https://review.openstack.org/#/c/184243/ > [5] https://review.openstack.org/#/c/180078/ > [6] https://review.openstack.org/#/c/180419/ > > On Thu, May 28, 2015 at 4:51 AM, Sridar Kandaswamy (skandasw) > mailto:skand...@cisco.com)> wrote: > > Hi All: > > > > Thanks German for articulating this – we did have this discussion on last > > Fri as well on the need to have more user inputs. FWaaS has been in a bit > > of a Catch22 situation with the experimental state. Regarding feature > > velocity – it has definitely been frustrating and we also lost > > contributors along the journey due to their frustration with moving things > > forward making things worse. > > > > Kilo has been interesting in that there are more new contributors, repo > > split and more in terms of vendor support has gone in than ever before. We > > hope that this will improve traction for the customers they represent as > > well. Adding more user inputs and having a concerted conversation will > > definitely help. I echo Kyle and can certainly speak for all the current > > contributors in also helping out in any way possible to get this going. New > > Contributors are always welcome – Slawek & Vikram among the most recent >
Re: [openstack-dev] [Ironic][Neutron] Ironic/Neutron Integration weekly meeting kick off
Thanks for sharing Sukhdev, I’ll join the meetings. Miguel Ángel Ajo On Thursday, 28 de May de 2015 at 6:59, Sukhdev Kapur wrote: > Folks, > > Starting next monday (June 1, 2015), we are kicking off weekly meeting to > discuss and track the integration of Ironic and Neutron (ML2). > We are hoping to implement the Networking support within Liberty cycle. Come > join and help us achieve this goal. > > Anybody who is interested in this topic, wants to contribute, share their > wisdom with the team, are welcome to join us. Here are the details of the > meeting: > > > Weekly on Mondays at 1600 UTC (9am Pacific Time) > > IRC Channel - #openstack-meeting-4 > > > Meeting Agenda and team charter - > > https://wiki.openstack.org/wiki/Meetings/Ironic-neutron > > > Feel free to add a topic to the agenda for discussion. > > Looking forward to meeting you in the channel. > > regards.. > -Sukhdev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto: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] Stepping down from Neutron core team
Ahh, I missed this email while I was in the summit. Thank you for so many years of hard work Salvatore, as Edgar said, your “pedant” comments made it better. I will miss your sense of humor ;) Best, Miguel Ángel Ajo On Thursday, 21 de May de 2015 at 21:04, Gary Kotton wrote: > -1 > > From: Carl Baldwin mailto:c...@ecbaldwin.net)> > Reply-To: OpenStack List (mailto:openstack-dev@lists.openstack.org)> > Date: Thursday, May 21, 2015 at 11:32 AM > To: OpenStack List (mailto:openstack-dev@lists.openstack.org)> > Subject: Re: [openstack-dev] [Neutron] Stepping down from Neutron core team > > > On May 21, 2015 9:06 AM, "Kyle Mestery" (mailto:mest...@mestery.com)> wrote: > > > > On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando > (mailto:sorla...@nicira.com)> wrote: > >> > >> After putting the whole OpenStack networking contributors community > >> through almost 8 cycles of pedant comments and annoying "what if" > >> questions, it is probably time for me to relieve neutron contributors from > >> this burden. > >> > >> It has been a pleasure for me serving the Neutron community (or Quantum as > >> it was called at the time), and now it feel right - and probably overdue - > >> to relinquish my position as a core team member in a spirit of rotation > >> and alternation between contributors. > >> > >> Note: Before you uncork your champagne bottles, please be aware that I > >> will stay in the Neutron community as a contributors and I might still end > >> up reviewing patches. > >> > >> Thanks for being so understanding with my pedant remarks, > >> Salvatore > >> > > > > If I could -1 this as a patch, I would. > > > > But seriously. Salvatore, thanks for all the years of work you've put into > > Neutron. Please note that just because you've stepped down from the core > > reviewer team doesn't mean we won't be relying on you to be a part of the > > community. > > > > Thanks, > > Kyle > Kyle, I think you should -2 this one. ;) Maybe we should put the core team > list in a repo just so you can. > All joking aside, @Salv, I have appreciated your feedback much more than you > give yourself credit for, maybe more than I let on. You don't need to be a > core to give it, so keep it coming. > Carl > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto: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][QoS] Neutron QoS (Quality Of Service) update
Gal, thank you very much for the update to the list, I believe it’s very helpful, I’ll add some inline notes. On Thursday, 7 de May de 2015 at 8:51, Gal Sagie wrote: > Hello All, > > I think that the Neutron QoS effort is progressing into critical point and i > asked Miguel if i could post an update on our progress. > > First, i would like to thank Sean and Miguel for running this effort and > everyone else that is involved, i personally think its on the right track, > However i would like to see more people involved, especially more Neutron > experienced members because i believe we want to make the right decisions and > learn from past mistakes when making the API design. > > Feel free to update in the meeting wiki [1], and the spec review [2] > > Topics > > API microversioning spec implications [3] > QoS can benefit from this design, however some concerns were raised that this > will > only be available at mid L cycle. > I think a better view is needed how this aligns with the new QoS design and > any feedback/recommendation is use full I guess an strategy here could be: go on with an extension, and translate that into an experimental API once micro versioning is ready, then after one cycle we could “graduate it” to get versioned. > > > Changes to the QoS API spec: scoping into bandwidth limiting > At this point the concentration is on the API and implementation > of bandwidth limiting. > > However it is important to keep the design easily extensible for some next > steps > like traffic classification and marking. > > Changes to the QoS API spec: modeling of rules (class hierarchy) (Guarantee > split out) > There is a QoSPolicy which is composed of different QoSRules, there is > a discussion of splitting the rules into different types like QoSRule. > (This in order to support easy extension of this model by adding new type > of rules which extend the possible parameters) > > Plugins can then separate optional aspects into separate rules. > Any feedback on this approach is appreciated. > > Discuss multiple API end points (per rule type) vs single here, the topic name was incorrect, where I said API end points, we were meaning URLs or REST resources.. (thanks Irena for the correction) > > In summary this means that in the above model, do we want to support > /v1/qosrule/.. or /v1/qosrule/ API's > I think the consensus right now is that the later is more flexible. > > Miguel is also checking the possibility of using something like: > /v1/qosrule/type/... kind of parsing > Feedback is desired here too :) > > Traffic Classification considerations > The idea right now is to extract the TC classification to another data model > and attach it to rule > that way no need to repeat same filters for the same kind of traffic. > > Of course we need to consider here what it means to "update" a classifier > and not to introduce too much dependencies About this, the intention is not to fully model this, or to include it in the data model now, but try to see how could we do it in future iterations and see if it fits the current data model and APIs we’re proposing. > > > The ingress vs egress differences and issues > Egress bandwidth limiting is much more use full and supported, > There is still doubt on the support of Ingress bandwidth limiting in OVS, > anyone > that knows if Ingress QoS is supported in OVS we want your feedback :) > (For example implementing OF1.3 Metering spec) > > Thanks all (Miguel, Sean or anyone else, please update this if i forgot > anything) > > [1] https://wiki.openstack.org/wiki/Meetings/QoS > [2] https://review.openstack.org/#/c/88599/ > [3] https://review.openstack.org/#/c/136760/ > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto: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] replace external ip monitor
Does the library require root privileges to work for the operations you’re planning to do? That would be a stopper, since all the agents run unprivileged, and all the operations are filtered by the oslo root wrap daemon or cmdline tool. Best, Miguel Ángel. Miguel Ángel Ajo On Monday, 4 de May de 2015 at 14:58, Assaf Muller wrote: > . > > - Original Message - > > … > > > > Hello. > > > > I would like to discuss the possibility to replace external ip monitor > > in the neutron code [1] with an internal native Python code [2] > > > > The issues of the current implementation: > > * an external process management > > * text output parsing (possibly buffered) > > > > The proposed library: > > * pure Python code > > * threadless (by default) socket-like objects to work with netlink > > * optional eventlet optimization > > * netlink messages as native python objects > > * compatible license > > > > > How's packaging looking on all supported platforms? > > On a related note, ip_monitor.py is 87 lines of code, I'd be wary of getting > rid of it and using a full blown library instead. Then again, using pyroute2, > we might want to replace other pieces of code (Such as parts of ip_lib). > > > If it's ok, I would prepare a patchset this week. > > > > [1] neutron/agent/linux/ip_monitor.py > > [2] https://github.com/svinota/pyroute2 > > > > -- > > Peter V. Saveliev > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > (mailto: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 > (mailto: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] [QoS] QoS weekly meeting
On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote: > On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando (mailto:sorla...@nicira.com)> wrote: > > > > > > On 7 April 2015 at 00:33, Armando M. > (mailto:arma...@gmail.com)> wrote: > > > > > > On 6 April 2015 at 08:56, Miguel Ángel Ajo > > (mailto:majop...@redhat.com)> wrote: > > > > I’d like to co-organized a QoS weekly meeting with Sean M. Collins, > > > > > > > > In the last few years, the interest for QoS support has increased, > > > > Sean has been leading > > > > this effort [1] and we believe we should get into a consensus about how > > > > to model an extension > > > > to let vendor plugins implement QoS capabilities on network ports and > > > > tenant networks, and > > > > how to extend agents, and the reference implementation & others [2] > > > > > > > > > > > > > > > > > > > > > > As you surely know, so far every attempt to achieve a consensus has failed > > in a pretty miserable way. > > This mostly because "QoS" can be interpreted in a lot of different ways, > > both from the conceptual and practical perspective. > > > > > > > > > > > > Yes, I’m fully aware of it, it was also a new feature, so it was out of scope for Kilo. > > It is important in my opinion to clearly define the goals first. For > > instance a simple extensions for bandwidth limiting could be a reasonable > > target for the Liberty release. > > > > > > > > > > > > I quite agree here, but IMHO, as you said it’s a quite open field (limiting, guaranteeing, marking, traffic shaping..), we should do our best in trying to define a model allowing us to build that up in the future without huge changes, on the API side I guess micro versioning is going to help in the API evolution. Also, at some point, we should/could need to involve the nova folks, for example, to define port flavors that can be associated to nova instance flavors, providing them 1) different types of network port speeds/guarantees/priorities, 2) being able to schedule instance/ports in coordination to be able to met specified guarantees. yes, complexity can sky rocket fast, > > Moving things such as ECN into "future works" is the right thing to do in > > my opinion. Attempting to define a flexible framework that can deal with > > advanced QoS policies specification is a laudable effort, but I am a bit > > skeptical about its feasibility. > > > ++, I think focusing on perhaps bandwidth limiting may make a lot of sense Yes, I believe we should look into the future , but at the same pick our very first feature (or a very simple set of them) for L, stick to it, and try to make a design that can be extended. > > > > > > > > > > > > As per discussion we’ve had during the last few months [3], I > > > > believe we should start simple, but > > > > prepare a model allowing future extendibility, to allow for example > > > > specific traffic rules (per port, > > > > per IP, etc..), congestion notification support [4], … > > > > > > > > > > > > > > > > > > > > > > "Simple" in my mind is even more extreme then what you're proposing here... > > I'd start with bare APIs for specifying bandwidth limiting, and then phase > > them out once this "framework" is in place. > > Also note that this kind of design bears some overlap with the flavor > > framework which is probably going to be another goal for Liberty. > > > Indeed, and the flavor framework is something I'm hoping we can land by > Liberty-1 (yes, I just said Liberty-1). Yes it’s something I looked at, I must admit I wasn’t able to see it work together (It doesn’t mean it doesn’t play well, but most probably I was silly enough not to see it :) ), I didn’t want to distract attention from the Kilo cycle focus making questions, so it should be a good thing to talk about during the first meetings. Who are the flavor fathers/mothers? ;) > > > Morever, consider using "common" tools such as the specs repo to share and > > discuss design documents. > > > > > > > > > > Also a good idea. Yes, that was the plan now, we didn’t use it before to avoid creating unnecessary noise during this cycle. > > > > > > > > >
[openstack-dev] [neutron] [QoS] QoS weekly meeting
I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation & others [2] As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification __ 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] initial OVN testing
That’s super nice ;) !!! :D
I’m prototyping over here [1] to gather some benchmarks for the summit
presentation
about “Taking Security Groups To Ludicrous Speed with Open vSwitch” with Ivar,
Justin
and Thomas.
I know Justin and Joe have been doing good advances on it ;) [3] lately.
[1] https://review.openstack.org/#/c/167671/
[2] https://github.com/justinpettit/ovs/tree/conntrack
[3] https://github.com/justinpettit/ovs/commits/conntrack
Miguel Ángel Ajo
On Tuesday, 31 de March de 2015 at 9:34, Kevin Benton wrote:
> Very cool. What's the latest status on data-plane support for the conntrack
> based things like firewall rules and conntrack integration?
>
> On Mon, Mar 30, 2015 at 7:19 PM, Russell Bryant (mailto:rbry...@redhat.com)> wrote:
> > On 03/26/2015 07:54 PM, Russell Bryant wrote:
> > > Gary and Kyle, I saw in my IRC backlog that you guys were briefly
> > > talking about testing the Neutron ovn ml2 driver. I suppose it's time
> > > to add some more code to the devstack integration to install the current
> > > ovn branch and set up ovsdb-server to serve up the right database for
> > > this. I'll try to work on that tomorrow. Of course, note that all we
> > > can set up right now is the northbound database. None of the code that
> > > reacts to updates to that database is merged yet. We can still go ahead
> > > and test our code and make sure the expected data makes it there, though.
> >
> > With help from Kyle Mestery, Gary Kotton, and Gal Sagie, some great
> > progress has been made over the last few days. Devstack support has
> > merged and the ML2 driver seems to be doing the right thing.
> >
> > After devstack runs, you can see that the default networks created by
> > devstack are in the OVN db:
> >
> > > $ neutron net-list
> > > +--+-+--+
> > > | id | name| subnets
> > > |
> > > +--+-+--+
> > > | 1c4c9a38-afae-40aa-a890-17cd460b314b | private |
> > > 115f27d1-5330-489e-b81f-e7f7da123a31 10.0.0.0/24 (http://10.0.0.0/24) |
> > > | 69fc7d7c-6906-43e7-b5e2-77c059cf4143 | public |
> > > 6b5c1597-4af8-4ad3-b28b-a4e83a07121b |
> > > +--+-+--+
> >
> > > $ ovn-nbctl lswitch-list
> > > 47135494-6b36-4db9-8ced-3bdc9b711ca9
> > > (neutron-1c4c9a38-afae-40aa-a890-17cd460b314b)
> > > 03494923-48cf-4af5-a391-ed48fe180c0b
> > > (neutron-69fc7d7c-6906-43e7-b5e2-77c059cf4143)
> >
> > > $ ovn-nbctl lswitch-get-external-id
> > > neutron-1c4c9a38-afae-40aa-a890-17cd460b314b
> > > neutron:network_id=1c4c9a38-afae-40aa-a890-17cd460b314b
> > > neutron:network_name=private
> >
> > > $ ovn-nbctl lswitch-get-external-id
> > > neutron-69fc7d7c-6906-43e7-b5e2-77c059cf4143
> > > neutron:network_id=69fc7d7c-6906-43e7-b5e2-77c059cf4143
> > > neutron:network_name=public
> >
> > You can also create ports and see those reflected in the OVN db:
> >
> > > $ neutron port-create 1c4c9a38-afae-40aa-a890-17cd460b314b
> > > Created a new port:
> > > +---+-+
> > > | Field | Value
> > > |
> > > +---+-+
> > > | admin_state_up| True
> > > |
> > > | allowed_address_pairs |
> > > |
> > > | binding:vnic_type | normal
> > > |
> > > | device_id |
> > > |
> > > | device_owner |
> > > |
> > > | fixed_ips | {"subnet_id":
> > > "115f27d1-5330-489e-b81f-e7f7da123a31", "ip_address": "10.0.0.3"} |
> > > | id|
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
On Tuesday, 31 de March de 2015 at 7:14, George Shuklin wrote: > > > On 03/30/2015 11:18 AM, Kevin Benton wrote: > > What does fog do? Is it just a client to the Neutron HTTP API? If so, > > it should not have broken like that because the API has remained > > pretty stable. If it's a deployment tool, then I could see that > > because the configuration options to tend to suffer quite a bit of > > churn as tools used by the reference implementation evolve. > > > > As far as I understand (I'm not ruby guy, I'm openstack guy, but I > peeking to ruby guys attempts to use openstack with fog as replacement > for vagrant/virtualbox), the problem lies in the default network selection. > > Fog expects to have one network and use it, and neutron network-rich > environment is simply too complex for it. May be it is fog to blame, but > result is simple: some user library worked fine with nova networks but > struggling after update to neutron. > > Linux usually covers all those cases to make transition between versions > very smooth. Openstack is not. > > > I agree that these changes are an unpleasant experience for the end > > users, but that's what the deprecation timeline is for. This feature > > won't break in L, it will just result in deprecation warnings. If we > > get feedback from users that this serves an important use case that > > can't be addressed another way, we can always stop the deprecation at > > that point. > > > > In my opinion it happens too fast and cruel. For example: It deprecates > in 'L' release and will be kept only of 'L' users complains. But for > that many users should switch from havana to newer version. But it not > true, many skips few versions before moving to the new one. > > Openstack releases are too wild and untested to be used 'after release' > (simple example: VLAN id bug in neutron, which completely breaks hard > reboots in neutron, was fixed in last update of havana, that means all > havanas was broken from the moment of release to the very last moment), > so users wait until bugs are fixed. And they deploy new version after > that. So it is something like half of the year between new version and > deployment. And no one wants to do upgrade right after they done > deployment. Add one or two more years. And only than user find that > everything is deprecated and removed and openstack is new and shiny > again, and everyone need to learn it from scratches. I'm exaggerating a > bit, but that's true - the older and mature installation (like big > public cloud) the less they want to upgrade every half of the year to > the shiny new bugs. > > TL;DR: Deprecation cycle should take at least few years to get proper > feedback from real heavy users. > > From the user POV I can’t do other thing but agree, you pictured it right, currently we mark something for deprecation, and by the middle/end of next cycle it’s deprecated. But most users won’t realize it’s deprecated until it’s too late, either because they jump to use a stable version after a few stable releases to be safe, or because they skip versions. From the code point of view, it can, sometimes become messy, but we should take care of our customers… __ 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] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
I see you point Van, In the other hand, removing it, cleans up lot of conditional code parts (moving parts at the other side), and also the non-netns case is not tested by upstream CI, AFAIK, so it could be broken anytime and we would not notice it. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote: > > I think there are valid reasons to not use namespaces: > > Fewer moving parts == less can potentialy fail > > Troubleshooting is easier due to less places to look / need no familiarity > > with namespaces & tools > > If I remember correctly setting up a namespace can get really slow when you > > have a lot of them on a single machine > > > > > > > > > > > > IMHO, those shouldn’t be valid reasons anymore, since they were due > > iproute, or sudo issues > > that have been corrected long ago, and all distros installing neutron are > > supporting netns at this > > Well, you exactly made my point: > There is lots that can and will go wrong with more moving parts. > That they are fixed at the moment does not mean that there will not be a new > bug in the future… > > Cheers, > Robert van Leeuwen > > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > (mailto:openstack-operat...@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > __ 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] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
On Monday, 23 de March de 2015 at 8:20, Van Leeuwen, Robert wrote: > > > >> Are the setups out there *not* using the use_namespaces option? I'm > > > >> curious as > > > >> to why, and if it would be difficult to migrate such a setup to use > > > >> namespaces. > > At my previous employer we did not use namespaces. > This was due to a installation a few years ago on SL6 which did not have name > space support at that time. > > I think there are valid reasons to not use namespaces: > Fewer moving parts == less can potentialy fail > Troubleshooting is easier due to less places to look / need no familiarity > with namespaces & tools > If I remember correctly setting up a namespace can get really slow when you > have a lot of them on a single machine > > If you have a requirement for having all networks to be routable disabling > namespaces does make sense. > Since I’m currently in the design phase for such an install I’d surely like > to know if it is going to be deprecated. > Thx for letting us know about this :) > > Hi Van, thanks for pointing those out IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, or sudo issues that have been corrected long ago, and all distros installing neutron are supporting netns at this point AFAIK. Best regards, Miguel Angel Ajo __ 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] [TripleO] [Ironic] Deprecating the use_namespaces option - Now's the time to speak up!
Looking at project Calico, I don’t know if what they do is similar to what the people from triple-o & ironic do with the neutron-dhcp-agent. I believe we should ask them before deprecation. I added their tags to the subject. AFAIK TripleO/Ironic was patching neutron-dhcp-agent too. For project Calico, why do you need no netns and why do you patch it? Kevin, thanks for pointing that out. Best, Miguel Ángel Ajo On Monday, 23 de March de 2015 at 7:34, Miguel Ángel Ajo wrote: > +1 for deprecation if people don’t have use cases / good reasons to keep it, > I don’t know > and I can’t think of any, but that doesn’t mean they don’t exist. > > Miguel Ángel Ajo > > > On Monday, 23 de March de 2015 at 2:34, shihanzhang wrote: > > > +1 to deprecate this option > > > > At 2015-03-21 02:57:09, "Assaf Muller" > (mailto:amul...@redhat.com)> wrote: >Hello everyone, > >The use_namespaces > > option in the L3 and DHCP Neutron agents controls if you >can create > > multiple routers and DHCP networks managed by a single L3/DHCP agent, >or > > if the agent manages only a single resource. > >Are the setups out there > > *not* using the use_namespaces option? I'm curious as >to why, and if it > > would be difficult to migrate such a setup to use namespaces. > >I'm asking > > because use_namespaces complicates Neutron code for what I gather >is an > > option that has not been relevant for years. I'd like to deprecate the > > option >for Kilo and remove it in Liberty. > > >Assaf Muller, Cloud > > Networking Engineer >Red Hat > > > >__ > > >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > (mailto: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 > > (mailto: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 > (mailto: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] Deprecating the use_namespaces option - Now's the time to speak up!
+1 for deprecation if people don’t have use cases / good reasons to keep it, I don’t know and I can’t think of any, but that doesn’t mean they don’t exist. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 2:34, shihanzhang wrote: > +1 to deprecate this option > > At 2015-03-21 02:57:09, "Assaf Muller" wrote: >Hello > everyone, > >The use_namespaces option in the L3 and DHCP Neutron agents > controls if you >can create multiple routers and DHCP networks managed by a > single L3/DHCP agent, >or if the agent manages only a single resource. > >Are > the setups out there *not* using the use_namespaces option? I'm curious as > >to why, and if it would be difficult to migrate such a setup to use > namespaces. > >I'm asking because use_namespaces complicates Neutron code for > what I gather >is an option that has not been relevant for years. I'd like to > deprecate the option >for Kilo and remove it in Liberty. > > >Assaf Muller, > Cloud Networking Engineer >Red Hat > > >__ > >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 > (mailto: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] [api][neutron] Best API for generating subnets from ool
Thanks to everybody working on this,
Answers inline:
On Tuesday, 10 de March de 2015 at 0:34, Tidwell, Ryan wrote:
> Thanks Salvatore. Here are my thoughts, hopefully there’s some merit to them:
>
> With implicit allocations, the thinking is that this is where a subnet is
> created in a backward-compatible way with no subnetpool_id and the subnets
> API’s continue to work as they always have.
>
> In the case of a specific subnet allocation request (create-subnet passing a
> pool ID and specific CIDR), I would look in the pool’s available prefix list
> and carve out a subnet from one of those prefixes and ask for it to be
> reserved for me. In that case I know the CIDR I’ll be getting up front. In
> such a case, I’m not sure I’d ever specify my gateway using notation like
> 0.0.0.1, even if I was allowed to. If I know I’ll be getting 10.10.10.0/24,
> I can simply pass gateway_ip as 10.10.10.1 and be done with it. I see no
> added value in supporting that wildcard notation for a gateway on a specific
> subnet allocation.
>
> In the case of an “any” subnet allocation request (create-subnet passing a
> pool ID, but no specific CIDR), I’m already delegating responsibility for
> addressing my subnet to Neutron. As such, it seems reasonable to not have
> strong opinions about details like gateway_ip when making the request to
> create a subnet in this manner.
>
> To me, this all points to not supporting wildcards for gateway_ip and
> allocation_pools on subnet create (even though it found its way into the
> spec). My opinion (which I think lines up with yours) is that on an any
> request it makes sense to let the pool fill in allocation_pools and
> gateway_ip when requesting an “any” allocation from a subnet pool. When
> creating a specific subnet from a pool, gateway IP and allocation pools could
> still be passed explicitly by the user.
>
> -Ryan
>
> From: Salvatore Orlando [mailto:sorla...@nicira.com]
> Sent: Monday, March 09, 2015 6:06 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [api][neutron] Best API for generating subnets from
> pool
>
> Greetings!
>
>
> Neutron is adding a new concept of "subnet pool". To put it simply, it is a
> collection of IP prefixes from which subnets can be allocated. In this way a
> user does not have to specify a full CIDR, but simply a desired prefix
> length, and then let the pool generate a CIDR from its prefixes. The full
> spec is available at [1], whereas two patches are up for review at [2] (CRUD)
> and [3] (integration between subnets and subnet pools).
>
> While [2] is quite straightforward, I must admit I am not really sure that
> the current approach chosen for generating subnets from a pool might be the
> best one, and I'm therefore seeking your advice on this matter.
>
>
>
> A subnet can be created with or without a pool.
>
> Without a pool the user will pass the desired cidr:
>
>
>
> POST /v2.0/subnets
>
> {'network_id': 'meh',
>
> 'cidr': '192.168.0.0/24 (http://192.168.0.0/24)'}
>
>
>
> Instead with a pool the user will pass pool id and desired prefix lenght:
>
> POST /v2.0/subnets
>
> {'network_id': 'meh',
>
> 'prefix_len': 24,
>
> 'pool_id': 'some_pool'}
>
>
>
> The response to the previous call would populate the subnet cidr.
>
> So far it looks quite good. Prefix_len is a bit of duplicated information,
> but that's tolerable.
>
> It gets a bit awkward when the user specifies also attributes such as desired
> gateway ip or allocation pools, as they have to be specified in a
> "cidr-agnostic" way. For instance:
>
>
>
> POST /v2.0/subnets
>
> {'network_id': 'meh',
>
> 'gateway_ip': '0.0.0.1',
>
> 'prefix_len': 24,
>
> 'pool_id': 'some_pool'}
>
>
>
>
> would indicate that the user wishes to use the first address in the range as
> the gateway IP, and the API would return something like this:
>
>
>
> POST /v2.0/subnets
>
> {'network_id': 'meh',
>
> 'cidr': '10.10.10.0/24 (http://10.10.10.0/24)'
>
> 'gateway_ip': '10.10.10.1',
>
> 'prefix_len': 24,
>
> 'pool_id': 'some_pool'}
>
>
>
>
>
> The problem with this approach is, in my opinion, that attributes such as
> gateway_ip are used with different semantics in requests and responses; this
> might also need users to write client applications expecting the values in
> the response might differ from those in the request.
>
>
>
> I have been considering alternatives, but could not find any that I would
> regard as winner.
>
> I therefore have some questions for the neutron community and the API working
> group:
>
>
>
> 1) (this is more for neutron people) Is there a real use case for requesting
> specific gateway IPs and allocation pools when allocating from a pool? If
> not, maybe we should let the pool set a default gateway IP and allocation
> pools. The user can then update them with an
Re: [openstack-dev] [Neutron] Issue when upgrading from Juno to Kilo due to agent report_state RPC namespace patch
I agree with Assaf, this is an issue across updates, and we may want (if that’s technically possible) to provide access to those functions with/without namespace. Or otherwise think about reverting for now until we find a migration strategy https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:master+topic:bp/rpc-docs-and-namespaces,n,z Best regards, Miguel Ángel Ajo On Wednesday, 4 de March de 2015 at 17:00, Assaf Muller wrote: > Hello everyone, > > I'd like to highlight an issue with: > https://review.openstack.org/#/c/154670/ > > According to my understanding, most deployments upgrade the controllers first > and compute/network nodes later. During that time period, all agents will > fail to report state as they're sending the report_state message outside > of any namespace while the server is expecting that message in a namespace. > This is a show stopper as the Neutron server will think all of its agents are > dead. > > I think the obvious solution is to modify the Neutron server code so that > it accepts the report_state method both in and outside of the report_state > RPC namespace and chuck that code away in L (Assuming we support rolling > upgrades > only from version N to N+1, which while is unfortunate, is the behavior I've > seen in multiple places in the code). > > Finally, are there additional similar issues for other RPC methods placed in > a namespace > this cycle? > > > Assaf Muller, Cloud Networking Engineer > Red Hat > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto: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] OpenFlow security groups (pre-benchmarking plan)
https://review.openstack.org/#/c/159840/1/doc/source/testing/openflow-firewall.rst I may need some help from the OVS experts to answer the questions from henry.hly. Ben, Thomas, could you please? (let me know if you are not registered to the openstack review system, I could answer in your name). Best, Miguel Ángel Ajo On Friday, 27 de February de 2015 at 14:50, Miguel Ángel Ajo wrote: > Ok, I moved the document here [1], and I will eventually submit another patch > with the testing scripts when those are ready. > > Let’s move the discussion to the review!, > > > Best, > Miguel Ángel Ajo > [1] https://review.openstack.org/#/c/159840/ > > > On Friday, 27 de February de 2015 at 7:03, Kevin Benton wrote: > > > Sounds promising. We'll have to evaluate it for feature parity when the > > time comes. > > > > On Thu, Feb 26, 2015 at 8:21 PM, Ben Pfaff > (mailto:b...@nicira.com)> wrote: > > > This sounds quite similar to the planned support in OVN to "gateway" a > > > logical network to a particular VLAN on a physical port, so perhaps it > > > will be sufficient. > > > > > > On Thu, Feb 26, 2015 at 05:58:40PM -0800, Kevin Benton wrote: > > > > If a port is bound with a VLAN segmentation type, it will get a VLAN id > > > > and > > > > a name of a physical network that it corresponds to. In the current > > > > plugin, > > > > each agent is configured with a mapping between physical networks and > > > > OVS > > > > bridges. The agent takes the bound port information and sets up rules to > > > > forward traffic from the VM port to the OVS bridge corresponding to the > > > > physical network. The bridge usually then has a physical interface > > > > added to > > > > it for the tagged traffic to use to reach the rest of the network. > > > > > > > > On Thu, Feb 26, 2015 at 4:19 PM, Ben Pfaff > > > (mailto:b...@nicira.com)> wrote: > > > > > > > > > What kind of VLAN support would you need? > > > > > > > > > > On Thu, Feb 26, 2015 at 02:05:41PM -0800, Kevin Benton wrote: > > > > > > If OVN chooses not to support VLANs, we will still need the current > > > > > > OVS > > > > > > reference anyway so it definitely won't be wasted work. > > > > > > > > > > > > On Thu, Feb 26, 2015 at 2:56 AM, Miguel Angel Ajo Pelayo < > > > > > > majop...@redhat.com (mailto:majop...@redhat.com)> wrote: > > > > > > > > > > > > > > > > > > > > Sharing thoughts that I was having: > > > > > > > > > > > > > > May be during the next summit it???s worth discussing the future > > > > > > > of the > > > > > > > reference agent(s), I feel we???ll be replicating a lot of work > > > > > > > across > > > > > > > OVN/OVS/RYU(ofagent) and may be other plugins, > > > > > > > > > > > > > > I guess until OVN and it???s integration are ready we can???t > > > > > > > stop, so > > > > > it makes > > > > > > > sense to keep development at our side, also having an independent > > > > > plugin > > > > > > > can help us iterate faster for new features, yet I expect that OVN > > > > > will be > > > > > > > more fluent at working with OVS and OpenFlow, as their designers > > > > > > > have > > > > > > > a very deep knowledge of OVS under the hood, and it???s C. ;) > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > On 26/2/2015, at 7:57, Miguel ??ngel Ajo > > > > > > (mailto:majop...@redhat.com)> wrote: > > > > > > > > > > > > > > On Thursday, 26 de February de 2015 at 7:48, Miguel ??ngel Ajo > > > > > > > wrote: > > > > > > > > > > > > > > Inline comments follow after this, but I wanted to respond to > > > > > > > Brian > > > > > > > questionwhich has been cut out: > > > > > > > We???re talking here of doing a preliminary analysis of the > > > > > > > networking > > > > > > > performance,before writing any real code at neutron lev
Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)
Ok, I moved the document here [1], and I will eventually submit another patch with the testing scripts when those are ready. Let’s move the discussion to the review!, Best, Miguel Ángel Ajo [1] https://review.openstack.org/#/c/159840/ On Friday, 27 de February de 2015 at 7:03, Kevin Benton wrote: > Sounds promising. We'll have to evaluate it for feature parity when the time > comes. > > On Thu, Feb 26, 2015 at 8:21 PM, Ben Pfaff (mailto:b...@nicira.com)> wrote: > > This sounds quite similar to the planned support in OVN to "gateway" a > > logical network to a particular VLAN on a physical port, so perhaps it > > will be sufficient. > > > > On Thu, Feb 26, 2015 at 05:58:40PM -0800, Kevin Benton wrote: > > > If a port is bound with a VLAN segmentation type, it will get a VLAN id > > > and > > > a name of a physical network that it corresponds to. In the current > > > plugin, > > > each agent is configured with a mapping between physical networks and OVS > > > bridges. The agent takes the bound port information and sets up rules to > > > forward traffic from the VM port to the OVS bridge corresponding to the > > > physical network. The bridge usually then has a physical interface added > > > to > > > it for the tagged traffic to use to reach the rest of the network. > > > > > > On Thu, Feb 26, 2015 at 4:19 PM, Ben Pfaff > > (mailto:b...@nicira.com)> wrote: > > > > > > > What kind of VLAN support would you need? > > > > > > > > On Thu, Feb 26, 2015 at 02:05:41PM -0800, Kevin Benton wrote: > > > > > If OVN chooses not to support VLANs, we will still need the current > > > > > OVS > > > > > reference anyway so it definitely won't be wasted work. > > > > > > > > > > On Thu, Feb 26, 2015 at 2:56 AM, Miguel Angel Ajo Pelayo < > > > > > majop...@redhat.com (mailto:majop...@redhat.com)> wrote: > > > > > > > > > > > > > > > > > Sharing thoughts that I was having: > > > > > > > > > > > > May be during the next summit it???s worth discussing the future of > > > > > > the > > > > > > reference agent(s), I feel we???ll be replicating a lot of work > > > > > > across > > > > > > OVN/OVS/RYU(ofagent) and may be other plugins, > > > > > > > > > > > > I guess until OVN and it???s integration are ready we can???t stop, > > > > > > so > > > > it makes > > > > > > sense to keep development at our side, also having an independent > > > > plugin > > > > > > can help us iterate faster for new features, yet I expect that OVN > > > > will be > > > > > > more fluent at working with OVS and OpenFlow, as their designers > > > > > > have > > > > > > a very deep knowledge of OVS under the hood, and it???s C. ;) > > > > > > > > > > > > Best regards, > > > > > > > > > > > > On 26/2/2015, at 7:57, Miguel ??ngel Ajo > > > > > (mailto:majop...@redhat.com)> wrote: > > > > > > > > > > > > On Thursday, 26 de February de 2015 at 7:48, Miguel ??ngel Ajo > > > > > > wrote: > > > > > > > > > > > > Inline comments follow after this, but I wanted to respond to Brian > > > > > > questionwhich has been cut out: > > > > > > We???re talking here of doing a preliminary analysis of the > > > > > > networking > > > > > > performance,before writing any real code at neutron level. > > > > > > > > > > > > If that looks right, then we should go into a preliminary (and > > > > orthogonal > > > > > > to iptables/LB)implementation. At that moment we will be able to > > > > examine > > > > > > the scalability of the solutionin regards of switching openflow > > > > > > rules, > > > > > > which is going to be severely affectedby the way we use to handle OF > > > > rules > > > > > > in the bridge: > > > > > >* via OpenFlow, making the agent a ???real" OF controller, with > > > > > > the > > > > > > current effort to use the ryu framework plugin to do that. * > > > > > > via > > > > &
Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)
On Thursday, 26 de February de 2015 at 7:48, Miguel Ángel Ajo wrote: > Inline comments follow after this, but I wanted to respond to Brian question > which has been cut out: > > We’re talking here of doing a preliminary analysis of the networking > performance, > before writing any real code at neutron level. > > If that looks right, then we should go into a preliminary (and orthogonal to > iptables/LB) > implementation. At that moment we will be able to examine the scalability of > the solution > in regards of switching openflow rules, which is going to be severely affected > by the way we use to handle OF rules in the bridge: > >* via OpenFlow, making the agent a “real" OF controller, with the current > effort to use > the ryu framework plugin to do that. >* via cmdline (would be alleviated with the current rootwrap work, but the > former one > would be preferred). > > Also, ipset groups can be moved into conjunctive groups in OF (thanks Ben > Pfaff for the > explanation, if you’re reading this ;-)) > > Best, > Miguel Ángel > > > > On Wednesday, 25 de February de 2015 at 20:34, Tapio Tallgren wrote: > > Hi, > > > > The RFC2544 with near zero packet loss is a pretty standard performance > > benchmark. It is also used in the OPNFV project > > (https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases). > > > > Does this mean that OpenStack will have stateful firewalls (or security > > groups)? Any other ideas planned, like ebtables type filtering? > > > What I am proposing is in the terms of maintaining the statefulness we have > now > regards security groups (RELATED/ESTABLISHED connections are allowed back > on open ports) while adding a new firewall driver working only with OVS+OF > (no iptables > or linux bridge). > > That will be possible (without auto-populating OF rules in oposite > directions) due to > the new connection tracker functionality to be eventually merged into ovs. > > > -Tapio > > > > > > On Wed, Feb 25, 2015 at 5:07 PM, Rick Jones > (mailto:rick.jon...@hp.com)> wrote: > > > On 02/25/2015 05:52 AM, Miguel Ángel Ajo wrote: > > > > I’m writing a plan/script to benchmark OVS+OF(CT) vs > > > > OVS+LB+iptables+ipsets, > > > > so we can make sure there’s a real difference before jumping into any > > > > OpenFlow security group filters when we have connection tracking in OVS. > > > > > > > > The plan is to keep all of it in a single multicore host, and make > > > > all the measures within it, to make sure we just measure the > > > > difference due to the software layers. > > > > > > > > Suggestions or ideas on what to measure are welcome, there’s an initial > > > > draft here: > > > > > > > > https://github.com/mangelajo/ovs-experiments/tree/master/ovs-ct > > > > > > Conditions to be benchmarked > > > > > > Initial connection establishment time > > > Max throughput on the same CPU > > > > > > Large MTUs and stateless offloads can mask a multitude of path-length > > > sins. And there is a great deal more to performance than Mbit/s. While > > > some of that may be covered by the first item via the likes of say > > > netperf TCP_CRR or TCP_CC testing, I would suggest that in addition to a > > > focus on Mbit/s (which I assume is the focus of the second item) there is > > > something for packet per second performance. Something like netperf > > > TCP_RR and perhaps aggregate TCP_RR or UDP_RR testing. > > > > > > Doesn't have to be netperf, that is simply the hammer I wield :) > > > > > > What follows may be a bit of perfect being the enemy of the good, or > > > mission creep... > > > > > > On the same CPU would certainly simplify things, but it will almost > > > certainly exhibit different processor data cache behaviour than actually > > > going through a physical network with a multi-core system. Physical NICs > > > will possibly (probably?) have RSS going, which may cause cache lines to > > > be pulled around. The way packets will be buffered will differ as well. > > > Etc etc. How well the different solutions scale with cores is definitely > > > a difference of interest between the two sofware layers. > > > Hi rick, thanks for your feedback here, I’ll take it into consideration, specially about the small packet pps measurements, and re
Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)
Inline comments follow after this, but I wanted to respond to Brian question which has been cut out: We’re talking here of doing a preliminary analysis of the networking performance, before writing any real code at neutron level. If that looks right, then we should go into a preliminary (and orthogonal to iptables/LB) implementation. At that moment we will be able to examine the scalability of the solution in regards of switching openflow rules, which is going to be severely affected by the way we use to handle OF rules in the bridge: * via OpenFlow, making the agent a “real" OF controller, with the current effort to use the ryu framework plugin to do that. * via cmdline (would be alleviated with the current rootwrap work, but the former one would be preferred). Also, ipset groups can be moved into conjunctive groups in OF (thanks Ben Pfaff for the explanation, if you’re reading this ;-)) Best, Miguel Ángel On Wednesday, 25 de February de 2015 at 20:34, Tapio Tallgren wrote: > Hi, > > The RFC2544 with near zero packet loss is a pretty standard performance > benchmark. It is also used in the OPNFV project > (https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases). > > Does this mean that OpenStack will have stateful firewalls (or security > groups)? Any other ideas planned, like ebtables type filtering? > What I am proposing is in the terms of maintaining the statefulness we have now regards security groups (RELATED/ESTABLISHED connections are allowed back on open ports) while adding a new firewall driver working only with OVS+OF (no iptables or linux bridge). That will be possible (without auto-populating OF rules in oposite directions) due to the new connection tracker functionality to be eventually merged into ovs. > > -Tapio > > > On Wed, Feb 25, 2015 at 5:07 PM, Rick Jones (mailto:rick.jon...@hp.com)> wrote: > > On 02/25/2015 05:52 AM, Miguel Ángel Ajo wrote: > > > I’m writing a plan/script to benchmark OVS+OF(CT) vs > > > OVS+LB+iptables+ipsets, > > > so we can make sure there’s a real difference before jumping into any > > > OpenFlow security group filters when we have connection tracking in OVS. > > > > > > The plan is to keep all of it in a single multicore host, and make > > > all the measures within it, to make sure we just measure the > > > difference due to the software layers. > > > > > > Suggestions or ideas on what to measure are welcome, there’s an initial > > > draft here: > > > > > > https://github.com/mangelajo/ovs-experiments/tree/master/ovs-ct > > > > Conditions to be benchmarked > > > > Initial connection establishment time > > Max throughput on the same CPU > > > > Large MTUs and stateless offloads can mask a multitude of path-length sins. > > And there is a great deal more to performance than Mbit/s. While some of > > that may be covered by the first item via the likes of say netperf TCP_CRR > > or TCP_CC testing, I would suggest that in addition to a focus on Mbit/s > > (which I assume is the focus of the second item) there is something for > > packet per second performance. Something like netperf TCP_RR and perhaps > > aggregate TCP_RR or UDP_RR testing. > > > > Doesn't have to be netperf, that is simply the hammer I wield :) > > > > What follows may be a bit of perfect being the enemy of the good, or > > mission creep... > > > > On the same CPU would certainly simplify things, but it will almost > > certainly exhibit different processor data cache behaviour than actually > > going through a physical network with a multi-core system. Physical NICs > > will possibly (probably?) have RSS going, which may cause cache lines to be > > pulled around. The way packets will be buffered will differ as well. Etc > > etc. How well the different solutions scale with cores is definitely a > > difference of interest between the two sofware layers. > > > > rick > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > (http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > -Tapio > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subje
Re: [openstack-dev] [all] creating a unified developer reference manual
Sounds like a very good idea. Cross project development shared knowledge. Miguel Ángel Ajo On Wednesday, 25 de February de 2015 at 22:32, michael mccune wrote: > On 02/25/2015 02:54 PM, Doug Hellmann wrote: > > During yesterday’s cross-project meeting [1], we discussed the "Eventlet > > Best Practices” spec [2] started by bnemec. The discussion of that spec > > revolved around the question of whether our cross-project specs repository > > is the right place for this type of document that isn’t a “plan” for a > > change, and is more a reference guide. Eventually we came around to the > > idea of creating a cross-project developer guide to hold these sorts of > > materials. > > > > That leads to two questions, then: > > > > 1. Should we have a unified developer guide for the project? > > +1, this sounds like a fantastic idea. > > > 2. Where should it live and how should we manage it? > > i like the idea of creating a new repository, akin to the other > OpenStack manuals. i think it would be great if there was an easy way > for the individual projects to add their specific recommendations as well. > > the main downside i see to creating a new repo/manual/infra is the > project overhead. hopefully there will be enough interest that this > won't be an issue though. > > mike > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto: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] OpenFlow security groups (pre-benchmarking plan)
On Wednesday, 25 de February de 2015 at 15:38, Kyle Mestery wrote: > On Wed, Feb 25, 2015 at 7:52 AM, Miguel Ángel Ajo (mailto:majop...@redhat.com)> wrote: > > I’m writing a plan/script to benchmark OVS+OF(CT) vs > > OVS+LB+iptables+ipsets, > > so we can make sure there’s a real difference before jumping into any > > OpenFlow security group filters when we have connection tracking in OVS. > > > > The plan is to keep all of it in a single multicore host, and make all the > > measures > > within it, to make sure we just measure the difference due to the software > > layers. > > > > Suggestions or ideas on what to measure are welcome, there’s an initial > > draft here: > > > > https://github.com/mangelajo/ovs-experiments/tree/master/ovs-ct > > > This is a good idea Miguel, thanks for taking this on! Might I suggest we add > this document into the neutron tree once you feel it's ready? Having it exist > there may make a lot of sense for people who want to understand your > performance test setup and who may want to run it in the future. > That’s actually a good idea, so we can use gerrit to review and gather comments. Where should I put the document? in /doc/source we have devref with it’s own index in rst. Best, Miguel Ángel. __ 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] [neutron] OpenFlow security groups (pre-benchmarking plan)
I’m writing a plan/script to benchmark OVS+OF(CT) vs OVS+LB+iptables+ipsets, so we can make sure there’s a real difference before jumping into any OpenFlow security group filters when we have connection tracking in OVS. The plan is to keep all of it in a single multicore host, and make all the measures within it, to make sure we just measure the difference due to the software layers. Suggestions or ideas on what to measure are welcome, there’s an initial draft here: https://github.com/mangelajo/ovs-experiments/tree/master/ovs-ct Miguel Ángel Ajo __ 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] [ovs-dev] [PATCH 8/8] [RFC] [neutron] ovn: Start work on design ocumentation.
On Friday, 20 de February de 2015 at 17:06, Ben Pfaff wrote:
> On Fri, Feb 20, 2015 at 12:45:46PM +0100, Miguel Ángel Ajo wrote:
> > On Thursday, 19 de February de 2015 at 23:15, Kyle Mestery wrote:
> > > On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff > > (mailto:b...@nicira.com)> wrote:
> > > > My initial reaction is that we can implement security groups as
> > > > another action in the ACL table that is similar to "allow" but in
> > > > addition permits reciprocal inbound traffic. Does that sound
> > > > sufficient to you?
> > > >
> > >
> > >
> >
> > Yes, having fine grained allows (matching on protocols, ports, and
> > remote ips would satisfy the neutron use case).
> >
> > Also we use connection tracking to allow reciprocal inbound traffic
> > via ESTABLISHED/RELATED, any equivalent solution would do.
> >
> > For reference, our SG implementation, currently is able to match on
> > combinations of:
> >
> > * direction: ingress/egress
> > * protocol: icmp/tcp/udp/
> > * port_range: min-max (it’s always dst)
> > * L2 packet ethertype: IPv4, IPv6, etc...
> > * remote_ip_prefix: as a CIDR or * remote_group_id (to reference all other
> > IPs in a certain group)
> >
> > All of them assume connection tracking so known connection packets will
> > go the other way around.
> >
>
>
> OK. All of those should work OK. (I don't know for sure whether we'll
> have explicit groups; initially, probably not.)
>
>
That makes sense.
>
> > > > Is the exponential explosion due to cross-producting, that is, because
> > > > you have, say, n1 source addresses and n2 destination addresses and so
> > > > you need n1*n2 flows to specify all the combinations? We aim to solve
> > > > that in OVN by giving the CMS direct support for more sophisticated
> > > > matching rules, so that it can say something like:
> > > >
> > > > ip.src in {, , , ...} && ip.dst in {, , , ...}
> > > > && (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})
> > > >
> > >
> >
> >
> > That sounds good and very flexible.
> > > >
> > > > and let OVN implement it in OVS via the "conjunctive match" feature
> > > > recently added, which is like a set membership match but more
> > > > powerful.
> > > >
> > >
> >
> > Hmm, where can I find examples about that feature, sounds interesting.
> >
>
>
> If you look at ovs-ofctl(8) in a development version of OVS, such as
> http://benpfaff.org/~blp/dist-docs/ovs-ofctl.8.pdf
> search for "conjunction", which explains the implementation.
>
>
Amazing, yes, it seems like conjunctions will do the work quite optimally
at OpenFlow level.
My hat off… :)
> (This
> isn't the form that Neutron would use with OVN; that is the Boolean
> expression syntax above.)
>
Of course, understood, I was curious about the low level supporting the
high level above.
>
> > > > It might still be nice to support lists of IPs (or
> > > > whatever), since these lists could still recur in a number of
> > > > circumstances, but my guess is that this will help a lot even without
> > > > that.
> > > >
> > > >
> > >
> >
> > As afar as I understood, given the way megaflows resolve rules via hashes
> > even if we had lots of rules with different ip addresses, that would be
> > very fast,
> > probably as fast or more than our current ipset solution.
> >
> > The only caveat would be having to update lots of flow rules when a port
> > goes
> > in or out of a security group, since you have to go and clear/add the rules
> > to each
> > single port on the same security group (as long as they have 1 rule
> > referencing the sg).
> >
>
>
> That sounds like another good argument for allowing explicit groups. I
> have a design in mind for that but I doubt it's the first thing to
> implement.
>
>
Of course, 1 step at a time. I will do a 2nd pass on your documents, looking a
bit
more on the higher level. I’m very happy to see that the low level is very well
tied
up and capable.
Best regards,
Miguel Ángel.
__
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] [ovs-dev] [PATCH 8/8] [RFC] [neutron] ovn: Start work on design ocumentation.
On Thursday, 19 de February de 2015 at 23:15, Kyle Mestery wrote:
> [Adding neutron tag to subject, comments below.]
>
> On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff (mailto:b...@nicira.com)> wrote:
> > [moving this conversation to openstack-dev because it's more
> > interesting there and that avoids crossposting to a subscribers-only
> > list]
> >
> > On Thu, Feb 19, 2015 at 10:57:02AM +0100, Miguel ??ngel Ajo wrote:
> > >I specially liked the VIF port lifecycle, looks good to me, Ionly miss
> > > some
> > > ???port_security??? concepts we have in neutron, which I guess could have
> > > been
> > > deliberately omitted for a start.
> > >
> > >In neutron we have something called security groups, and every port
> > > belongs to 1 or more security groups. Each security group has a list of
> > > rules to control traffic at port level in a very fine grained fashion
> > > (ingress/egress
> > > protocol/flags/etc??? remote_ip/mask or security_group ID)
> > >
> > > I guess we could build render security_group ID to multiple IPs for each
> > > port,
> > > but then we will miss the ingress/egress and protocol flags (like type
> > > of protocol,
> > > ports, etc.. [1])
> > >
> > > Also, be aware, that not having security group ID references from neutron,
> > > when lot???s of ports go to the same security group we end up with an
> > > exponential
> > > growth of rules / OF entries per port, we solved this in the
> > > server<->agent
> > > communication for the reference OVS solution by keeping a lists of IPs
> > > belonging to security group IDs, and then, separately having the
> > > references from the rules.
> >
> > Thanks a lot for the comment.
> >
> > We aim to fully support security groups in OVN. The current documents
> > don't capture that intent. (That's partly because we're planning to
> > implement them in terms of some new "connection tracking" code for OVS
> > that's still in the process of getting committed, and partly because I
> > haven't fully thought them through yet.)
> >
Ah, yes, I know it, I’m tracking that effort to benchmark and
shed some numbers over the OVS+OF vs OVS+veths+LB+iptables
stateful firewalling/security groups.
I guess also routing namespaceless router benchmarking would make
sense too.
> > My initial reaction is that we can implement security groups as
> > another action in the ACL table that is similar to "allow" but in
> > addition permits reciprocal inbound traffic. Does that sound
> > sufficient to you?
Yes, having fine grained allows (matching on protocols, ports, and
remote ips would satisfy the neutron use case).
Also we use connection tracking to allow reciprocal inbound traffic
via ESTABLISHED/RELATED, any equivalent solution would do.
For reference, our SG implementation, currently is able to match on
combinations of:
* direction: ingress/egress
* protocol: icmp/tcp/udp/
* port_range: min-max (it’s always dst)
* L2 packet ethertype: IPv4, IPv6, etc...
* remote_ip_prefix: as a CIDR or* remote_group_id (to reference all other
IPs in a certain group)
All of them assume connection tracking so known connection packets will
go the other way around.
> >
> > Is the exponential explosion due to cross-producting, that is, because
> > you have, say, n1 source addresses and n2 destination addresses and so
> > you need n1*n2 flows to specify all the combinations? We aim to solve
> > that in OVN by giving the CMS direct support for more sophisticated
> > matching rules, so that it can say something like:
> >
> > ip.src in {, , , ...} && ip.dst in {, , , ...}
> > && (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})
That sounds good and very flexible.
> >
> > and let OVN implement it in OVS via the "conjunctive match" feature
> > recently added, which is like a set membership match but more
> > powerful.
Hmm, where can I find examples about that feature, sounds interesting.
> > It might still be nice to support lists of IPs (or
> > whatever), since these lists could still recur in a number of
> > circumstances, but my guess is that this will help a lot even without
> > that.
> >
As afar as I understood, given the way megaflows resolve rules via hashes
even if we had lots of rules with different ip addresses, that would be very
fast,
probably as fast or more than our current ipset solution.
The only caveat would be having to update lots of flow rules when a port goes
in or out of a security group, since you have to go and clear/add the rules to
each
single port on the same security group (as long as they have 1 rule referencing
the sg).
> > Thoughts?
> >
> This all sounds really good to me Ben. I look forward to seeing the
> connection tracking code land
> and some design details on the security groups aspects of OVN published once
> that happens!
>
>
>
>
>
>
>
> Thanks,
> Kyle
>
> > __
> > OpenS
[openstack-dev] [neutron] [ovs-dev] [PATCH 8/8] [RFC] ovn: Start work on design Documentation.
Thank you Ben!, Cross posting [1] to openstack list /neutron. [1] http://benpfaff.org/~blp/dist-docs. On Thursday, 19 de February de 2015 at 09:13, Ben Pfaff wrote: > On Thu, Feb 19, 2015 at 12:12:26AM -0800, Ben Pfaff wrote: > > This commit adds preliminary design documentation for Open Virtual Network, > > or OVN, a new OVS-based project to add support for virtual networking to > > OVS, initially with OpenStack integration. > > > > This initial design has been influenced by many people, including (in > > alphabetical order) Aaron Rosen, Chris Wright, Jeremy Stribling, > > Justin Pettit, Ken Duda, Madhu Venugopal, Martin Casado, Pankaj Thakkar, > > Russell Bryant, and Teemu Koponen. All blunders, however, are due to my > > own hubris. > > > > Signed-off-by: Ben Pfaff mailto:b...@nicira.com)> > > I've posted the rendered version of the documentation following this > commit at http://benpfaff.org/~blp/dist-docs. You probably want to look > at the ovn* manpages, especially ovn-architecture(7), ovn(5), and > ovn-nb(5). > ___ > dev mailing list > d...@openvswitch.org (mailto:d...@openvswitch.org) > http://openvswitch.org/mailman/listinfo/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] per-agent/driver/plugin requirements
Miguel Ángel Ajo On Wednesday, 18 de February de 2015 at 08:14, yamam...@valinux.co.jp wrote: > hi, > > > On Wednesday, 18 de February de 2015 at 07:00, yamam...@valinux.co.jp > > (mailto:yamam...@valinux.co.jp) wrote: > > > hi, > > > > > > i want to add an extra requirement specific to OVS-agent. > > > (namely, I want to add ryu for ovs-ofctl-to-python blueprint. [1] > > > but the question is not specific to the blueprint.) > > > to avoid messing deployments without OVS-agent, such a requirement > > > should be per-agent/driver/plugin/etc. however, there currently > > > seems no standard mechanism for such a requirement. > > > > > > > > > > > > > > > > > Awesome, I was thinking of the same a few days ago, we make lots > > and lots of calls to ovs-ofctl, and we will do more if we change to > > security groups/routers in OF, if that proves to be efficient, and we > > get CT. > > > > > CT? Connection tracking in OVS. At that point we could do NAT/stateful firewalling, etc > > > > > After this change, what would be the differences of ofagent to ovs-agent ? > > > > I guess OVS set’s rules in advance, while ofagent works as a normal > > OF controller? > > > > > the basic architecture will be same. > > actually it was suggested to merge two agents during spec review. > i think it's a good idea for longer term. (but unlikely for kilo) > > If that’s the case, I would love to see both evaluated side to side, and make a community decision on that. > > > > some ideas: > > > > > > a. don't bother to make it per-agent. > > > add it to neutron's requirements. (and global-requirement) > > > simple, but this would make non-ovs plugin users unhappy. > > > > > > > > > > I would simply go with a, what’s the ryu’s internal requirement list? is > > it big? > > > > > no additional requirements as far as we use only openflow part of ryu. Then IMHO I don’t believe this is a big deal as for any other dependency. > > > > b. make devstack look at per-agent extra requirements file in neutron > > > tree. > > > eg. neutron/plugins/$Q_AGENT/requirements.txt > > > > > > > > > > IMHO that would make distribution work a bit harder because we > > may need to process new requirement files, but my answer could depend > > on what I asked for a. > > > > > probably. > i guess distributors can speak up. > > I speak up, I prefer a. But looping Ihar as he’s doing the majority of work related to neutron distribution in RH/RDO. > > > > c. move OVS agent to a separate repository, just like other > > > after-decomposition vendor plugins. and use requirements.txt there. > > > for longer term, this might be a way to go. but i don't want to > > > block my work until it happens. > > > > > > > > > > > > > > > We’re not ready for that yet, as co-gating has proven as a bad strategy > > and we need to keep the reference implementation working for tests. > > > > > i agree that it will not likely be ready in near future. > > YAMAMOTO Takashi > > > > d. follow the way how openvswitch is installed by devstack. > > > a downside: we can't give a jenkins run for a patch which introduces > > > an extra requirement. (like my patch for the mentioned blueprint [2]) > > > > > > i think b. is the most reasonable choice, at least for short/mid term. > > > > > > any comments/thoughts? > > > > > > YAMAMOTO Takashi > > > > > > [1] https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python > > > [2] https://review.openstack.org/#/c/153946/ > > > > > > __ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > (mailto: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 > (mailto: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] per-agent/driver/plugin requirements
On Wednesday, 18 de February de 2015 at 07:00, yamam...@valinux.co.jp wrote: > hi, > > i want to add an extra requirement specific to OVS-agent. > (namely, I want to add ryu for ovs-ofctl-to-python blueprint. [1] > but the question is not specific to the blueprint.) > to avoid messing deployments without OVS-agent, such a requirement > should be per-agent/driver/plugin/etc. however, there currently > seems no standard mechanism for such a requirement. > > Awesome, I was thinking of the same a few days ago, we make lots and lots of calls to ovs-ofctl, and we will do more if we change to security groups/routers in OF, if that proves to be efficient, and we get CT. After this change, what would be the differences of ofagent to ovs-agent ? I guess OVS set’s rules in advance, while ofagent works as a normal OF controller? > > some ideas: > > a. don't bother to make it per-agent. > add it to neutron's requirements. (and global-requirement) > simple, but this would make non-ovs plugin users unhappy. > I would simply go with a, what’s the ryu’s internal requirement list? is it big? > > b. make devstack look at per-agent extra requirements file in neutron tree. > eg. neutron/plugins/$Q_AGENT/requirements.txt > IMHO that would make distribution work a bit harder because we may need to process new requirement files, but my answer could depend on what I asked for a. > > c. move OVS agent to a separate repository, just like other > after-decomposition vendor plugins. and use requirements.txt there. > for longer term, this might be a way to go. but i don't want to > block my work until it happens. > > We’re not ready for that yet, as co-gating has proven as a bad strategy and we need to keep the reference implementation working for tests. > > d. follow the way how openvswitch is installed by devstack. > a downside: we can't give a jenkins run for a patch which introduces > an extra requirement. (like my patch for the mentioned blueprint [2]) > > i think b. is the most reasonable choice, at least for short/mid term. > > any comments/thoughts? > > YAMAMOTO Takashi > > [1] https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python > [2] https://review.openstack.org/#/c/153946/ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto: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] moving openvswitch ports between namespaces considered harmful
Sorry, I forgot about 5) If we put all our OVS/OF bridge logic in just one bridge (instead of N: br-tun, br-int, br-ex, br-xxx), the performance should be yet higher, since, as far as I understood, flow rule lookup could be more optimized into the kernel megaflows without forwarding and re-starting evaluation due to patch ports. (Please correct me here where I’m wrong, I just have very high level view of this). Best, Miguel Ángel Ajo On Friday, 13 de February de 2015 at 13:42, Miguel Ángel Ajo wrote: > Hi, Ihar & Jiri, thank you for pointing this out. > > I’m working on the following items: > > 1) Doing Openflow traffic filtering (stateful firewall) based on OVS+CT[1] > patch, which may > eventually merge. Here I want to build a good amount of benchmarks to be > able to compare > the current network iptables+LB solution to just openflow. > > Openflow filtering should be fast, as it’s quite smart at using hashes > to match OF rules > in the kernel megaflows (thanks Jiri & T.Graf for explaining me this) > > The only bad part is that we would have to dynamically change more rules > based on security > group changes (now we do that via ip sets without reloading all the rules). > > To do this properly, we may want to make the OVS plugin a real OF > controller to be able to > push OF rules to the bridge without the need of calling ovs-ofctl on the > command line all the time. > > 2) Using OVS+OF to do QoS > > other interesting stuff to look at: > > 3) Doing routing in OF too, thanks to the NAT capabilities of having OVS+CT > > 4) The namespace problem, what kinds of statistics get broken by moving ports > into namespaces now?, > the short-term fix could be using vets, but “namespaceable” OVS ports > would be perfect, yet I understand > the change is a big feature. > > If we had 1 & 3, may be 4 wouldn’t be a problem anymore. > > [1] https://github.com/justinpettit/ovs/tree/conntrack > > Miguel Ángel Ajo > > > On Friday, 13 de February de 2015 at 13:14, Ihar Hrachyshka wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hi neutroners, > > > > we** had several conversations recently with our Red Hat fellows who > > work on openvswitch (Jiri Benc and Jiri Pirko) regarding the way > > neutron utilizes their software. Those were beneficial to both sides > > to understand what we do right and wrong. I was asked to share some of > > the points from those discussions with broader community. > > > > === > > > > One of the issues that came up during discussions is the way neutron > > connects ovs ports to namespaces. The short story is that openvswitch > > is not designed with namespaces in mind, and the fact that moving its > > ports into a different namespace works for neutron is mere > > coincidence, and is actually considered as a bug by openvswitch guys. > > > > It's not just broken in theory from software design standpoint, but > > also in practice. Specifically, > > > > 1. ovsdb dump does not work properly for namespaces: > > - - https://bugzilla.redhat.com/show_bug.cgi?id=1160340 > > > > This results in wrong statistics and other data collected for these ports; > > > > 2. We suspect that the following kernel crash is triggered because of > > our usage of the feature that is actually a bug: > > - - https://bugs.launchpad.net/neutron/+bug/1418097 > > > > Quoting Jiri Benc, > > > > "The problem is openvswitch does not support its ports to be moved to > > a different name space. The fact that it's possible to do that is a > > bug - such operation should have been denied. Unfortunately, due to a > > missing check, it's not been denied. Such setup does not work > > reliably, though, and leads to various issues from incorrect resource > > accounting to kernel crashes. > > > > We're aware of the bug but we don't have any easy way to fix it. The > > most obvious option, disabling moving of ovs ports to different name > > spaces, would be easy to do but it would break Neutron. The other > > option, making ovs to work across net name spaces, is hard and will > > require addition of different kernel APIs and large changes in ovs > > user space daemons. This constitutes tremendous amount of work." > > > > The tracker bug on openvswitch side is: > > - - https://bugzilla.redhat.com/show_bug.cgi?id=1160340 > > > > So in the best case, we may expect openvswitch to properly support the
Re: [openstack-dev] [neutron] moving openvswitch ports between namespaces considered harmful
Hi, Ihar & Jiri, thank you for pointing this out. I’m working on the following items: 1) Doing Openflow traffic filtering (stateful firewall) based on OVS+CT[1] patch, which may eventually merge. Here I want to build a good amount of benchmarks to be able to compare the current network iptables+LB solution to just openflow. Openflow filtering should be fast, as it’s quite smart at using hashes to match OF rules in the kernel megaflows (thanks Jiri & T.Graf for explaining me this) The only bad part is that we would have to dynamically change more rules based on security group changes (now we do that via ip sets without reloading all the rules). To do this properly, we may want to make the OVS plugin a real OF controller to be able to push OF rules to the bridge without the need of calling ovs-ofctl on the command line all the time. 2) Using OVS+OF to do QoS other interesting stuff to look at: 3) Doing routing in OF too, thanks to the NAT capabilities of having OVS+CT 4) The namespace problem, what kinds of statistics get broken by moving ports into namespaces now?, the short-term fix could be using vets, but “namespaceable” OVS ports would be perfect, yet I understand the change is a big feature. If we had 1 & 3, may be 4 wouldn’t be a problem anymore. [1] https://github.com/justinpettit/ovs/tree/conntrack Miguel Ángel Ajo On Friday, 13 de February de 2015 at 13:14, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi neutroners, > > we** had several conversations recently with our Red Hat fellows who > work on openvswitch (Jiri Benc and Jiri Pirko) regarding the way > neutron utilizes their software. Those were beneficial to both sides > to understand what we do right and wrong. I was asked to share some of > the points from those discussions with broader community. > > === > > One of the issues that came up during discussions is the way neutron > connects ovs ports to namespaces. The short story is that openvswitch > is not designed with namespaces in mind, and the fact that moving its > ports into a different namespace works for neutron is mere > coincidence, and is actually considered as a bug by openvswitch guys. > > It's not just broken in theory from software design standpoint, but > also in practice. Specifically, > > 1. ovsdb dump does not work properly for namespaces: > - - https://bugzilla.redhat.com/show_bug.cgi?id=1160340 > > This results in wrong statistics and other data collected for these ports; > > 2. We suspect that the following kernel crash is triggered because of > our usage of the feature that is actually a bug: > - - https://bugs.launchpad.net/neutron/+bug/1418097 > > Quoting Jiri Benc, > > "The problem is openvswitch does not support its ports to be moved to > a different name space. The fact that it's possible to do that is a > bug - such operation should have been denied. Unfortunately, due to a > missing check, it's not been denied. Such setup does not work > reliably, though, and leads to various issues from incorrect resource > accounting to kernel crashes. > > We're aware of the bug but we don't have any easy way to fix it. The > most obvious option, disabling moving of ovs ports to different name > spaces, would be easy to do but it would break Neutron. The other > option, making ovs to work across net name spaces, is hard and will > require addition of different kernel APIs and large changes in ovs > user space daemons. This constitutes tremendous amount of work." > > The tracker bug on openvswitch side is: > - - https://bugzilla.redhat.com/show_bug.cgi?id=1160340 > > So in the best case, we may expect openvswitch to properly support the > feature in long term, but short term it won't work, especially while > neutron expects other features implemented in openvswitch for it (like > NAT, or connection tracking, or ipv6 tunnel endpoints, to name a few). > > We could try to handle the issue neutron side. We can fix it by > utilizing veth pairs to get into namespaces, but it may mean worse > performance, and will definitely require proper benchmarking to see > whether we can live with performance drop. > > === > > There were other suggestions on how we can enhance our way of usage of > openvswitch. Among those, getting rid of linux bridge used for > security groups, with special attention on getting rid of ebtables > (sic!) for they are a lot slower than iptables; getting rid of veth > pair for instance ports. > > === > > I really encourage everyone to check the following video from > devconf.cz (http://devconf.cz) 2015 on all that and more at: > > - - https://www.youtube.co
Re: [openstack-dev] [neutron][security][rootwrap] Proposal to replace rootwrap/sudo with privsep helper process (for neutron, but others too)
We have an ongoing effort in neutron to move to rootwrap-daemon.
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/rootwrap-daemon-mode,n,z
To speed up multiple system calls, and be able to spawn daemons inside
namespaces.
I have to read a bit what are the good & bad points of privsep.
The advantage of rootwrap-daemon, is that we don’t need to change all our
networking libraries across neutron,
and we kill the sudo/rootwrap spawn for every call, yet keeping the rootwrap
permission granularity.
Miguel Ángel Ajo
On Friday, 13 de February de 2015 at 10:54, Angus Lees wrote:
> On Fri Feb 13 2015 at 5:45:36 PM Eric Windisch (mailto:e...@windisch.us)> wrote:
> > ᐧ
> > >
> > > from neutron.agent.privileged.commands import ip_lib as priv_ip
> > > def foo():
> > > # Need to create a new veth interface pair - that usually
> > > requires root/NET_ADMIN
> > > priv_ip.CreateLink('veth', 'veth0', peer='veth1')
> > >
> > > Because we now have elevated privileges directly (on the privileged
> > > daemon side) without having to shell out through sudo, we can do all
> > > sorts of nicer things like just using netlink directly to configure
> > > networking. This avoids the overhead of executing subcommands, the
> > > ugliness (and danger) of generating command lines and regex parsing
> > > output, and make us less reliant on specific versions of command line
> > > tools (since the kernel API should be very stable).
> >
> > One of the advantages of spawning a new process is being able to use flags
> > to clone(2) and to set capabilities. This basically means to create
> > containers, by some definition. Anything you have in a "privileged daemon"
> > or privileged process ideally should reduce its privilege set for any
> > operation it performs. That might mean it clones itself and executes
> > Python, or it may execvp an executable, but either way, the new process
> > would have less-than-full-privilege.
> >
> > For instance, writing a file might require root access, but does not need
> > the ability to load kernel modules. Changing network interfaces does not
> > need access to the filesystem, no more than changes to the filesystem needs
> > access to the network. The capabilities and namespaces mechanisms resolve
> > these security conundrums and simplify principle of least privilege.
>
> Agreed wholeheartedly, and I'd appreciate your thoughts on how I'm using
> capabilities in this change. The privsep daemon limits itself to a
> particular set of capabilities (and drops root). The assumption is that most
> OpenStack services commonly need the same small set of capabilities to
> perform their duties (neutron -> net_admin+sys_admin for example), so it
> makes sense to reuse the same privileged process.
>
> If we have a single service that somehow needs to frequently use a broad
> swathe of capabilities then we might want to break it up further somehow
> between the different internal aspects (multiple privsep helpers?) - but is
> there such a case? There's also no problems with mixing privsep for
> frequent operations with the existing sudo/rootwrap approach for rare/awkward
> cases.
>
> - Gus
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> (mailto: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] high dhcp lease times in neutron deployments considered harmful (or not???)
Miguel Ángel Ajo On Wednesday, 4 de February de 2015 at 10:41, Cory Benfield wrote: > On Wed, Feb 04, 2015 at 08:59:54, Kevin Benton wrote: > > I proposed an alternative to adjusting the lease time early on the in > > the thread. By specifying the renewal time (DHCP option 58), we can > > have > > the benefits of a long lease time (resiliency to long DHCP server > > outages) while having a frequent renewal interval to check for IP > > changes. I favored this approach because it only required a patch to > > dnsmasq to allow that option to be set and patch to our agent to set > > that option, both of which are pretty straight-forward. > > > > > It's hard to see a downside to this proposal. Even if one of the other ideas > goes forward as well, a short DHCP renewal interval feels like a very good > idea to me. > +1 I understand some dhcp-clients could ignore option 58, but yet, I understand they will obey the longer lease time, without affecting they behavior. So only who really needs it would take care of using fully compliant clients… __ 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] [lbaas] LBaaS Haproxy performance benchmarking
You can try with httperf[1], or ab[2] for http workloads. If you will use overlay, make sure your network MTU is correctly configured to handle the extra size of the overlay (GRE / VXLAN packets) otherwise you will be introducing fragmentation overhead on the tenant networks. [1] http://www.hpl.hp.com/research/linux/httperf/ [2] http://httpd.apache.org/docs/2.2/programs/ab.html Miguel Ángel Ajo On Wednesday, 4 de February de 2015 at 01:58, Varun Lodaya wrote: > Hi, > > We were trying to use haproxy as our LBaaS solution on the overlay. Has > anybody done some baseline benchmarking with LBaaSv1 haproxy solution? > > Also, any recommended tools which we could use to do that? > > Thanks, > Varun > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto: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] high dhcp lease times in neutron deployments considered harmful (or not???)
Miguel Ángel Ajo On Wednesday, 28 de January de 2015 at 09:50, Kevin Benton wrote: > Hi, > > Approximately a year and a half ago, the default DHCP lease time in Neutron > was increased from 120 seconds to 86400 seconds.[1] This was done with the > goal of reducing DHCP traffic with very little discussion (based on what I > can see in the review and bug report). While it it does indeed reduce DHCP > traffic, I don't think any bug reports were filed showing that a 120 second > lease time resulted in too much traffic or that a jump all of the way to > 86400 seconds was required instead of a value in the same order of magnitude. > > Why does this matter? > > Neutron ports can be updated with a new IP address from the same subnet or > another subnet on the same network. The port update will result in > anti-spoofing iptables rule changes that immediately stop the old IP address > from working on the host. This means the host is unreachable for 0-12 hours > based on the current default lease time without manual intervention[2] > (assuming half-lease length DHCP renewal attempts). > > Why is this on the mailing list? > > In an attempt to make the VMs usable in a much shorter timeframe following a > Neutron port address change, I submitted a patch to reduce the default DHCP > lease time to 8 minutes.[3] However, this was upsetting to several people,[4] > so it was suggested I bring this discussion to the mailing list. The > following are the high-level concerns followed by my responses: > 8 minutes is arbitrary > Yes, but it's no more arbitrary than 1440 minutes. I picked it as an interval > because it is still 4 times larger than the last short value, but it still > allows VMs to regain connectivity in <5 minutes in the event their IP is > changed. If someone has a good suggestion for another interval based on known > dnsmasq QPS limits or some other quantitative reason, please chime in here. > > other datacenters use long lease times > This is true, but it's not really a valid comparison. In most regular > datacenters, updating a static DHCP lease has no effect on the data plane so > it doesn't matter that the client doesn't react for hours/days (even with > DHCP snooping enabled). However, in Neutron's case, the security groups are > immediately updated so all traffic using the old address is blocked. > > dhcp traffic is scary because it's broadcast > ARP traffic is also broadcast and many clients will expire entries every 5-10 > minutes and re-ARP. L2population may be used to prevent ARP propagation, so > the comparison between DHCP and ARP isn't always relevant here. > > > > For what I’ve seen, at least for linux, the first DHCP request will be broadcast. Then all lease renewals are unicast, unless, the original DHCP can’t be contacted, in which case, the dhcp client will turn back to broadcast trying to find out another server to renew his lease. So, only initial boot of an instance should generate broadcast traffic. Your proposal seems reasonable to me. In this context, please see this ongoing work [5], specially comments here [6], where we’re discussing about optimization, due to theoretical 120 second limit for renews at scale, and we made some calculations of CPU usage for the current default, I will recalculate those for the new proposed default: 8 minutes. TL; DR. That patch fixes an issue found when you restart dnsmasq, and old leases can’t be renewed, so we end up in a storm of requests, for that we need to provide dnsmasq with a script for initialization of the leases table, initially such script was provided in python, but that means that script is called for: init (once), lease (once per instance), and renew (every lease renew time * number of instances), thus we should minimize the impact of such script as much as possible, or contribute dnsmasq to avoid such script being called for lease renews under some flag. > > Please reply back with your opinions/anecdotes/data related to short DHCP > lease times. > > Cheers > > 1. > https://github.com/openstack/neutron/commit/d9832282cf656b162c51afdefb830dacab72defe > 2. Manual intervention could be an instance reboot, a dhcp client invocation > via the console, or a delayed invocation right before the update. (all > significantly more difficult to script than a simple update of a port's IP > via the API). > 3. https://review.openstack.org/#/c/150595/ > 4. http://i.imgur.com/xtvatkP.jpg > > > > 5. https://review.openstack.org/#/c/108272/ (https://review.openstack.org/#/c/108272/8/neutron/agent/linux/dhcp.py) 6. https://review.openstack.org/#/c/108272/8/neutron/agent/linux/dhcp.py > > -- > Kevin
Re: [openstack-dev] [Neutron] Project Idea: IDS integration.
Hi Mario, Salvatore and Kevin perfectly expressed what I think. I’d follow his advice, and look on how the advanced services [1] [2] integrate with neutron, and build a POC. If the POC looks good it could be a good start point to build community around and go on with the development. [1] https://github.com/openstack/neutron-lbaas [2] https://github.com/openstack/neutron-fwaas Miguel Ángel Ajo On Sunday, 18 de January de 2015 at 13:42, Salvatore Orlando wrote: > Hello Mario, > > IDS surely is an interesting topic for OpenStack integration. I think there > might be users out there which could be interested in having this capability > in OpenStack networks. > As Kevin said, we are moving towards a model where it becomes easier for > developers to add such capabilities in the form of "service plugins" - you > should be able to develop everything you need in a separate repository and > still integrate it with Neutron. > > According to what you wrote you have just a bit more than 100 hours to spend > on this project. What can be achieved in this timeframe really depends on > one's skills, but I believe it could be enough to provide some sort of > Proof-of-Concept. However, this time won't be enough at all if you also aim > to seek feedback on your proposal, build a consensus and a developer > community around it. Unsurprisingly these aspects, albeit not technically > challenging, take an awful lot more time than coding! > > Therefore the only advice I have here is that you should focus on achieving > your real goal, which is graduate with the highest possible marks! Then, if > from your thesis there will be something to gain for the OpenStack community, > that would be awesome. With a PoC implementation and perhaps some time on > your hands, you can then be able to work with the community to transform your > masters' project into an OpenStack project and avoid it becomes a bitrotting > shelved piece of code. > > Salvatore > > On 18 January 2015 at 10:45, Kevin Benton (mailto:blak...@gmail.com)> wrote: > > Hi Mario, > > > > There is currently a large backlog of network-related features that many > > people want to develop for Neutron. The model of adding them all to the > > main neutron codebase has failed to keep up. Due to this, all of the > > advanced services (LBaaS, FWaaS, etc) are being separated into their own > > repositories. The main Neutron repo will only be for establishing L2/L3 > > connectivity and providing a framework for other networking services to > > build on. You can read more about it in the advanced services split > > blueprint.[1] > > > > Based on what you've described, it sounds like you would be developing an > > IDS service plugin with a driver/plugin framework for different vendors. > > For an initial proof of concept, you could do it in github to get started > > quickly or you can also request a new stackforge repo for it. The benefit > > of stackforge is that you get the OpenStack testing infrastructure and > > integration with its gerrit system so other OpenStack developers don't have > > to switch code review workflows to contribute. > > > > To gauge interest, I would try emailing the OpenStack users list. It > > doesn't matter if developers are interested if nobody ever wants to > > actually try it out. > > > > 1. https://blueprints.launchpad.net/neutron/+spec/services-split > > > > Cheers, > > Kevin Benton > > > > > > On Fri, Jan 16, 2015 at 2:32 PM, Mario Tejedor González > > mailto:m.tejedor-gonza...@mycit.ie)> wrote: > > > Hello, Neutron developers. > > > > > > My name is Mario and I am a Masters student in Networking and Security. > > > > > > I am considering the possibility of integrating IDS technology to Neutron > > > as part of my Masters project. > > > As there are many flavors of open ID[P]S out there and those might follow > > > different philosophies, my approach would be developing a Neutron plugin > > > that might cover IDS integration as a service and also a driver (or more, > > > depending on time constraints) to cover the specifics of an IDS. > > > Following the nature of Neutron and OpenStack projects these drivers > > > would be developed for Free and Open Software IDSs and the plugin would > > > be as vendor-agnostic as possible. In order to achieve that the plugin > > > would have to deal with the need for logging and alerting. > > > > > > The time window I have for the development of this project goes from > &
Re: [openstack-dev] [Neutron] grenade failures
Hi Sukhdev, thanks, Can you post links to the specific patches? Miguel Ángel Ajo On Wednesday, 14 de January de 2015 at 09:01, Sukhdev Kapur wrote: > Hi All, > > I noticed that several neutron patches are failing > check-grenade-dsvm-neutron. I pinged it on IRC, did not get any response, > thought I post it here. > > > -Sukhdev > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto: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][L3][Devstack] Bug during delete loating Ps?
That’s nice Sunil, can you send the patch for review on gerrit?
May be it’s also interesting to avoid sending a notify_routers_updated when
there are
no router_ids.
Miguel Ángel Ajo
On Sunday, 11 de January de 2015 at 08:42, Sunil Kumar wrote:
> This trivial patch fixes the tracebacks:
>
> $ cat disassociate_floating_ips.patch
> --- neutron/db/l3_db.py.orig2015-01-10 22:20:30.101506298 -0800
> +++ neutron/db/l3_db.py 2015-01-10 22:24:18.111479818 -0800
> @@ -1257,4 +1257,4 @@
>
> def notify_routers_updated(self, context, router_ids):
> super(L3_NAT_db_mixin, self).notify_routers_updated(
> -context, list(router_ids), 'disassociate_floatingips', {})
> +context, list(router_ids) if router_ids else None,
> 'disassociate_floatingips', {})
>
>
> -Sunil
> From: Sunil Kumar [su...@embrane.com (mailto:su...@embrane.com)]
> Sent: Saturday, January 10, 2015 7:07 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Neutron][L3][Devstack] Bug during delete floating
> IPs?
>
> Not sure if its something seen by others. I hit this when I run
> tempest.scenario.test_network_basic_ops.TestNetworkBasicOps against master:
>
> 2015-01-10 17:45:13.227 5350 DEBUG neutron.plugins.ml2.plugin
> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Deleting port
> e5deb014-0063-4d55-8ee3-5ba3524fee14 delete_port
> /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:995
> 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils
> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Created new semaphore "db-access"
> internal_lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:206
> 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils
> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Acquired semaphore "db-access"
> lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:229
> 2015-01-10 17:45:13.252 5350 DEBUG neutron.plugins.ml2.plugin
> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Calling delete_port for
> e5deb014-0063-4d55-8ee3-5ba3524fee14 owned by network:floatingip delete_port
> /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:1043
> 2015-01-10 17:45:13.254 5350 DEBUG neutron.openstack.common.lockutils
> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Releasing semaphore "db-access"
> lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:238
> 2015-01-10 17:45:13.282 5350 ERROR neutron.api.v2.resource
> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] delete failed
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource Traceback (most
> recent call last):
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource File
> "/opt/stack/new/neutron/neutron/api/v2/resource.py", line 83, in resource
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource result =
> method(request=request, **args)
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource File
> "/opt/stack/new/neutron/neutron/api/v2/base.py", line 479, in delete
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource
> obj_deleter(request.context, id, **kwargs)
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource File
> "/opt/stack/new/neutron/neutron/db/l3_dvr_db.py", line 198, in
> delete_floatingip
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource
> self).delete_floatingip(context, id)
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource File
> "/opt/stack/new/neutron/neutron/db/l3_db.py", line 1237, in delete_floatingip
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource router_id =
> self._delete_floatingip(context, id)
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource File
> "/opt/stack/new/neutron/neutron/db/l3_db.py", line 902, in _delete_floatingip
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource
> l3_port_check=False)
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource File
> "/opt/stack/new/neutron/neutron/plugins/ml2/plugin.py", line 1050, in
> delete_port
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource
> l3plugin.notify_routers_updated(context, router_ids)
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource File
> "/opt/stack/new/neutron/neutron/db/l3_db.py", line 1260, in
> notify_routers_updated
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource context,
> list(router_ids), 'disassociate_floatingips', {})
> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource TypeError:
> 'NoneType' object is not iterable
>
> Looks lik
Re: [openstack-dev] [stable][neutron] minimal dnsmasq version
Now that I re-read the patch. Shouldn't the version checking need to be converted into a sanity check? Miguel Ángel Ajo On Thursday, 8 de January de 2015 at 12:51, Kevin Benton wrote: > Thanks for the insight. > > On Thu, Jan 8, 2015 at 3:41 AM, Miguel Ángel Ajo (mailto:majop...@redhat.com)> wrote: > > Correct, that’s the problem, what Kevin said should be the ideal case, but > > distros have > > proven to fail satisfying this kind of requirements earlier. > > > > So at least a warning to the user may be good to have IMHO. > > > > Miguel Ángel Ajo > > > > > > On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka wrote: > > > > > The problem is probably due to the fact that some operators may run > > > neutron from git and manage their dependencies in some other way; or > > > distributions may suck sometimes, so packagers may miss the release note > > > and fail to upgrade dnsmasq; or distributions may have their specific > > > concerns on upgrading dnsmasq version, and would just backport the needed > > > fix to their 'claimed to 2.66' dnsmasq (common story in Red Hat world). > > > > > > On 01/08/2015 05:25 AM, Kevin Benton wrote: > > > > If the new requirement is expressed in the neutron packages for the > > > > distro, wouldn't it be transparent to the operators? > > > > > > > > On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery > > > (mailto:mest...@mestery.com)> wrote: > > > > > On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka > > > > (mailto:ihrac...@redhat.com)> wrote: > > > > > > Hi all, > > > > > > > > > > > > I've found out that dnsmasq < 2.67 does not work properly for IPv6 > > > > > > clients when it comes to MAC address matching (it fails to match, > > > > > > and so clients get 'no addresses available' response). I've > > > > > > requested version bump to 2.67 in: > > > > > > https://review.openstack.org/145482 > > > > > > > > > > > Good catch, thanks for finding this Ihar! > > > > > > > > > > > Now, since we've already released Juno with IPv6 DHCP stateful > > > > > > support, and DHCP agent still has minimal version set to 2.63 > > > > > > there, we have a dilemma on how to manage it from stable > > > > > > perspective. > > > > > > > > > > > > Obviously, we should communicate the revealed version dependency to > > > > > > deployers via next release notes. > > > > > > > > > > > > Should we also backport the minimal version bump to Juno? This will > > > > > > result in DHCP agent failing to start in case packagers don't bump > > > > > > dnsmasq version with the next Juno release. If we don't bump the > > > > > > version, we may leave deployers uninformed about the fact that > > > > > > their IPv6 stateful instances won't get any IPv6 address assigned. > > > > > > > > > > > > An alternative is to add a special check just for Juno that would > > > > > > WARN administrators instead of failing to start DHCP agent. > > > > > > > > > > > > Comments? > > > > > > > > > > > Personally, I think the WARN may be the best route to go. Backporting > > > > > a change which bumps the required dnsmasq version seems like it may > > > > > be harder for operators to handle. > > > > > > > > > > Kyle > > > > > > > > > > > /Ihar > > > > > > > > > > > > ___ > > > > > > OpenStack-dev mailing list > > > > > > OpenStack-dev@lists.openstack.org > > > > > > (mailto:OpenStack-dev@lists.openstack.org) > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > > > ___ > > > > > OpenStack-dev mailing list > > > > > OpenStack-dev@lists.openstack.org > > > > > (mailto:OpenStack-dev@lists.openstack.org) > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [stable][neutron] minimal dnsmasq version
Correct, that’s the problem, what Kevin said should be the ideal case, but distros have proven to fail satisfying this kind of requirements earlier. So at least a warning to the user may be good to have IMHO. Miguel Ángel Ajo On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka wrote: > The problem is probably due to the fact that some operators may run neutron > from git and manage their dependencies in some other way; or distributions > may suck sometimes, so packagers may miss the release note and fail to > upgrade dnsmasq; or distributions may have their specific concerns on > upgrading dnsmasq version, and would just backport the needed fix to their > 'claimed to 2.66' dnsmasq (common story in Red Hat world). > > On 01/08/2015 05:25 AM, Kevin Benton wrote: > > If the new requirement is expressed in the neutron packages for the distro, > > wouldn't it be transparent to the operators? > > > > On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery > (mailto:mest...@mestery.com)> wrote: > > > On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka > > (mailto:ihrac...@redhat.com)> wrote: > > > > Hi all, > > > > > > > > I've found out that dnsmasq < 2.67 does not work properly for IPv6 > > > > clients when it comes to MAC address matching (it fails to match, and > > > > so clients get 'no addresses available' response). I've requested > > > > version bump to 2.67 in: https://review.openstack.org/145482 > > > > > > > Good catch, thanks for finding this Ihar! > > > > > > > Now, since we've already released Juno with IPv6 DHCP stateful support, > > > > and DHCP agent still has minimal version set to 2.63 there, we have a > > > > dilemma on how to manage it from stable perspective. > > > > > > > > Obviously, we should communicate the revealed version dependency to > > > > deployers via next release notes. > > > > > > > > Should we also backport the minimal version bump to Juno? This will > > > > result in DHCP agent failing to start in case packagers don't bump > > > > dnsmasq version with the next Juno release. If we don't bump the > > > > version, we may leave deployers uninformed about the fact that their > > > > IPv6 stateful instances won't get any IPv6 address assigned. > > > > > > > > An alternative is to add a special check just for Juno that would WARN > > > > administrators instead of failing to start DHCP agent. > > > > > > > > Comments? > > > > > > > Personally, I think the WARN may be the best route to go. Backporting a > > > change which bumps the required dnsmasq version seems like it may be > > > harder for operators to handle. > > > > > > Kyle > > > > > > > /Ihar > > > > > > > > ___ > > > > OpenStack-dev mailing list > > > > OpenStack-dev@lists.openstack.org > > > > (mailto:OpenStack-dev@lists.openstack.org) > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > ___ > > > OpenStack-dev mailing list > > > OpenStack-dev@lists.openstack.org > > > (mailto:OpenStack-dev@lists.openstack.org) > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > -- > > Kevin Benton > > > > ___ OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > (mailto:OpenStack-dev@lists.openstack.org) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices
Totally correct, that’s what I was meaning with “will remain active”
but “unmanaged”.
Yes, it would be good to have something to tell the schedulers to ban a host.
Miguel Ángel Ajo
On Thursday, 8 de January de 2015 at 00:52, Kevin Benton wrote:
> The problem is that if you just stop the service, it not only removes it from
> scheduling, but it stops it from receiving updates to floating IP changes,
> interface changes, etc. I think it would be nice to have a way to explicitly
> stop it from being scheduled new routers, but still act as a functioning L3
> agent otherwise.
>
> On Wed, Jan 7, 2015 at 3:30 PM, Miguel Ángel Ajo (mailto:majop...@redhat.com)> wrote:
> > You can stop the neutron-dhcp-agent or neutron-l3-agent,
> > the agents should go not-active after reporting timeout.
> >
> > The actual network services (routers, dhcp, etc) will stay
> > active into the node, but unmanaged. In some cases,
> > if you have automatic rescheduling of the resources
> > configured, those will be spawned on other hosts.
> >
> > Depending on your use case this will be enough or not.
> > It’s intended for upgrades and maintenance. But not
> > for controlling resources in a node.
> >
> >
> > Miguel Ángel Ajo
> >
> >
> > On Thursday, 8 de January de 2015 at 00:20, Itsuro ODA wrote:
> >
> > > Carl,
> > >
> > > Thank you for your comment.
> > >
> > > It seems there is no clear opinion about whether bug report or
> > > buleprint is better.
> > > So I submitted a bug report for the moment so that the requirememt
> > > is not forgotten.
> > > https://bugs.launchpad.net/neutron/+bug/1408488
> > >
> > > Thanks.
> > > Itsuro Oda
> > >
> > > On Tue, 6 Jan 2015 09:05:19 -0700
> > > Carl Baldwin mailto:c...@ecbaldwin.net)> wrote:
> > >
> > > > Itsuro,
> > > >
> > > > It would be desirable to be able to be hide an agent from scheduling
> > > > but no one has stepped up to make this happen. Come to think of it,
> > > > I'm not sure that a bug or blueprint has been filed yet to address it
> > > > though it is something that I've wanted for a little while now.
> > > >
> > > > Carl
> > > >
> > > > On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA > > > (mailto:o...@valinux.co.jp)> wrote:
> > > > > Neutron experts,
> > > > >
> > > > > I want to stop scheduling to a specific {dhcp|l3}_agent without
> > > > > stopping router/dhcp services on it.
> > > > > I expected setting admin_state_up of the agent to False is met
> > > > > this demand. But this operation stops all services on the agent
> > > > > in actuality. (Is this behavior intended ? It seems there is no
> > > > > document for agent API.)
> > > > >
> > > > > I think admin_state_up of agents should affect only scheduling.
> > > > > If it is accepted I will submit a bug report and make a fix.
> > > > >
> > > > > Or should I propose a blueprint for adding function to stop
> > > > > agent's scheduling without stopping services on it ?
> > > > >
> > > > > I'd like to hear neutron experts' suggestions.
> > > > >
> > > > > Thanks.
> > > > > Itsuro Oda
> > > > > --
> > > > > Itsuro ODA mailto:o...@valinux.co.jp)>
> > > > >
> > > > >
> > > > > ___
> > > > > OpenStack-dev mailing list
> > > > > OpenStack-dev@lists.openstack.org
> > > > > (mailto:OpenStack-dev@lists.openstack.org)
> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > > >
> > > >
> > > >
> > > > ___
> > > > OpenStack-dev mailing list
> > > > OpenStack-dev@lists.openstack.org
> > > > (mailto:OpenStack-dev@lists.openstack.org)
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > >
> > >
> > >
> > > --
> > > Itsuro ODA mailto:o...@valinux.co.jp)>
> > >
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > (mailto:OpenStack-dev@lists.openstack.org)
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Kevin Benton
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices
You can stop the neutron-dhcp-agent or neutron-l3-agent,
the agents should go not-active after reporting timeout.
The actual network services (routers, dhcp, etc) will stay
active into the node, but unmanaged. In some cases,
if you have automatic rescheduling of the resources
configured, those will be spawned on other hosts.
Depending on your use case this will be enough or not.
It’s intended for upgrades and maintenance. But not
for controlling resources in a node.
Miguel Ángel Ajo
On Thursday, 8 de January de 2015 at 00:20, Itsuro ODA wrote:
> Carl,
>
> Thank you for your comment.
>
> It seems there is no clear opinion about whether bug report or
> buleprint is better.
> So I submitted a bug report for the moment so that the requirememt
> is not forgotten.
> https://bugs.launchpad.net/neutron/+bug/1408488
>
> Thanks.
> Itsuro Oda
>
> On Tue, 6 Jan 2015 09:05:19 -0700
> Carl Baldwin mailto:c...@ecbaldwin.net)> wrote:
>
> > Itsuro,
> >
> > It would be desirable to be able to be hide an agent from scheduling
> > but no one has stepped up to make this happen. Come to think of it,
> > I'm not sure that a bug or blueprint has been filed yet to address it
> > though it is something that I've wanted for a little while now.
> >
> > Carl
> >
> > On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA > (mailto:o...@valinux.co.jp)> wrote:
> > > Neutron experts,
> > >
> > > I want to stop scheduling to a specific {dhcp|l3}_agent without
> > > stopping router/dhcp services on it.
> > > I expected setting admin_state_up of the agent to False is met
> > > this demand. But this operation stops all services on the agent
> > > in actuality. (Is this behavior intended ? It seems there is no
> > > document for agent API.)
> > >
> > > I think admin_state_up of agents should affect only scheduling.
> > > If it is accepted I will submit a bug report and make a fix.
> > >
> > > Or should I propose a blueprint for adding function to stop
> > > agent's scheduling without stopping services on it ?
> > >
> > > I'd like to hear neutron experts' suggestions.
> > >
> > > Thanks.
> > > Itsuro Oda
> > > --
> > > Itsuro ODA mailto:o...@valinux.co.jp)>
> > >
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > (mailto:OpenStack-dev@lists.openstack.org)
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Itsuro ODA mailto:o...@valinux.co.jp)>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] client noauth deprecation
Seems like a good reason to keep it, this allows us to test internal integration in isolation from keystone. Miguel Ángel Ajo On Wednesday, 7 de January de 2015 at 10:05, Assaf Muller wrote: > > > - Original Message - > > The option to disable keystone authentication in the neutron client was > > marked for deprecation in August as part of a Keystone support upgrade.[1] > > > > What was the reason for this? As far as I can tell, Neutron works fine in > > the > > 'noauth' mode and there isn't a lot of code that tightly couples neutron to > > Keystone that I can think of. > > > > > It was actually broken until John fixed it in: > https://review.openstack.org/#/c/125022/ > > We plan on using it in the Neutron in-tree full-stack testing. I'd appreciate > if the functionality was not removed or otherwise broken :) > > > > > 1. > > https://github.com/openstack/python-neutronclient/commit/2203b013fb66808ef280eff0285318ce21d9bc67#diff-ba2e4fad85e66d9aabb6193f222fcc4cR438 > > > > -- > > Kevin Benton > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Canceling the next two meetings
Happy Holidays!, thank you Kyle. Miguel Ángel Ajo On Monday, 22 de December de 2014 at 21:12, Kyle Mestery wrote: > Hi folks, given I expect low attendance today and next week, lets just cancel > the next two Neutron meetings. We'll reconvene in the new year on Monday, > January 5, 2015 at 2100 UTC. > > Happy holidays to all! > > Kyle > > [1] https://wiki.openstack.org/wiki/Network/Meetings > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][fwaas] neutron/agent/firewall.py
Correct, this is for the security groups implementation Miguel Ángel Ajo On Friday, 19 de December de 2014 at 23:50, Sridar Kandaswamy (skandasw) wrote: > +1 Mathieu. Paul, this is not related to FWaaS. > > Thanks > > Sridar > > On 12/19/14, 2:23 PM, "Mathieu Gagné" http://web.com)> > wrote: > > > On 2014-12-19 5:16 PM, Paul Michali (pcm) wrote: > > > > > > This has a FirewallDriver and NoopFirewallDriver. Should this be moved > > > into the neutron_fwaas repo? > > > > > > > > > AFAIK, FirewallDriver is used to implement SecurityGroup: > > > > See: > > - > > https://github.com/openstack/neutron/blob/master/neutron/agent/firewall.py > > #L26-L29 > > - > > https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptab > > les_firewall.py#L45 > > - > > https://github.com/openstack/neutron/blob/master/neutron/plugins/hyperv/ag > > ent/security_groups_driver.py#L25 > > > > This class looks to not be used by neutron-fwaas > > > > -- > > Mathieu > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] mid-cycle "hot reviews"
Hi all! It would be great if you could use this thread to post hot reviews on stuff that it’s being worked out during the mid-cycle, where others from different timezones could participate. I know posting reviews to the list is not permitted, but I think an exception in this case would be beneficial. Best regards, Miguel Ángel Ajo ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Deprecating old security groups code / RPC.
On Thursday, 4 de December de 2014 at 15:19, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > On Thursday, 4 de December de 2014 at 15:06, Miguel Ángel Ajo > > wrote: > > > > > > > > > > > During Juno, we introduced the enhanced security groups rpc > > > (security_groups_info_for_devices) instead of > > > (security_group_rules_for_devices), and the ipset functionality > > > to offload iptable chains a bit. > > > > > > > > > Here I propose to: > > > > > > 1) Remove the old security_group_info_for_devices, which was left > > > to ease operators upgrade path from I to J (allowing running old > > > openvswitch agents as we upgrade) > > > > > > Doing this we can cleanup the current iptables firewall driver a > > > bit from unused code paths. > > > > > > > > > > +1. > > > > > > > I suppose this would require a major RPC version bump. > > > > > > 2) Remove the option to disable ipset (now it’s enabled by > > > default and seems to be working without problems), and make it an > > > standard way to handle “IP” groups from the iptables > > > perspective. > > > > > > > > Is ipset support present in all supported distributions? > It is from Red Hat perspective, not sure Ubuntu, and the others, I think Juno was targeted to ubuntu 14.04 only (which does have ipset kernel support and it’s tool). Ipset was in kernel since 2.4.x, but RHEL6/Centos6 didn’t ship the tools neither enabled it on kernel (AFAIK). > > > > > > > > > > Thoughts?, > > > > > > Best regards, Miguel Ángel Ajo > > > > > > ___ OpenStack-dev > > > mailing list OpenStack-dev@lists.openstack.org > > > (mailto:OpenStack-dev@lists.openstack.org) > > > <mailto:OpenStack-dev@lists.openstack.org> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > ___ OpenStack-dev > > mailing list OpenStack-dev@lists.openstack.org > > (mailto:OpenStack-dev@lists.openstack.org) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > iQEcBAEBCgAGBQJUgG1jAAoJEC5aWaUY1u57aK4H/1G0R0NgURf1l7WCx27VqRDR > jdFlYzecMk2E6h84Fv5tJgGqAm6mGEFUrLf8MJ9+kDB33Syb+zvxJc9v6CvMw7br > o+Qjk4lbHiiko1W8kDmq+onjUDHExapTR1+PsSX0HmuEvwV8yrAm/VJyccAAiqB6 > XPrWG4Xft2zEp004/uT9jzJPeW4YhRNY84Sa2C1ghemzKn43QYlu8U3DfuDzfQFP > 2MjzTwdP1FfBIX0jhXHrMlnHGuuxAscL9v6DM7Np2Iro6ExXK1ry9ex4/NWbdcIY > sP9MkuA2wAMYE8pN1UM4LwSPg2rpEZEuwJfXyTohshcVHDoyPk81F4Q6R+ABPqM= > =xzY6 > -END PGP SIGNATURE- > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Deprecating old security groups code / RPC.
Sorry, adding [neutron] to the subject. Miguel Ángel Ajo On Thursday, 4 de December de 2014 at 15:06, Miguel Ángel Ajo wrote: > > > During Juno, we introduced the enhanced security groups rpc > (security_groups_info_for_devices) instead of > (security_group_rules_for_devices), > and the ipset functionality to offload iptable chains a bit. > > > Here I propose to: > > 1) Remove the old security_group_info_for_devices, which was left to ease > operators upgrade > path from I to J (allowing running old openvswitch agents as we upgrade) > > Doing this we can cleanup the current iptables firewall driver a bit from > unused code paths. > > > I suppose this would require a major RPC version bump. > > 2) Remove the option to disable ipset (now it’s enabled by default and seems > to be working without problems), and make it an standard way to handle “IP” > groups > from the iptables perspective. > > > Thoughts?, > > Best regards, > Miguel Ángel Ajo > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Deprecating old security groups code / RPC.
During Juno, we introduced the enhanced security groups rpc (security_groups_info_for_devices) instead of (security_group_rules_for_devices), and the ipset functionality to offload iptable chains a bit. Here I propose to: 1) Remove the old security_group_info_for_devices, which was left to ease operators upgrade path from I to J (allowing running old openvswitch agents as we upgrade) Doing this we can cleanup the current iptables firewall driver a bit from unused code paths. I suppose this would require a major RPC version bump. 2) Remove the option to disable ipset (now it’s enabled by default and seems to be working without problems), and make it an standard way to handle “IP” groups from the iptables perspective. Thoughts?, Best regards, Miguel Ángel Ajo ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] force_gateway_on_subnet, please don't deprecate
I will spend some time on it during tonight/weekend to make sure it’s removed and that we have reference implementation working at once. I propose following the bug fix way, as it’s a tiny change. https://bugs.launchpad.net/neutron/+bug/1398768 @amuller, I’m not sure I understand why does it need to be covered in the dhcp-agent side. Pushing extra routes to guest-vms?, I think we don’t cover the case of instances connected to an external network where we provide dhcp, but we may do that if we are or if we start covering that case anytime. Miguel Ángel Ajo On Tuesday, 2 de December de 2014 at 15:48, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 01/12/14 21:19, Kyle Mestery wrote: > > On Mon, Dec 1, 2014 at 6:12 AM, Assaf Muller > (mailto:amul...@redhat.com)> > > wrote: > > > > > > > > > - Original Message - > > > > > > > > My proposal here, is, _let’s not deprecate this setting_, as > > > > it’s a valid use case of a gateway configuration, and let’s > > > > provide it on the reference implementation. > > > > > > > > > > > > > I agree. As long as the reference implementation works with the > > > setting off there's no need to deprecate it. I still think the > > > default should be set to True though. > > > > > > Keep in mind that the DHCP agent will need changes as well. > > ++ to both suggestions Assaf. Thanks for bringing this up Miguel! > > > > > Miguel, how about sending a patch that removes deprecation warning > from the help text then? > > > > > Kyle > > > > > > > > > > TL;DR > > > > > > > > I’ve been looking at this yesterday, during a test deployment > > > > on a site where they provide external connectivity with the > > > > gateway outside subnet. > > > > > > > > And I needed to switch it of, to actually be able to have any > > > > external connectivity. > > > > > > > > https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L121 > This is handled by providing an on-link route to the gateway first, > > > > and then adding the default gateway. > > > > > > > > It looks to me very interesting (not only because it’s the only > > > > way to work on that specific site [2][3][4]), because you can > > > > dynamically wire RIPE blocks to your server, without needing to > > > > use an specific IP for external routing or broadcast purposes, > > > > and instead use the full block in openstack. > > > > > > > > > > > > I have a tiny patch to support this on the neutron l3-agent [1] > > > > I yet need to add the logic to check “gateway outside subnet”, > > > > then add the “onlink” route. > > > > > > > > > > > > [1] > > > > > > > > diff --git a/neutron/agent/linux/interface.py > > > > b/neutron/agent/linux/interface.py index 538527b..5a9f186 > > > > 100644 --- a/neutron/agent/linux/interface.py +++ > > > > b/neutron/agent/linux/interface.py @@ -116,15 +116,16 @@ class > > > > LinuxInterfaceDriver(object): namespace=namespace, ip=ip_cidr) > > > > > > > > - if gateway: - device.route.add_gateway(gateway) - > > > > new_onlink_routes = set(s['cidr'] for s in extra_subnets) + if > > > > gateway: + new_onlink_routes.update([gateway]) > > > > existing_onlink_routes = > > > > set(device.route.list_onlink_routes()) for route in > > > > new_onlink_routes - existing_onlink_routes: > > > > device.route.add_onlink_route(route) for route in > > > > existing_onlink_routes - new_onlink_routes: > > > > device.route.delete_onlink_route(route) + if gateway: + > > > > device.route.add_gateway(gateway) > > > > > > > > def delete_conntrack_state(self, root_helper, namespace, ip): > > > > """Delete conntrack state associated with an IP address. > > > > > > > > [2] http://www.soyoustart.com/ [3] http://www.ovh.co.uk/ [4] > > > > http://www.kimsufi.com/ > > > > > > > > > > > > Miguel Ángel Ajo > > > > > > > > > > > > > > > > > > > > ___ OpenStack-dev > > > > mailing list OpenStack-dev@lists.openstac
Re: [openstack-dev] [neutron] Changes to the core team
Congratulations to Henry and Kevin, very well deserved!, keep up the good work! :) Miguel Ángel Ajo On Wednesday, 3 de December de 2014 at 09:44, Oleg Bondarev wrote: > +1! Congrats, Henry and Kevin! > > On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery (mailto:mest...@mestery.com)> wrote: > > Now that we're in the thick of working hard on Kilo deliverables, I'd > > like to make some changes to the neutron core team. Reviews are the > > most important part of being a core reviewer, so we need to ensure > > cores are doing reviews. The stats for the 180 day period [1] indicate > > some changes are needed for cores who are no longer reviewing. > > > > First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from > > neutron-core. Bob and Nachi have been core members for a while now. > > They have contributed to Neutron over the years in reviews, code and > > leading sub-teams. I'd like to thank them for all that they have done > > over the years. I'd also like to propose that should they start > > reviewing more going forward the core team looks to fast track them > > back into neutron-core. But for now, their review stats place them > > below the rest of the team for 180 days. > > > > As part of the changes, I'd also like to propose two new members to > > neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have > > been very active in reviews, meetings, and code for a while now. Henry > > lead the DB team which fixed Neutron DB migrations during Juno. Kevin > > has been actively working across all of Neutron, he's done some great > > work on security fixes and stability fixes in particular. Their > > comments in reviews are insightful and they have helped to onboard new > > reviewers and taken the time to work with people on their patches. > > > > Existing neutron cores, please vote +1/-1 for the addition of Henry > > and Kevin to the core team. > > > > Thanks! > > Kyle > > > > [1] http://stackalytics.com/report/contribution/neutron-group/180 > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] force_gateway_on_subnet, please don't deprecate
My proposal here, is, _let’s not deprecate this setting_, as it’s a valid use case of a gateway configuration, and let’s provide it on the reference implementation. TL;DR I’ve been looking at this yesterday, during a test deployment on a site where they provide external connectivity with the gateway outside subnet. And I needed to switch it of, to actually be able to have any external connectivity. https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L121 This is handled by providing an on-link route to the gateway first, and then adding the default gateway. It looks to me very interesting (not only because it’s the only way to work on that specific site [2][3][4]), because you can dynamically wire RIPE blocks to your server, without needing to use an specific IP for external routing or broadcast purposes, and instead use the full block in openstack. I have a tiny patch to support this on the neutron l3-agent [1] I yet need to add the logic to check “gateway outside subnet”, then add the “onlink” route. [1] diff --git a/neutron/agent/linux/interface.py b/neutron/agent/linux/interface.py index 538527b..5a9f186 100644 --- a/neutron/agent/linux/interface.py +++ b/neutron/agent/linux/interface.py @@ -116,15 +116,16 @@ class LinuxInterfaceDriver(object): namespace=namespace, ip=ip_cidr) -if gateway: -device.route.add_gateway(gateway) - new_onlink_routes = set(s['cidr'] for s in extra_subnets) + if gateway: + new_onlink_routes.update([gateway]) existing_onlink_routes = set(device.route.list_onlink_routes()) for route in new_onlink_routes - existing_onlink_routes: device.route.add_onlink_route(route) for route in existing_onlink_routes - new_onlink_routes: device.route.delete_onlink_route(route) +if gateway: +device.route.add_gateway(gateway) def delete_conntrack_state(self, root_helper, namespace, ip): """Delete conntrack state associated with an IP address. [2] http://www.soyoustart.com/ (http://www.soyoustart.com/en/essential-servers/) [3] http://www.ovh.co.uk/ (http://www.ovh.co.uk/dedicated_servers/) [4] http://www.kimsufi.com/ (http://www.kimsufi.com/uk/) Miguel Ángel Ajo ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [qa] gate-tempest-dsvm-neutron-heat-slow uture
+1 from me! good catch.
Miguel Ángel Ajo
On Tuesday, 25 de November de 2014 at 16:57, Kyle Mestery wrote:
> On Tue, Nov 25, 2014 at 9:28 AM, Sean Dague (mailto:s...@dague.net)> wrote:
> > So as I was waiting for other tests to return, I started looking through
> > our existing test lists.
> >
> > gate-tempest-dsvm-neutron-heat-slow has been slowly evaporating, and I'm
> > no longer convinced that it does anything useful (and just burns test
> > nodes).
> >
> > The entire output of the job is currently as follows:
> >
> > 2014-11-25 14:43:13.801 | heat-slow runtests: commands[0] | bash
> > tools/pretty_tox.sh (http://pretty_tox.sh)
> > (?=.*\[.*\bslow\b.*\])(^tempest\.(api|scenario)\.orchestration)
> > --concurrency=4
> > 2014-11-25 14:43:21.313 | {1}
> > tempest.scenario.orchestration.test_server_cfn_init.CfnInitScenarioTest.test_server_cfn_init
> > ... SKIPPED: Skipped until Bug: 1374175 is resolved.
> > 2014-11-25 14:47:36.271 | {0}
> > tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON.test_created_network
> > [0.169736s] ... ok
> > 2014-11-25 14:47:36.271 | {0}
> > tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON.test_created_resources
> > [0.000508s] ... ok
> > 2014-11-25 14:47:36.291 | {0}
> > tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON.test_created_router
> > [0.019679s] ... ok
> > 2014-11-25 14:47:36.313 | {0}
> > tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON.test_created_router_interface
> > [0.020597s] ... ok
> > 2014-11-25 14:47:36.564 | {0}
> > tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON.test_created_server
> > [0.250788s] ... ok
> > 2014-11-25 14:47:36.580 | {0}
> > tempest.api.orchestration.stacks.test_neutron_resources.NeutronResourcesTestJSON.test_created_subnet
> > [0.015410s] ... ok
> > 2014-11-25 14:47:44.113 |
> > 2014-11-25 14:47:44.113 | ==
> > 2014-11-25 14:47:44.113 | Totals
> > 2014-11-25 14:47:44.113 | ==
> > 2014-11-25 14:47:44.114 | Run: 7 in 0.478173 sec.
> > 2014-11-25 14:47:44.114 | - Passed: 6
> > 2014-11-25 14:47:44.114 | - Skipped: 1
> > 2014-11-25 14:47:44.115 | - Failed: 0
> > 2014-11-25 14:47:44.115 |
> > 2014-11-25 14:47:44.116 | ==
> > 2014-11-25 14:47:44.116 | Worker Balance
> > 2014-11-25 14:47:44.116 | ==
> > 2014-11-25 14:47:44.117 | - Worker 0 (6 tests) => 0:00:00.480677s
> > 2014-11-25 14:47:44.117 | - Worker 1 (1 tests) => 0:00:00.001455s
> >
> > So we are running about 1s worth of work, no longer in parallel (as
> > there aren't enough classes to even do parallel runs).
> >
> > Given the emergence of the heat functional job, and the fact that this
> > is really not testing anything any more, I'd like to propose we just
> > remove it entirely at this stage and get the test nodes back.
> >
>
> +1 from me.
>
> > -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Stale patches
Thanks for cleaning up the house!, Best regards, Miguel Ángel Ajo On Friday, 14 de November de 2014 at 00:46, Salvatore Orlando wrote: > There are a lot of neutron patches which, for different reasons, have not > been updated in a while. > In order to ensure reviewers focus on active patch, I have set a few patches > (about 75) as 'abandoned'. > > No patch with an update in the past month, either patchset or review, has > been abandoned. Moreover, only a part of the patches not updated for over a > month have been abandoned. I took extra care in identifying which ones could > safely be abandoned, and which ones were instead still valuable; > nevertheless, if you find out I abandoned a change you're actively working > on, please restore it. > > If you are the owner of one of these patches, you can use the 'restore > change' button in gerrit to resurrect the change. If you're not the other and > wish to resume work on these patches either contact any member of the > neutron-core team in IRC or push a new patch. > > Salvatore > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Is this fix introducing another different bug to dhcp-agent?
Wow Xu!, that was fast, Thank you very much. Miguel Ángel ajo @ freenode.net On Friday, 14 de November de 2014 at 04:01, Xu Han Peng wrote: > I opened a new bug and submitted a fix for this problem since it was > introduced by my previous patch. > > https://bugs.launchpad.net/neutron/+bug/1392564 > https://review.openstack.org/#/c/134432/ > > It will be great if you can have a look at the fix and comment. Thanks! > > Xu Han > > On 11/14/2014 05:54 AM, Ihar Hrachyshka wrote: > > -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Robert, Miguel, do you plan > > to take care of the bug and the fix, or you need help? RDO depends on the > > fix, also we should introduce the fix before the next Juno release that > > includes the bad patch, so I would be glad to step in if you don't have > > spare cycles. /Ihar On 13/11/14 16:44, Robert Li (baoli) wrote: > > > Nice catch. Since it’s already merged, a new bug may be in order. —Robert > > > On 11/13/14, 10:25 AM, "Miguel Ángel Ajo" > > (mailto:majop...@redhat.com) <mailto:majop...@redhat.com> > > > (mailto:majop...@redhat.com)> wrote: I believe this fix to IPv6 dhcp > > > spawn breaks isolated metadata when we have a subnet combination like > > > this on a network: 1) IPv6 subnet, with DHCP enabled 2) IPv4 subnet, with > > > isolated metadata enabled. > > > https://review.openstack.org/#/c/123671/1/neutron/agent/dhcp_agent.py I > > > haven’t been able to test yet, but wanted to share it before I forget. > > > Miguel Ángel ajo @ freenode.net (http://freenode.net) > > > > > > > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > iQEcBAEBCgAGBQJUZSioAAoJEC5aWaUY1u57WvIH/0pEFnXwPF9dKGbmWGvxgURW > > Fec0SMxl544DUyKXfhy/fEJPiedAm63TcBbBRkcLrwrGrAI23iMvAi96tCuH/eb7 > > uYbgoDF16b6DGUg0V2bXh8OufpgoIn4T38Vwwr0MFhfxOLbux4QfK1MshsRF1XWx > > LnzmLLnDuJvEYF/gq9ifAA0ekQ+OdwYaKpTEyoVXZNuSJzJOkY8BnwjPQTuRStYG > > M1oBsIxO9j9C/fw1/lkIKasaq9Vmy5LtG+neOyQDzM6EjZrVKO+Z9ZbJnhlkIoaF > > fL8dKqDBzDbFbHpE/pHcUSR5lMnBkHWjsfqC6w8NKpEKnPW6UN88oipSoB9h7U4= =NfOp > > -END PGP SIGNATURE- ___ > > OpenStack-dev mailing list OpenStack-dev@lists.openstack.org > > (mailto:OpenStack-dev@lists.openstack.org) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- Thanks, Xu Han > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Neutron mid-cycle announcement
I was willing to go, (plane is ~850€ from Madrid) but it’s going to push too much stress on my family as it’s too close to the summit. (I need to add at least 3 more days because of flights). I’d love to participate remotely, even with the timezone differences, if you find a way to leave “homework" to the ones at CEST without making your work more difficult I’d allocate those days to help where I can/It’s needed. Miguel Ángel ajo @ freenode.net On Friday, 14 de November de 2014 at 00:17, Kyle Mestery wrote: > A severe typo hopefully didn't result in people booking week and a half trips > to Lehi! > > The mid-cycle is as originally planned: December 8-10. > > Thanks, > Kyle > > > On Nov 13, 2014, at 2:04 PM, Carl Baldwin > (mailto:c...@ecbaldwin.net)> wrote: > > > > > On Thu, Nov 13, 2014 at 1:00 PM, Salvatore Orlando > > (mailto:sorla...@nicira.com)> wrote: > > > No worries, > > > > > > you get one day off over the weekend. And you also get to choose if it's > > > saturday or sunday. > > > > > > > > > I didn't think it was going to be a whole day. > > > > > Salvatore > > > > > > > On 13 November 2014 20:05, Kevin Benton > > > (mailto:blak...@gmail.com)> wrote: > > > > > > > > December 8-19? 11 day mid-cycle seems a little intense... > > > > If you thought the summits fried your brain... > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] HA cross project session summary and next teps
Thank you for sharing, I missed that session. Somehow related to the health checks: https://review.openstack.org/#/c/97748/ This is an spec/functionality for oslo I’m working on, to provide feedback to the process manager that runs the daemons (init.d, pacemaker, systemd, pacemaker+systemd, upstart). The idea is that daemons themselves could provide feedback about their inner status, with an status code + status message. To allow, for example, degraded operation. Feedback on the spec/comments is appreciated. Best regards, Miguel Ángel Miguel Ángel ajo @ freenode.net On Thursday, 13 de November de 2014 at 12:59, Angus Salkeld wrote: > On Tue, Nov 11, 2014 at 12:13 PM, Angus Salkeld (mailto:asalk...@mirantis.com)> wrote: > > Hi all > > > > The HA session was really well attended and I'd like to give some feedback > > from the session. > > > > Firstly there is some really good content here: > > https://etherpad.openstack.org/p/kilo-crossproject-ha-integration > > > > 1. We SHOULD provide better health checks for OCF resources > > (http://linux-ha.org/wiki/OCF_Resource_Agents). > > These should be fast and reliable. We should probably bike shed on some > > convention like "-manage healthcheck" > > and then roll this out for each project. > > > > 2. We should really move > > https://github.com/madkiss/openstack-resource-agents to stackforge or > > openstack if the author is agreeable to it (it's referred to in our > > official docs). > > > > I have chatted to the author of this repo and he is happy for it to live > under stackforge or openstack. Or each OCF resource going into each of the > projects. > Does anyone have any particular preference? I suspect stackforge will be the > path of least resistance. > > -Angus > > > 3. All services SHOULD support Active/Active configurations > > (better scaling and it's always tested) > > > > 4. We should be testing HA (there are a number of ideas on the etherpad > > about this) > > > > 5. Many services do not recovery in the case of failure mid-task > > This seems like a big problem to me (some leave the DB in a mess). > > Someone linked to an interesting article ( > > crash-only-software: http://lwn.net/Articles/191059/) > > (http://lwn.net/Articles/191059/) that suggests that we if we do this > > correctly we should not need the concept of clean shutdown. > > > > (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/service.py#L459-L471) > > I'd be interested in how people think this needs to be approached > > (just raise bugs for each?). > > > > Regards > > Angus > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Is this fix introducing another different bug to dhcp-agent?
I believe this fix to IPv6 dhcp spawn breaks isolated metadata when we have a subnet combination like this on a network: 1) IPv6 subnet, with DHCP enabled 2) IPv4 subnet, with isolated metadata enabled. https://review.openstack.org/#/c/123671/1/neutron/agent/dhcp_agent.py I haven’t been able to test yet, but wanted to share it before I forget. Miguel Ángel ajo @ freenode.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Reminder: No meeting this week
Congratulations :-) -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Monday, 10 de November de 2014 at 21:22, Brandon Logan wrote: > Congrats! Another little mestery in the world, scary! > > On Mon, 2014-11-10 at 12:22 -0600, Kyle Mestery wrote: > > Since most folks are either freshly back from traveling, in the midst > > of returning, or perhaps even with a new baby, we'll be skipping this > > week's meeting. We'll resume next week at our normally scheduled time > > [1] of 1400UTC on Tuesday. > > > > Thanks! > > Kyle > > > > [1] https://wiki.openstack.org/wiki/Network/Meetings > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Neutron] Rootwrap daemon ode support
Yuriy, what’s the status of the rootwrap-daemon implementation on the nova side?, was it merged?, otherwise do you think there could be anyone interested in picking it up? Best regards, -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, 7 de November de 2014 at 11:52, Miguel Ángel Ajo wrote: > Ohh, sad to hear that Yuriy, you were doing an awesome work. I will take some > time to re-review the final state of the code and specs, and move it forward. > Thank you very much for your contribution. > > -- > Miguel Ángel Ajo > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Friday, 7 de November de 2014 at 11:44, Yuriy Taraday wrote: > > > Hello, Miguel. > > > > I switched departments recently and unfortunately don't have much free time > > for community work. Feel free to pick up my change requests and push them > > if you have time. I'll try to keep track of these changes and give some > > feedback on them on occasion, but don't wait on me. > > Thank you for keeping this feature in mind. I'd be glad to see it finally > > used in Neutron (and any other project). > > > > -- > > > > Kind regards, Yuriy. > > > > On Fri, Nov 7, 2014 at 1:05 PM, Miguel Ángel Ajo > (mailto:majop...@redhat.com)> wrote: > > > > > > Hi Yorik, > > > > > >I was talking with Mark Mcclain a minute ago here at the summit about > > > this. And he told me that now at the start of the cycle looks like a good > > > moment to merge the spec & the root wrap daemon bits, so we have a lot of > > > headroom for testing during the next months. > > > > > >We need to upgrade the spec [1] to the new Kilo format. > > > > > >Do you have some time to do it?, I can allocate some time and do it > > > right away. > > > > > > [1] https://review.openstack.org/#/c/93889/ > > > -- > > > Miguel Ángel Ajo > > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > > > > > > > On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: > > > > > > > +1 > > > > > > > > Sent from my Android phone using TouchDown (www.nitrodesk.com > > > > (http://www.nitrodesk.com)) > > > > > > > > > > > > -Original Message- > > > > From: Yuriy Taraday [yorik@gmail.com (mailto:yorik@gmail.com)] > > > > Received: Thursday, 24 Jul 2014, 0:42 > > > > To: OpenStack Development Mailing List > > > > [openstack-dev@lists.openstack.org > > > > (mailto:openstack-dev@lists.openstack.org)] > > > > Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap > > > > daemon mode support > > > > > > > > > > > > Hello. > > > > > > > > I'd like to propose making a spec freeze exception for > > > > rootwrap-daemon-mode spec [1]. > > > > > > > > Its goal is to save agents' execution time by using daemon mode for > > > > rootwrap and thus avoiding python interpreter startup time as well as > > > > sudo overhead for each call. Preliminary benchmark shows 10x+ speedup > > > > of the rootwrap interaction itself. > > > > > > > > This spec have a number of supporters from Neutron team (Carl and > > > > Miguel gave it their +2 and +1) and have all code waiting for review > > > > [2], [3], [4]. > > > > The only thing that has been blocking its progress is Mark's -2 left > > > > when oslo.rootwrap spec hasn't been merged yet. Now that's not the case > > > > and code in oslo.rootwrap is steadily getting approved [5]. > > > > > > > > [1] https://review.openstack.org/93889 > > > > [2] https://review.openstack.org/82787 > > > > [3] https://review.openstack.org/84667 > > > > [4] https://review.openstack.org/107386 > > > > [5] > > > > https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support
Ohh, sad to hear that Yuriy, you were doing an awesome work. I will take some time to re-review the final state of the code and specs, and move it forward. Thank you very much for your contribution. -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, 7 de November de 2014 at 11:44, Yuriy Taraday wrote: > Hello, Miguel. > > I switched departments recently and unfortunately don't have much free time > for community work. Feel free to pick up my change requests and push them if > you have time. I'll try to keep track of these changes and give some feedback > on them on occasion, but don't wait on me. > Thank you for keeping this feature in mind. I'd be glad to see it finally > used in Neutron (and any other project). > > -- > > Kind regards, Yuriy. > > On Fri, Nov 7, 2014 at 1:05 PM, Miguel Ángel Ajo (mailto:majop...@redhat.com)> wrote: > > > > Hi Yorik, > > > >I was talking with Mark Mcclain a minute ago here at the summit about > > this. And he told me that now at the start of the cycle looks like a good > > moment to merge the spec & the root wrap daemon bits, so we have a lot of > > headroom for testing during the next months. > > > >We need to upgrade the spec [1] to the new Kilo format. > > > >Do you have some time to do it?, I can allocate some time and do it > > right away. > > > > [1] https://review.openstack.org/#/c/93889/ > > -- > > Miguel Ángel Ajo > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > > > > On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: > > > > > +1 > > > > > > Sent from my Android phone using TouchDown (www.nitrodesk.com > > > (http://www.nitrodesk.com)) > > > > > > > > > -Original Message- > > > From: Yuriy Taraday [yorik@gmail.com (mailto:yorik@gmail.com)] > > > Received: Thursday, 24 Jul 2014, 0:42 > > > To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org > > > (mailto:openstack-dev@lists.openstack.org)] > > > Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon > > > mode support > > > > > > > > > Hello. > > > > > > I'd like to propose making a spec freeze exception for > > > rootwrap-daemon-mode spec [1]. > > > > > > Its goal is to save agents' execution time by using daemon mode for > > > rootwrap and thus avoiding python interpreter startup time as well as > > > sudo overhead for each call. Preliminary benchmark shows 10x+ speedup of > > > the rootwrap interaction itself. > > > > > > This spec have a number of supporters from Neutron team (Carl and Miguel > > > gave it their +2 and +1) and have all code waiting for review [2], [3], > > > [4]. > > > The only thing that has been blocking its progress is Mark's -2 left when > > > oslo.rootwrap spec hasn't been merged yet. Now that's not the case and > > > code in oslo.rootwrap is steadily getting approved [5]. > > > > > > [1] https://review.openstack.org/93889 > > > [2] https://review.openstack.org/82787 > > > [3] https://review.openstack.org/84667 > > > [4] https://review.openstack.org/107386 > > > [5] > > > https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support
Hi Yorik, I was talking with Mark Mcclain a minute ago here at the summit about this. And he told me that now at the start of the cycle looks like a good moment to merge the spec & the root wrap daemon bits, so we have a lot of headroom for testing during the next months. We need to upgrade the spec [1] to the new Kilo format. Do you have some time to do it?, I can allocate some time and do it right away. [1] https://review.openstack.org/#/c/93889/ -- Miguel Ángel Ajo Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: > +1 > > Sent from my Android phone using TouchDown (www.nitrodesk.com) > > > -Original Message- > From: Yuriy Taraday [yorik@gmail.com (mailto:yorik@gmail.com)] > Received: Thursday, 24 Jul 2014, 0:42 > To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org > (mailto:openstack-dev@lists.openstack.org)] > Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon > mode support > > > Hello. > > I'd like to propose making a spec freeze exception for rootwrap-daemon-mode > spec [1]. > > Its goal is to save agents' execution time by using daemon mode for rootwrap > and thus avoiding python interpreter startup time as well as sudo overhead > for each call. Preliminary benchmark shows 10x+ speedup of the rootwrap > interaction itself. > > This spec have a number of supporters from Neutron team (Carl and Miguel gave > it their +2 and +1) and have all code waiting for review [2], [3], [4]. > The only thing that has been blocking its progress is Mark's -2 left when > oslo.rootwrap spec hasn't been merged yet. Now that's not the case and code > in oslo.rootwrap is steadily getting approved [5]. > > [1] https://review.openstack.org/93889 > [2] https://review.openstack.org/82787 > [3] https://review.openstack.org/84667 > [4] https://review.openstack.org/107386 > [5] > https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z > > -- > > Kind regards, Yuriy. > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
