Re: [openstack-dev] Why need br-int and br-tun in openstack neutron
There's no real reason as far as I'm aware, just an implementation decision. This is inaccurate. There is a reason(s), and this has been asked before: http://lists.openstack.org/pipermail/openstack/2014-March/005950.html This link is to a thread asking why do we connect a Linux bridge between a tap device and br-int (For security groups). http://lists.openstack.org/pipermail/openstack/2014-April/006865.html This link is to this thread itself. In a nutshell, the design decision that led to the existing architecture is due to the way OVS handles packets and interact with netfilter. I think you're talking about the bridge between a tap device and br-int and not about br-tun. sure, these are separate topics. FYI, ofagent uses a single openflow bridge (ie. no br-tun) but for SGs still needs LBs as ovs-agent does. YAMAMOTO Takashi __ 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] [pbr] 1.0.1 released
hi, can you explain why you want to use pbr 1.0.1 in the first place? what's wrong with requiring pbr1.0 ? YAMAMOTO Takashi Hi openstack-dev team, Can you also release latest oslo.config to allow pbr 1.0.1? In my convenience I want to use it. Thanks, kakuma On Wed, 20 May 2015 11:07:36 +1200 Robert Collins robe...@robertcollins.net wrote: We are super psyched to announce the release of: pbr 1.0.1: Python Build Reasonableness With source available at: http://git.openstack.org/cgit/openstack-dev/pbr For more details, please see the git log history below and: http://launchpad.net/pbr/+milestone/1.0.1 Please report issues through launchpad: http://bugs.launchpad.net/pbr Changes in pbr 1.0.0..1.0.1 --- b72e446 Remove self.pre_run calls in packaging.py 8e87679 Update hacking to 0.10.x series Diffstat (except docs and test files) - pbr/packaging.py | 2 -- test-requirements.txt | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) Requirements updates diff --git a/test-requirements.txt b/test-requirements.txt index 2b33504..6e4521c 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -4 +4 @@ fixtures=0.3.14 -hacking=0.9.2,0.10 +hacking=0.10.0,0.11 -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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 -- fumihiko kakuma kak...@valinux.co.jp __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi
On 27 April 2015 at 09:09, Rossella Sblendido rsblend...@suse.com wrote: Hello all, I am working at the blueprint Restructure the L2 agent [1] . One of the work item of this blueprint is to modify the port_update message to include the attributes of the ports that were modified. This is implemented in this patch [2] . The client side of the RPC is in AgentNotifierApi , the server side is implemented in the L2 agent. A problem arises since now the vendor plugins are out of the tree. If they use a custom L2 agent (like for example the Ryu plugin) when the patch is merged they will get an fwiw, it's ofagent, not ryu plugin. UnsupportedVersion error if the version is not bumped in their agent too. Could the server fall back and keep on using the old version of the API? I think that would make for a much nicer experience, especially in face of upgrades. Is this not possible? If it is, then the in vs out matter is not really an issue and out-of-tree code can reflect the change in API at their own pace. while it's indeed nicer, it's difficult as port_update is an async call (cast) and does not wait for errors including UnsupportedVersion. YAMAMOTO Takashi Cheers, Armando I am writing this email as heads up and also to ask a question. The port_update signature on the server side is like this: def port_update(self, context, **kwargs) kwargs is used, no specific parameter is specified. If a new key is added like in this case, the minor version of the RPC should be bumped anyway? I think so. cheers, Rossella [1] https://blueprints.launchpad.net/neutron/+spec/restructure-l2-agent [2] https://review.openstack.org/#/c/155223 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Sahara][Heat] Kilo RC2 available
Hello everyone, Due to release-critical issues spotted in Nova, Sahara and Heat during RC1 testing, new release candidates were created for Kilo. The list of RC2 fixes, as well as RC2 tarballs are available at: https://launchpad.net/nova/kilo/kilo-rc2 https://launchpad.net/nova/sahara/kilo-rc2 https://launchpad.net/nova/heat/kilo-rc2 https://launchpad.net/sahara/kilo/kilo-rc2 https://launchpad.net/heat/kilo/kilo-rc2 Unless new release-critical issues are found that warrant a release candidate respin, these tarballs will be formally released as the final Kilo versions on April 30. You are therefore strongly encouraged to test and validate these tarballs ! Alternatively, you can directly test the stable/kilo branches at: https://github.com/openstack/nova/tree/stable/kilo https://github.com/openstack/sahara/tree/stable/kilo https://github.com/openstack/heat/tree/stable/kilo If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/nova/+filebug https://bugs.launchpad.net/sahara/+filebug https://bugs.launchpad.net/heat/+filebug and tag it *kilo-rc-potential* to bring it to the release crew's attention. Thanks! -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB
However, I briefly looked through the L2 agent code and didn't see a periodic task to resync the port information to protect from a neutron server that failed to send a notification because it crashed or lost its amqp connection. The L3 agent has a period sync routers task that helps in this regard. Maybe another neutron developer more familiar with the L2 agent can chime in here if I'm missing anything. i don't think you are missing anything. periodic sync would be a good improvement. YAMAMAOTO Takashi __ 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] Ryu/ofagent CI outage
hi,
sorry for keep forgetting and thank you for reminder.
YAMAMOTO Takashi
Hi-
Regarding the CI offline mails, I previously received an email from Anita.
Please find the summary below.
Please set your account listing to down on this page:
https://wiki.openstack.org/wiki/ThirdPartySystems
Following these instructions: If your system is going down or having
problems, change the entry to {{ThirdPartySystemTableEntryDown|your
ci system name}} which are found on the
https://wiki.openstack.org/wiki/ThirdPartySystems page.
Leave the details of your system status on this page:
https://wiki.openstack.org/wiki/ThirdPartySystems/Ryu_CI
This is the expected workflow of offline systems communication.
Posting to this mailing list is not part of the communication.
Hope this helps when you further communicate the CI status.
--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048
-Original Message-
From: YAMAMOTO Takashi [mailto:yamam...@valinux.co.jp]
Sent: Wednesday, March 11, 2015 12:33 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Ryu/ofagent CI outage
hi,
Ryu/ofagent CI will be offline during the next weekend for a scheduled
maintenance. sorry for inconvenience.
YAMAMOTO Takashi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Ryu/ofagent CI outage
hi, Ryu/ofagent CI will be offline during the next weekend for a scheduled maintenance. sorry for inconvenience. YAMAMOTO Takashi __ 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 17 February 2015 at 22:00, YAMAMOTO Takashi 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. 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. b. make devstack look at per-agent extra requirements file in neutron tree. eg. neutron/plugins/$Q_AGENT/requirements.txt 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. 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? One thing that I want to ensure we are clear on is about the agent's OpenFlow communication strategy going forward, because that determines how we make a decision based on the options you have outlined: do we enforce the use of ryu while ovs-ofctl goes away from day 0? Or do we provide an 'opt-in' type of approach where users can explicitly choose if/when to adopt ryu in favor of ovs-ofctl? The latter means that we'll keep both solutions for a reasonable amount of time to smooth the transition process. my plan is the former. the latter would need to invent a backend-neutral api which covers large enough subset of openflow and nicira extensions. my impression is that it isn't a reasonable amount of work for the benefit. If we adopt the former (i.e. ryu goes in, ovs-ofctl goes out), then option a) makes sense to me, but I am not sure how happy deployers, and packagers are going to be welcoming this approach. There's already too much going on in Kilo right now :) sure, there's always been too much things to do. If we adopt the latter, then I think it's desirable to have two separate configurations with which we test the agent. This means that we'll have a new job (besides the existing ones) that runs the agent with ryu instead of ovs-ofctl. This means that option d) is the viable one, where DevStack will have to install the dependency based on some configuration variable that is determined by the openstack-infra project definition. i tend to think the latter is too much. but if we decide to go the route, i agree it's reasonable to have separate jobs. either ways, i need to write working code first. so i want to be able to try jenkins runs. adding ryu to global-requirements [3] would allow it, while it doesn't hurt anything as far as i know. (i'm not familiar with infra stuff though. please correct me if wrong.) [3] https://review.openstack.org/#/c/154354/ YAMAMOTO Takashi Thoughts? Cheers, Armando 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 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
hi, 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. 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? 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) 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. 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. 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] per-agent/driver/plugin requirements
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. 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. b. make devstack look at per-agent extra requirements file in neutron tree. eg. neutron/plugins/$Q_AGENT/requirements.txt 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. 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Ryu CI scheduled outage
Ryu/ofagent CI will be offline during this weekend. sorry for inconvenience. YAMAMOTO Takashi __ 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] XenAPI questions
hi, i added an item to the agenda. https://wiki.openstack.org/wiki/Meetings/XenAPI#Next_meeting YAMAMOTO Takashi Hi, The next meeting will be tomorrow @ 15:00 UTC - We'd love to see you there and we can talk about the CI and Terry's work. We're currently meeting fortnightly and skipped one due to travel, which is why there haven't been minutes recently. Thanks, Bob -Original Message- From: YAMAMOTO Takashi [mailto:yamam...@valinux.co.jp] Sent: 04 February 2015 07:18 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] XenAPI questions hi Bob, is there any news on the CI work? do you think the idea of small proxy program can work? i think Terry Wilson's ovsdb effort will eventually need something similar, unless we will maintain two versions of the library forever. btw, when will the next XenAPI IRC meeting be? (i checked wiki and previous meeting logs but it wasn't clear to me) YAMAMOTO Takashi hi, good to hear. do you have any estimate when it will be available? will it cover dom0 side of the code found in neutron/plugins/openvswitch/agent/xenapi? YAMAMOTO Takashi Hi Yamamoto, XenAPI and Neutron do work well together, and we have an private CI that is running Neutron jobs. As it's not currently the public CI it's harder to access logs. We're working on trying to move the existing XenServer CI from a nova- network base to a neutron base, at which point the logs will of course be publically accessible and tested against any changes, thus making it easy to answer questions such as the below. Bob -Original Message- From: YAMAMOTO Takashi [mailto:yamam...@valinux.co.jp] Sent: 11 December 2014 03:17 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] XenAPI questions hi, i have questions for XenAPI folks: - what's the status of XenAPI support in neutron? - is there any CI covering it? i want to look at logs. - is it possible to write a small program which runs with the xen rootwrap and proxies OpenFlow channel between domains? (cf. https://review.openstack.org/#/c/138980/) thank you. YAMAMOTO Takashi ___ OpenStack-dev mailing list 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ ___ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev- requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] XenAPI questions
hi Bob, is there any news on the CI work? do you think the idea of small proxy program can work? i think Terry Wilson's ovsdb effort will eventually need something similar, unless we will maintain two versions of the library forever. btw, when will the next XenAPI IRC meeting be? (i checked wiki and previous meeting logs but it wasn't clear to me) YAMAMOTO Takashi hi, good to hear. do you have any estimate when it will be available? will it cover dom0 side of the code found in neutron/plugins/openvswitch/agent/xenapi? YAMAMOTO Takashi Hi Yamamoto, XenAPI and Neutron do work well together, and we have an private CI that is running Neutron jobs. As it's not currently the public CI it's harder to access logs. We're working on trying to move the existing XenServer CI from a nova-network base to a neutron base, at which point the logs will of course be publically accessible and tested against any changes, thus making it easy to answer questions such as the below. Bob -Original Message- From: YAMAMOTO Takashi [mailto:yamam...@valinux.co.jp] Sent: 11 December 2014 03:17 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] XenAPI questions hi, i have questions for XenAPI folks: - what's the status of XenAPI support in neutron? - is there any CI covering it? i want to look at logs. - is it possible to write a small program which runs with the xen rootwrap and proxies OpenFlow channel between domains? (cf. https://review.openstack.org/#/c/138980/) thank you. YAMAMOTO Takashi ___ OpenStack-dev mailing list 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 mailing list OpenStack-dev@lists.openstack.org 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] XenAPI questions
hi, good to hear. do you have any estimate when it will be available? will it cover dom0 side of the code found in neutron/plugins/openvswitch/agent/xenapi? YAMAMOTO Takashi Hi Yamamoto, XenAPI and Neutron do work well together, and we have an private CI that is running Neutron jobs. As it's not currently the public CI it's harder to access logs. We're working on trying to move the existing XenServer CI from a nova-network base to a neutron base, at which point the logs will of course be publically accessible and tested against any changes, thus making it easy to answer questions such as the below. Bob -Original Message- From: YAMAMOTO Takashi [mailto:yamam...@valinux.co.jp] Sent: 11 December 2014 03:17 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] XenAPI questions hi, i have questions for XenAPI folks: - what's the status of XenAPI support in neutron? - is there any CI covering it? i want to look at logs. - is it possible to write a small program which runs with the xen rootwrap and proxies OpenFlow channel between domains? (cf. https://review.openstack.org/#/c/138980/) thank you. YAMAMOTO Takashi ___ OpenStack-dev mailing list 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] XenAPI questions
hi, i have questions for XenAPI folks: - what's the status of XenAPI support in neutron? - is there any CI covering it? i want to look at logs. - is it possible to write a small program which runs with the xen rootwrap and proxies OpenFlow channel between domains? (cf. https://review.openstack.org/#/c/138980/) thank you. YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][OVS] ovs-ofctl-to-python blueprint
hi, here's a blueprint to make OVS agent use Ryu to talk with OVS. https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python https://review.openstack.org/#/c/138980/ (kilo spec) given that ML2/OVS is one of the most popular plugins and the proposal has a few possible controversial points, i want to ask wider opinions. - it introduces a new requirement for OVS agent. (Ryu) - it makes OVS agent require newer OVS version than it currently does. - what to do for xenapi support is still under investigation/research. - possible security impact. please comment on gerrit if you have any opinions. thank you. YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ServiceVM] chainging weekly servicevm IRC meeting time
Hello. As we discussed at the summit and following irc meeting, the time slot/channel is changed from Nov 19, 2014. - Weekly 17:00AM UTC(Wednesday) 30min 17:00AM ??? - IRC channel: #openstack-meeting-4 - Next: Nov 19, 2014 see https://wiki.openstack.org/wiki/Meetings/ServiceVM for details and Kilo planning. thanks, -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list 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] [infra][devstack] CI failed The plugin token_endpoint could not be found
Hi, My third party CI becomes failed from about 21:00 12th UTC in execution of devstack. The error occurs at openstack project create admin -f value -c id --- ERROR: openstack The plugin token_endpoint could not be found --- does your CI clean $DEST for each runs? i guess you are somehow mixing different versions of code. YAMAMOTO Takashi I found some CIs have same problem. Does anyone give me a hint to solve this problem ? Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list 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] Can ofagent connect to switches other than OVS?
hi, Hi, all I’m trying to connect ofagent to switches other than OVS. thank you for trying ofagent. But, it’s not going. I think that the ofagent cannot connect their switches. Is there anyone tried? ofagent is still OVS-only. to support non-OVS switches, there are some todo items including nova/neutron interface drivers. https://wiki.openstack.org/wiki/Neutron/OFAgent/Todo YAMAMTO Takashi Hirofumi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Enabling vlan trunking on neutron port.
more specifically, the way OVS-agent uses OVS (internal vlan) is incompatible with tenant tagged VLANs. ofagent for Juno, which also uses OVS as its dataplane, doesn't have the problem. i'm not sure how tenant VLANs are supposed to be used with neutron, though. (eg. what ip addresses should be used for non-trunk VLANs) YAMAMOTO Takashi Aaron: untrue. It does, but OVS doesn't, and so networks implemented with the OVS driver will drop packets. Use Linuxbridge instead. -- Ian. On 19 September 2014 22:27, Aaron Rosen aaronoro...@gmail.com wrote: Neutron doesn't allow you to send tagged traffic from the guest today https://github.com/openstack/neutron/blob/master/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py#L384 On Fri, Sep 19, 2014 at 7:01 AM, Parikshit Manur parikshit.ma...@citrix.com wrote: Hi All, I have a setup which has VM on flat provider network , and I want to reach VM on VLAN provider network. The packets are forwarded till veth pair and are getting dropped by br-int. Can neutron port be configured to allow vlan trunking? Thanks, Parikshit Manur ___ OpenStack-dev mailing list 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [third party][neutron] - OpenDaylight CI and -1 voting
I have had multiple occasions where the OpenDaylight CI will vote a -1 on a patch for something completely unrelated (e.g. [1]). This would be fine except for two issues. First, there doesn't appear to be any way to trigger a recheck. Second, there is no maintainer listed on the Neutron third party drivers page.[2] Because of this, there is effectively no way to get the -1 removed without uploading a new patch and losing current code review votes. http://stackalytics.com/report/driverlog says its maintainer is irc:mestery. last time it happened to me, i asked him to trigger recheck and it worked. YAMAMOTO Takashi Can we remove the voting rights for the ODL CI until there is a documented way to trigger rechecks and a public contact on the drivers page for when things go wrong? Getting reviews is already hard enough, let alone when there is a -1 in the 'verified' column. 1. https://review.openstack.org/#/c/116187/ 2. https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Ryu plugin deprecation
hi, As announced in the last neutron meeting [1], the Ryu plugin is being deprecated. Juno is the last release to support Ryu plugin. The Ryu team will be focusing on the ofagent going forward. btw, i'll be mostly offline from Aug 16 to Aug 31. sorry for inconvenience. [1] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-11-21.00.html YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron Ryu status
just an update: the Neutron Ryu CI is getting stable now. please let me know if you noticed any problems. thank you. YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] how to deprecate a plugin
On Thu, Jul 31, 2014 at 1:43 AM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: On Wed, Jul 30, 2014 at 12:17 PM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: hi, what's the right procedure to deprecate a plugin? we (ryu team) are considering deprecating ryu plugin, in favor of ofagent. probably in K-timeframe, if it's acceptable. The typical way is to announce the deprecation at least one cycle before removing the deprecated plugin from the tree. So, you could announce the ryu plugin is deprecated in Juno, and then remove it from the tree in Kilo. where is an appropriate place to announce? this ML? Yes, and also, put an item on the weekly Neutron meeting agenda [1] in the announcements section. [1] https://wiki.openstack.org/wiki/Network/Meetings i added an item. i'll try to attend the next meeting but i'm not sure if i can. i have an overlapping schedule this month. sorry. YAMAMOTO Takashi YAMAMOTO Takashi Thanks, Kyle YAMAMOTO Takashi ___ OpenStack-dev mailing list 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 mailing list 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] how to deprecate a plugin
On Wed, Jul 30, 2014 at 12:17 PM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: hi, what's the right procedure to deprecate a plugin? we (ryu team) are considering deprecating ryu plugin, in favor of ofagent. probably in K-timeframe, if it's acceptable. The typical way is to announce the deprecation at least one cycle before removing the deprecated plugin from the tree. So, you could announce the ryu plugin is deprecated in Juno, and then remove it from the tree in Kilo. where is an appropriate place to announce? this ML? YAMAMOTO Takashi Thanks, Kyle YAMAMOTO Takashi ___ OpenStack-dev mailing list 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] how to deprecate a plugin
hi, In Nova we have done the following: - add a warning in the current version that this will be deprecated in K - start of K drop the code It is also important to have an upgrade path. What happens if I have my RYU plugin in production and I upgrade to the next version. That should be clearly documented. it depends on what functionalities of the plugin you are using. i think simple setups (eg. vlan isolation) can be covered by other plugins like ofagent. but we haven't investigated further. I think that maybe we should consider on working on a migration scheme - from plugin A to plugin B. i afraid it's impossible in general. YAMAMOTO Takashi Thanks Gary On 7/30/14, 8:17 PM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: hi, what's the right procedure to deprecate a plugin? we (ryu team) are considering deprecating ryu plugin, in favor of ofagent. probably in K-timeframe, if it's acceptable. YAMAMOTO Takashi ___ OpenStack-dev mailing list 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] how to deprecate a plugin
hi, what's the right procedure to deprecate a plugin? we (ryu team) are considering deprecating ryu plugin, in favor of ofagent. probably in K-timeframe, if it's acceptable. YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Spec Approval Deadline (SAD) has passed, next steps
Hi all! A quick note that SAD has passed. We briskly approved a pile of BPs it's sad. ;-( over the weekend, most of them vendor related as low priority, best effort attempts for Juno-3. At this point, we're hugely oversubscribed for Juno-3, so it's unlikely we'll make exceptions for things into Juno-3 now. my specs are ok'ed by Kyle but failed to get another core reviewer. https://review.openstack.org/#/c/98702/ https://review.openstack.org/#/c/103737/ does it indicate core reviewers man-power problems? if so, can you consider increasing the number of them? postponing vendor stuffs (like mine) for the reason would make the situation worse as many of developers/reviewers are paid for vendor stuffs. YAMAMOTO Takashi I don't plan to open a Kilo directory in the specs repository quite yet. I'd like to first let things settle down a bit with Juno-3 before going there. Once I do, specs which were not approved should be moved to that directory where they can be reviewed with the idea they are targeting Kilo instead of Juno. Also, just a note that we have a handful of bugs and BPs we're trying to land in Juno-3 yet today, so core reviewers, please focus on those today. Thanks! Kyle [1] https://launchpad.net/neutron/+milestone/juno-2 ___ OpenStack-dev mailing list 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 Ryu status
On Tue, Jul 15, 2014 at 9:12 AM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: if you are wondering why ofagent CI (Neutron Ryu) reported a failure (non-voting) for your review recently, you can probably safely ignore it. sorry for inconvenience. the CI has been fixed recently. unfortunately ofagent on master is broken (a consequence of the broken CI) and the CI started detecting the breakage correctly. the breakage will be fixed if the following changes are merged. https://review.openstack.org/#/c/103764/ https://review.openstack.org/#/c/106701/ an update: the above mentioned changes have been merged. (thanks) but shortly new problems are introduced and thus the CI started reporting failures again. the following changes would fix the relevant problems. https://review.openstack.org/#/c/107229/ (workarounded in our CI) https://review.openstack.org/#/c/107884/ YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Neutron Ryu status
if you are wondering why ofagent CI (Neutron Ryu) reported a failure (non-voting) for your review recently, you can probably safely ignore it. sorry for inconvenience. the CI has been fixed recently. unfortunately ofagent on master is broken (a consequence of the broken CI) and the CI started detecting the breakage correctly. the breakage will be fixed if the following changes are merged. https://review.openstack.org/#/c/103764/ https://review.openstack.org/#/c/106701/ YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron Ryu status
On Tue, Jul 15, 2014 at 9:12 AM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: if you are wondering why ofagent CI (Neutron Ryu) reported a failure (non-voting) for your review recently, you can probably safely ignore it. sorry for inconvenience. the CI has been fixed recently. unfortunately ofagent on master is broken (a consequence of the broken CI) and the CI started detecting the breakage correctly. the breakage will be fixed if the following changes are merged. https://review.openstack.org/#/c/103764/ https://review.openstack.org/#/c/106701/ YAMAMOTO Takashi Thanks for the update on this YAMAMOTO. I'll work to try and get those two bug fixes merged by having other cores review them ASAP so we can get ofagent working again. thank you! YAMAMOTO Takashi Kyle ___ OpenStack-dev mailing list 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party] Current status of Neutron 3rd Party CI and how to move forward
hi, My initial analysis of Neutron 3rd Party CI is here [1]. This was somewhat correlated with information from DriverLog [2], which was helpful to put this together. i updated the etherpad for ofagent. currently a single CI system is running tests for both of ofagent and ryu. is it ok? YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Specs repository update and the way forward
Since Juno-1 is about to close, I wanted to give everyone an update on Neutron's usage of the specs repository. These are observations from using this since a few weeks before the Summit. I thought it would be good to share with the broader community to see if other projects using spec repositories had similar thoughts, and I also wanted to share this info for BP submitters and reviewers. it would be better if there's an easy way for reviewers to see formatted versions of specs rather than raw *.rst, especially for diagrams. does other project have such a machinary? YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
hi, ExaBgp was our first choice because we thought that run something in library mode would be much more easy to deal with (especially the exceptions and corner cases) and the code would be much cleaner. But seems that Ryu BGP also can fit in this requirement. And having the help from a Ryu developer like you turns it into a promising candidate! I'll start working now in a proof of concept to run the agent with these implementations and see if we need more requirements to compare between the speakers. we (ryu team) love to hear any suggestions and/or requests. we are currently working on our bgp api refinement and documentation. hopefully they will be available early next week. for both of bgp blueprints, it would be possible, and might be desirable, to create reference implementations in python using ryu or exabgp. (i prefer ryu. :-) YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] request for review
can anyone please review this small fix for ofagent? https://review.openstack.org/#/c/88224/ it's unfortunate a simple fix like this taking months to be merged. YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi folks ExaBGP won't suit for BGPVPN implementation because it isn't support vpnv4. Ryu is supporting it, however they have no internal api to binding neutron network route target. can you explain a little more? do you have api suggestions? YAMAMOTO Takashi so I think contrail is a only solution for BGPVPN implementation now. 2014-05-30 2:22 GMT-07:00 Mathieu Rohon mathieu.ro...@gmail.com: Hi, I was about mentionning ExaBGP too! can we also consider using those BGP speakers for BGPVPN implementation [1]. This would be consistent to have the same BGP speaker used for every BGP needs inside Neutron. [1]https://review.openstack.org/#/c/93329/ On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa devv...@gmail.com wrote: Hello Takashi, thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing blueprint[2], I've added a new column for this speaker in the wiki page. I plan to fill it soon. ExaBgp was our first choice because we thought that run something in library mode would be much more easy to deal with (especially the exceptions and corner cases) and the code would be much cleaner. But seems that Ryu BGP also can fit in this requirement. And having the help from a Ryu developer like you turns it into a promising candidate! I'll start working now in a proof of concept to run the agent with these implementations and see if we need more requirements to compare between the speakers. [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison [2]: https://review.openstack.org/#/c/90833/ Regards, On 29 May 2014 18:42, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: as per discussions on l3 subteem meeting today, i started a bgp speakers comparison wiki page for this bp. https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison Artem, can you add other requirements as columns? as one of ryu developers, i'm naturally biased to ryu bgp. i appreciate if someone provides more info for other bgp speakers. YAMAMOTO Takashi Good afternoon Neutron developers! There has been a discussion about dynamic routing in Neutron for the past few weeks in the L3 subteam weekly meetings. I've submitted a review request of the blueprint documenting the proposal of this feature: https://review.openstack.org/#/c/90833/. If you have any feedback or suggestions for improvement, I would love to hear your comments and include your thoughts in the document. Thank you. Sincerely, Artem Dmytrenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list 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 mailing list 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] BGP Dynamic Routing Proposal
as per discussions on l3 subteem meeting today, i started a bgp speakers comparison wiki page for this bp. https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison Artem, can you add other requirements as columns? as one of ryu developers, i'm naturally biased to ryu bgp. i appreciate if someone provides more info for other bgp speakers. YAMAMOTO Takashi Good afternoon Neutron developers! There has been a discussion about dynamic routing in Neutron for the past few weeks in the L3 subteam weekly meetings. I've submitted a review request of the blueprint documenting the proposal of this feature: https://review.openstack.org/#/c/90833/. If you have any feedback or suggestions for improvement, I would love to hear your comments and include your thoughts in the document. Thank you. Sincerely, Artem Dmytrenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron
Hi,
I am Vinay, working with Ericsson.
I am interested in the following blueprint regarding port mirroring
extension in neutron:
https://blueprints.launchpad.net/neutron/+spec/port-mirroring
I am close to finishing an implementation for this extension in OVS plugin
and would be submitting a neutron spec related to the blueprint soon.
does your implementation use OVS' mirroring functionality?
or is it flow-based?
YAMAMOTO Takashi
I would like to know other who are also interested in introducing Port
Mirroring extension in neutron.
It would be great if we can discuss and collaborate in development and
testing this extension
I am currently attending the OpenStack Summit in Atlanta, so if any of you
are interested in the blueprint, we can meet here in the summit and discuss
how to proceed with the blueprint.
Cheers,
main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents
Please note that I have created an etherpad for the Modular L2 Agent session at [1]. It relates to one of the three topics that are to be discussed during the Modular Layer2 Agent design session scheduled for Thursday 11:50am-12:30pm [2]. Please update the etherpad and/or use the ML or contact me if you have any comments/suggestions/criticism. (I have also asked several people who have worked on the agents and/or expressed interest in this topic individually for their input.) can you pick a few existing agents (eg. ovs and lb) and prototype a modular agent to demonstrate how much of the code can be shared by this effort? YAMAMOTO Takashi Thanks, -Mohammad [1] https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent [2] http://junodesignsummit.sched.org/event/4205f2c4084e8a0c3bd8d420803ddf02#.U2k7RdyZpjI ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ML2] No ML2 sub-team meeting today (4/30/2014)
Today's ML2 sub-team meeting is cancelled. -Bob will the next one be held normally? i want to hear details of modular l2 agent idea before the summit. sooner is better because it's blocking ofagent works. YAMAMOTO Takashi ___ OpenStack-dev mailing list 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] ryu-ml2-driver
hi, we (Ryu project) are currently working on a new version of Ryu neutron plugin/agent. we have a blueprint for it waiting for review/approval. can you please take a look? thanks. https://blueprints.launchpad.net/neutron/+spec/ryu-ml2-driver we uploaded ready-to-review code to gerrit. mark, can you please consider moving it back into icehouse? YAMAMOTO Takashi YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] ryu-ml2-driver
hi, we (Ryu project) are currently working on a new version of Ryu neutron plugin/agent. we have a blueprint for it waiting for review/approval. can you please take a look? thanks. https://blueprints.launchpad.net/neutron/+spec/ryu-ml2-driver YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
