Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic
ation required is somehow sent to neutron (possibly as > part of the binding profile, which we could send at each time port > actions are requested by Ironic.) > * The Neutron agent running on the control plane connects outbound to > the smartnic, using information supplied to perform the appropriate > network configuration. > * In Ironic, this would likely be a new network_interface driver > module, with some additional methods that help facilitate the > work-flow logic changes needed in each deploy_interface driver module. > * Ironic would then be informed or gain awareness that the > configuration has been completed and that the deployment can proceed. > (A different spec has been proposed regarding this.) > > I have submitted a forum session based upon this and the agreed upon > goal at the PTG was to have the ironic spec written up to describe the > required changes. > > I guess the next question is, who wants to update the specification? > > -Julia > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2FOpenStack-dev-request%40lists.openstack.org%3Fsubject%3Aunsubscribe&data=02%7C01%7Cmoshele%40mellanox.com%7Ce5607928a41c44bf065508d6266a9435%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636738636550233328&sdata=PexKWkCH7u4kRWjzs2kOIZsHFmzSL%2BCl6bqzY2B5KWA%3D&reserved=0> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev&data=02%7C01%7Cmoshele%40mellanox.com%7Ce5607928a41c44bf065508d6266a9435%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636738636550243338&sdata=dHTuFDlyKrA8ouPU7JV4GKokCKNBg%2Fzw9KlpIrZW5x0%3D&reserved=0> > __ > 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 -- Isaku Yamahata __ 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] [networking-odl] Builds are failing in Stable/pike in networking-odl
Hello Vamsikrishna.
Carbon snapshot hasn't been build any more and not available from opendaylight
nexus server.
But the carbon job tried to get carbon snapshot and filed.
So the fix is to use latest(and final?) carbon release(carbon SR4) instead of
carbon snapshot.
Maybe you'd like to twist networking-odl/devstack/pre_test_hook.sh
or networking-odl/devstack/odl-release/carbon-snapshot
to point carbon SR4 release.
thanks,
On Mon, Jul 16, 2018 at 03:04:00PM +,
A Vamsikrishna wrote:
> +Isaku
>
> Hi Isaku,
>
> I found the reason for the build failure. below path it should be
> distribution-artifacts instead of distribution-karaf
>
> https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/-SNAPSHOT/maven-metadata.xml
>
> Line no: 7 is causing the problem
>
> https://github.com/openstack/networking-odl/blob/stable/pike/devstack/functions
>
> From logs:
>
> http://logs.openstack.org/45/582745/5/check/networking-odl-rally-dsvm-carbon-snapshot/be4abe3/logs/devstacklog.txt.gz#_2018-07-15_18_23_41_854
>
>
> opt/stack/new/networking-odl/devstack/functions:_odl_nexus_path:7 : echo
> https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf
>
>
> I think below code needs a fix, Can you please help us out ?
>
> https://github.com/openstack/networking-odl/blob/stable/pike/devstack/settings.odl#L72-L81
>
> case "$ODL_RELEASE" in
>
>
> latest-snapshot|nitrogen-snapshot-0.7*)
>
>
> # use karaf because distribution-karaf isn't available for Nitrogen
> at the moment
>
>
> # TODO(yamahata): when distriution-karaf is available, remove this
>
>
>
> ODL_URL_DISTRIBUTION_KARAF_PATH=${ODL_URL_DISTRIBUTION_KARAF_PATH:-org/opendaylight/integration/karaf}
>
>
> ;;
>
>
> *)
>
>
>
> ODL_URL_DISTRIBUTION_KARAF_PATH=${ODL_URL_DISTRIBUTION_KARAF_PATH:-org/opendaylight/integration/distribution-karaf}
>
>
> ;;
>
>
> Esac
>
>
>
> Thanks,
> Vamsi
>
> From: A Vamsikrishna
> Sent: Monday, July 16, 2018 6:14 PM
> To: 'openstack-dev@lists.openstack.org' ;
> openst...@lists.openstack.org
> Subject: [networking-odl] Builds are failing in Stable/pike in networking-odl
>
> Hi All,
>
> Builds are failing in Stable/pike in networking-odl on below review:
>
> https://review.openstack.org/#/c/582745/
> looks that issue is here:
> http://logs.openstack.org/45/582745/5/check/networking-odl-rally-dsvm-carbon-snapshot/be4abe3/logs/devstacklog.txt.gz#_2018-07-15_18_23_41_854
> There is 404 from opendaylight.org<http://opendaylight.org> service and
> snapshot version is missing & only /-SNAPSHOT/maven-metadata.xml, it should
> be 0.8.3-SNAPSHOT or 0.9.0-SNAPSHOT
> This job is making use of carbon based ODL version & not able to find it.
>
> Any idea how to fix / proceed further to make stable/pike builds to be
> successful ?
>
>
> Thanks,
> Vamsi
--
Isaku Yamahata
__
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] [Qos]Unable to apply qos policy with dscp marking rule to a port
Please step up to drive https://review.openstack.org/#/c/519513/ At the moment no one is working on the patch. Thanks, On Fri, Mar 16, 2018 at 07:25:58PM +, A Vamsikrishna wrote: > Hi Manjeet / Isaku, > > I am unable to apply qos policy with dscp marking rule to a port. > > > 1.Create a Qos Policy > 2.Create a dscp marking rule on to create qos policy > 3.Apply above created policy to a port > > openstack network qos rule set --dscp-mark 22 dscp-marking > 115e4f70-8034-41768fe9-2c47f8878a7d > > HttpException: Conflict (HTTP 409) (Request-ID: > req-da7d8998-9d8c-4aea-a10b-326cc21b608e), Rule dscp_marking is not supported > by port 115e4f70-8034-41768fe9-2c47f8878a7d > > stack@pike-ctrl:~/devstack$ > > Seeing above error during the qos policy application on a port. > > Any suggestions on this ? > > I see below review has been abandoned which is "Allow networking-odl to > support DSCP Marking rule for qos driver": > > https://review.openstack.org/#/c/460470/ > > Is dscp marking supported in PIKE ? Can you please confirm ? > > I have raised below bug to track this issue: > > https://bugs.launchpad.net/networking-odl/+bug/1756132 > > > > Thanks, > Vamsi -- Isaku Yamahata __ 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] Generalized issues in the unit testing of ML2 mechanism drivers
On Tue, Feb 13, 2018 at 05:48:32PM -0500, Assaf Muller wrote: > On Wed, Dec 13, 2017 at 7:30 AM, Michel Peterson wrote: > > Through my work in networking-odl I've found what I believe is an issue > > present in a majority of ML2 drivers. An issue I think needs awareness so > > each project can decide a course of action. > > > > The issue stems from the adopted practice of importing > > `neutron.tests.unit.plugins.ml2.test_plugin` and creating classes with noop > > operation to "inherit" tests for free [1]. The idea behind is nice, you > > inherit >600 tests that cover several scenarios. > > > > There are several issues of adopting this pattern, two of which are > > paramount: > > > > 1. If the mechanism driver is not loaded correctly [2], the tests then don't > > test the mechanism driver but still succeed and therefore there is no > > indication that there is something wrong with the code. In the case of > > networking-odl it wasn't discovered until last week, which means that for >1 > > year it this was adding PASSed tests uselessly. > > > > 2. It gives a false sense of reassurance. If the code of those tests is > > analyzed it's possible to see that the code itself is mostly centered around > > testing the REST endpoint of neutron than actually testing that the > > mechanism succeeds on the operation it was supposed to test. As a result of > > this, there is marginally added value on having those tests. To be clear, > > the hooks for the respective operations are called on the mechanism driver, > > but the result of the operation is not asserted. > > > > I would love to hear more voices around this, so feel free to comment. > > > > Regarding networking-odl the solution I propose is the following: > > **First**, discard completely the change mentioned in the footnote #2. > > **Second**, create a patch that completely removes the tests that follow > > this pattern. > > An interesting exercise would be to add 'raise ValueError' type > exceptions in various ODL ML2 mech driver flows and seeing which tests > fail. Basically, if a test passes without the ODL mech driver loaded, > or with a faulty ODL mech driver, then you don't need to run the test > for networking-odl changes. I'd be hesitant to remove all tests > though, it's a good investment of time to figure out which tests are > valuable to you. Mike and Michel should raise it at the PTG for discussion. I know Mike will attend. thanks, -- Isaku Yamahata __ 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-dev] [neutron] Generalized issues in the unit testing of ML2 mechanism drivers
Hello. Any comments/thoughts? This issue is generic to neutron. not specific to networking-odl. So this should be addressed as Neutron wide, and neutron and sub-project should be addressed uniformly. Thanks, On Mon, Dec 18, 2017 at 12:52:37PM +0200, Mike Kolesnik wrote: > On Wed, Dec 13, 2017 at 2:30 PM, Michel Peterson wrote: > > > Through my work in networking-odl I've found what I believe is an issue > > present in a majority of ML2 drivers. An issue I think needs awareness so > > each project can decide a course of action. > > > > The issue stems from the adopted practice of importing > > `neutron.tests.unit.plugins.ml2.test_plugin` and creating classes with > > noop operation to "inherit" tests for free [1]. The idea behind is nice, > > you inherit >600 tests that cover several scenarios. > > > > There are several issues of adopting this pattern, two of which are > > paramount: > > > > 1. If the mechanism driver is not loaded correctly [2], the tests then > > don't test the mechanism driver but still succeed and therefore there is no > > indication that there is something wrong with the code. In the case of > > networking-odl it wasn't discovered until last week, which means that for > > >1 year it this was adding PASSed tests uselessly. > > > > 2. It gives a false sense of reassurance. If the code of those tests is > > analyzed it's possible to see that the code itself is mostly centered > > around testing the REST endpoint of neutron than actually testing that the > > mechanism succeeds on the operation it was supposed to test. As a result of > > this, there is marginally added value on having those tests. To be clear, > > the hooks for the respective operations are called on the mechanism driver, > > but the result of the operation is not asserted. > > > > I would love to hear more voices around this, so feel free to comment. > > > > ???i talked to a few guys from networking-ovn which are now processing this > info so they could chime in, but from what I've understood the issue wasn't > given much thought in networking-ovn (and I suspect other mechanism > drivers). > ??? > > > > > Regarding networking-odl the solution I propose is the following: > > **First**, discard completely the change mentioned in the footnote #2. > > **Second**, create a patch that completely removes the tests that follow > > this pattern. > > **Third**, incorporate the neutron tempest plugin into the CI and rely > > on that for assuring coverage of the different scenarios. > > > > ???This sounds like a good plan to me. > ??? > > > > > Also to mention that when discovered this issue in networking-odl we took > > a decision not to merge more patches until the PS of footnote #2 was > > addressed. I think we can now decide to overrule that decision and proceed > > as usual. > > > > ???Agreed. > ??? > > > > > > > > > [1]: http://codesearch.openstack.org/?q=class%20.*\(.*TestMl2 > > <http://codesearch.openstack.org/?q=class%20.*%5C(.*TestMl2> > > [2]: something that was happening in networking-odl and addressed by > > https://review.openstack.org/#/c/523934 > > > > ___ > > neutron-dev mailing list > > neutron-...@lists.opendaylight.org > > https://lists.opendaylight.org/mailman/listinfo/neutron-dev > > > > > > > -- > Regards, > Mike > __ > 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 -- Isaku Yamahata __ 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] [Networking-odl] [Qos] networking-odl is not sending complete data during qos-policy-name update
Added odl neutron-dev. Basically this issue is fixed with master already. As newton is about to be EOL, I don't see any point to dig into it. Probably you'd like to check the fix in the master and backport it to newton. Thanks, On Tue, Nov 21, 2017 at 10:08:03AM +, A Vamsikrishna wrote: > Hi All, > > Networking-odl is not sending bandwidth_limit_rules & dscp_marking_rules > along with the updated qos policy name when I have updated the > qos-policy-name from Vamsi to Krish. > > Expected behavior is to have the updated policy name along with > bandwidth_limit_rules & dscp_marking_rules same as that in old > qos-policy-name. > > > > Version: Stable/Newton > 192.168.56.102 --> Openstack > 192.168.56.1 --> ODL > > Any thoughts on how to move forward ? > > PFA for wireshark cap. > > JavaScript Object Notation: application/json > Object > Member Key: policy > Object > Member Key: bandwidth_limit_rules > Array > Key: bandwidth_limit_rules > Member Key: name > String value: Krish > Key: name > Member Key: created_at > String value: 2017-11-20T19:27:06Z > Key: created_at > Member Key: updated_at > String value: 2017-11-20T19:27:15Z > Key: updated_at > Member Key: dscp_marking_rules > Array > Key: dscp_marking_rules > Member Key: revision_number > Number value: 4 > Key: revision_number > Member Key: shared > False value > Key: shared > Member Key: project_id > String value: eacd04d3ff4b4e1d9dc2f5282edbb9e0 > Key: project_id > Member Key: id > String value: 066fd21e-2041-43f6-956a-6bec0948bf15 > Key: id > Member Key: description > String value: > Key: description > Key: policy > > > Thanks, > Vamsi > __ > 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 -- Isaku Yamahata __ 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] Re?: [Neutron] Denver Team Dinner
+1 On Wed, Sep 13, 2017 at 07:28:31AM -0600, Thomas Morin wrote: > +1 > > -Thomas > > > Takashi Yamamoto, 2017-09-13 03:05: > > +1 > > > > On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro > > wrote: > > > +1 > > > thanks for organizing! > > > > > > On Wed, 13 Sep 2017 14:18:45 +0900, > > > Brian Haley wrote: > > > > > > > > +1 > > > > > > > > On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote: > > > > > +1 > > > > > > > > > > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton > > > > > wrote: > > > > > > +1 > > > > > > > > > > > > On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński > > > > > lonski.pl> > > > > > > wrote: > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > ??? > > > > > > > Best regards > > > > > > > Slawek Kaplonski > > > > > > > sla...@kaplonski.pl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wiadomość napisana przez Miguel Lavalle > > > > > > > com> w dniu > > > > > > > > 12.09.2017, o godz. 17:23: > > > > > > > > > > > > > > > > Dear Neutrinos, > > > > > > > > > > > > > > > > Our social event will take place on Thursday September > > > > > > > > 12th at 7:30pm. > > > > > > > > The venue is going to be https://www.famousdaves.com/Denv > > > > > > > > er-Stapleton. It is > > > > > > > > located 0.4 miles from the Renaissance Hotel, which > > > > > > > > translates to an easy 9 > > > > > > > > minutes walk. > > > > > > > > > > > > > > > > I have a reservation for a group of 30 people under my > > > > > > > > name. Please > > > > > > > > respond to this message with your attendance confirmation > > > > > > > > by Wednesday > > > > > > > > night, so I can get a more accurate head count. > > > > > > > > > > > > > > > > Looking forward to see y'all Thursday night > > > > > > > > > > > > > > > > Best regards > > > > > > > > > > > > > > > > Miguel > > > > > > > > > > > > > > > > _ > > > > > > > > _ > > > > > > > > OpenStack Development Mailing List (not for usage > > > > > > > > questions) > > > > > > > > Unsubscribe: > > > > > > > > openstack-dev-requ...@lists.openstack.org?subject:unsubsc > > > > > > > > ribe > > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opens > > > > > > > > tack-dev > > > > > > > > > > > > > > > > > > > > > ___ > > > > > > > ___ > > > > > > > OpenStack Development Mailing List (not for usage > > > > > > > questions) > > > > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj > > > > > > > ect:unsubscribe > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta > > > > > > > ck-dev > > > > > > > > > > > > > > > > > > > > > > > > > _ > > > > > > _ > > > > > > OpenStack Development Mailing List (not for usage questions) > > > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec > > > > > > t:unsubscribe > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > -dev > > > > > > > > > > > > > > > > _
Re: [openstack-dev] [neutron] out-of-tree l3 service providers
On Fri, Sep 08, 2017 at 12:26:56PM +0900, Takashi Yamamoto wrote: > hi, > > On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata > wrote: > > Hi. > > > > Any update on this? Now L3 service provider got the time slot at the PTG. > > > > Yamamoto, do you have any proposal for the interface? > > no > > > Although ODL surely is interested in L3 flavor, the networking-odl team > > hasn't > > spec or experimental patch yet unfortunately. > > can you at least provide your requirements? Sure. networking-odl needs PRECOMMIT/AFTER_CREATE/UPDATE/DELETE for router/floaringip and PRECOMMIT for disassociate_floatingip. The reason why precommit_disassociate_floatingip is needed is that right now ODL doesn't support to updating floatingip status by ODL. So floatingip status is forcibly set to DOWN by the callback for now. (It's in future roadmap) networking-odl doesn't need callback for add/remove_router_interface because only db operation does. ODL identifies router interface by port:owner which is updated by update_port. Thanks, > networking-midonet needs to send the following info to its backend on > AFTER_CREATE/AFTER_UPDATE for router, router_interface, and > floating_ip. > https://github.com/midonet/midonet/blob/fcc127f5c9216b7a563c89d2684461428feb9a67/nsdb/src/main/proto/neutron.proto#L129-L161 > (some of fields are actually unused right now. eg. tenant_id) > on AFTER_DELETE, we only need "id" field of the resource. > in feature we want to use PRECOMMIT_xxx events as well. necessary > fields are same as AFTER_xxx. > > > Dragon flow folks seems to have their own spec. > > > > thanks, > > > > On Mon, Jul 31, 2017 at 02:10:07PM +0900, > > Takashi Yamamoto wrote: > > > >> hi, > >> > >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton wrote: > >> > If I understand the main issue with using regular callbacks, it's mainly > >> > just that the flavor assignment itself is in a callback, right? > >> > >> yes. > >> > >> > > >> > If so, couldn't we solve the problem by just moving flavor assignment to > >> > an > >> > explicit call before emitting the callbacks? Or would that still result > >> > in > >> > other ordering issues? > >> > >> it would solve the problem for CREATE. > >> for UPDATE and DELETE, i'm not sure. > >> UPDATE can change the flavor but it's supposed to be a special case > >> only for dvr/ha, right? > >> AFTER_DELETE might be tricky as we probably need to provide flavor > >> info to subscribers. > >> > >> > > >> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto > >> > wrote: > >> >> > >> >> hi, > >> >> > >> >> today i managed to play with l3 flavors. > >> >> i wrote a crude patch to implement midonet flavor. [1] > >> >> > >> >> [1] https://review.openstack.org/#/c/483174/ > >> >> > >> >> a good news is it's somehow working. > >> >> > >> >> a bad news is it has a lot of issues, as you can see in TODO comments > >> >> in the patch. > >> >> given these issues, now i tend to think it's cleaner to introduce > >> >> ml2-like precommit/postcommit driver api (or its equivalent via > >> >> callbacks) rather than using these existing notifications. > >> >> > >> >> how do you think? > >> > > >> > > >> > >> __ > >> 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 > > > > -- > > Isaku Yamahata -- Isaku Yamahata __ 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] out-of-tree l3 service providers
Hi. Any update on this? Now L3 service provider got the time slot at the PTG. Yamamoto, do you have any proposal for the interface? Although ODL surely is interested in L3 flavor, the networking-odl team hasn't spec or experimental patch yet unfortunately. Dragon flow folks seems to have their own spec. thanks, On Mon, Jul 31, 2017 at 02:10:07PM +0900, Takashi Yamamoto wrote: > hi, > > On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton wrote: > > If I understand the main issue with using regular callbacks, it's mainly > > just that the flavor assignment itself is in a callback, right? > > yes. > > > > > If so, couldn't we solve the problem by just moving flavor assignment to an > > explicit call before emitting the callbacks? Or would that still result in > > other ordering issues? > > it would solve the problem for CREATE. > for UPDATE and DELETE, i'm not sure. > UPDATE can change the flavor but it's supposed to be a special case > only for dvr/ha, right? > AFTER_DELETE might be tricky as we probably need to provide flavor > info to subscribers. > > > > > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto > > wrote: > >> > >> hi, > >> > >> today i managed to play with l3 flavors. > >> i wrote a crude patch to implement midonet flavor. [1] > >> > >> [1] https://review.openstack.org/#/c/483174/ > >> > >> a good news is it's somehow working. > >> > >> a bad news is it has a lot of issues, as you can see in TODO comments > >> in the patch. > >> given these issues, now i tend to think it's cleaner to introduce > >> ml2-like precommit/postcommit driver api (or its equivalent via > >> callbacks) rather than using these existing notifications. > >> > >> how do you think? > > > > > > __ > 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 -- Isaku Yamahata __ 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] security group OVO change
It also broke networking-odl. The patch[1] is needed to unbreak. [1] https://review.openstack.org/#/c/448420/ necessary db info is taken from context.session.new. But with OVO, those expunge themselves with create method. Those info needs to be passed as callback argument. Thanks, On Fri, Jun 16, 2017 at 01:25:28PM -0700, Ihar Hrachyshka wrote: > To close the loop here, > > - this also broke heat py3 job (https://launchpad.net/bugs/1698355) > - we polished https://review.openstack.org/474575 to fix both > vmware-nsx and heat issues > - I also posted a patch for oslo.serialization for the bug that > triggered MemoryError in heat gate: > https://review.openstack.org/475052 > - the vmware-nsx adoption patch is at: > https://review.openstack.org/#/c/474608/ and @boden is working on it, > should be ready to go in due course. > > Thanks and sorry for inconveniences, > Ihar > > On Thu, Jun 15, 2017 at 6:17 AM, Gary Kotton wrote: > > Hi, > > > > The commit https://review.openstack.org/284738 has broken decomposed plugins > > (those that extend security groups and rules). The reason for this is that > > there is a extend callback that we use which expects to get a database > > object and the aforementioned patch passes a new neutron object. > > > > I have posted [i] to temporarily address the issue. An alternative is to > > revert the patch until the decomposed plugins can figure out how to > > correctly address this. > > > > Thanks > > > > Gary > > > > [i] https://review.openstack.org/474575 > > > > > > __ > > 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 -- Isaku Yamahata __ 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] [telemetry][ceilometer][opendaylight][networking-odl] OpenDaylight Driver for Ceilometer
What's the policy of telemetry or ceilometer? As long as it follows the policy of them, networking-odl is fine to include such drivers. Thanks, On Mon, Jun 12, 2017 at 08:25:49AM +, Deepthi V V wrote: > Hi, > > We plan to propose a ceilometer driver for collecting network statistics > information from OpenDaylight. We were thinking if we could have the driver > code residing in networking-odl project instead of Ceilometer project. The > thought is we have OpenDaylight depended code restricted to n-odl repo. > Please let us know your thoughts on the same. > > Thanks, > Deepthi > __ > 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 -- Isaku Yamahata __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday
+1 On Fri, Feb 17, 2017 at 11:18:41AM -0800, Kevin Benton wrote: > Hi all, > > I'm organizing a Neutron social event for Thursday evening in Atlanta > somewhere near the venue for dinner/drinks. If you're interested, please > reply to this email with a "+1" so I can get a general count for a > reservation. > > Cheers, > Kevin Benton > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata __ 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] [stadium] subprojects on independent release cycle
Regarding to networking-odl, we're going to cut stable/ocata branch around Feb 11. After a while testing, the release will be done to avoid much delay the official schedule. The plan for Pike is to graduate from independent model. thanks, On Wed, Feb 08, 2017 at 08:16:13AM -0800, "Armando M." wrote: > On 2 February 2017 at 16:09, Armando M. wrote: > > > Hi neutrinos, > > > > I have put a number of patches in the merge queue for a few sub-projects. > > We currently have a number of these that are on an independent release > > schedule. In particular: > > > >- networking-bagpipe > >- networking-bgpvpn > >- networking-midonet > >- networking-odl > >- networking-sfc > > > > Please make sure that between now and March 10th [1], you work to prepare > > at least one ocata release that works with neutron's [2] and cut a stable > > branch before than. That would incredibly help consumers who are interested > > in assembling these bits together and start testing ocata as soon as it's > > out. > > > > Your collaboration is much appreciated. > > > > Many thanks, > > Armando > > > > Hi neutrinos, > > I did not hear anything back from the liaisons of the above mentioned > project over the past few days. Can you clarify your plans for cutting an > Ocata release? > > Thanks, > Armando > > > > [1] https://releases.openstack.org/ocata/schedule.html > > [2] https://review.openstack.org/#/c/428474/ > > > ______ > 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 -- Isaku Yamahata __ 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] [networking-odl] Neutron with OpenDaylight Boron controller
Hello Elena. Added related opendaylight mailing lists to cc. Probably you'll get more reply by sending a mail to OpenDaylight specific mailing list. thanks, On Wed, Dec 07, 2016 at 04:20:37PM +0400, Elena Ezhova wrote: > Hi folks, > > We are trying to deploy Neutron with OpenDaylight Boron-0.5.0 controller > using DevStack (master version) on Ubuntu 14.04 and there is a number of > issues we face. > > First, we tried to deploy OpenDaylight with odl-ovsdb-openstack feature > using the following local.conf [0]. In this case VMs successfully got IP > addresses and L2 connectivity was working, but there was no L3 connectivity > meaning we couldn't ping router IP from qdhcp namespace and VMs in > different subnets couldn't reach each other. > We've also tried to deploy OpenDaylight odl-ovsdb-openstack with Neutron L3 > agent by enabling q-l3 and setting ODL_L3=False in local.conf, but in this > case stack.sh failed due to br-int not having been created. > > After that, we were given an advice on opendaylight irc channel to use > odl-netvirt-openstack feature instead as odl-ovsdb-openstack is kind of > deprecated. > When deploying Neutron+ODL with this feature we were referencing the > NetVirt demo from the latest ODL summit [1] as well as networking-odl > DevStack guide [2] and our local.conf was looking the following way [3]. > As a result, though br-int is created and when a subnet or a VM are created > corresponding tap interfaces are added, there is no L2 and L3 connectivity > and there are a lot of error in karaf logs: > >- Errors on start: http://paste.openstack.org/show/591432/ >- Logs during Neutron subnet create: >http://paste.openstack.org/show/591437/ >- OVS ports and flows after a Neutron network with a subnet were >created: http://paste.openstack.org/show/591642/ . >Here it seems that not all flows had been created, for example there is >a flow in table 51 that sends traffic to table 52 which is missing. >- There are also tons of traces identical to ones in bug [4] which >should have been fixed in Beryllium release. > > Has someone successfully deployed operational Neutron+OpenDaylight with > NetVirt or ovsdb feature recently? If so, we would really appreciate an > example of local.conf that was used as well as any clues that point out > what we can be missing. > > Thanks, > Elena > > [0] http://paste.openstack.org/show/591645/ > https://docs.google.com/presentation/d/1VLzRIOEptSOY1b0w4PezRIQ0gF5vx7GyLKECWXRV5mE/edit#slide=id.g17efbe8461_0_146 > [2] > https://github.com/openstack/networking-odl/blob/master/devstack/README.rst > [3] http://paste.openstack.org/show/591641/ > [4] https://bugs.opendaylight.org/show_bug.cgi?id=5275 > __ > 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 -- Isaku Yamahata __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona
+1 Thanks for organizing this. On Fri, Oct 14, 2016 at 01:30:57PM -0500, Miguel Lavalle wrote: > Dear Neutrinos, > > I am organizing a social event for the team on Thursday 27th at 19:30. > After doing some Google research, I am proposing Raco de la Vila, which is > located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is > here: http://www.racodelavila.com/en/carta-racodelavila.htm > > It is easy to get there by subway from the Summit venue: > https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under > 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get > a final count. > > Here's some reviews: > https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html > > Cheers > > Miguel > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata __ 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] [devstack] [odl-networking] Devstack with ODL using Mitaka?
Hi. (Added neutron-...@lists.opendaylight.org) It seems like networking-odl bug. Can you please file a bug? Just in case, can you please check if you don't "enable_service odl-server" somewhere manually? thanks, On Tue, Jun 07, 2016 at 01:42:39PM +0200, Wojciech Dec wrote: > Hi Openstack dev Folks, > > I'd appreciate your help with setting up the necessary local.conf for using > an ODL as the controller, along with Mitaka. > > Would be great if anyone could share a working Mitaka updated local.conf > that they could share? > > A more specific problem I've been experiencing, is that the devstack script > insists on pulling and starting ODL no matter what ODL_MODE setting is > used. According to : > https://github.com/openstack/networking-odl/blob/master/devstack/settings > I've been using ODL_MODE=externalodl as well as =manual. In both cases > devstack starts the ODL it pulls. > > Thanks, > Wojtek. > __ > 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 -- Isaku Yamahata __ 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] service chaining feature development meeting minutes
Hello Cathy. Thank you for arranging the meeting. Will we have goto meeting/irc meeting this week(May 12) on this topic? I haven't seen any announcement yet. thanks in advance Isaku Yamahata On Tue, May 05, 2015 at 08:55:25PM +, Cathy Zhang wrote: > Attendees (Sorry we did not catch all the names): > Cathy Zhang (Huawei), Louis Fourie, Alex Barclay (HP), Vikram Choudhary, > Carlos Goncalves (NTT) m...@cgoncalves.pt<mailto:m...@cgoncalves.pt>, Adolfo > Duarte (HP) adolfo.dua...@hp.com<mailto:adolfo.dua...@hp.com> > German Eichberger (HP) > german.eichber...@hp.com<mailto:german.eichber...@hp.com>, Swami Vasudevan > (HP) swaminathan.vasude...@hp.com<mailto:swaminathan.vasude...@hp.com>, Uri > Elzur (Intel) uri.el...@intel.com<mailto:uri.el...@intel.com> > Joe D'Andrea (ATT) > jdand...@research.att.com<mailto:jdand...@research.att.com>, Isaku Yamahata > (Intel) isaku.yamah...@gmail.com<mailto:isaku.yamah...@gmail.com>, Malini > Bhandaru malini.k.bhand...@intel.com<mailto:malini.k.bhand...@intel.com>, > Michael Johnson (HP) john...@hp.com<mailto:john...@hp.com>, Lynn Li (HP) > lynn...@hp.com<mailto:lynn...@hp.com>, Mickey Spiegel (IBM) > emspi...@us.ibm.com<mailto:emspi...@us.ibm.com>, Ryan Tidwell (HP) > ryan.tidw...@hp.com<mailto:ryan.tidw...@hp.com> > Ralf Trezeciak openst...@trezeciak.de<mailto:openst...@trezeciak.de>, David > Pinheiro, Hardik Italia > > Agenda: > Cathy presented the service chain architecture and blueprints and Gerrit > review for: > > - Neutron Extensions for Service chaining > > - Common Neutron SFC Driver API > > > > There is a lot of interest on this feature. > > > > Questions > > Uri: Does this BP specify the implementation in the backend data path? Cathy: > This could be implemented by various data path chaining schemes: eg. IETF > service chain header, VLAN. > > Uri: What happens if the security group/iptables conflict with SGs for > port-chain? Cathy: it is expected that conflicts will be resolved by the > upper layer "Intent Infra". > > Vikram: can other datapath transports be used. Cathy: Yes, what is defined in > the BP is the NBI for Neutron. > > Swami: add use case and example. Cathy: will add. There is a SFC use case BP, > will contact authors. > > Carlos: how does this relate to older traffic steering BP. Cathy: we can > discuss offline and work together to incorporate the traffic steering BP idea > into this BP. > > Uri: are these two BPs for NBI and SBI for Neutron? Cathy: yes > > Isaku: does Kyle know about BPs? Cathy: yes > > Uri: how do these BPs relate to rest of Openstack? Cathy: There will be a > presentation on the service chain framework at 2pm May 18 at the Vancouver > Summit. It will be presented by Cathy together with Kyle Mestery and Dave > Lenrow. > > Swami: It helps to present a simple service chain use case at meeting next > week. Suggest to have IRC meeting too as it provides a record of what is > discussed. Cathy: I have already created the IRC meeting for service chain > project, will start the IRC meeting too. > > Malini: we should have a complete spec so redesign is avoided. > > Swami: We should use Neutron design session at Vancouver to discuss this BP > and flesh out details. > Action Items > > > 1. We will have two meetings next week: one "goto" meeting with audio and > data sharing, the other IRC meeting with link to google doc for sharing > diagrams. Cathy will send out the meeting info to the community > > 2. Swami will send an email to Kyle Mestery requesting a time slot for > service chaining topic in Neutron design session so that we can get all > interested parties in one room for a good face-to-face discussion. > > 3. Cathy will discuss with Carlos offline about incorporating the traffic > steering idea into the service chain BPs. > > 4. Service chaining is a complicated solution involving management plane, > control plane, and data plane as well as multiple components. The consensus > is to first design/implement the two Neutron related service chain BPs > https://review.openstack.org/#/c/177946 and get the feature approved by > Neutron Core/Driver team and implemented for the OpenStack L release. If we > can not get a slot in the design session, we will meet at the service chain > presentation on May 18 and find a room to discuss how to move forward with > this feature development in OpenStack. > > Feel free to chime in if I miss any points. > > Thanks, > Cathy > > > > ___
Re: [openstack-dev] [neutron] openwrt VM as service
in to give proper attribution so if anyone knows who > > > originated this I'd be grateful. > > > > > > dt > > > > > > [0] https://github.com/dtroyer/openwrt-packages/tree/master/rc.cloud > > > -- > > > > > > Dean Troyer > > > dtro...@gmail.com > > > > > > > __ > > > 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 -- Isaku Yamahata __ 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
Surely eliminating linux bridge for iptables by ovs+tc is quite important for performance. On Fri, Feb 13, 2015 at 01:57:46PM +0100, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/13/2015 01:47 PM, Miguel Ángel Ajo wrote: > > 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). > > Indeed, that was also mentioned by Jiri in our private talks. That > said, I'm as unaware of details here as you probably are (or more). The current ovs instantiates only kernel datapath and optimizes out patch port in kernel. the patch port logic is handled by ovs-vswitchd side when building flow rules for kernel datapath. I don't know which version, so you may be using old versions... Or are you referring to recirculation? > >> 2) Using OVS+OF to do QoS > >> > >> other interesting stuff to look at: What exactly do you mean? marking packet or tc queuing? thanks, -- Isaku Yamahata __ 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][ServiceVM] servicevm IRC meeting reminder (Nov 19 Wednesday 17:00 UTC-)
Hi. This is a reminder mail for the weekly servicevm IRC meeting. >From Nov 19 2014, the timeslot/channel has been changed. Please be prepared. Nov 19, 2014 Wednesday 17:00 UTC- #openstack-meeting-4 on freenode https://wiki.openstack.org/wiki/Meetings/ServiceVM -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] L2 gateway as a service
design summit discussion in the ML? > >>>> > >>>> I see at least 3 specs which would be under such an umbrella spec : > >>>> https://review.openstack.org/#/c/93329/ (BGPVPN) > >>>> https://review.openstack.org/#/c/101043/ (Inter DC connectivity with > >>>> VPN) > >>>> https://review.openstack.org/#/c/134179/ (l2 gw aas) > >>>> > >>>> > >>>> On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando > >>>> wrote: > >>>> > Thanks Maruti, > >>>> > > >>>> > I have some comments and questions which I've posted on gerrit. > >>>> > There are two things I would like to discuss on the mailing list > >>>> > concerning > >>>> > this effort. > >>>> > > >>>> > 1) Is this spec replacing https://review.openstack.org/#/c/100278 and > >>>> > https://review.openstack.org/#/c/93613 - I hope so, otherwise this > >>>> > just adds > >>>> > even more complexity. > >>>> > > >>>> > 2) It sounds like you should be able to implement this service plugin > >>>> > in > >>>> > either a feature branch or a repository distinct from neutron. Can you > >>>> > confirm that? > >>>> > > >>>> > Salvatore > >>>> > > >>>> > On 13 November 2014 13:26, Kamat, Maruti Haridas > >>>> > wrote: > >>>> >> > >>>> >> Hi Friends, > >>>> >> > >>>> >> As discussed during the summit, I have uploaded the spec for > >>>> >> review > >>>> >> at https://review.openstack.org/#/c/134179/ > >>>> >> > >>>> >> Thanks, > >>>> >> Maruti > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> ___ > >>>> >> 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 > >>> > >>> > >>> > >>> > >>> -- > >>> Igor Duarte Cardoso. > >>> http://igordcard.com > >>> @igordcard > >>> > >>> ___ > >>> 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 -- Isaku Yamahata ___ 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
On Thu, Nov 13, 2014 at 12:09:18PM +0900, Isaku Yamahata wrote: > 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 Oops. - Weekly 17:00 UTC(Wednesday) 30min (time is correct. AM is wrong. should be PM or nothing.) thanks, > - 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 Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 - 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!
I'm also interested in it. On Sat, Nov 01, 2014 at 10:27:59AM -0700, Chuck Carlino wrote: > On 10/31/2014 01:01 PM, Ian Wells wrote: > >Maruti's talk is, in fact, so interesting that we should probably > >get together and talk about this earlier in the week. I very much > >want to see virtual-physical programmatic bridging, and I know > >Kevin Benton is also interested. Arguably the MPLS VPN stuff also > >is similar in scope. Can I propose we have a meeting on cloud > >edge functionality? > >-- > >Ian. > > > > > >___ > >OpenStack-dev mailing list > >OpenStack-dev@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > I am interested in these discussions as well. > > Chuck Carlino > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][ServiceVM] servicevm and Paris summit(BoF)
Hi, there are several efforts to run service in VM.[1][2][3] Although we focused on router service, other services like lbaas have similar requirements. So it will be good to have a BoF or something. I created a poll page(following NFV BoF), and please register if you're interested https://doodle.com/5tyi2bifag2f5ud4 Etherpad page is to manage topics. https://etherpad.openstack.org/p/servicevm This is also a reminder mail for the servicevm IRC meeting. This is the last irc meeting before Paris Summit and discuss for the planning Oct 28, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode links: [0] https://wiki.openstack.org/wiki/ServiceVM [1] https://blueprints.launchpad.net/neutron/+spec/cisco-routing-service-vm https://blueprints.launchpad.net/neutron/+spec/cisco-config-agent https://blueprints.launchpad.net/neutron/+spec/fwaas-cisco [2] https://blueprints.launchpad.net/neutron/+spec/l3-plugin-brocade-vyatta-vrouter https://blueprints.launchpad.net/neutron/+spec/firewall-plugin-for-brocade-vyatta-vrouter [3] https://blueprints.launchpad.net/neutron/+spec/tcs-fwaas-netconf-host-plugin -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][ServiceVM] servicevm IRC meeting reminder (cancel Sep 9, next Sep 16 Tuesday 5:00(AM)UTC-)
Hi. This is a reminder mail for the servicevm IRC meeting. The meeting on Sep 9 will be canceled due to my conflicts. If someone is willing chair the meeting on, please go ahead(without me). The next meeting will be held on Sep 16. Sep 16, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode https://wiki.openstack.org/wiki/Meetings/ServiceVM -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] 答???: [Neutron] Auth token in context
ne. > >>> >class NeutronKeystoneContext(wsgi.Middleware) > >>> >. > >>> ># token not get from the header and not passed to context. Just > >>> >change here like what Nova/Cinder did. > >>> >context.Context(user_id, tenant_id, roles=roles, > >>> > user_name=user_name, > >>> >tenant_name=tenant_name, > >>> > request_id=req_id) > >>> >req.environ['neutron.context'] = ctx > >>> > > >>> >I think I'd better to report a bug for your case. > >>> > > >>> >Best Regards > >>> >Chaoyi Huang ( Joe Huang ) > >>> >-???件原件- > >>> >???件人: Phillip Toohill [mailto:phillip.tooh...@rackspace.com] > >>> >???送??: 2014年7月18日 14:07 > >>> >收件人: OpenStack Development Mailing List (not for usage questions) > >>> >主???: [openstack-dev] [Neutron] Auth token in context > >>> > > >>> >Hello all, > >>> > > >>> >I am wondering how to get the auth token from a user request passed down > >>> >to the context so it can potentially be used by the plugin or driver? > >>> > > >>> >Thank you > >>> > > >>> > > >>> >___ > >>> >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 > >>> > >> > >> > >> > >> -- > >> Kevin Benton > >> > >> ___ > >> OpenStack-dev mailing list > >> 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 > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > -- > Kevin Benton > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Ready to change the meeting time?
Hi Steve. The timeslot of 5:00AM UTC(Tuesday) 30min clashes with it. https://wiki.openstack.org/wiki/Meetings/ServiceVM Please disable this time slot. thanks, On Tue, Jul 29, 2014 at 10:53:21AM -0400, Steve Gordon wrote: > Hi all, > > I have recently had a few people express concern to me that the current > meeting time is preventing their attendance at the meeting. As we're still > using the original meeting time we discussed using for a trial period > immediately after summit it is probably time we reassess anyway. > > I have been through the global iCal [1] and tried to identify times where at > least one of the IRC meeting rooms is available and no other NFV related team > or subteam (E.g. Nova, Neutron, DVR, L3, etc.) is meeting. The resultant > times are available for voting on this whenisgood.net sheet - be sure to > select your location to view in your local time: > > http://whenisgood.net/exzzbi8 > > If you are a regular participant in the NFV meetings, or even more > importantly if you would like to be but are restrained from doing so because > of the current timing then please record your preferences above. If you think > there is an available time slot that I've missed, or I've made a time slot > available that actually clashes with a meeting relevant to NFV participants, > then please respond on list! > > This week's meeting will proceed at the regular time on Wednesday, July 30 at > 1400 UTC in #openstack-meeting-alt. > > Thanks, > > Steve > > [1] > https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ 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] ml2-ovs-portsecurity
On Tue, Jul 22, 2014 at 01:12:24PM +0800, loy wolfe wrote: > any relation with this BP? > > https://review.openstack.org/#/c/97715/6/specs/juno/nfv-unaddressed-interfaces.rst No direct relationship because the above blueprint doesn't specify concrete plugin/mechanism driver, but it defines only rest API. If it touches iptables_firewall driver, both BPs need mostly same code change on the driver. thanks, > > > > On Tue, Jul 22, 2014 at 11:17 AM, Isaku Yamahata > wrote: > > > > > I'd like to request Juno spec freeze exception for ML2 OVS portsecurity > > extension. > > > > - https://review.openstack.org/#/c/99873/ > > ML2 OVS: portsecurity extension support > > > > - https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity > > Add portsecurity support to ML2 OVS mechanism driver > > > > The spec/blueprint adds portsecurity extension to ML2 plugin and implements > > it in ovs mechanism driver with iptables_firewall driver. > > The spec has gotten 5 +1 with many respins. > > This feature will be a basement to run network service within VM. > > > > There is another spec whose goal is same. > > - https://review.openstack.org/#/c/106222/ > > Add Port Security Implementation in ML2 Plugin > > The author, Shweta, and I have agreed to consolidate those specs/blueprints > > and unite for the same goal. > > > > Thanks, > > -- > > Isaku Yamahata > > > > ___ > > 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][Spec Freeze Exception] ml2-ovs-portsecurity
I'd like to request Juno spec freeze exception for ML2 OVS portsecurity extension. - https://review.openstack.org/#/c/99873/ ML2 OVS: portsecurity extension support - https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity Add portsecurity support to ML2 OVS mechanism driver The spec/blueprint adds portsecurity extension to ML2 plugin and implements it in ovs mechanism driver with iptables_firewall driver. The spec has gotten 5 +1 with many respins. This feature will be a basement to run network service within VM. There is another spec whose goal is same. - https://review.openstack.org/#/c/106222/ Add Port Security Implementation in ML2 Plugin The author, Shweta, and I have agreed to consolidate those specs/blueprints and unite for the same goal. Thanks, -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] Networks without subnets
On Mon, Jul 21, 2014 at 02:52:04PM -0500, Kyle Mestery wrote: > > Following up with post SAD status: > > > >> * https://review.openstack.org/#/c/99873/ ML2 OVS: portsecurity > >> extension support > > > > Remains unapproved, no negative feedback on current revision. > > > >> * https://review.openstack.org/#/c/106222/ Add Port Security > >> Implementation in ML2 Plugin > > > > Has a -2 to highlight the significant overlap with 99873 above. > > > > Although there were some discussions about these last week I am not sure we > > reached consensus on whether either of these (or even both of them) are the > > correct path forward - particularly to address the problem Brent raised > > w.r.t. to creation of networks without subnets - I believe this currently > > still works with nova-network? > > > > Regardless, I am wondering if either of the spec authors intend to propose > > these for a spec freeze exception? > > > For the port security implementation in ML2, I've had one of the > authors reach out to me. I'd like them to send an email to the > openstack-dev ML though, so we can have the discussion here. As I commented at the gerrit, we, two authors of port security (Shweta and me), have agreed that the blueprints/specs will be unified. I'll send a mail for a spec freeze exception soon. thanks, -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] Networks without subnets
an address. However, on review it seems that the > >> intent is not necessarily inline with the some of the BZs mentioned > >> above. Indeed there is text that seems to pretty clearly state that it > >> is not intended to cover the port-without-an-IP situation. As an aside, > >> the title in the commit message in the review could use revising. > >> > >> In order to implement something that finally implements the > >> functionality alluded to in the above BZs in Juno, we need to settle on > >> a blueprint and direction. Barring the happy possiblity of a resolution > >> beforehand, can this be made an agenda item in the next Nova and/or > >> Neutron meetings? > >> > >> I think this is worth discussing. I've added this to the "Team Discussion > > Topics" section of the Neutron meeting [1] on 7-14-2014. I hope you can > > attend Brent! > > > > Thanks, > > Kyle > > > > [1] > > https://wiki.openstack.org/wiki/Network/Meetings#Team_Discussion_Topics > > > > > >> Cheers, > >> > >> Brent > >> > >> ___ > >> 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ServiceVM] servicevm IRC meeting reminder (June 28 Tuesday 5:00(AM)UTC-)
As action items, I've moved API spec to google-doc until stackforge repo is created. Here is the link https://docs.google.com/document/d/10v818QsHWw5lSpiCMfh908PAvVzkw7_ZUL0cgDiH3Vk/edit?usp=sharing thanks, On Mon, Jun 23, 2014 at 11:25:03PM +0900, Isaku Yamahata wrote: > Hi. This is a reminder mail for the servicevm IRC meeting > June 28, 2014 Tuesdays 5:00(AM)UTC- > #openstack-meeting on freenode > https://wiki.openstack.org/wiki/Meetings/ServiceVM > > > agenda: (feel free to add your items) > * announcements > * action items from the last week > * new repo in github and API discussion > I hoped to use stackforge so far, but the process of config seems > too slow. > So I'd like to start actual discussion with github until stackforge repo > is created. > * API discussion for consolidation > consolidate multiple existing implementations > * NFV meeting follow up > * blueprint follow up > * open discussion > * add your items > -- > Isaku Yamahata -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][ServiceVM] servicevm IRC meeting reminder (June 28 Tuesday 5:00(AM)UTC-)
Hi. This is a reminder mail for the servicevm IRC meeting June 28, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode https://wiki.openstack.org/wiki/Meetings/ServiceVM agenda: (feel free to add your items) * announcements * action items from the last week * new repo in github and API discussion I hoped to use stackforge so far, but the process of config seems too slow. So I'd like to start actual discussion with github until stackforge repo is created. * API discussion for consolidation consolidate multiple existing implementations * NFV meeting follow up * blueprint follow up * open discussion * add your items -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture
On Thu, Jun 19, 2014 at 11:05:53AM -0400, Terry Wilson wrote: > - Original Message - > > What's the progress by Terry Wilson? > > If not much, I'm willing to file blueprint/spec and drive it. > > > > thanks, > > I've been working on some proof-of-concept code to help flesh out ideas for > writing the spec. I'd talked to Maru and he mentioned that he didn't think > that the official OVS python library was a good base for this (the one that > ryu uses). I don't remember what all of the reasons were, though. It isn't > particularly well documented, but that can always be remedied. Does anyone > else have any experience with the official OVS python API who could speak to > its quality/stability/usefulness? It looked fairly full-featured. Interesting. Can you share the technical reason? Maru? I'm curious. At least I fixed the issues I hit when I wrote ovs_vsctl.py. Thanks, > Terry > > > On Wed, Jun 18, 2014 at 07:00:59PM +0900, > > Isaku Yamahata wrote: > > > > > Hi. Ryu provides ovs_vsctl.py library which is python equivalent to > > > ovs-vsctl command. It speaks OVSDB protocl. > > > https://github.com/osrg/ryu/blob/master/ryu/lib/ovs/vsctl.py > > > > > > So with the library, it's mostly mechanical change to convert > > > ovs_lib.py, I think. > > > I'm not aware other similar library written in python. > > Most of ryu's library is implemented on top of the official OVS python stuff: > https://github.com/openvswitch/ovs/tree/master/python/ovs > > Terry > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture
What's the progress by Terry Wilson? If not much, I'm willing to file blueprint/spec and drive it. thanks, On Wed, Jun 18, 2014 at 07:00:59PM +0900, Isaku Yamahata wrote: > Hi. Ryu provides ovs_vsctl.py library which is python equivalent to > ovs-vsctl command. It speaks OVSDB protocl. > https://github.com/osrg/ryu/blob/master/ryu/lib/ovs/vsctl.py > > So with the library, it's mostly mechanical change to convert > ovs_lib.py, I think. > I'm not aware other similar library written in python. > > thanks, > Isaku Yamahata > > > On Tue, Jun 17, 2014 at 11:38:36AM -0500, > Kyle Mestery wrote: > > > Another area of improvement for the agent would be to move away from > > executing CLIs for port commands and instead use OVSDB. Terry Wilson > > and I talked about this, and re-writing ovs_lib to use an OVSDB > > connection instead of the CLI methods would be a huge improvement > > here. I'm not sure if Terry was going to move forward with this, but > > I'd be in favor of this for Juno if he or someone else wants to move > > in this direction. > > > > Thanks, > > Kyle > > > > On Tue, Jun 17, 2014 at 11:24 AM, Salvatore Orlando > > wrote: > > > We've started doing this in a slightly more reasonable way for icehouse. > > > What we've done is: > > > - remove unnecessary notification from the server > > > - process all port-related events, either trigger via RPC or via monitor > > > in > > > one place > > > > > > Obviously there is always a lot of room for improvement, and I agree > > > something along the lines of what Zang suggests would be more maintainable > > > and ensure faster event processing as well as making it easier to have > > > some > > > form of reliability on event processing. > > > > > > I was considering doing something for the ovs-agent again in Juno, but > > > since > > > we've moving towards a unified agent, I think any new "big" ticket should > > > address this effort. > > > > > > Salvatore > > > > > > > > > On 17 June 2014 13:31, Zang MingJie wrote: > > >> > > >> Hi: > > >> > > >> Awesome! Currently we are suffering lots of bugs in ovs-agent, also > > >> intent to rebuild a more stable flexible agent. > > >> > > >> Taking the experience of ovs-agent bugs, I think the concurrency > > >> problem is also a very important problem, the agent gets lots of event > > >> from different greenlets, the rpc, the ovs monitor or the main loop. > > >> I'd suggest to serialize all event to a queue, then process events in > > >> a dedicated thread. The thread check the events one by one ordered, > > >> and resolve what has been changed, then apply the corresponding > > >> changes. If there is any error occurred in the thread, discard the > > >> current processing event, do a fresh start event, which reset > > >> everything, then apply the correct settings. > > >> > > >> The threading model is so important and may prevent tons of bugs in > > >> the future development, we should describe it clearly in the > > >> architecture > > >> > > >> > > >> On Wed, Jun 11, 2014 at 4:19 AM, Mohammad Banikazemi > > >> wrote: > > >> > Following the discussions in the ML2 subgroup weekly meetings, I have > > >> > added > > >> > more information on the etherpad [1] describing the proposed > > >> > architecture > > >> > for modular L2 agents. I have also posted some code fragments at [2] > > >> > sketching the implementation of the proposed architecture. Please have > > >> > a > > >> > look when you get a chance and let us know if you have any comments. > > >> > > > >> > [1] https://etherpad.openstack.org/p/modular-l2-agent-outline > > >> > [2] https://review.openstack.org/#/c/99187/ > > >> > > > >> > > > >> > ___ > > >> > 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 > > -- > Isaku Yamahata -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture
Hi. Ryu provides ovs_vsctl.py library which is python equivalent to ovs-vsctl command. It speaks OVSDB protocl. https://github.com/osrg/ryu/blob/master/ryu/lib/ovs/vsctl.py So with the library, it's mostly mechanical change to convert ovs_lib.py, I think. I'm not aware other similar library written in python. thanks, Isaku Yamahata On Tue, Jun 17, 2014 at 11:38:36AM -0500, Kyle Mestery wrote: > Another area of improvement for the agent would be to move away from > executing CLIs for port commands and instead use OVSDB. Terry Wilson > and I talked about this, and re-writing ovs_lib to use an OVSDB > connection instead of the CLI methods would be a huge improvement > here. I'm not sure if Terry was going to move forward with this, but > I'd be in favor of this for Juno if he or someone else wants to move > in this direction. > > Thanks, > Kyle > > On Tue, Jun 17, 2014 at 11:24 AM, Salvatore Orlando > wrote: > > We've started doing this in a slightly more reasonable way for icehouse. > > What we've done is: > > - remove unnecessary notification from the server > > - process all port-related events, either trigger via RPC or via monitor in > > one place > > > > Obviously there is always a lot of room for improvement, and I agree > > something along the lines of what Zang suggests would be more maintainable > > and ensure faster event processing as well as making it easier to have some > > form of reliability on event processing. > > > > I was considering doing something for the ovs-agent again in Juno, but since > > we've moving towards a unified agent, I think any new "big" ticket should > > address this effort. > > > > Salvatore > > > > > > On 17 June 2014 13:31, Zang MingJie wrote: > >> > >> Hi: > >> > >> Awesome! Currently we are suffering lots of bugs in ovs-agent, also > >> intent to rebuild a more stable flexible agent. > >> > >> Taking the experience of ovs-agent bugs, I think the concurrency > >> problem is also a very important problem, the agent gets lots of event > >> from different greenlets, the rpc, the ovs monitor or the main loop. > >> I'd suggest to serialize all event to a queue, then process events in > >> a dedicated thread. The thread check the events one by one ordered, > >> and resolve what has been changed, then apply the corresponding > >> changes. If there is any error occurred in the thread, discard the > >> current processing event, do a fresh start event, which reset > >> everything, then apply the correct settings. > >> > >> The threading model is so important and may prevent tons of bugs in > >> the future development, we should describe it clearly in the > >> architecture > >> > >> > >> On Wed, Jun 11, 2014 at 4:19 AM, Mohammad Banikazemi > >> wrote: > >> > Following the discussions in the ML2 subgroup weekly meetings, I have > >> > added > >> > more information on the etherpad [1] describing the proposed > >> > architecture > >> > for modular L2 agents. I have also posted some code fragments at [2] > >> > sketching the implementation of the proposed architecture. Please have a > >> > look when you get a chance and let us know if you have any comments. > >> > > >> > [1] https://etherpad.openstack.org/p/modular-l2-agent-outline > >> > [2] https://review.openstack.org/#/c/99187/ > >> > > >> > > >> > ___ > >> > 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture
t;> > Salvatore > >> > > >> > > >> > On 17 June 2014 13:31, Zang MingJie wrote: > >> >> > >> >> Hi: > >> >> > >> >> Awesome! Currently we are suffering lots of bugs in ovs-agent, also > >> >> intent to rebuild a more stable flexible agent. > >> >> > >> >> Taking the experience of ovs-agent bugs, I think the concurrency > >> >> problem is also a very important problem, the agent gets lots of event > >> >> from different greenlets, the rpc, the ovs monitor or the main loop. > >> >> I'd suggest to serialize all event to a queue, then process events in > >> >> a dedicated thread. The thread check the events one by one ordered, > >> >> and resolve what has been changed, then apply the corresponding > >> >> changes. If there is any error occurred in the thread, discard the > >> >> current processing event, do a fresh start event, which reset > >> >> everything, then apply the correct settings. > >> >> > >> >> The threading model is so important and may prevent tons of bugs in > >> >> the future development, we should describe it clearly in the > >> >> architecture > >> >> > >> >> > >> >> On Wed, Jun 11, 2014 at 4:19 AM, Mohammad Banikazemi > >> >> wrote: > >> >> > Following the discussions in the ML2 subgroup weekly meetings, I have > >> >> > added > >> >> > more information on the etherpad [1] describing the proposed > >> >> > architecture > >> >> > for modular L2 agents. I have also posted some code fragments at [2] > >> >> > sketching the implementation of the proposed architecture. Please > >> >> > have a > >> >> > look when you get a chance and let us know if you have any comments. > >> >> > > >> >> > [1] https://etherpad.openstack.org/p/modular-l2-agent-outline > >> >> > [2] https://review.openstack.org/#/c/99187/ > >> >> > > >> >> > > >> >> > ___ > >> >> > 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 > >> > > > > > > ___ > > 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][ServiceVM] servicevm IRC meeting reminder (June 17 Tuesday 5:00(AM)UTC-)
Hi. This is a reminder mail for the servicevm IRC meeting June 17, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode https://wiki.openstack.org/wiki/Meetings/ServiceVM Maybe some won't make it because of mid-cycle meet up, though. agenda: (feel free to add your items) * announcement * action items from the last week * project incubation * NFV meeting follow up * blueprint follow up * open discussion -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][ServiceVM] servicevm IRC meeting minutes (June 10 Tuesday 5:00(AM)UTC-)
Meeting minutes of June 10 * Announcement - started to create repos in stackforge review is on-going * nfv follow up blueprints - VLAN-aware-VLAN, l2-gateway, network-truncking https://review.openstack.org/#/c/97714/ https://review.openstack.org/#/c/94612/ https://blueprints.launchpad.net/neutron/+spec/l2-gateway ACTION: yamahata update BP, see how review goes unless eric does. (yamahata, 05:13:45) ACTION: s3wong ping rossella_s (yamahata, 05:13:57) - unfirewall port https://review.openstack.org/97715 (yamahata, 05:15:21) => collect use case/requirements on neutron ports ACTION: anyone update wiki page with usecase/requirement (yamahata, 05:28:43) https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes (yamahata, 05:28:06) * open discussion (yamahata, 05:37:12) some ideas relationship with NFV team thanks, On Mon, Jun 09, 2014 at 03:16:27PM +0900, Isaku Yamahata wrote: > Hi. This is a reminder mail for the servicevm IRC meeting > June 10, 2014 Tuesdays 5:00(AM)UTC- > #openstack-meeting on freenode > https://wiki.openstack.org/wiki/Meetings/ServiceVM > > agenda: (feel free to add your items) > * project incubation > * NFV meeting follow up > * open discussion > > -- > Isaku Yamahata -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][ServiceVM] servicevm IRC meeting reminder (June 10 Tuesday 5:00(AM)UTC-)
Hi. This is a reminder mail for the servicevm IRC meeting June 10, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode https://wiki.openstack.org/wiki/Meetings/ServiceVM agenda: (feel free to add your items) * project incubation * NFV meeting follow up * open discussion -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ServiceVM] IRC meeting minutes June 3, 2014 5:00(AM)UTC-)
Hi Dmitry. Thanks for your interest. What's your time zone? In fact we have already many time zones. http://lists.openstack.org/pipermail/openstack-dev/2014-March/030405.html If desirable, we could think about rotating timezones. Do you have specific items to discuss? We could also arrange ad-hoc irc meetings for specific topics. thanks, On Thu, Jun 05, 2014 at 05:58:53PM +0300, Dmitry wrote: > Hi Isaku, > In order to make possible to European audience to join ServiceVM meetings, > could you please to move it 2-3 hours later (7-8AM UTC)? > Thank you very much, > Dmitry > > > On Tue, Jun 3, 2014 at 10:00 AM, Isaku Yamahata > wrote: > > > Here is the meeting minutes of the meeting. > > > > ServiceVM/device manager > > meeting minutes on June 3, 2014: > > https://wiki.openstack.org/wiki/Meetings/ServiceVM > > > > next meeting: > > June 10, 2014 5:00AM UTC (Tuesday) > > > > agreement: > > - include NFV conformance to servicevm project into servicevm project > > => will continue discuss on nomenclature at gerrit. tacker-specs > > - we have to define the relationship between NFV team and servicevm team > > - consolidate floating implementations > > > > Action Items: > > - everyone add your name/bio to contributor of incubation page > > - yamahata create tacker-specs repo in stackforge for further discussion > > on terminology > > - yamahata update draft to include NFV conformance > > - s3wong look into vif creation/network connection > > - everyone review incubation page > > > > Detailed logs: > > > > http://eavesdrop.openstack.org/meetings/servicevm_device_manager/2014/servicevm_device_manager.2014-06-03-05.04.html > > > > http://eavesdrop.openstack.org/meetings/servicevm_device_manager/2014/servicevm_device_manager.2014-06-03-05.04.log.html > > > > thanks, > > -- > > Isaku Yamahata > > > > ___ > > 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation
AM, I have been entertaining the idea of creating an allocation > >>> >> agent that would manage the availability of IPs in memory rather than > >>> >> in the database. I hesitate, because that brings up a whole new set > >>> >> of complications. I'm sure there are other potential solutions that I > >>> >> haven't yet considered. > >>> >> > >>> >> The L3 subteam is currently working on a pluggable IPAM model. Once > >>> >> the initial framework for this is done, we can more easily play around > >>> >> with changing the underlying IPAM implementation. > >>> >> > >>> >> Thoughts? > >>> >> > >>> >> Carl > >>> >> > >>> >> On Thu, May 29, 2014 at 4:01 AM, Xurong Yang > >>> wrote: > >>> >> > Hi, Folks, > >>> >> > > >>> >> > When we configure VXLAN range [1,16M], neutron-server service costs > >>> long > >>> >> > time and cpu rate is very high(100%) when initiation. One test base > >>> on > >>> >> > postgresql has been verified: more than 1h when VXLAN range is [1, > >>> 1M]. > >>> >> > > >>> >> > So, any good solution about this performance issue? > >>> >> > > >>> >> > Thanks, > >>> >> > Xurong Yang > >>> >> > > >>> >> > > >>> >> > > >>> >> > ___ > >>> >> > 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 > >> > >> > > ___ > > 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ServiceVM] IRC meeting minutes June 3, 2014 5:00(AM)UTC-)
Here is the meeting minutes of the meeting. ServiceVM/device manager meeting minutes on June 3, 2014: https://wiki.openstack.org/wiki/Meetings/ServiceVM next meeting: June 10, 2014 5:00AM UTC (Tuesday) agreement: - include NFV conformance to servicevm project into servicevm project => will continue discuss on nomenclature at gerrit. tacker-specs - we have to define the relationship between NFV team and servicevm team - consolidate floating implementations Action Items: - everyone add your name/bio to contributor of incubation page - yamahata create tacker-specs repo in stackforge for further discussion on terminology - yamahata update draft to include NFV conformance - s3wong look into vif creation/network connection - everyone review incubation page Detailed logs: http://eavesdrop.openstack.org/meetings/servicevm_device_manager/2014/servicevm_device_manager.2014-06-03-05.04.html http://eavesdrop.openstack.org/meetings/servicevm_device_manager/2014/servicevm_device_manager.2014-06-03-05.04.log.html thanks, -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] ServiceVM IRC meeting(next: June 3rd Tuesday) 5:00(AM)UTC-)
Hi, this is just a reminder and a correction. The correct date is June 3rd Tuesday (Actual date for you depends on your timezone) June 3rd, 2014 Tuesdays 5:00(AM)UTC- <<<<<<<<<< (3rd is correct. not 2nd) on #openstack-meeting (May 20, 27 will be skipped). https://etherpad.openstack.org/p/servicevm https://wiki.openstack.org/wiki/Meetings/ServiceVM Sorry for confusion. thanks, On Mon, May 19, 2014 at 10:59:26PM +0900, Isaku Yamahata wrote: > Hi. This is a follow up mail of the design summit. > The next IRC meeting will be held on > June 2nd, 2014 Tuesdays 5:00(AM)UTC- > on #openstack-meeting > (May 20, 27 will be skipped). > https://etherpad.openstack.org/p/servicevm > https://wiki.openstack.org/wiki/Meetings/ServiceVM > > thanks, > -- > Isaku Yamahata -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input any consideration ?
Hi. At this moment, Neutron doesn't offer physical network information for now. There is a proposal for it[1] and it was discussed at the summit [2]. Although it is still early design phase[3][4], using routing protocol will surely help to discover physical network topology. [1] https://wiki.openstack.org/wiki/Topology-as-a-service [2] https://etherpad.openstack.org/p/hierarchical_network_topology [3] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035868.html [4] https://review.openstack.org/#/c/91275/ thanks, Isaku Yamahata On Fri, May 30, 2014 at 11:11:46AM +0200, Mathieu Rohon wrote: > I'm also very interested in scheduling VMs with Network requirement. This > seems to be in the scope of NFV workgroup [1]. > For instance, I think that scheduling should take into account bandwith/QoS > requirement for a VM, or specific Nic requirement for a VM (availability of > a SRIOV Vif on compute nodes). > > To do this, it seems that Neutron should report its available capacity (Vif > availability, bandwith availability) for each compute node, and Gantt > should take this reporting into account for scheduling. > > [1]https://etherpad.openstack.org/p/juno-nfv-bof > > > > On Fri, May 30, 2014 at 10:47 AM, jcsf wrote: > > > Sylvain, > > > > > > > > Thank you for the background ??? I will educate myself on this work. > > > > > > > > Thanks, > > > > John > > > > > > > > > > > > *From:* Sylvain Bauza [mailto:sba...@redhat.com] > > *Sent:* Friday, May 30, 2014 11:31 AM > > > > *To:* OpenStack Development Mailing List (not for usage questions) > > *Cc:* jcsf; 'Carl Baldwin'; 'A, Keshava' > > > > *Subject:* Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as > > input any consideration ? > > > > > > > > Le 30/05/2014 10:06, jcsf a écrit : > > > > Carl, > > > > > > > > A new routing protocol is certainly of great interest. Are you working > > with IETF or can you share more here? > > > > > > > > WRT:Nova Schedule - There still are requirements for the Schedule to > > taking into consideration network as a resource. My focus is to figure > > out how to add network capabilities to the Scheduler’s algorithm while > > still maintaining clean separation of concerns between Nova and Neutron. > > We wouldn’t want to get back into the nova-network situation. > > > > > > > > John > > > > > > As it was previously mentioned, there are already different kinds of > > grouping for VMs in Nova that probably don't require to add new > > network-specific features : > > - aggregates and user-facing AZs allow to define a common set of > > capabilities for physical hosts upon which you can boot VMs > > - ServerGroups with Affinity/Anti-Affinity filters allow you to enforce a > > certain level of network proximity for VMs > > > > > > Once that said, there is also another effort of forking the Nova Scheduler > > code into a separate project so that cross-projects scheduling could happen > > (and consequently Neutron could use it). This project is planned to be > > delivered by K release, and will be called Gantt. > > > > > > So, could you please mention which features do you need for Nova, so we > > could discuss that here before issuing a spec ? > > > > -Sylvain > > > > > > > > > > > > > > > > > > > > *From:* Carl Baldwin [mailto:c...@ecbaldwin.net ] > > *Sent:* Friday, May 30, 2014 12:05 AM > > *To:* A, Keshava > > *Cc:* jcsf31...@gmail.com; Armando M.; OpenStack Development Mailing List > > (not for usage questions); Kyle Mestery > > *Subject:* Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as > > input any consideration ? > > > > > > > > Keshava, > > > > > > > > How much of a problem is routing prefix fragmentation for you? > > Fragmentation causes routing table bloat and may reduce the performance of > > the routing table. It also increases the amount of information traded by > > the routing protocol. Which aspect(s) is (are) affecting you? Can you > > quantify this effect? > > > > > > > > A major motivation for my interest in employing a dynamic routing protocol > > within a datacenter is to enable IP mobility so that I don't need to worry > > about doing things like scheduling instances based on their IP addresses. > > Also, I believe that it can make floating ips more "flo
Re: [openstack-dev] Network-as-a-Service
On Mon, May 26, 2014 at 03:46:28PM +0400, Artem Shepelev wrote: > Hello, Isaku. Hi Artem. > I've read your mail on OpenStack maillist. > I'm a Google Summer of Code student who works on scheduler project. > For my project I need to build a true physical network topology for > optimal resource placement. > > I've done some research on methods of topology building. They are: > LLDP (CDP, etc.) and Network Tomography. > The first one has some limitations based on the equipment support. > > So I looked forward on Network Tomography. I've read some research > papers of unicast and multicast probing. The authors' experiments > showed good results, but no programs or sources I have found. > > I'm about to start work on it and looking forward for some ideas and > feedback. Interesting. Your work will be surely useful. The information which is got by your work can be used for many purpose. -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][ironic] topology as a service (physical network topology): design summit follow up
Hi. As discussed at the summit[1], there are much requirement for topology as a service that stores/provides information of physical network topology in one place. In order to make progress, I'd like to discuss issues which were raised at the summit. I also created etherpad page and wiki page for this[2][3]. - IRC meeting For starter, how about having IRC meeting? I propose this time slot June 4 Wednesday: 5:00am UTC- #openstack-meeting-3 My time zone is JST(UTC+9) - Should this service be a separated service from Neutron? Although I originally created blueprint/specs for neutron extension[4][5], it was argued that this service should be a separated service from neutron because it is useful not only for neutron, but also for nova, ironic, gantt and so on without neutron. To be honest I don't have strong opinion on this and I'm fine to start incubation process. Are there anyone who helps as core-reviewer? I need help for incubation process. Otherwise I have no choice except staying in Neutron. - TripleO link aggrigation > TripleO has a need to configure link aggregation. Will this > provide enough info/capability? - ChuckC Chuck, could you please elaborate on it and/or provide any pointers for it? http://lists.openstack.org/pipermail/openstack-dev/2014-February/026868.html I found only the pointer. As long as I understand from this link, what TripleO needs is something like - compute-node has multiple nics - those nics are connected to same switch - the configuration of the switch (properly configured) - API and data models are under review as [5] [1] https://etherpad.openstack.org/p/hierarchical_network_topology [2] https://wiki.openstack.org/wiki/Topology-as-a-service [3] https://etherpad.openstack.org/p/topology-as-a-service [4] https://blueprints.launchpad.net/neutron/+spec/physical-network-topology [5] https://review.openstack.org/#/c/91275/ thanks, -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
On Thu, May 22, 2014 at 11:40:02AM +0300, Dmitry wrote: > Hi Isaku, > Thank you for the updated link. I'n not sure where from I get the previous > one, probably from the direct Google search. > If we're talking about NFV Mano, it's very important to keep NFVO and VNFM > as a separate services, where VNFM might be (and probably will be) supplied > jointly with a vendor's specific VNF. Can you please point the public documentations that describes those terminology and architecture? The pptx slide you pointed out below describes only the overview. The public documents I can find, ETSO GS NFV 001,002,003,004, NFV-PER002 and white paper describes them in very high level. > In addition, it's possible that VNFC components will not be able to be > placed on the same machine - anti-affinity rules. > Talking in NFV terminology, we need to have a new OpenStack Services which > (from what I've understood from the document you sent) is called Adv > Service and is responsible to be: Probably it will corresponds to vm/service scheduler. Eventually it would be integrated into Gantt. > 1) NFVO - which is using Nova to provision new Service VMs and Neutron to > establish connectivity and service chaining > 2) Service Catalog - to accommodate multiple VNF services. Question: the > same problem exists with Trove which need a catalog for multiple concrete > DB implementations. Do you know which solution they will take for Juno? Regarding to Trove, I don't know. Any Trove developer, can you comment on it? > 2) Infrastructure for VNFM plugins - which will be called by NFVO to decide > where Service VM should be placed and which LSI should be provisioned on > these Service VMs. I don't know what VNFM plugins means. Can you please elaborate it? > This flow is more or less what was stated by NFV committee. Where is publicly available documents that describe it? > Please let me know what you think about this and how far is that from what > you planed for Service VM. The first things to do is to clarify the requirement of NFV and to unify the terminology(or something like terminology conversion matrix). and then analyze the gap. The first target of servicevm is to address the case of single function in single VM(VNFC in NFV terminology?). Then evolve the implementation for more complex case like forwarding graph (VNF and VNF-FG in NFV terminology?). > In addition, I would happy to know if Service VM will be incubated for Juno > release. Yea, I'm going to create the first repo in stackforge in one or two weeks. thanks, Isaku Yamahata > Thank you very much, > Dmitry > > > > On Thu, May 22, 2014 at 9:28 AM, Isaku Yamahata > wrote: > > > On Wed, May 21, 2014 at 10:54:03AM +0300, > > Dmitry wrote: > > > > > HI, > > > > Hi. > > > > > I would happy to get explanation of what is the difference between Adv > > > Service Management< > > https://docs.google.com/file/d/0Bz-bErEEHJxLTGY4NUVvTzRDaEk/edit>from > > > the Service VM > > > > The above document is stale. > > the right one is > > > > https://docs.google.com/document/d/1pwFVV8UavvQkBz92bT-BweBAiIZoMJP0NPAO4-60XFY/edit?pli=1 > > > > https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn1ZduCA/edit?pli=1# > > https://wiki.openstack.org/wiki/ServiceVM > > > > Anyway how did you find the link? I'd like to remove stale links. > > > > > > > and NFVO > > > orchestration< > > http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf>from > > > NFV Mano. > > > The most interesting part if service provider management as part of the > > > service catalog. > > > > servicevm corresponds to (a part of) NFV orchestrator and VNF manager. > > Especially life cycle management of VMs/services. configuration of > > services. > > I think the above document and the NFV documents only give high level > > statement of components, right? > > > > thanks, > > > > > > > > Thanks, > > > Dmitry > > > > > > > > > On Wed, May 21, 2014 at 9:01 AM, Isaku Yamahata < > > isaku.yamah...@gmail.com>wrote: > > > > > > > Hi, I will also attend the NFV IRC meeting. > > > > > > > > thanks, > > > > Isaku Yamahata > > > > > > > > On Tue, May 20, 2014 at 01:23:22PM -0700, > > > > Stephen Wong wrote: > > > > > > > > > Hi, > > > > > > > > > > I am part of the ServiceVM team and I will attend the NFV IRC > > > > meetings. > >
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
On Fri, May 23, 2014 at 04:13:57PM +0900, "Ogaki, Kenichi" wrote: > Hi All, Hi. > I’m newbie to Openstack, so I want to clarify how OpenStack can implement > ETSI NFV Architecture. > > The concept of Advanced service looks like Network Service in ETSI NFV > Architecture as shown in Figure 3 below: > http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf > > As the functional role, VNF (Virtualized Network Function) may be > corespondent to Logical Service Instance. > However, in ETSI NFV Architecture, VNF is composed of VNFC (VNF Component) > or VDU (Virtual Deployment Unit) and each VNFC or VDU instance is deployed > as a VM. > These VNFC or VDU instances are connected by logical or physical network > links in a manner of a kind of service chaining, then a VNF instance is > created. > In the same manner, Network Service is created from one or multiple VNF(s). Hmm, we don't use same terminology. Is there any public documentation for those terminology? The public docuemnts I can find is too high-level to understand the requirement. The first target of servicevm project is to address the case of single service in single VM(VNFC in NFV terminology?) at first. Then evolve the implementation for more complex case with experiment. > My question is: > Is it possible that the current OpenStack components realize an advanced > service in the above manner? > Meaning, an advanced service is composed of hierarchical multiple VMs. I suspect no one knows. This is why we unite to make efforts for NFV. thanks, Isaku Yamahata > All the best, > Kenichi > > > > > From: Dmitry [mailto:mey...@gmail.com] > > Sent: Thursday, May 22, 2014 5:40 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit > > > > Hi Isaku, > > Thank you for the updated link. I'n not sure where from I get the previous > > one, probably from the direct Google search. > > If we're talking about NFV Mano, it's very important to keep NFVO and VNFM > > as a separate services, where VNFM might be (and probably will be) supplied > > jointly with a vendor's specific VNF. > > In addition, it's possible that VNFC components will not be able to be > > placed on the same machine - anti-affinity rules. > > Talking in NFV terminology, we need to have a new OpenStack Services which > > (from what I've understood from the document you sent) is called Adv > > Service and is responsible to be: > > 1) NFVO - which is using Nova to provision new Service VMs and Neutron to > > establish connectivity and service chaining > > 2) Service Catalog - to accommodate multiple VNF services. Question: the > > same problem exists with Trove which need a catalog for multiple concrete > > DB implementations. Do you know which solution they will take for Juno? > > 2) Infrastructure for VNFM plugins - which will be called by NFVO to > > decide where Service VM should be placed and which LSI should be > > provisioned on these Service VMs. > > > > This flow is more or less what was stated by NFV committee. > > > > Please let me know what you think about this and how far is that from what > > you planed for Service VM. > > In addition, I would happy to know if Service VM will be incubated for > > Juno release. > > > > Thank you very much, > > Dmitry > > > > > > > > On Thu, May 22, 2014 at 9:28 AM, Isaku Yamahata > > wrote: > > > > > > On Wed, May 21, 2014 at 10:54:03AM +0300, > > Dmitry wrote: > > > > > HI, > > > > Hi. > > > > > > > I would happy to get explanation of what is the difference > > between Adv > > > > > Service Management< > > https://docs.google.com/file/d/0Bz-bErEEHJxLTGY4NUVvTzRDaEk/edit>from > > > the Service VM > > > > The above document is stale. > > the right one is > > > > https://docs.google.com/document/d/1pwFVV8UavvQkBz92bT-BweBAiIZoMJP0NPAO4-60XFY/edit?pli=1 > > > > https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn1ZduCA/edit?pli=1# > > https://wiki.openstack.org/wiki/ServiceVM > > > > Anyway how did you find the link? I'd like to remove stale links. > > > > > > > and NFVO > > > orchestration< > > http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf>from > > > > > NFV Mano. > > > The most interestin
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
On Wed, May 21, 2014 at 10:54:03AM +0300, Dmitry wrote: > HI, Hi. > I would happy to get explanation of what is the difference between Adv > Service > Management<https://docs.google.com/file/d/0Bz-bErEEHJxLTGY4NUVvTzRDaEk/edit>from > the Service VM The above document is stale. the right one is https://docs.google.com/document/d/1pwFVV8UavvQkBz92bT-BweBAiIZoMJP0NPAO4-60XFY/edit?pli=1 https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn1ZduCA/edit?pli=1# https://wiki.openstack.org/wiki/ServiceVM Anyway how did you find the link? I'd like to remove stale links. > and NFVO > orchestration<http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf>from > NFV Mano. > The most interesting part if service provider management as part of the > service catalog. servicevm corresponds to (a part of) NFV orchestrator and VNF manager. Especially life cycle management of VMs/services. configuration of services. I think the above document and the NFV documents only give high level statement of components, right? thanks, > > Thanks, > Dmitry > > > On Wed, May 21, 2014 at 9:01 AM, Isaku Yamahata > wrote: > > > Hi, I will also attend the NFV IRC meeting. > > > > thanks, > > Isaku Yamahata > > > > On Tue, May 20, 2014 at 01:23:22PM -0700, > > Stephen Wong wrote: > > > > > Hi, > > > > > > I am part of the ServiceVM team and I will attend the NFV IRC > > meetings. > > > > > > Thanks, > > > - Stephen > > > > > > > > > On Tue, May 20, 2014 at 8:59 AM, Chris Wright > > wrote: > > > > > > > * balaj...@freescale.com (balaj...@freescale.com) wrote: > > > > > > -Original Message- > > > > > > From: Kyle Mestery [mailto:mest...@noironetworks.com] > > > > > > Sent: Tuesday, May 20, 2014 12:19 AM > > > > > > To: OpenStack Development Mailing List (not for usage questions) > > > > > > Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design > > summit > > > > > > > > > > > > On Mon, May 19, 2014 at 1:44 PM, Ian Wells > > > > > > > > wrote: > > > > > > > I think the Service VM discussion resolved itself in a way that > > > > > > > reduces the problem to a form of NFV - there are standing issues > > > > using > > > > > > > VMs for services, orchestration is probably not a responsibility > > that > > > > > > > lies in Neutron, and as such the importance is in identifying the > > > > > > > problems with the plumbing features of Neutron that cause > > > > > > > implementation difficulties. The end result will be that VMs > > > > > > > implementing tenant services and implementing NFV should be much > > the > > > > > > > same, with the addition of offering a multitenant interface to > > > > > > Openstack users on the tenant service VM case. > > > > > > > > > > > > > > Geoff Arnold is dealing with the collating of information from > > people > > > > > > > that have made the attempt to implement service VMs. The problem > > > > > > > areas should fall out of his effort. I also suspect that the key > > > > > > > points of NFV that cause problems (for instance, dealing with > > VLANs > > > > > > > and trunking) will actually appear quite high up the service VM > > list > > > > as > > > > > > well. > > > > > > > -- > > > > > > There is a weekly meeting for the Service VM project [1], I hope > > some > > > > > > representatives from the NFB sub-project can make it to this > > meeting > > > > and > > > > > > participate there. > > > > > [P Balaji-B37839] I agree with Kyle, so that we will have enough > > synch > > > > between Service VM and NFV goals. > > > > > > > > Makes good sense. Will make sure to get someone there. > > > > > > > > thanks, > > > > -chris > > > > > > > > ___ > > > > 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 > > > > > > -- > > Isaku Yamahata > > > > ___ > > 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
Hi, I will also attend the NFV IRC meeting. thanks, Isaku Yamahata On Tue, May 20, 2014 at 01:23:22PM -0700, Stephen Wong wrote: > Hi, > > I am part of the ServiceVM team and I will attend the NFV IRC meetings. > > Thanks, > - Stephen > > > On Tue, May 20, 2014 at 8:59 AM, Chris Wright wrote: > > > * balaj...@freescale.com (balaj...@freescale.com) wrote: > > > > -Original Message- > > > > From: Kyle Mestery [mailto:mest...@noironetworks.com] > > > > Sent: Tuesday, May 20, 2014 12:19 AM > > > > To: OpenStack Development Mailing List (not for usage questions) > > > > Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit > > > > > > > > On Mon, May 19, 2014 at 1:44 PM, Ian Wells > > > > wrote: > > > > > I think the Service VM discussion resolved itself in a way that > > > > > reduces the problem to a form of NFV - there are standing issues > > using > > > > > VMs for services, orchestration is probably not a responsibility that > > > > > lies in Neutron, and as such the importance is in identifying the > > > > > problems with the plumbing features of Neutron that cause > > > > > implementation difficulties. The end result will be that VMs > > > > > implementing tenant services and implementing NFV should be much the > > > > > same, with the addition of offering a multitenant interface to > > > > Openstack users on the tenant service VM case. > > > > > > > > > > Geoff Arnold is dealing with the collating of information from people > > > > > that have made the attempt to implement service VMs. The problem > > > > > areas should fall out of his effort. I also suspect that the key > > > > > points of NFV that cause problems (for instance, dealing with VLANs > > > > > and trunking) will actually appear quite high up the service VM list > > as > > > > well. > > > > > -- > > > > There is a weekly meeting for the Service VM project [1], I hope some > > > > representatives from the NFB sub-project can make it to this meeting > > and > > > > participate there. > > > [P Balaji-B37839] I agree with Kyle, so that we will have enough synch > > between Service VM and NFV goals. > > > > Makes good sense. Will make sure to get someone there. > > > > thanks, > > -chris > > > > ___ > > 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] ServiceVM IRC meeting(next: June 2nd Tuesday 5:00(AM)UTC-)
Hi. This is a follow up mail of the design summit. The next IRC meeting will be held on June 2nd, 2014 Tuesdays 5:00(AM)UTC- on #openstack-meeting (May 20, 27 will be skipped). https://etherpad.openstack.org/p/servicevm https://wiki.openstack.org/wiki/Meetings/ServiceVM thanks, -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] ServiceVM IRC meeting minutes May 6 (was Re: [Neutron] ServiceVM IRC meeting(May 6 Tuesday 5:00(AM)UTC-))
Hi. The document is - public on the web - anyone can comment So I don't think it's due to setting of google-doc. On Wed, May 07, 2014 at 09:31:49PM +0800, neutrondev wrote: > hello, > > > Is there anyone may kindly send me the content of this meeting, i can not > visit docs.google.com in China. > >url: > https://docs.google.com/presentation/d/14dvV3S9Eph2z-auk34I_Ftld-lHA3VMoyNWAPRTeWgE/edit?usp=sharing > > > many thanks! > > > > > > > > > > At 2014-05-06 14:54:09,"Isaku Yamahata" wrote: > >Here's the minute. > >The May 13 will be skipped. The next meeting is on May 20. > >bmelanda, hareesh, if you have items for session agenda, > >please update ether and replay this mail. > > > >AGREED: unconference Monday 5pm- at the summit > >ACTION: whoever goes to the unconference board and secure the room > >ACTION: yamahata update the etherpad for the session > >ACTION: bmelanda, hareeshpc update session adgenda in etherpad > >ACTION: bmelanda, yamahata add terminology > >https://wiki.openstack.org/wiki/ServiceVM/terminology for convergence > > > >LINK: https://etherpad.openstack.org/p/servicevm > >LINK: https://wiki.openstack.org/wiki/ServiceVM/terminology > >LINK: https://wiki.openstack.org/wiki/ServiceVM > > > >lots of short-term gap-filler discussion > > > >thanks, > >Isaku Yamahata > > > >On Fri, May 02, 2014 at 02:01:31PM +0900, > >Isaku Yamahata wrote: > > > >> Hi. This is a reminder mail for the servicevm IRC meeting > >> May 6, 2014 Tuesdays 5:00(AM)UTC- > >> #openstack-meeting on freenode > >> (May 13 will be skipped due to design summit) > >> > >> * design summit plan > >> - unconference > >> * status update > >> * new project planning > >> - project name > >> code name: virtue, ginie, jeeve,... > >> topic name: servicevm, hosting device,... > >> - design API/model > >> - way to review: gerrit or google-doc? > >> - design strategy > >> * open discussion > >> -- > >> Isaku Yamahata > > > >-- > >Isaku Yamahata > > > >___ > >OpenStack-dev mailing list > >OpenStack-dev@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] ServiceVM IRC meeting minutes May 6 (was Re: [Neutron] ServiceVM IRC meeting(May 6 Tuesday 5:00(AM)UTC-))
Here's the minute. The May 13 will be skipped. The next meeting is on May 20. bmelanda, hareesh, if you have items for session agenda, please update ether and replay this mail. AGREED: unconference Monday 5pm- at the summit ACTION: whoever goes to the unconference board and secure the room ACTION: yamahata update the etherpad for the session ACTION: bmelanda, hareeshpc update session adgenda in etherpad ACTION: bmelanda, yamahata add terminology https://wiki.openstack.org/wiki/ServiceVM/terminology for convergence LINK: https://etherpad.openstack.org/p/servicevm LINK: https://wiki.openstack.org/wiki/ServiceVM/terminology LINK: https://wiki.openstack.org/wiki/ServiceVM lots of short-term gap-filler discussion thanks, Isaku Yamahata On Fri, May 02, 2014 at 02:01:31PM +0900, Isaku Yamahata wrote: > Hi. This is a reminder mail for the servicevm IRC meeting > May 6, 2014 Tuesdays 5:00(AM)UTC- > #openstack-meeting on freenode > (May 13 will be skipped due to design summit) > > * design summit plan > - unconference > * status update > * new project planning > - project name > code name: virtue, ginie, jeeve,... > topic name: servicevm, hosting device,... > - design API/model > - way to review: gerrit or google-doc? > - design strategy > * open discussion > -- > Isaku Yamahata -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] ServiceVM IRC meeting(May 6 Tuesday 5:00(AM)UTC-)
Hi. This is a reminder mail for the servicevm IRC meeting May 6, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode (May 13 will be skipped due to design summit) * design summit plan - unconference * status update * new project planning - project name code name: virtue, ginie, jeeve,... topic name: servicevm, hosting device,... - design API/model - way to review: gerrit or google-doc? - design strategy * open discussion -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Service VMs
Hi Balaji. Although I don't have specific opinion on name itself, can you share its origin? googlability for virtue seems okay, but I'm bit worried about legal stuff. thanks, On Thu, Apr 24, 2014 at 05:55:43AM +, "balaj...@freescale.com" wrote: > +1 for the proposal to make it as separate project. > > Can we name it as 'Virtue'!!. > > Any suggestions/comments. > > Regards, > Balaji.P > > > -Original Message- > > From: Kyle Mestery [mailto:mest...@noironetworks.com] > > Sent: Wednesday, April 23, 2014 7:17 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Cc: isaku yamahata > > Subject: Re: [openstack-dev] [neutron] Service VMs > > > > On Tue, Apr 22, 2014 at 5:49 PM, Isaku Yamahata > > wrote: > > > Hi. Keyle, thank you for starting this discussion to make progress. > > > > > > On Mon, Apr 21, 2014 at 08:41:19PM -0500, Kyle Mestery > > > wrote: > > > > > >> On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann > > >> wrote: > > >> > On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery > > wrote: > > >> >> For the upcoming Summit there are 3 sessions filed around "Service > > >> >> VMs" in Neutron. After discussing this with a few different > > >> >> people, I'd like to propose the idea that the "Service VM" work be > > >> >> moved out of Neutron and into it's own project on stackforge. > > >> >> There are a few reasons for this: > > >> > > > >> > How long do you anticipate the project needing to live on > > >> > stackforge before it can move to a place where we can introduce > > >> > symmetric gating with the projects that use it? > > > > > > To be honest, I'm not sure how long it will take. We will see after > > > the summit. > > > At this point, my feeling is > > > - before the summit, preliminary discussion, preparation for the > > > summit > > > - discuss at the summit (including project name?) > > > - after the summit, create its own project on stackforge and start > > > its own activity like weekly IRC meeting. > > > import neutron code repo as the first code base, and > > cleaning/stripping > > > it up and so on. > > > > > > What do you think? > > > > > I think this is a good starting plan. > > > > > > > >> The patches for this (look at the BP here [1]) have been in review > > >> for a while now as WIP. I think it's reasonable to expect that moving > > >> this to stackforge would let the authors and others interested > > >> collaborate faster. I expect this would take a cycle on stackforge > > >> before we could talk about other projects using this. But honestly, > > >> that's a better question for Isaku and Bob. > > > > > > In fact, this is not the first time that such opinion is claimed. > > > But this is the first time to get much feedback. > > > It's good timing to give it a consideration. > > > > > > Just to make it clear, the session slot will be allocated to discuss > > > on this? At least it would be valuable to share the current status and > > > to discuss on its future direction, and which part will be separated > > > out and which part will remain in Neutron. > > > > > Yes, I will keep this summit session so we can discuss it in Atlanta and > > move forward from there. > > > > > > > >> > Who is going to drive the development work? > > >> > > > >> For that, I'm thinking Isaku and Bob (copied above) would be the ones > > >> driving it. But anyone else who is interested should feel free to > > >> jump in as well. > > > > > > I'm willing to take the responsibility (and to share it with Bob). > > > Also others to help are very welcome. > > > > > > thanks, > > > > > >> Thanks, > > >> Kyle > > >> > > >> [1] > > >> https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms > > >> > > >> > Doug > > >> > > > >> >> > > >> >> 1. There is nothing Neutron specific about service VMs. > > >> >> 2. Service VMs can perform services for other OpenStack projects. > > >> >> 3. The code is quite large and may be better served b
Re: [openstack-dev] [neutron] Service VMs
Hi. Keyle, thank you for starting this discussion to make progress. On Mon, Apr 21, 2014 at 08:41:19PM -0500, Kyle Mestery wrote: > On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann > wrote: > > On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery > > wrote: > >> For the upcoming Summit there are 3 sessions filed around "Service > >> VMs" in Neutron. After discussing this with a few different people, > >> I'd like to propose the idea that the "Service VM" work be moved out > >> of Neutron and into it's own project on stackforge. There are a few > >> reasons for this: > > > > How long do you anticipate the project needing to live on stackforge > > before it can move to a place where we can introduce symmetric gating > > with the projects that use it? To be honest, I'm not sure how long it will take. We will see after the summit. At this point, my feeling is - before the summit, preliminary discussion, preparation for the summit - discuss at the summit (including project name?) - after the summit, create its own project on stackforge and start its own activity like weekly IRC meeting. import neutron code repo as the first code base, and cleaning/stripping it up and so on. What do you think? > The patches for this (look at the BP here [1]) have been in review for > a while now as WIP. I think it's reasonable to expect that moving this > to stackforge would let the authors and others interested collaborate > faster. I expect this would take a cycle on stackforge before we could > talk about other projects using this. But honestly, that's a better > question for Isaku and Bob. In fact, this is not the first time that such opinion is claimed. But this is the first time to get much feedback. It's good timing to give it a consideration. Just to make it clear, the session slot will be allocated to discuss on this? At least it would be valuable to share the current status and to discuss on its future direction, and which part will be separated out and which part will remain in Neutron. > > Who is going to drive the development work? > > > For that, I'm thinking Isaku and Bob (copied above) would be the ones > driving it. But anyone else who is interested should feel free to jump > in as well. I'm willing to take the responsibility (and to share it with Bob). Also others to help are very welcome. thanks, > Thanks, > Kyle > > [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms > > > Doug > > > >> > >> 1. There is nothing Neutron specific about service VMs. > >> 2. Service VMs can perform services for other OpenStack projects. > >> 3. The code is quite large and may be better served being inside it's > >> own project. > >> > >> Moving the work out of Neutron and into it's own project would allow > >> for separate velocity for this project, and for code to be shared for > >> the Service VM work for things other than Neutron services. > >> > >> I'm starting this email thread now to get people's feedback on this > >> and see what comments other have. I've specifically copied Isaku and > >> Bob, who both filed summit sessions on this and have done a lot of > >> work in this area to date. > >> > >> Thanks, > >> 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [olso][neutron] proxying oslo.messaging from management network into tenant network/VMs
> Also, how are you proposing to deal with live migration of VMs ? The > virtio serial channel can get closed due to QEMU migrating while the > proxy is in the middle of sending data to the guest VM, potentially > causing a lost or mangled message in the guest and the sender won't > know this if this channel write-only since there's no ACK. Basically agent in host will takes care of it. Probably it periodically pushes necessary information into guest agent. In Neutron case, the existing neutron agents in host already observe message loss/reorder, so the situation doesn't get worse with this proposal > What sort of things are you expecting the guest agent todo for Neutron ? It depends on what network service guest agents provides. For example In case of firewall, update iptables, update routing tables and so on in case of loadbalancer, start/stop haproxy with new configuration neutron server sends message for configuration change. - guest agents update setting/configuration on new request For example, user changes firewall rules, the requested change is pushed to the agent. guest agent sends messages to neutron server for maintenance. - status report: update stats/agent liveness In case of loadbalancer example, the loadbalancer needs to report its status(active/slave) to neutron server. then reaction will be taken. - periodically get the current configuration for message reorder/loss agents needs to poll and resync its configuration in case that the agent local configuration is out of sync with what neutron server thinks. thanks, Isaku Yamahata On Thu, Apr 10, 2014 at 2:11 AM, Daniel P. Berrange wrote: > On Wed, Apr 09, 2014 at 05:33:49PM +0900, Isaku Yamahata wrote: >> Hello developers. >> >> >> As discussed many times so far[1], there are many projects that needs >> to propagate RPC messages into VMs running on OpenStack. Neutron in my case. >> >> My idea is to relay RPC messages from management network into tenant >> network over file-like object. By file-like object, I mean virtio-serial, >> unix domain socket, unix pipe and so on. >> I've wrote some code based on oslo.messaging[2][3] and a documentation >> on use cases.[4][5] >> Only file-like transport and proxying messages would be in oslo.messaging >> and agent side code wouldn't be a part of oslo.messaging. >> >> >> use cases:([5] for more figures) >> file-like object: virtio-serial, unix domain socket, unix pipe >> >> server <-> AMQP <-> agent in host <-virtio serial-> guest agent in VM >> per VM >> >> server <-> AMQP <-> agent in host <-unix socket/pipe-> >> agent in tenant network <-> guest agent in VM >> >> >> So far there are security concerns to forward oslo.messaging from management >> network into tenant network. One approach is to allow only cast-RPC from >> server to guest agent in VM so that guest agent in VM only receives messages >> and can't send anything to servers. With unix pipe, it's write-only >> for server, read-only for guest agent. >> >> Thoughts? comments? > > I'm still somewhat aprehensive about the idea of just proxying arbitrary > data betwetween host & guest agent at the message bus protocol level. > I'd tend to be more comfortable with some that going through the virt > driver API in the compute node. > > Also, how are you proposing to deal with live migration of VMs ? The > virtio serial channel can get closed due to QEMU migrating while the > proxy is in the middle of sending data to the guest VM, potentially > causing a lost or mangled message in the guest and the sender won't > know this if this channel write-only since there's no ACK. > >> Details of Neutron NFV use case[6]: >> Neutron services so far typically runs agents in host, the host agent >> in host receives RPCs from neutron server, then it executes necessary >> operations. Sometimes the agent in host issues RPC to neutron server >> periodically.(e.g. status report etc) >> It's desirable to make such services virtualized as Network Function >> Virtualizaton(NFV), i.e. make those features run in VMs. So it's quite >> natural approach to propagate those RPC message into agents into VMs. > > What sort of things are you expecting the guest agent todo for Neutron ? > You have to bear in mind that the guest OS is 100% untrusted from the > hosts POV, so anything that Neutron asks the guest agent todo can be > completely ignored, or manipulated in any way the guest OS decides to. > Similarly, if there were a feedback channel, any data the Neutron might > receive back from the gu
Re: [openstack-dev] [olso][neutron] proxying oslo.messaging from management network into tenant network/VMs
Hello Dmitry. Thank you for reply. On Wed, Apr 09, 2014 at 03:19:10PM +0400, Dmitry Mescheryakov wrote: > Hello Isaku, > > Thanks for sharing this! Right now in Sahara project we think to use > Marconi as a mean to communicate with VM. Seems like you are familiar > with the discussions happened so far. If not, please see links at the > bottom of UnifiedGuestAgent [1] wiki page. In short we see Marconi's > supports for multi-tenancy as a huge advantage over other MQ > solutions. Our agent is network-based, so tenant isolation is a real > issue here. For clarity, here is the overview scheme of network based > agent: > > server <-> MQ (Marconi) <-> agent > > All communication goes over network. I've made a PoC of the Marconi > driver for oslo.messaging, you can find it at [2] I'm not familiar with Marconi, so please enlighten me first. How does MQ(Marconi) communicates both to management network and tenant network? Does it work with Neutron network? not nova-network. Neutron network isolates not only tenant networks each other, but also management network at L2. So openstack servers can't send any packets to VMs. VMs can't to openstack servers. This is the reason why neutron introduced HTTP proxy for instance metadata. It is also the reason why I choose to introduce new agent on host. If Marconi (or other porjects like sahara) already solved those issues, that's great. > We also considered 'hypervisor-dependent' agents (as I called them in > the initial thread) like the one you propose. They also provide tenant > isolation. But the drawback is _much_ bigger development cost and more > fragile and complex deployment. > > In case of network-based agent all the code is > * Marconi driver for RPC library (oslo.messaging) > * thin client for server to make calls > * a guest agent with thin server-side > If you write your agent on python, it will work on any OS with any > host hypervisor. > > > For hypervisor dependent-agent it becomes much more complex. You need > one more additional component - a proxy-agent running on Compute host, > which makes deployment harder. You also need to support various > transports for various hypervisors: virtio-serial for KVM, XenStore > for Xen, something for Hyper-V, etc. Moreover guest OS must have > driver for these transports and you will probably need to write > different implementation for different OSes. > > Also you mention that in some cases a second proxy-agent is needed and > again in some cases only cast operations could be used. Using cast > only is not an option for Sahara, as we do need feedback from the > agent and sometimes getting the return value is the main reason to > make an RPC call. > > I didn't see a discussion in Neutron on which approach to use (if it > was, I missed it). I see simplicity of network-based agent as a huge > advantage. Could you please clarify why you've picked design depending > on hypervisor? I agree those arguments. But I don't see how network-based agent approach works with Neutron network for now. Can you please elaborate on it? thanks, > Thanks, > > Dmitry > > > [1] https://wiki.openstack.org/wiki/UnifiedGuestAgent > [2] https://github.com/dmitrymex/oslo.messaging > > 2014-04-09 12:33 GMT+04:00 Isaku Yamahata : > > Hello developers. > > > > > > As discussed many times so far[1], there are many projects that needs > > to propagate RPC messages into VMs running on OpenStack. Neutron in my case. > > > > My idea is to relay RPC messages from management network into tenant > > network over file-like object. By file-like object, I mean virtio-serial, > > unix domain socket, unix pipe and so on. > > I've wrote some code based on oslo.messaging[2][3] and a documentation > > on use cases.[4][5] > > Only file-like transport and proxying messages would be in oslo.messaging > > and agent side code wouldn't be a part of oslo.messaging. > > > > > > use cases:([5] for more figures) > > file-like object: virtio-serial, unix domain socket, unix pipe > > > > server <-> AMQP <-> agent in host <-virtio serial-> guest agent in VM > > per VM > > > > server <-> AMQP <-> agent in host <-unix socket/pipe-> > > agent in tenant network <-> guest agent in VM > > > > > > So far there are security concerns to forward oslo.messaging from management > > network into tenant network. One approach is to allow only cast-RPC from > > server to guest agent in VM so that guest agent in VM only receives messages > > and can't send anything to serv
[openstack-dev] [olso][neutron] proxying oslo.messaging from management network into tenant network/VMs
Hello developers. As discussed many times so far[1], there are many projects that needs to propagate RPC messages into VMs running on OpenStack. Neutron in my case. My idea is to relay RPC messages from management network into tenant network over file-like object. By file-like object, I mean virtio-serial, unix domain socket, unix pipe and so on. I've wrote some code based on oslo.messaging[2][3] and a documentation on use cases.[4][5] Only file-like transport and proxying messages would be in oslo.messaging and agent side code wouldn't be a part of oslo.messaging. use cases:([5] for more figures) file-like object: virtio-serial, unix domain socket, unix pipe server <-> AMQP <-> agent in host <-virtio serial-> guest agent in VM per VM server <-> AMQP <-> agent in host <-unix socket/pipe-> agent in tenant network <-> guest agent in VM So far there are security concerns to forward oslo.messaging from management network into tenant network. One approach is to allow only cast-RPC from server to guest agent in VM so that guest agent in VM only receives messages and can't send anything to servers. With unix pipe, it's write-only for server, read-only for guest agent. Thoughts? comments? Details of Neutron NFV use case[6]: Neutron services so far typically runs agents in host, the host agent in host receives RPCs from neutron server, then it executes necessary operations. Sometimes the agent in host issues RPC to neutron server periodically.(e.g. status report etc) It's desirable to make such services virtualized as Network Function Virtualizaton(NFV), i.e. make those features run in VMs. So it's quite natural approach to propagate those RPC message into agents into VMs. [1] https://wiki.openstack.org/wiki/UnifiedGuestAgent [2] https://review.openstack.org/#/c/77862/ [3] https://review.openstack.org/#/c/77863/ [4] https://blueprints.launchpad.net/oslo.messaging/+spec/message-proxy-server [5] https://wiki.openstack.org/wiki/Oslo/blueprints/message-proxy-server [6] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] servicevm: weekly servicevm IRC meeting(April 8, 2014)
Hi. This is a reminder mail for the servicevm IRC meeting April 8, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode - status update - details of dividing the blueprints (Sorry I'm going to write it up from now on.) - design summit plan -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] servicevm: weekly servicevm IRC meeting
Hi. This is a reminder mail for the servicevm IRC meeting April 1, 2014 Tuesdays 5:00(AM)UTC- - status update - dividing the blueprints into smaller elemental ones -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] advanced servicevm framework: meeting time slot proposal 5:00UTC (Tue) and minutes (was Re: [Neutron] advanced servicevm framework IRC meeting March 18(Tuesday) 23:00 UTC)
* Time slot Weekly Tuesday 5:00UTC- Next meeting: March 24, 5:00UTC- Since there were many requests for new time slots, the proposed time slot at the meeting is 5:00UTC. The related timezones are JST(UTC+9), IST(UTC+5.30), CED(UTC+1), EST(UTC-5), PDT(UTC-7), PST(UTC-8) Hope it's easy for the most. Sorry if it's not. * meeting minutes The irc meeting was held on March 18, The minutes can be found from [1]. I also added some useful links. * time zone: see above * the meeting will be held weekly at first. can be bi-weekly later. * the current status summary [1] https://wiki.openstack.org/wiki/Meetings/ServiceVM Thanks, On Tue, Mar 18, 2014 at 03:04:53PM +0900, Isaku Yamahata wrote: > Hello. This is a reminder for servicevm framework IRC meeting. > date: March 18 (Tuesday) 23:00 UTC > channel: #openstack-meeting > > the followings are proposed as agenda. > Meeting wiki: https://wiki.openstack.org/wiki/Meetings/ServiceVM > > * the current status summary > * decide the time/day/frequency > > Thanks, > -- > Isaku Yamahata -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] advanced servicevm framework IRC meeting March 18(Tuesday) 23:00 UTC
Hi Balaji. Let's discuss/determine on the time at the meeting as it is listed as agenda. Sorry for inconvenience for the first time. Do you have any feedback other than the meeting time? thanks, On Tue, Mar 18, 2014 at 06:18:01AM +, "balaj...@freescale.com" wrote: > Hi Isaku Yamahata, > > Is it possible to have any convenient slot between 4.00 - 6.30 PM - UTC. > > So, that folks from asia can also join the meetings. > > Regards, > Balaji.P > > > -----Original Message- > > From: Isaku Yamahata [mailto:isaku.yamah...@gmail.com] > > Sent: Tuesday, March 18, 2014 11:35 AM > > To: OpenStack Development Mailing List > > Cc: isaku.yamah...@gmail.com > > Subject: [openstack-dev] [Neutron] advanced servicevm framework IRC > > meeting March 18(Tuesday) 23:00 UTC > > > > Hello. This is a reminder for servicevm framework IRC meeting. > > date: March 18 (Tuesday) 23:00 UTC > > channel: #openstack-meeting > > > > the followings are proposed as agenda. > > Meeting wiki: https://wiki.openstack.org/wiki/Meetings/ServiceVM > > > > * the current status summary > > * decide the time/day/frequency > > > > Thanks, > > -- > > Isaku Yamahata > > > > ___ > > 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] advanced servicevm framework IRC meeting March 18(Tuesday) 23:00 UTC
Hello. This is a reminder for servicevm framework IRC meeting. date: March 18 (Tuesday) 23:00 UTC channel: #openstack-meeting the followings are proposed as agenda. Meeting wiki: https://wiki.openstack.org/wiki/Meetings/ServiceVM * the current status summary * decide the time/day/frequency Thanks, -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Service VM: irc discussion?
Hi. Sorry for it. Tuesdays at 23:00 UTC is correct. I mixed the time with it due to the daylight saving time. On the next week(March 18), it will be held on the correct time. Again, sorry for it. thanks, On Tue, Mar 11, 2014 at 04:15:27PM -0700, Stephen Wong wrote: > Hi Isaku, > > Seems like you had the meeting at 22:00 UTC instead of 23:00 UTC? > > [15:01] hello? is anybody there for servicevm meeting? > [15:02] #startmeeting neutron/servicevm > [15:02] Meeting started Tue Mar 11 22:02:14 2014 UTC and is due > to finish in 60 minutes. The chair is yamahata. Information about MeetBot > at http://wiki.debian.org/MeetBot. > [snip] > [15:24] #endmeeting > [15:24] *** openstack sets the channel topic to " (Meeting topic: project)". > [15:24] Meeting ended Tue Mar 11 22:24:08 2014 UTC. > Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) > > To clarify, are you looking at Tuesdays at 22:00 UTC or 23:00 UTC? > > Thanks, > - Stephen > > > > On Wed, Mar 5, 2014 at 9:57 AM, Isaku Yamahata > wrote: > > > Since I received some mails privately, I'd like to start weekly IRC > > meeting. > > The first meeting will be > > > > Tuesdays 23:00UTC from March 11, 2014 > > #openstack-meeting > > https://wiki.openstack.org/wiki/Meetings/ServiceVM > > If you have topics to discuss, please add to the page. > > > > Sorry if the time is inconvenient for you. The schedule will also be > > discussed, and the meeting time would be changed from the 2nd one. > > > > Thanks, > > > > On Mon, Feb 10, 2014 at 03:11:43PM +0900, > > Isaku Yamahata wrote: > > > > > As the first patch for service vm framework is ready for review[1][2], > > > it would be a good idea to have IRC meeting. > > > Anyone interested in it? How about schedule? > > > > > > Schedule candidate > > > Monday 22:00UTC-, 23:00UTC- > > > Tuesday 22:00UTC-, 23:00UTC- > > > (Although the slot of servanced service vm[3] can be resuled, > > > it doesn't work for me because my timezone is UTC+9.) > > > > > > topics for > > > - discussion/review on the patch > > > - next steps > > > - other open issues? > > > > > > [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms > > > [2] https://review.openstack.org/#/c/56892/ > > > [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices > > > -- > > > Isaku Yamahata > > > > -- > > Isaku Yamahata > > > > ___ > > 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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Service VM: irc discussion?
Since I received some mails privately, I'd like to start weekly IRC meeting. The first meeting will be Tuesdays 23:00UTC from March 11, 2014 #openstack-meeting https://wiki.openstack.org/wiki/Meetings/ServiceVM If you have topics to discuss, please add to the page. Sorry if the time is inconvenient for you. The schedule will also be discussed, and the meeting time would be changed from the 2nd one. Thanks, On Mon, Feb 10, 2014 at 03:11:43PM +0900, Isaku Yamahata wrote: > As the first patch for service vm framework is ready for review[1][2], > it would be a good idea to have IRC meeting. > Anyone interested in it? How about schedule? > > Schedule candidate > Monday 22:00UTC-, 23:00UTC- > Tuesday 22:00UTC-, 23:00UTC- > (Although the slot of servanced service vm[3] can be resuled, > it doesn't work for me because my timezone is UTC+9.) > > topics for > - discussion/review on the patch > - next steps > - other open issues? > > [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms > [2] https://review.openstack.org/#/c/56892/ > [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices > -- > Isaku Yamahata -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [group-policy] Changing the meeting time
I'd like to make it sure. The followings pages seems still have old time. Which is correct? 1700UTC or 1900UTC Thursday? https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting Thanks, On Tue, Feb 11, 2014 at 02:25:12PM -0600, Kyle Mestery wrote: > FYI, I’ve made the change on the meeting pages as well [1]. The Neutron > Group Policy meeting is now at 1700UTC Thursday’s on #openstack-meeting-alt. > > Thanks! > Kyle > > [1] > https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting > > On Feb 11, 2014, at 11:30 AM, Sumit Naiksatam > wrote: > > > Hi Kyle, > > > > The new time sounds good to me as well, thanks for initiating this. > > > > ~sumit. > > > > On Tue, Feb 11, 2014 at 9:02 AM, Stephen Wong wrote: > >> Hi Kyle, > >> > >>Almost missed this - sounds good to me. > >> > >> Thanks, > >> - Stephen > >> > >> > >> > >> On Mon, Feb 10, 2014 at 7:30 PM, Kyle Mestery > >> wrote: > >>> > >>> Folks: > >>> > >>> I'd like to propose moving the Neutron Group Policy meeting going > >>> forward, starting with this Thursday. The meeting has been at 1600 > >>> UTC on Thursdays, I'd like to move this to 1700UTC Thursdays > >>> on #openstack-meeting-alt. If this is a problem for anyone who > >>> regularly attends this meeting, please reply here. If I don't hear > >>> any replies by Wednesday, I'll officially move the meeting. > >>> > >>> Thanks! > >>> 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 > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Service VM: irc discussion?
https://wiki.openstack.org/wiki/Meetings Now we're scheduling. On Mon, Feb 10, 2014 at 07:43:09AM +, "Wangyang (Alex)" wrote: > Hi everyone, > Is there anyone can kindly tell me how to join your conference? > ^^ > > > -?始?原件- > ??件人: balaj...@freescale.com [mailto:balaj...@freescale.com] > ??送?奔?: 2014年2月10日 15:11 > 收件人: Isaku Yamahata; OpenStack Development Mailing List (not for usage > questions) > 主??: Re: [openstack-dev] [Neutron] Service VM: irc discussion? > > Hi Isaku Yamahata, > > We are at UTC+5.30.[IST] > > Regards, > Balaji.P > > > -Original Message- > > From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata > > Sent: Monday, February 10, 2014 12:36 PM > > To: P Balaji-B37839; OpenStack Development Mailing List (not for usage > > questions) > > Cc: Isaku Yamahata > > Subject: Re: [openstack-dev] [Neutron] Service VM: irc discussion? > > > > What's your timezone? > > 18.00UTC doesn't work for me because my timezone is UTC+9 and it's > > 3:00AM. > > > > thanks, > > > > On Mon, Feb 10, 2014 at 06:43:05AM +, "balaj...@freescale.com" > > wrote: > > > > > Hi Isaku Yamahata, > > > > > > Is it possible to move the below time slot a little earlier like > > 18.00UTC? > > > > > > Regards, > > > Balaji.P > > > > > > > -Original Message- > > > > From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku > > > > Yamahata > > > > Sent: Monday, February 10, 2014 11:42 AM > > > > To: openstack-dev@lists.openstack.org > > > > Cc: isaku.yamah...@gmail.com > > > > Subject: [Neutron] Service VM: irc discussion? > > > > > > > > As the first patch for service vm framework is ready for > > > > review[1][2], it would be a good idea to have IRC meeting. > > > > Anyone interested in it? How about schedule? > > > > > > > > Schedule candidate > > > > Monday 22:00UTC-, 23:00UTC- > > > > Tuesday 22:00UTC-, 23:00UTC- > > > > (Although the slot of servanced service vm[3] can be resuled, it > > > > doesn't work for me because my timezone is UTC+9.) > > > > > > > > topics for > > > > - discussion/review on the patch > > > > - next steps > > > > - other open issues? > > > > > > > > [1] > > > > https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms > > > > [2] https://review.openstack.org/#/c/56892/ > > > > [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices > > > > -- > > > > Isaku Yamahata > > > > > > > > > > > > > ___ > > > OpenStack-dev mailing list > > > OpenStack-dev@lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > > Isaku Yamahata > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Service VM: irc discussion?
What's your timezone? 18.00UTC doesn't work for me because my timezone is UTC+9 and it's 3:00AM. thanks, On Mon, Feb 10, 2014 at 06:43:05AM +, "balaj...@freescale.com" wrote: > Hi Isaku Yamahata, > > Is it possible to move the below time slot a little earlier like 18.00UTC? > > Regards, > Balaji.P > > > -Original Message- > > From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata > > Sent: Monday, February 10, 2014 11:42 AM > > To: openstack-dev@lists.openstack.org > > Cc: isaku.yamah...@gmail.com > > Subject: [Neutron] Service VM: irc discussion? > > > > As the first patch for service vm framework is ready for review[1][2], it > > would be a good idea to have IRC meeting. > > Anyone interested in it? How about schedule? > > > > Schedule candidate > > Monday 22:00UTC-, 23:00UTC- > > Tuesday 22:00UTC-, 23:00UTC- > > (Although the slot of servanced service vm[3] can be resuled, it doesn't > > work for me because my timezone is UTC+9.) > > > > topics for > > - discussion/review on the patch > > - next steps > > - other open issues? > > > > [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms > > [2] https://review.openstack.org/#/c/56892/ > > [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices > > -- > > Isaku Yamahata > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to write a new neutron L2 plugin using ML2 framework?
On Sat, Feb 08, 2014 at 03:49:46AM +, "Yang, Yi Y" wrote: > Hi, All Hi. > I want to write a new neutron L2 plugin using ML2 framework, I noticed > openvswitch and linxubridge have been ported into ML2 framework, but it seems > many code is removed compared to standalone L2 plugin, I guess some code has > been written into a common library. Now I want to write a L2 plugin to enable > switch for a SR-IOV 10g NIC, I think I need to write as follows: > 1. a new mechanism driver neutron/plugins/ml2/drivers/mech_XXX.py, but from > source code, it seems nothing to do. This requires to define how your plugin utilize network. If multi tenant network is wanted, what/how technology will be used. The common one is VLAN or tunneling(GRE, VXLAN). This depends on what feature your NIC supports. > 2. a new agent neutron/plugins/XXX/ XXX_neutron_plugin.py > > After this, an issue it how to let neutron know it and load it by default or > by configuration. Debugging is also an issue, nobody can write code correctly > once :-), does neutron have any good debugging way for a newbie? LOG.debug and debug middle ware. If there are any other better way, I'd also like to know. thanks, > I'm very eager to be able to get your help and sincerely thank you in advance. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Service VM: irc discussion?
As the first patch for service vm framework is ready for review[1][2], it would be a good idea to have IRC meeting. Anyone interested in it? How about schedule? Schedule candidate Monday 22:00UTC-, 23:00UTC- Tuesday 22:00UTC-, 23:00UTC- (Although the slot of servanced service vm[3] can be resuled, it doesn't work for me because my timezone is UTC+9.) topics for - discussion/review on the patch - next steps - other open issues? [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms [2] https://review.openstack.org/#/c/56892/ [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services?
I'm interested in it. My timezone is JST(UTC+9). thanks, On Mon, Feb 03, 2014 at 05:19:35PM -0500, Paul Michali wrote: > I'd like to see if there is interest in discussing vendor plugins for L3 > services. The goal is to strive for consistency across vendor plugins/drivers > and across service types (if possible/sensible). Some of this could/should > apply to reference drivers as well. I'm thinking about these topics (based on > questions I've had on VPNaaS - feel free to add to the list): > > How to handle vendor specific validation (e.g. say a vendor has restrictions > or added capabilities compared to the reference drivers for attributes). > Providing "client" feedback (e.g. should help and validation be extended to > include vendor capabilities or should it be delegated to server reporting?) > Handling and reporting of errors to the user (e.g. how to indicate to the > user that a failure has occurred establishing a IPSec tunnel in device > driver?) > Persistence of vendor specific information (e.g. should new tables be used or > should/can existing reference tables be extended?). > Provider selection for resources (e.g. should we allow --provider attribute > on VPN IPSec policies to have vendor specific policies or should we rely on > checks at connection creation for policy compatibility?) > Handling of multiple device drivers per vendor (e.g. have service driver > determine which device driver to send RPC requests, or have agent determine > what driver requests should go to - say based on the router type) > If you have an interest, please reply to me and include some days/times that > would be good for you, and I'll send out a notice on the ML of the time/date > and we can discuss. > > Looking to hearing form you! > > PCM (Paul Michali) > > MAIL p...@cisco.com > IRCpcm_ (irc.freenode.net) > TW@pmichali > GPG key4525ECC253E31A83 > Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] auto configration of local_ip
On Thu, Jan 16, 2014 at 10:53:11PM +1300, Robert Collins wrote: > On 16 January 2014 22:51, Robert Collins wrote: > > > I don't think 1 is a special case of 3 - interface based connections > > are dependent on physical wiring, > > > > How about 4. Send a few packets with a nonce in them to any of the > > already meshed nodes, and those nodes can report what ip they > > originated from. > > Oh, and 5: do an 'ip route get ' which will > give you output like: > Press ENTER or type command to continue > 192.168.3.1 via 192.168.1.1 dev wlan0 src 192.168.1.17 > cache 6: run a command which is specified in the config file. use its output. Then arbitrary logic can be used by writing shell script or whatever without modifying neutron. Some samples which implement option 1-5 can be put in the repo. thanks, Isaku Yamahata > > The src is the src address the local machine would be outputting from. > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Service VM: Meeting on framework for advanced service
I sent out the invitation mail to the attendees. If you haven't received it for some reason (sorry if I missed anyone), please let me know. (mail to isaku.yamahata at intel.com or IRC) If you haven't expressed your interest yet, it's still open so that, don't hesitate. Thanks, On Fri, Jan 10, 2014 at 01:36:23PM +0900, Isaku Yamahata wrote: > Hello Neutron developers. > > Framework for advanced service[1][2] was discussed at the last summit. > Since it's been a while and there has been a progress as the code[3], > I think it's good time to brain storm/discuss on it in face-to-face manner. > So I'm arranging it. > If you'd like to attend, please contact me for the arrangement. > > > Topics: Framework for Advanced Service VM > current status and next step > Date: Monday Jan 20, 2014 (Sorry for the already fixed schedule.) > Time: 10:00am(PST) - > Place: Intel Office in Santa Clara >(I'll send the details to the attendees later) > NOTE: Neutron team meeting starts at 1:00pm(PST) that day. > We'll provide network access so that the attendees can join it. > > > Expected topics: > - the current status > - open discussion for next step > - needs to be discussed with the current implementation > - terminology(naming) > - creating/registering VM > - communicating with vm/service as management > - use case > - horizon > > Please update the etherpad[4] page if you have any ideas. > > > > [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms > [2] > https://docs.google.com/document/d/1pwFVV8UavvQkBz92bT-BweBAiIZoMJP0NPAO4-60XFY/edit > [3] https://review.openstack.org/#/c/56892/ > [4] https://etherpad.openstack.org/p/NeutronServiceVM > -- > Isaku Yamahata -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Service VM: Meeting on framework for advanced service
Hello Neutron developers. Framework for advanced service[1][2] was discussed at the last summit. Since it's been a while and there has been a progress as the code[3], I think it's good time to brain storm/discuss on it in face-to-face manner. So I'm arranging it. If you'd like to attend, please contact me for the arrangement. Topics: Framework for Advanced Service VM current status and next step Date: Monday Jan 20, 2014 (Sorry for the already fixed schedule.) Time: 10:00am(PST) - Place: Intel Office in Santa Clara (I'll send the details to the attendees later) NOTE: Neutron team meeting starts at 1:00pm(PST) that day. We'll provide network access so that the attendees can join it. Expected topics: - the current status - open discussion for next step - needs to be discussed with the current implementation - terminology(naming) - creating/registering VM - communicating with vm/service as management - use case - horizon Please update the etherpad[4] page if you have any ideas. [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms [2] https://docs.google.com/document/d/1pwFVV8UavvQkBz92bT-BweBAiIZoMJP0NPAO4-60XFY/edit [3] https://review.openstack.org/#/c/56892/ [4] https://etherpad.openstack.org/p/NeutronServiceVM -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][qa] Parallel testing update
Mathieu, Thank you for clarification. I'll take a look at the patches. On Tue, Jan 07, 2014 at 02:34:24PM +0100, Salvatore Orlando wrote: > Thanks Mathieu! > > I think we should first merge Edouard's patch, which appears to be a > prerequisite. > I think we could benefit a lot by applying this mechanism to > process_network_ports. > > However, I am not sure if there could be drawbacks arising from the fact > that the agent would assign the local VLAN port (either the lvm id or the > DEAD_VLAN tag) and then at the end of the iteration the flow modifications, > such as the drop all rule, will be applied. > This will probably create a short interval of time in which we might have > unexpected behaviours (such as VMs on DEAD VLAN able to communicate each > other for instance). Agree that more careful ordered update is necessary with deferred application. Thanks, Isaku Yamahata > I think we can generalize this discussion and use deferred application for > ovs-vsctl as well. > Would you agree with that? > > Thanks, > Salvatore > > > On 7 January 2014 14:08, Mathieu Rohon wrote: > > > I think that isaku is talking about a more intensive usage of > > defer_apply_on/off as it is done in the patch of gongysh [1]. > > > > Isaku, i don't see any reason why this could not be done in > > precess_network_ports, if needed. Moreover the patch from edouard [2] > > resolves multithreading issues while precessing defer_apply_off. > > > > > > [1]https://review.openstack.org/#/c/61341/ > > [2]https://review.openstack.org/#/c/63917/ > > > > On Mon, Jan 6, 2014 at 9:24 PM, Salvatore Orlando > > wrote: > > > This thread is starting to get a bit confusing, at least for people with > > a > > > single-pipeline brain like me! > > > > > > I am not entirely sure if I understand correctly Isaku's proposal > > concerning > > > deferring the application of flow changes. > > > I think it's worth discussing in a separate thread, and a supporting > > patch > > > will help as well; I think that in order to avoid unexpected behaviours, > > > vlan tagging on the port and flow setup should always be performed at the > > > same time; if we get a much better performance using a mechanism similar > > to > > > iptables' defer_apply, then we should it. > > > > > > Regarding rootwrap. This 6x slowdown, while proving that rootwrap > > imposes a > > > non-negligible overhead, it should not be used as a sort of proof that > > > rootwrap makes things 6 times worse! What I've been seeing on the gate > > and > > > in my tests are ALRM_CLOCK errors raised by ovs commands, so rootwrap has > > > little to do with it. > > > > > > Still, I think we can say that rootwrap adds about 50ms to each command, > > > becoming particularly penalising especially for 'fast' commands. > > > I think the best things to do, as Joe advices, a test with rootwrap > > disabled > > > on the gate - and I will take care of that. > > > > > > On the other hand, I would invite community members picking up some of > > the > > > bugs we've registered for 'less frequent' failures observed during > > parallel > > > testing; especially if you're coming to Montreal next week. > > > > > > Salvatore > > > > > > > > > > > > On 6 January 2014 20:31, Jay Pipes wrote: > > >> > > >> On Mon, 2014-01-06 at 11:17 -0800, Joe Gordon wrote: > > >> > > > >> > > > >> > > > >> > On Mon, Jan 6, 2014 at 10:35 AM, Jay Pipes > > wrote: > > >> > On Mon, 2014-01-06 at 09:56 -0800, Joe Gordon wrote: > > >> > > > >> > > What about it? Also those numbers are pretty old at this > > >> > point. I was > > >> > > thinking disable rootwrap and run full parallel tempest > > >> > against it. > > >> > > > >> > > > >> > I think that is a little overkill for what we're trying to do > > >> > here. We > > >> > are specifically talking about combining many utils.execute() > > >> > calls into > > >> > a single one. I think it's pretty obvious that the latter will > > >> > be better > > >> > performing than the first, unless you think that rootwrap has >
Re: [openstack-dev] [Neutron][qa] Parallel testing update
On Mon, Jan 06, 2014 at 05:04:47PM +0100, Salvatore Orlando wrote: > I have already discussed the matter with Jay on IRC, even if for a > different issue. > In this specific case 'batching' will have the benefit of reducing the > rootwrap overhead. > > However, it seems the benefit from batching is not resolutive. I admit I > have not run tests in the gate with batching; I've just tested in an > environment without significant load, obtaining a performance increase of > less than 10%. > > From what I gathered even if commands are 'batched' to ovs-vsctl, > operations are still individually performed on the kernel module. I did not > investigate whether the cli commands sends a single or multiple commands on > the ovsdb interface. > Nevertheless, another thing to note is that it's not just ovs-vsctl that > becomes very slow, but also, and more often than that, ovs-ofctl, for which > there is no batching. Then ovs-ofctl add/mod-flows SWITCH FILE will help on defer_apply_off()? If yes, I'm willing to create such patch. add/mod-flows batches add/mod-flow. ovs-ofctl sends OF barrier message and wait for its reply to confirm the result. Single barrier synchronization of add/mod-flows vs each barrier synchronizations of add/mod-flow. The current implementation doesn't have defer_apply_on/off in process_network_ports(). Is there any reason for it? Thanks, Isaku Yamahata > Summarising, I'm not opposed to batching for ovs-vsctl, and I would > definitely welcome it; I just don't think it will be the ultimate solution. > > Salvatore > > > On 6 January 2014 11:40, Isaku Yamahata wrote: > > > On Fri, Dec 27, 2013 at 11:09:02AM +0100, > > Salvatore Orlando wrote: > > > > > Hi, > > > > > > We now have several patches under review which improve a lot how neutron > > > handles parallel testing. > > > In a nutshell, these patches try to ensure the ovs agent processes new, > > > removed, and updated interfaces as soon as possible, > > > > > > These patches are: > > > https://review.openstack.org/#/c/61105/ > > > https://review.openstack.org/#/c/61964/ > > > https://review.openstack.org/#/c/63100/ > > > https://review.openstack.org/#/c/63558/ > > > > > > There is still room for improvement. For instance the calls from the > > agent > > > into the plugins might be consistently reduced. > > > However, even if the above patches shrink a lot the time required for > > > processing a device, we are still hitting a hard limit with the execution > > > ovs commands for setting local vlan tags and clearing flows (or adding > > the > > > flow rule for dropping all the traffic). > > > In some instances this commands slow down a lot, requiring almost 10 > > > seconds to complete. This adds a delay in interface processing which in > > > some cases leads to the hideous SSH timeout error (the same we see with > > bug > > > 1253896 in normal testing). > > > It is also worth noting that when this happens sysstat reveal CPU usage > > is > > > very close to 100% > > > > > > From the neutron side there is little we can do. Introducing parallel > > > processing for interface, as we do for the l3 agent, is not actually a > > > solution, since ovs-vswitchd v1.4.x, the one executed on gate tests, is > > not > > > multithreaded. If you think the situation might be improved by changing > > the > > > logic for handling local vlan tags and putting ports on the dead vlan, I > > > would be happy to talk about that. > > > > How about batching those ovsdb operations? > > Instead of issueing many ovs-vsctl command, > > ovs-vsctl -- command0 [args] -- command1 [args] -- ... > > > > Then, the number of ovs-vsctl will be reduced and ovs-vsctl issues > > only single ovsdb transaction. > > -- > > Isaku Yamahata > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][qa] Parallel testing update
On Fri, Dec 27, 2013 at 11:09:02AM +0100, Salvatore Orlando wrote: > Hi, > > We now have several patches under review which improve a lot how neutron > handles parallel testing. > In a nutshell, these patches try to ensure the ovs agent processes new, > removed, and updated interfaces as soon as possible, > > These patches are: > https://review.openstack.org/#/c/61105/ > https://review.openstack.org/#/c/61964/ > https://review.openstack.org/#/c/63100/ > https://review.openstack.org/#/c/63558/ > > There is still room for improvement. For instance the calls from the agent > into the plugins might be consistently reduced. > However, even if the above patches shrink a lot the time required for > processing a device, we are still hitting a hard limit with the execution > ovs commands for setting local vlan tags and clearing flows (or adding the > flow rule for dropping all the traffic). > In some instances this commands slow down a lot, requiring almost 10 > seconds to complete. This adds a delay in interface processing which in > some cases leads to the hideous SSH timeout error (the same we see with bug > 1253896 in normal testing). > It is also worth noting that when this happens sysstat reveal CPU usage is > very close to 100% > > From the neutron side there is little we can do. Introducing parallel > processing for interface, as we do for the l3 agent, is not actually a > solution, since ovs-vswitchd v1.4.x, the one executed on gate tests, is not > multithreaded. If you think the situation might be improved by changing the > logic for handling local vlan tags and putting ports on the dead vlan, I > would be happy to talk about that. How about batching those ovsdb operations? Instead of issueing many ovs-vsctl command, ovs-vsctl -- command0 [args] -- command1 [args] -- ... Then, the number of ovs-vsctl will be reduced and ovs-vsctl issues only single ovsdb transaction. -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
Hi Ian. I can't see your proposal. Can you please make it public viewable? Some comments inlined below. On Wed, Dec 18, 2013 at 01:20:50PM +0100, Ian Wells wrote: > A Neutron network is analagous to a wire between ports. We can do almost > everything with this wire - we can pass both IP and non-IP traffic, I can > even pass MPLS traffic over it (yes, I tried). For no rational reason, at > least if you live north of the API, I sometimes can't pass VLAN traffic > over it. You would think this would be in the specification for what a > network is, but as it happens I don't think we have a specification for > what a network is in those terms. > > I have a counterproposal that I wrote up yesterday [1]. This is the > absurdly simple approach, taking the position that implementing trunks > *should* be easy. That's actually not such a bad position to take, because > the problem lies with certain plugins (OVS-based setups, basically) - it's > not a problem with Neutron. > > It's very uncompromising, though - it just allows you to request a > VLAN-clean network. It would work with OVS code because it allows plugins > to decline a request, but it doesn't solve the VLAN problem for you, it > just ensures that you don't run somewhere where your application doesn't > work, and gives plugins with problems an opportunity for special case > code. You could expand it so that you're requesting either a VLAN-safe > network or a network that passes *specified* VLANs - which is the starting > position of Eric's document, a plugin-specific solution to a > plugin-specific problem. > > I accept that, for as long as we use VLAN based infrastructure, we have to > accommodate the fact that VLANs are a special case, but this is very much > an artifact of the plugin implementation - Linux bridge based network > infrastructure simply doesn't have this problem, for instance. > > On 17 December 2013 06:17, Isaku Yamahata wrote: > > > - 2 Modeling proposal > > What's the purpose of trunk network? > > Can you please add a use case that trunk network can't be optimized away? > > > > Even before I read the document I could list three use cases. Eric's > covered some of them himself. I'm not against trunking. I'm trying to understand what requirements need "trunk network" in the figure 1 in addition to "L2 gateway" directly connected to VM via "trunk port". thanks, > The reasons you might want to have a trunked network passing VLAN traffic: > 1: You're replicating a physical design for simulation purposes [2] > > 2: There are any number of reasons to use VLANs in a physical design, but > generally it's a port reduction thing. In Openstack, clearly I can do this > a different way - instead of using 30 VLANs over one network with two > ports, I can use 30 networks with two ports each. Ports are cheaper when > you're virtual, but they're not free - KVM has a limitation of, from > memory, 254 ports per VM. So I might well still want to use VLANs. I > could arbitrarily switch to another encap technology, but this is the tail > wagging the dog - I have to change my design because Neutron's contract is > inconsistent. > > 3: I want to condense many tenant networks into a single VM or physical box > because I'm using a single VM to offer logically separated services to > multiple tenants. This has all the points of (2) basically, that VLANs are > not the only encap I could use, but they're the conventional one and widely > supported. Provider networks do actually offer the functionality you need > for this already - if you're talking physical - but they would, I think, be > awkward to use in practice, and they would eat NIC ports on your hosts. > > -- > Ian. > > [1] > https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs > [2] http://blogs.cisco.com/wp-content/uploads/network1-550x334.png - a > network simulator (search for 'Cisco VIRL'). Shameless plug, sorry, but > it's an Openstack based application and I'm rather proud of it. > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
Added openstack-dev On Mon, Dec 16, 2013 at 11:34:05PM +0100, Erik Moe wrote: > Hi, > > I have added a new document to the launchpad. Document should now be more > in line with what we discussed at the Icehouse summit. > > https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms > > Doc: > https://docs.google.com/document/d/1lDJ31-XqkjjWC-IBq-_wV1KVhi7DzPkKYlCxTIPs_9U/edit?usp=sharing > > You are very welcome to give feedback if this is the solution you had in > mind. The document is view-only. So I commented below. - 2 Modeling proposal What's the purpose of trunk network? Can you please add a use case that trunk network can't be optimized away? - 4 IP address management nitpick Can you please clarify what "the L2 gateway ports" in section 2 modeling proposal, figure 1? - Table 3 Will this be same to l2-gateway one? https://blueprints.launchpad.net/neutron/+spec/l2-gateway - Figure 5 What's the purpose of br-int local VID? VID can be directly converted from br-eth1 VID to VM VID untagged. -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On Fri, Dec 06, 2013 at 04:30:17PM +0900, Maru Newby wrote: > > On Dec 5, 2013, at 5:21 PM, Isaku Yamahata wrote: > > > On Wed, Dec 04, 2013 at 12:37:19PM +0900, > > Maru Newby wrote: > > > >> In the current architecture, the Neutron service handles RPC and WSGI with > >> a single process and is prone to being overloaded such that agent > >> heartbeats can be delayed beyond the limit for the agent being declared > >> 'down'. Even if we increased the agent timeout as Yongsheg suggests, > >> there is no guarantee that we can accurately detect whether an agent is > >> 'live' with the current architecture. Given that amqp can ensure eventual > >> delivery - it is a queue - is sending a notification blind such a bad > >> idea? In the best case the agent isn't really down and can process the > >> notification. In the worst case, the agent really is down but will be > >> brought up eventually by a deployment's monitoring solution and process > >> the notification when it returns. What am I missing? > >> > > > > Do you mean overload of neutron server? Not neutron agent. > > So event agent sends periodic 'live' report, the reports are piled up > > unprocessed by server. > > When server sends notification, it considers agent dead wrongly. > > Not because agent didn't send live reports due to overload of agent. > > Is this understanding correct? > > Your interpretation is likely correct. The demands on the service are going > to be much higher by virtue of having to field RPC requests from all the > agents to interact with the database on their behalf. Is this strongly indicating thread-starvation. i.e. too much unfair thread scheduling. Given that eventlet is cooperative threading, should sleep(0) to hogging thread? -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On Wed, Dec 11, 2013 at 01:23:36AM +0900, Maru Newby wrote: > > On Dec 10, 2013, at 6:36 PM, Isaku Yamahata wrote: > > > On Mon, Dec 09, 2013 at 08:43:59AM +1300, > > Robert Collins wrote: > > > >>>> listening: when an agent connects after an outage, it first starts > >>>> listening, then does a poll for updates it missed. > >>> > >>> Are you suggesting that processing of notifications and full state > >>> synchronization are able to cooperate safely? Or hoping that it will be > >>> so in the future? > >> > >> I'm saying that you can avoid race conditions by a combination of > >> 'subscribe to changes' + 'give me the full state'. > > > > Like this? > > https://review.openstack.org/#/c/61057/ > > This patch is just to confirm the idea. > > I'm afraid the proposed patch is no more reliable than the current approach > of using file-based locking. I am working on an alternate patch that puts > the rpc event loop in the dhcp agent so that better coordination between full > synchronization and notification handling is possible. This approach has > already been taken with the L3 agent and work on the L2 agent is in process. You objected against agent polling in the discussion. But you're now proposing polling now. Did you change your mind? -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On Tue, Dec 10, 2013 at 06:35:38PM +0900,
Maru Newby wrote:
>
> On Dec 10, 2013, at 4:47 PM, Isaku Yamahata wrote:
>
> > On Tue, Dec 10, 2013 at 07:28:10PM +1300,
> > Robert Collins wrote:
> >
> >> On 10 December 2013 19:16, Isaku Yamahata wrote:
> >>
> >>> Answering myself. If connection is closed, it will reconnects
> >>> automatically
> >>> at rpc layer. See neutron.openstack.common.rpc.impl_{kombu, qpid}.py.
> >>> So notifications during reconnects can be lost if AMQP service is set
> >>> to discard notifications during no subscriber.
> >>
> >> Which is fine: the agent repulls the full set it's running on that
> >> machine, and life goes on.
> >
> > On what event?
> > Polling in agent seems effectively disabled by self.needs_resync with
> > the current code.
>
> If the agent is not connected, it is either down (needs_resync will be set to
> True on launch) or experiencing a loss of connectivity to the amqp service
> (needs_resync will have been set to True on error). The loss of
> notifications is not a problem in either case.
I agree in launch case.
But suppose only port_xxx_end notifications are sent. No change of network nor
subnet. In that case I don't see code path that sets needs_resync = True
unless dhcp driver fails.
--
Isaku Yamahata
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On Mon, Dec 09, 2013 at 08:43:59AM +1300, Robert Collins wrote: > >> listening: when an agent connects after an outage, it first starts > >> listening, then does a poll for updates it missed. > > > > Are you suggesting that processing of notifications and full state > > synchronization are able to cooperate safely? Or hoping that it will be so > > in the future? > > I'm saying that you can avoid race conditions by a combination of > 'subscribe to changes' + 'give me the full state'. Like this? https://review.openstack.org/#/c/61057/ This patch is just to confirm the idea. -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On Tue, Dec 10, 2013 at 07:28:10PM +1300,
Robert Collins wrote:
> On 10 December 2013 19:16, Isaku Yamahata wrote:
>
> > Answering myself. If connection is closed, it will reconnects automatically
> > at rpc layer. See neutron.openstack.common.rpc.impl_{kombu, qpid}.py.
> > So notifications during reconnects can be lost if AMQP service is set
> > to discard notifications during no subscriber.
>
> Which is fine: the agent repulls the full set it's running on that
> machine, and life goes on.
On what event?
Polling in agent seems effectively disabled by self.needs_resync with
the current code.
--
Isaku Yamahata
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On Mon, Dec 09, 2013 at 08:07:12PM +0900,
Isaku Yamahata wrote:
> On Mon, Dec 09, 2013 at 08:43:59AM +1300,
> Robert Collins wrote:
>
> > On 9 December 2013 01:43, Maru Newby wrote:
> > >
> >
> > >>> If AMQP service is set up not to lose notification, notifications will
> > >>> be piled up
> > >>> and stress AMQP service. I would say single node failure isn't
> > >>> catastrophic.
> > >>
> > >> So we should have AMQP set to discard notifications if there is noone
> > >
> > > What are the semantics of AMQP discarding notifications when a consumer
> > > is no longer present? Can this be relied upon to ensure that potentially
> > > stale notifications do not remain in the queue when an agent restarts?
> >
> > If the queue is set to autodelete, it will delete when the agent
> > disconnects. There will be no queue until the agent reconnects. I
> > don't know if we expose that functionality via oslo.messaging, but
> > it's certainly something AMQP can do.
>
> What happens if intermittent network instability occur?
> When the connection between agent <-> AMQP is unintentionally closed,
> will agent die or reconnect to it?
Answering myself. If connection is closed, it will reconnects automatically
at rpc layer. See neutron.openstack.common.rpc.impl_{kombu, qpid}.py.
So notifications during reconnects can be lost if AMQP service is set
to discard notifications during no subscriber.
--
Isaku Yamahata
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On Mon, Dec 09, 2013 at 08:43:59AM +1300, Robert Collins wrote: > On 9 December 2013 01:43, Maru Newby wrote: > > > > >>> If AMQP service is set up not to lose notification, notifications will be > >>> piled up > >>> and stress AMQP service. I would say single node failure isn't > >>> catastrophic. > >> > >> So we should have AMQP set to discard notifications if there is noone > > > > What are the semantics of AMQP discarding notifications when a consumer is > > no longer present? Can this be relied upon to ensure that potentially > > stale notifications do not remain in the queue when an agent restarts? > > If the queue is set to autodelete, it will delete when the agent > disconnects. There will be no queue until the agent reconnects. I > don't know if we expose that functionality via oslo.messaging, but > it's certainly something AMQP can do. What happens if intermittent network instability occur? When the connection between agent <-> AMQP is unintentionally closed, will agent die or reconnect to it? -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
ork 'up' > - agent processes stale 'network down' notification > > Though tracking sequence numbers is one possible fix, what do you think of > instead ignoring all notifications generated before a timestamp set at the > beginning of sync_state()? I agree that improvement is necessary in the are and it is better for agent to ignore stale notification somehow. Regarding to out-of-order notification, making agent to be able to accept out-of-order notifications somehow (by polling, sequence number or however) will open up the possibility for active-active Neutron server which is being discussed in this thread. > > - periodic resync spawns threads, but doesn't wait their completion. > > So if resync takes long time, next resync can start even while > > resync is going on. > > sync_state() now waits for the completion of threads thanks to the following > patch: > > https://review.openstack.org/#/c/59863/ Wow, great. -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
otifications before start processing actual tasks. Server can crash after commiting changes to DB before sending notifications. In such cases, notification will be lost. Polling to resync would be necessary somewhere. - notification loss isn't considered. self.resync is not always run. some optimization is possible, for example - detect loss by sequence number - polling can be postponed when notifications come without loss. - periodic resync spawns threads, but doesn't wait their completion. So if resync takes long time, next resync can start even while resync is going on. - processing notification can be batched. - reducing live report. piggyback on other RPC call. -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation
On Thu, Nov 21, 2013 at 12:34:33PM -0800, Gary Duan wrote: > Advanced service plugins don't have two-step transition today. IMO, If > vendor plugins/drivers don't maintain their own databases for these > services, it might not be urgent to add these steps in the plugin. I agree. OVS/linux bridge plugin (or mechanism driver) is in theory. Unfortunately most of controller based plugin isn't. They update neutron db and delegate the requests to the controller. This is common pattern. No polling or something. It is very fragile. For example restarting neutron-server during processing requests easily causes inconsistency between neutron db and controller side. Errors during delegation of requests tend to be ignored. Do we want to address it to some extent by framework (ie ML2 plugin)? or just leave it and declare that's the problem of plugin/mechanism driver? > How to > make sure database and back-end implementation in sync need more thought. > As configuring backend device can be an a-sync process, rollback database > tables can be cumbersome. -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation
On Wed, Nov 20, 2013 at 10:16:46PM -0800, Gary Duan wrote: > Hi, Isaku and Edgar, Hi. > As part of the effort to implement L3 router service type framework, I have > reworked L3 plugin to introduce a 2-step process, precommit and postcommit, > similar to ML2. If you plan to work on L3 code, we can collaborate. Sure, let's collaborate. This is discussion phase at this moment. I envisage that our plan will be - 1st step: introduce 2-step transition to ML2 plugin (and hope other simple plugin will follow) - 2nd step: introduce locking protocol or any other mechanism like async update similar NVP, or taskflow... (design and implementation) ... - Nth step: introduce debugging/test framework e.g. insert hooks to trigger artificial sleep or context switch in debug mode in order to make race more likely to happen > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type-framework Is there any code publicly available? > Also, for advanced services such as FW and LBaas, there already is a state > transition logic in the plugin. For example, a firewall instance can have > CREATE, UPDATE and DELETE_PENDING states. Oh great! Advanced services have more complex state than core plugin, I suppose. Are you aware of further issues? Does they require further synchronization in addition to 2-step transition? Like lock, serialization, async update... Probably we can learn from other projects, nova, cinder... thanks, -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation
On Tue, Nov 19, 2013 at 11:22:46PM +0100, Salvatore Orlando wrote: > For what is worth we have considered this aspect from the perspective of > the Neutron plugin my team maintains (NVP) during the past release cycle. > > The synchronous model that most plugins with a controller on the backend > currently implement is simple and convenient, but has some flaws: > > - reliability: the current approach where the plugin orchestrates the > backend is not really optimal when it comes to ensuring your running > configuration (backend/control plane) is in sync with your desired > configuration (neutron/mgmt plane); moreover in some case, due to neutron > internals, API calls to the backend are wrapped in a transaction too, > leading to very long SQL transactions, which are quite dangerous indeed. It > is not easy to recover from a failure due to an eventlet thread deadlocking > with a mysql transaction, where by 'recover' I mean ensuring neutron and > backend state are in sync. > > - maintainability: since handling rollback in case of failures on the > backend and/or the db is cumbersome, this often leads to spaghetti code > which is very hard to maintain regardless of the effort (ok, I agree here > that this also depends on how good the devs are - most of the guys in my > team are very good, but unfortunately they have me too...). > > - performance & scalability: > - roundtrips to the backend take a non-negligible toll on the duration > of an API call, whereas most Neutron API calls should probably just > terminate at the DB just like a nova boot call does not wait for the VM to > be ACTIVE to return. > - we need to keep some operation serialized in order to avoid the > mentioned race issues > > For this reason we're progressively moving toward a change in the NVP > plugin with a series of patches under this umbrella-blueprint [1]. Interesting. A question from curiosity. successful return of POST/PUT doesn't necessarily mean that creation/update was completed. So polling by client side is needed to wait for its completion. Right? Or some kind of callback? Especially vif creation case would matter. > For answering the issues mentioned by Isaku, we've been looking at a task > management library with an efficient and reliable set of abstractions for > ensuring operations are properly ordered thus avoiding those races (I agree > on the observation on the pre/post commit solution). This discussion has been started with core plugin, another resources like service (lbaas, fw, vpn...) have similar race condition, I think. Thanks, Isaku Yamahata > We are currently looking at using celery [2] rather than taskflow; mostly > because we've already have expertise on how to use it into our > applications, and has very easy abstractions for workflow design, as well > as for handling task failures. > Said that, I think we're still open to switch to taskflow should we become > aware of some very good reason for using it. > > Regards, > Salvatore > > [1] > https://blueprints.launchpad.net/neutron/+spec/nvp-async-backend-communication > [2] http://docs.celeryproject.org/en/master/index.html > > > > On 19 November 2013 19:42, Joshua Harlow wrote: > > > And also of course, nearly forgot a similar situation/review in heat. > > > > https://review.openstack.org/#/c/49440/ > > > > Except theres was/is dealing with stack locking (a heat concept). > > > > On 11/19/13 10:33 AM, "Joshua Harlow" wrote: > > > > >If you start adding these states you might really want to consider the > > >following work that is going on in other projects. > > > > > >It surely appears that everyone is starting to hit the same problem (and > > >joining efforts would produce a more beneficial result). > > > > > >Relevant icehouse etherpads: > > >- https://etherpad.openstack.org/p/CinderTaskFlowFSM > > >- https://etherpad.openstack.org/p/icehouse-oslo-service-synchronization > > > > > >And of course my obvious plug for taskflow (which is designed to be a > > >useful library to help in all these usages). > > > > > >- https://wiki.openstack.org/wiki/TaskFlow > > > > > >The states u just mentioned start to line-up with > > >https://wiki.openstack.org/wiki/TaskFlow/States_of_Task_and_Flow > > > > > >If this sounds like a useful way to go (joining efforts) then lets see how > > >we can make it possible. > > > > > >IRC: #openstack-state-management is where I am usually at. > > > > > >On 11/19/13 3:57 AM, "Isaku Yamahata" wrote: > > > > > >
Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation
On Tue, Nov 19, 2013 at 08:59:38AM -0800,
Edgar Magana wrote:
> Do you have in mind any implementation, any BP?
> We could actually work on this together, all plugins will get the benefits
> of a better implementation.
Yes, let's work together. Here is my blueprint (it's somewhat old.
So needs to be updated.)
https://blueprints.launchpad.net/neutron/+spec/fix-races-of-db-based-plugin
https://docs.google.com/file/d/0B4LNMvjOzyDuU2xNd0piS3JBMHM/edit
Although I've thought of status change(adding more status) and locking
protocol so far, TaskFlow seems something to look at before starting and
another possible approach is decoupling backend process from api call
as Salvatore suggested like NVP plugin.
Even with taskflow or decoupling approach, some kind of enhancing status
change/locking protocol will be necessary for performance of creating
many ports at once.
thanks,
>
> Thanks,
>
> Edgar
>
> On 11/19/13 3:57 AM, "Isaku Yamahata" wrote:
>
> >On Mon, Nov 18, 2013 at 03:55:49PM -0500,
> >Robert Kukura wrote:
> >
> >> On 11/18/2013 03:25 PM, Edgar Magana wrote:
> >> > Developers,
> >> >
> >> > This topic has been discussed before but I do not remember if we have
> >>a
> >> > good solution or not.
> >>
> >> The ML2 plugin addresses this by calling each MechanismDriver twice. The
> >> create_network_precommit() method is called as part of the DB
> >> transaction, and the create_network_postcommit() method is called after
> >> the transaction has been committed. Interactions with devices or
> >> controllers are done in the postcommit methods. If the postcommit method
> >> raises an exception, the plugin deletes that partially-created resource
> >> and returns the exception to the client. You might consider a similar
> >> approach in your plugin.
> >
> >Splitting works into two phase, pre/post, is good approach.
> >But there still remains race window.
> >Once the transaction is committed, the result is visible to outside.
> >So the concurrent request to same resource will be racy.
> >There is a window after pre_xxx_yyy before post_xxx_yyy() where
> >other requests can be handled.
> >
> >The state machine needs to be enhanced, I think. (plugins need
> >modification)
> >For example, adding more states like pending_{create, delete, update}.
> >Also we would like to consider serializing between operation of ports
> >and subnets. or between operation of subnets and network depending on
> >performance requirement.
> >(Or carefully audit complex status change. i.e.
> >changing port during subnet/network update/deletion.)
> >
> >I think it would be useful to establish reference locking policy
> >for ML2 plugin for SDN controllers.
> >Thoughts or comments? If this is considered useful and acceptable,
> >I'm willing to help.
> >
> >thanks,
> >Isaku Yamahata
> >
> >> -Bob
> >>
> >> > Basically, if concurrent API calls are sent to Neutron, all of them
> >>are
> >> > sent to the plug-in level where two actions have to be made:
> >> >
> >> > 1. DB transaction ? No just for data persistence but also to collect
> >>the
> >> > information needed for the next action
> >> > 2. Plug-in back-end implementation ? In our case is a call to the
> >>python
> >> > library than consequentially calls PLUMgrid REST GW (soon SAL)
> >> >
> >> > For instance:
> >> >
> >> > def create_port(self, context, port):
> >> > with context.session.begin(subtransactions=True):
> >> > # Plugin DB - Port Create and Return port
> >> > port_db = super(NeutronPluginPLUMgridV2,
> >> > self).create_port(context,
> >> >
> >> port)
> >> > device_id = port_db["device_id"]
> >> > if port_db["device_owner"] == "network:router_gateway":
> >> > router_db = self._get_router(context, device_id)
> >> > else:
> >> > router_db = None
> >> > try:
> >> > LOG.debug(_("PLUMgrid Library: create_port() called"))
> >> > # Back-end implementation
> >> > self._plumlib.create_port(port_db, router_db)
> >> > except Exception:
> >> >
> >> >
> >> > The way we have implemented at the pl
Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation
On Mon, Nov 18, 2013 at 03:55:49PM -0500,
Robert Kukura wrote:
> On 11/18/2013 03:25 PM, Edgar Magana wrote:
> > Developers,
> >
> > This topic has been discussed before but I do not remember if we have a
> > good solution or not.
>
> The ML2 plugin addresses this by calling each MechanismDriver twice. The
> create_network_precommit() method is called as part of the DB
> transaction, and the create_network_postcommit() method is called after
> the transaction has been committed. Interactions with devices or
> controllers are done in the postcommit methods. If the postcommit method
> raises an exception, the plugin deletes that partially-created resource
> and returns the exception to the client. You might consider a similar
> approach in your plugin.
Splitting works into two phase, pre/post, is good approach.
But there still remains race window.
Once the transaction is committed, the result is visible to outside.
So the concurrent request to same resource will be racy.
There is a window after pre_xxx_yyy before post_xxx_yyy() where
other requests can be handled.
The state machine needs to be enhanced, I think. (plugins need modification)
For example, adding more states like pending_{create, delete, update}.
Also we would like to consider serializing between operation of ports
and subnets. or between operation of subnets and network depending on
performance requirement.
(Or carefully audit complex status change. i.e.
changing port during subnet/network update/deletion.)
I think it would be useful to establish reference locking policy
for ML2 plugin for SDN controllers.
Thoughts or comments? If this is considered useful and acceptable,
I'm willing to help.
thanks,
Isaku Yamahata
> -Bob
>
> > Basically, if concurrent API calls are sent to Neutron, all of them are
> > sent to the plug-in level where two actions have to be made:
> >
> > 1. DB transaction ? No just for data persistence but also to collect the
> > information needed for the next action
> > 2. Plug-in back-end implementation ? In our case is a call to the python
> > library than consequentially calls PLUMgrid REST GW (soon SAL)
> >
> > For instance:
> >
> > def create_port(self, context, port):
> > with context.session.begin(subtransactions=True):
> > # Plugin DB - Port Create and Return port
> > port_db = super(NeutronPluginPLUMgridV2,
> > self).create_port(context,
> >port)
> > device_id = port_db["device_id"]
> > if port_db["device_owner"] == "network:router_gateway":
> > router_db = self._get_router(context, device_id)
> > else:
> > router_db = None
> > try:
> > LOG.debug(_("PLUMgrid Library: create_port() called"))
> > # Back-end implementation
> > self._plumlib.create_port(port_db, router_db)
> > except Exception:
> > …
> >
> > The way we have implemented at the plugin-level in Havana (even in
> > Grizzly) is that both action are wrapped in the same "transaction" which
> > automatically rolls back any operation done to its original state
> > protecting mostly the DB of having any inconsistency state or left over
> > data if the back-end part fails.=.
> > The problem that we are experiencing is when concurrent calls to the
> > same API are sent, the number of operation at the plug-in back-end are
> > long enough to make the next concurrent API call to get stuck at the DB
> > transaction level, which creates a hung state for the Neutron Server to
> > the point that all concurrent API calls will fail.
> >
> > This can be fixed if we include some "locking" system such as calling:
> >
> > from neutron.common import utile
> > …
> >
> > @utils.synchronized('any-name', external=True)
> > def create_port(self, context, port):
> > …
> >
> > Obviously, this will create a serialization of all concurrent calls
> > which will ends up in having a really bad performance. Does anyone has a
> > better solution?
> >
> > Thanks,
> >
> > Edgar
> >
> >
> > ___
> > 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
--
Isaku Yamahata
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][api] Is this a potential issue
On Tue, Nov 12, 2013 at 03:07:19PM -0500, Andrew Laski wrote: > On 11/11/13 at 05:27pm, Jiang, Yunhong wrote: > >Resend after the HK summit, hope someone can give me hint on it. > > > >Thanks > >--jyh > > > >>-Original Message- > >>From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com] > >>Sent: Thursday, November 07, 2013 5:39 PM > >>To: openstack-dev@lists.openstack.org > >>Subject: [openstack-dev] [nova][api] Is this a potential issue > >> > >>Hi, all > >>I'm a bit confused of followed code in ./compute/api.py, which will be > >>invoked by api/openstack/compute/servers.py, _action_revert_resize(). > >>From the code seems there is a small windows between get the > >>migration object and update migration.status. If another API request > >>comes at this small window, it means two utility will try to revert resize > >>at > >>same time. Is this a potential issue? > >>Currently implementation already roll back the reservation if > >>something wrong, but not sure if we should update state to "reverting" as > >>a transaction in get_by_instance_and_status()? > > The migration shouldn't end up being set to 'reverting' twice > because of the expected_task_state set and check in > instance.save(expected_task_state=None). The quota reservation > could happen twice, so a rollback in the case of a failure in > instance.save could be good. nova.objects.instance.Intance.save() seems like that expected_task_state=None means don't care of task state instead of no-task going-on. Am I missing anything? thanks, > > >> > >>--jyh > >> > >>def revert_resize(self, context, instance): > >>"""Reverts a resize, deleting the 'new' instance in the process.""" > >>elevated = context.elevated() > >>migration = > >>migration_obj.Migration.get_by_instance_and_status( > >>elevated, instance.uuid, 'finished') > >>>>>>>>>>>>>>>>>>>>>>>>Here we get the migration object > >> > >># reverse quota reservation for increased resource usage > >>deltas = self._reverse_upsize_quota_delta(context, migration) > >>reservations = self._reserve_quota_delta(context, deltas) > >> > >>instance.task_state = task_states.RESIZE_REVERTING > >>instance.save(expected_task_state=None) > >> > >>migration.status = 'reverting' > >> >>>>>>>>>>>>>>Here > >>we update the status. > >> migration.save() > >> > >>___ > >>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 -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN aware VMs
I'm fine with 14:00 on Thursday. On Tue, Nov 05, 2013 at 07:59:55AM +0100, Erik Moe wrote: > Ok, 2PM Thursday is fine with me. > > > > On Tue, Nov 5, 2013 at 6:49 AM, Kyle Mestery (kmestery) > wrote: > > > How about if we do a developers lounge chat at 2PM Thursday? > > > > On Nov 4, 2013, at 10:20 PM, Yi Sun > > wrote: > > > > > Guys, > > > I just checked the schedule of unconference sessions. There are no free > > slots anymore. > > > > > > Yi > > > > > > On Tuesday, October 29, 2013, Isaku Yamahata wrote: > > > Hi Erik and Li. > > > Unconference at the next summit? > > > > > > On Mon, Oct 28, 2013 at 02:34:28PM -0700, > > > beyounn wrote: > > > > > > > Hi Erik, > > > > > > > > While we were discussing about the service VM framework, the trunk port > > > > support was also mentioned. I think people do see the needs for it. > > > > > > > > I have seen someone have mentioned another BP > > > > > > https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin > > > > your BP already. Maybe it is same as what you are doing. > > > > > > > > And the trunk port use case can also impact how the zone being > > constructed > > > > in the fwaas context (when a firewall VM uses a trunk port to connect > > > > multiple networks). The basic question is how we should present a > > trunk port > > > > and the vlan on a trunk port to Neutron. > > > > > > > > > > > > > > > > Yi > > > > > > > > > > > > > > > > From: Erik Moe [mailto:emoe...@gmail.com] > > > > Sent: Monday, October 28, 2013 1:56 PM > > > > To: openstack-dev@lists.openstack.org > > > > Subject: [openstack-dev] [Neutron] VLAN aware VMs > > > > > > > > > > > > > > > > Hi! > > > > > > > > We are looking into how to make it possible for tenant VMs to use VLAN > > > > tagged traffic to connect to different Neutron networks. > > > > > > > > > > > > > > > > The VID on frames sent/received will determine which Neutron network > > the > > > > frames are connected to. > > > > > > > > > > > > https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms > > > > > > > > I would like to find others that also see the need for this kind of > > > > functionality and would like to discuss this. > > > > > > > > Regards, > > > > Erik > > > > > > > > > > > ___ > > > > OpenStack-dev mailing list > > > > OpenStack-dev@lists.openstack.org > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > -- > > > Isaku Yamahata > > > > > > ___ > > > OpenStack-dev mailing list > > > OpenStack-dev@lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > -- > > > Android-x86 > > > http://www.android-x86.org > > > ___ > > > 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 > > -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
Port profile is generic way of Neutron to pass plugin-specific data as dictionary. Cisco plugin uses it to pass VMEFX specific data. Robert, correct me if I'm wrong. thanks, --- Isaku Yamahata On Thu, Oct 31, 2013 at 10:21:20PM +, "Jiang, Yunhong" wrote: > Robert, I think your change request for pci alias should be covered by the > extra infor enhancement. > https://blueprints.launchpad.net/nova/+spec/pci-extra-info and Yongli is > working on it. > > I'm not sure how the port profile is passed to the connected switch, is it a > Cisco VMEFX specific method or libvirt method? Sorry I'm not well on network > side. > > --jyh > > From: Robert Li (baoli) [mailto:ba...@cisco.com] > Sent: Wednesday, October 30, 2013 10:13 AM > To: Irena Berezovsky; Jiang, Yunhong; prashant.upadhy...@aricent.com; > chris.frie...@windriver.com; He, Yongli; Itzik Brown > Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery > (kmestery); Sandhya Dasu (sadasu) > Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support > > Hi, > > Regarding physical network mapping, This is what I thought. > > consider the following scenarios: >1. a compute node with SRIOV only interfaces attached to a physical > network. the node is connected to one upstream switch >2. a compute node with both SRIOV interfaces and non-SRIOV interfaces > attached to a physical network. the node is connected to one upstream switch >3. in addition to case 1 &2, a compute node may have multiple vNICs that > are connected to different upstream switches. > > CASE 1: > -- the mapping from a virtual network (in terms of neutron) to a physical > network is actually done by binding a port profile to a neutron port. With > cisco's VM-FEX, a port profile is associated with one or multiple vlans. Once > the neutron port is bound with this port-profile in the upstream switch, it's > effectively plugged into the physical network. > -- since the compute node is connected to one upstream switch, the existing > nova PCI alias will be sufficient. For example, one can boot a Nova instance > that is attached to a SRIOV port with the following command: > nova boot -flavor m1.large -image --nic > net-id=,pci-alias=,sriov=,port-profile= > the net-id will be useful in terms of allocating IP address, enable dhcp, > etc that is associated with the network. > -- the pci-alias specified in the nova boot command is used to create a PCI > request for scheduling purpose. a PCI device is bound to a neutron port > during the instance build time in the case of nova boot. Before invoking the > neutron API to create a port, an allocated PCI device out of a PCI alias will > be located from the PCI device list object. This device info among other > information will be sent to neutron to create the port. > > CASE 2: > -- Assume that OVS is used for the non-SRIOV interfaces. An example of > configuration with ovs plugin would look like: > bridge_mappings = physnet1:br-vmfex > network_vlan_ranges = physnet1:15:17 > tenant_network_type = vlan > When a neutron network is created, a vlan is either allocated or > specified in the neutron net-create command. Attaching a physical interface > to the bridge (in the above example br-vmfex) is an administrative task. > -- to create a Nova instance with non-SRIOV port: >nova boot -flavor m1.large -image --nic net-id= > -- to create a Nova instance with SRIOV port: >nova boot -flavor m1.large -image --nic > net-id=,pci-alias=,sriov=,port-profile= > it's essentially the same as in the first case. But since the net-id is > already associated with a vlan, the vlan associated with the port-profile > must be identical to that vlan. This has to be enforced by neutron. > again, since the node is connected to one upstream switch, the existing > nova PCI alias should be sufficient. > > CASE 3: > -- A compute node might be connected to multiple upstream switches, with each > being a separate network. This means SRIOV PFs/VFs are already implicitly > associated with physical networks. In the none-SRIOV case, a physical > interface is associated with a physical network by plugging it into that > network, and attaching this interface to the ovs bridge that represents this > physical network on the compute node. In the SRIOV case, we need a way to > group the SRIOV VFs that belong to the same physical networks. The existing > nova PCI alias is to facilitate PCI device allocation by associating > with an alias name. This will no longer be > sufficient. But it can be enhanced to achieve our goal
Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
On Wed, Oct 30, 2013 at 04:14:40AM +, "Jiang, Yunhong" wrote: > > But how about long term direction? > > Neutron should know/manage such network related resources on > > compute nodes? > > So you mean the PCI device management will be spited between Nova and > Neutron? For example, non-NIC device owned by nova and NIC device owned by > neutron? Yes. But I'd like to hear from other Neutron developers. > There have been so many discussion of the scheduler enhancement, like > https://etherpad.openstack.org/p/grizzly-split-out-scheduling , so possibly > that's the right direction? Let's wait for the summit discussion. Interesting. Yeah, I look forward for the summit discussion. Let's try to involve not only Nova developers, but also other Neutron developers. thanks, -- Isaku Yamahata ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
