Re: [openstack-dev] [Neutron] per-agent/driver/plugin requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2015 08:45 PM, Armando M. wrote: On 17 February 2015 at 22:00, YAMAMOTO Takashi 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. 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. 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 :) Even if we leave both options available, packagers wouldn't avoid shipping ryu, for if the option is present in the code and can be controlled from config files, then we should assume some users will switch implementations, and we don't want to break them. 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. 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://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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU536CAAoJEC5aWaUY1u57Q/4H/iJPbp/KA9ouI6lVv5v7U+i3 gOh4SSwWkc047iaPYmJmcvvLFSujSX9se3LJllaLZAnvVwpwViIqmx7BfcVMrGFP FVi3Jgz8yhEVXIrAz0wdrU1G2h13Gt1S67Oparype8Ivf5RzFx1ahHKVXVC89VYz XRo5rk7V4LTAUNB3IlPP8xpCalyuw67eyx2ubY8efbH7i342gJ/JHykxIWKlBNHL szjy3ydim7MyGCzFVrQUjQkw7jhH9cEbVAZU1MCXwzpuO0M+1Aciype0mtlAzo45 i+A+GfDtF9SGxH0D1PUepUwDXZ+P1UyyA53q41KDZ6Vg3ESRmYN3GUu/N/LXtgY= =3eA4 -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] 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. 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 :) 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. 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
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2015 08:14 AM, YAMAMOTO Takashi wrote: 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. The I suggest to just go with a. If you want to make distributions happier, just make sure you mark appropriate entries in requirements.txt with some metadata to suggest its an ovs plugin only 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 am packaging neutron for RDO, and I speak up. I don't think maintaining multiple requirements files is a good option, for it will require updating packaging tools not to miss updates for the files. Also, how would you make sure those dependencies stay consistent with openstack/requirements repo? Do you plan to update tooling around the bot that proposes updates to requirements.txt files in each project? I think this option requires too much from those who will implement it in all the tools around, and does not seem to justify itself in comparison with trivial option 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. That's a proper direction long term, but as it was already suggested here, it's not going to happen shortly, so no need to block your work on it. 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU5J9FAAoJEC5aWaUY1u57eJwH/2+O55t7VjOS0qwM2txpMDV4 MnvMeucX5MBvpcTZ4UuE1gHMxiMHFTmhr5i5Cv+05Pnv7sbyPju+I2Ksi2kdAHlz 4Y5WiJpvrHbEtT2SdJ3OWvjvFUuhz6NM8XMhcCViVBXE3rdLzBVf864Y/8pwZt7d dR6qiyxIQB+4BbhEqe3G0YWZdULWOBKEH7TM5uXiUewA1p0v14Yt3ysfpGd7Z5t9 HY9Ty1t4JOMB5s0BTGF2LubcaRGNh6Aj596mRCo9OryKy5NR95A/SFBx2B0CIIgV i58f+PqHlFcoMHp1Qv3H4LUcxfZXitxjheSXA2cAsWDTW6kulnsYMfnSpjfVE0Q= =4fro -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
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
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
[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
