Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic
he 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=02%7C01%7Cmoshele%40mellanox.com%7Ce5607928a41c44bf065508d6266a9435%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636738636550233328=PexKWkCH7u4kRWjzs2kOIZsHFmzSL%2BCl6bqzY2B5KWA%3D=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=02%7C01%7Cmoshele%40mellanox.com%7Ce5607928a41c44bf065508d6266a9435%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636738636550243338=dHTuFDlyKrA8ouPU7JV4GKokCKNBg%2Fzw9KlpIrZW5x0%3D=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 <a.vamsikris...@ericsson.com> 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 <isaku.yamah...@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
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 <as...@redhat.com> wrote: > On Wed, Dec 13, 2017 at 7:30 AM, Michel Peterson <mic...@redhat.com> 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 <isaku.yamah...@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
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 <mkole...@redhat.com> wrote: > On Wed, Dec 13, 2017 at 2:30 PM, Michel Peterson <mic...@redhat.com> 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 <isaku.yamah...@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
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 <a.vamsikris...@ericsson.com> 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 <isaku.yamah...@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
Re: [openstack-dev] Re?: [Neutron] Denver Team Dinner
+1 On Wed, Sep 13, 2017 at 07:28:31AM -0600, Thomas Morin <thomas.mo...@orange.com> wrote: > +1 > > -Thomas > > > Takashi Yamamoto, 2017-09-13 03:05: > > +1 > > > > On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro > > <iwam...@valinux.co.jp> 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 <ke...@benton.pub > > > > > > wrote: > > > > > > +1 > > > > > > > > > > > > On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński <slawek@kap > > > > > > lonski.pl> > > > > > > wrote: > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > ??? > > > > > > > Best regards > > > > > > > Slawek Kaplonski > > > > > > > sla...@kaplonski.pl > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wiadomość napisana przez Miguel Lavalle <miguel@mlavalle. > > > > > > > > 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 <yamam...@midokura.com> wrote: > hi, > > On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata <isaku.yamah...@gmail.com> > 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 <yamam...@midokura.com> wrote: > > > >> hi, > >> > >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton <ke...@benton.pub> 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 <yamam...@midokura.com> > >> > 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.yamah...@gmail.com> -- Isaku Yamahata <isaku.yamah...@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
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 <yamam...@midokura.com> wrote: > hi, > > On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton <ke...@benton.pub> 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 <yamam...@midokura.com> > > 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.yamah...@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
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 <ihrac...@redhat.com> 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 <gkot...@vmware.com> 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 <isaku.yamah...@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
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 <deepthi@ericsson.com> 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 <isaku.yamah...@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
Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday
+1 On Fri, Feb 17, 2017 at 11:18:41AM -0800, Kevin Benton <ke...@benton.pub> 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 <isaku.yamah...@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
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." <arma...@gmail.com> wrote: > On 2 February 2017 at 16:09, Armando M. <arma...@gmail.com> 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 <isaku.yamah...@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
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 <eezh...@mirantis.com> 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 <isaku.yamah...@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
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 <mig...@mlavalle.com> 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 <isaku.yamah...@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
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 <wdec.i...@gmail.com> 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 <isaku.yamah...@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
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 cathy.h.zh...@huawei.com 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.ptmailto:m...@cgoncalves.pt, Adolfo Duarte (HP) adolfo.dua...@hp.commailto:adolfo.dua...@hp.com German Eichberger (HP) german.eichber...@hp.commailto:german.eichber...@hp.com, Swami Vasudevan (HP) swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com, Uri Elzur (Intel) uri.el...@intel.commailto:uri.el...@intel.com Joe D'Andrea (ATT) jdand...@research.att.commailto:jdand...@research.att.com, Isaku Yamahata (Intel) isaku.yamah...@gmail.commailto:isaku.yamah...@gmail.com, Malini Bhandaru malini.k.bhand...@intel.commailto:malini.k.bhand...@intel.com, Michael Johnson (HP) john...@hp.commailto:john...@hp.com, Lynn Li (HP) lynn...@hp.commailto:lynn...@hp.com, Mickey Spiegel (IBM) emspi...@us.ibm.commailto:emspi...@us.ibm.com, Ryan Tidwell (HP) ryan.tidw...@hp.commailto:ryan.tidw...@hp.com Ralf Trezeciak openst...@trezeciak.demailto: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 __ 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.yamah...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi
Re: [openstack-dev] [neutron] openwrt VM as service
-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@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
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 ihrac...@redhat.com 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 isaku.yamah...@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
Re: [openstack-dev] [neutron] L2 gateway as a service
distinct from neutron. Can you confirm that? Salvatore On 13 November 2014 13:26, Kamat, Maruti Haridas maruti.ka...@hp.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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 isaku.yamah...@gmail.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 chuckjcarl...@gmail.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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
-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 isaku.yamah...@gmail.com ___ 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 sgor...@redhat.com 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 isaku.yamah...@gmail.com ___ 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 loywo...@gmail.com 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 isaku.yamah...@gmail.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] Networks without subnets
On Mon, Jul 21, 2014 at 02:52:04PM -0500, Kyle Mestery mest...@mestery.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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
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 isaku.yamah...@gmail.com ___ 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 isaku.yamah...@gmail.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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 twil...@redhat.com 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 isaku.yamah...@gmail.com 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 isaku.yamah...@gmail.com ___ 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
. [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 isaku.yamah...@gmail.com ___ 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 mest...@noironetworks.com 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 sorla...@nicira.com 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 zealot0...@gmail.com 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 m...@us.ibm.com 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.yamah...@gmail.com ___ 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 isaku.yamah...@gmail.com 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 mest...@noironetworks.com 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 sorla...@nicira.com 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 zealot0...@gmail.com 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 m...@us.ibm.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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 mey...@gmail.com 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 isaku.yamah...@gmail.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation
___ 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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 mathieu.ro...@gmail.com 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 jcsf31...@gmail.com 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 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 floaty so that they can cross network boundaries without having to statically configure routers. To get this mobility, it seems inevitable to accept the fragmentation in the routing prefixes. This level of fragmentation would be contained to a well-defined scope, like within a datacenter. Is it your opinion that trading off fragmentation for mobility a bad trade-off? Maybe it depends on the capabilities of the TOR switches and routers that you have. Maybe others can chime in here. Carl On Wed, May 28, 2014 at 10:11 PM, A, Keshava keshav...@hp.com wrote: Hi, Motivation behind this requirement is “ to achieve VM prefix aggregation using routing protocol ( BGP/OSPF)”. So that prefix advertised from cloud to upstream will be aggregated. I do not have idea how the current scheduler is implemented. But schedule
[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 isaku.yamah...@gmail.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Network-as-a-Service
On Mon, May 26, 2014 at 03:46:28PM +0400, Artem Shepelev shepelev.ar...@gmail.com 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 isaku.yamah...@gmail.com ___ 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 Fri, May 23, 2014 at 04:13:57PM +0900, Ogaki, Kenichi k.og...@gmail.com 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 isaku.yamah...@gmail.com wrote: On Wed, May 21, 2014 at 10:54:03AM +0300, Dmitry mey...@gmail.com 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/editfrom 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.pdffrom 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.comwrote: Hi, I will also attend the NFV IRC meeting. thanks, Isaku Yamahata On Tue, May 20
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
On Thu, May 22, 2014 at 11:40:02AM +0300, Dmitry mey...@gmail.com 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 isaku.yamah...@gmail.comwrote: On Wed, May 21, 2014 at 10:54:03AM +0300, Dmitry mey...@gmail.com 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/editfrom 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.pdffrom 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.comwrote: Hi, I will also attend the NFV IRC meeting. thanks, Isaku Yamahata On Tue, May 20, 2014 at 01:23:22PM -0700, Stephen Wong s3w...@midokura.com 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 chr...@sous-sol.org 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 ijw.ubu...@cack.org.uk 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
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
On Wed, May 21, 2014 at 10:54:03AM +0300, Dmitry mey...@gmail.com wrote: HI, Hi. I would happy to get explanation of what is the difference between Adv Service Managementhttps://docs.google.com/file/d/0Bz-bErEEHJxLTGY4NUVvTzRDaEk/editfrom 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 orchestrationhttp://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdffrom 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.comwrote: Hi, I will also attend the NFV IRC meeting. thanks, Isaku Yamahata On Tue, May 20, 2014 at 01:23:22PM -0700, Stephen Wong s3w...@midokura.com 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 chr...@sous-sol.org 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 ijw.ubu...@cack.org.uk 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 s3w...@midokura.com 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 chr...@sous-sol.org 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 ijw.ubu...@cack.org.uk 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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 neutron...@163.com 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 isaku.yamah...@gmail.com 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 isaku.yamah...@gmail.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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 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 isaku.yamah...@gmail.com wrote: Hi. Keyle, thank you for starting this discussion to make progress. On Mon, Apr 21, 2014 at 08:41:19PM -0500, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com 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 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list
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 mest...@noironetworks.com wrote: On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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
Hello Dmitry. Thank you for reply. On Wed, Apr 09, 2014 at 03:19:10PM +0400, Dmitry Mescheryakov dmescherya...@mirantis.com 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 isaku.yamah...@gmail.com: 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
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 berra...@redhat.com 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 guest agent has to be considered untrustworthy, so should not be used to make functional decisions in Neutron. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 s3w...@midokura.com wrote: Hi Isaku, Seems like you had the meeting at 22:00 UTC instead of 23:00 UTC? [15:01] yamahata hello? is anybody there for servicevm meeting? [15:02] yamahata #startmeeting neutron/servicevm [15:02] openstack 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] yamahata #endmeeting [15:24] *** openstack sets the channel topic to (Meeting topic: project). [15:24] openstack 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 isaku.yamah...@gmail.comwrote: 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 isaku.yamah...@gmail.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 isaku.yamah...@gmail.com 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.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 mest...@siliconloons.com 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 sumitnaiksa...@gmail.com 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 s3w...@midokura.com wrote: Hi Kyle, Almost missed this - sounds good to me. Thanks, - Stephen On Mon, Feb 10, 2014 at 7:30 PM, Kyle Mestery mest...@siliconloons.com 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 isaku.yamah...@gmail.com ___ 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) alex.wangy...@huawei.com 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 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 p...@cisco.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 isaku.yamah...@gmail.com ___ 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 yi.y.y...@intel.com 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 isaku.yamah...@gmail.com ___ 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 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] auto configration of local_ip
On Thu, Jan 16, 2014 at 10:53:11PM +1300, Robert Collins robe...@robertcollins.net wrote: On 16 January 2014 22:51, Robert Collins robe...@robertcollins.net 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 ip of existing mesh node' 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 rbtcoll...@hp.com 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 isaku.yamah...@gmail.com ___ 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 yamahat...@gmail.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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 sorla...@nicira.com 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 mathieu.ro...@gmail.com 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 sorla...@nicira.com 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 jaypi...@gmail.com wrote: On Mon, 2014-01-06 at 11:17 -0800, Joe Gordon wrote: On Mon, Jan 6, 2014 at 10:35 AM, Jay Pipes jaypi...@gmail.com 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 no performance overhead at all? mocking out rootwrap with straight sudo, is a very quick way to approximate the performance benefit of combining many utlils.execute() calls together (at least rootwrap wise). Also it would tell us how much of the problem is rootwrap induced and how much is other. Yes, I understand that, which is what the article I linked earlier showed? % time sudo ip link /dev/null sudo ip link /dev/null 0.00s user 0.00s system 43% cpu 0.009 total % sudo time quantum-rootwrap /etc/quantum/rootwrap.conf ip link /dev/null quantum-rootwrap /etc/quantum/rootwrap.conf ip link /dev/null 0.04s user 0.02s system 87% cpu 0.059 total A very tiny, non-scientific simple indication that rootwrap is around 6 times slower than a simple sudo call. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo
Re: [openstack-dev] [Neutron][qa] Parallel testing update
On Fri, Dec 27, 2013 at 11:09:02AM +0100, Salvatore Orlando sorla...@nicira.com 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 isaku.yamah...@gmail.com ___ 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 Mon, Jan 06, 2014 at 05:04:47PM +0100, Salvatore Orlando sorla...@nicira.com 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 isaku.yamah...@gmail.com wrote: On Fri, Dec 27, 2013 at 11:09:02AM +0100, Salvatore Orlando sorla...@nicira.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 ijw.ubu...@cack.org.uk 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 isaku.yamah...@gmail.com 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
Added openstack-dev On Mon, Dec 16, 2013 at 11:34:05PM +0100, Erik Moe emoe...@gmail.com 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 isaku.yamah...@gmail.com ___ 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 robe...@robertcollins.net 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 isaku.yamah...@gmail.com ___ 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 ma...@redhat.com wrote: On Dec 10, 2013, at 6:36 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote: On Mon, Dec 09, 2013 at 08:43:59AM +1300, Robert Collins robe...@robertcollins.net 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 isaku.yamah...@gmail.com ___ 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 isaku.yamah...@gmail.com wrote:
On Mon, Dec 09, 2013 at 08:43:59AM +1300,
Robert Collins robe...@robertcollins.net wrote:
On 9 December 2013 01:43, Maru Newby ma...@redhat.com 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 isaku.yamah...@gmail.com
___
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 robe...@robertcollins.net wrote:
On 10 December 2013 19:16, Isaku Yamahata isaku.yamah...@gmail.com 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 isaku.yamah...@gmail.com
___
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 robe...@robertcollins.net wrote: On 9 December 2013 01:43, Maru Newby ma...@redhat.com 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 isaku.yamah...@gmail.com ___ 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
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 isaku.yamah...@gmail.com ___ 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. - processing notification can be batched. - reducing live report. piggyback on other RPC call. -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 gd...@varmour.com 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 isaku.yamah...@gmail.com ___ 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 gd...@varmour.com 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 isaku.yamah...@gmail.com ___ 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 08:59:38AM -0800,
Edgar Magana emag...@plumgrid.com 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 isaku.yamah...@gmail.com wrote:
On Mon, Nov 18, 2013 at 03:55:49PM -0500,
Robert Kukura rkuk...@redhat.com 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
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 sorla...@nicira.com 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 harlo...@yahoo-inc.com 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 harlo...@yahoo-inc.com 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 isaku.yamah...@gmail.com wrote: On Mon, Nov 18, 2013 at 03:55:49PM -0500, Robert Kukura rkuk...@redhat.com 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
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 rkuk...@redhat.com 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 isaku.yamah...@gmail.com
___
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 andrew.la...@rackspace.com 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 isaku.yamah...@gmail.com ___ 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 emoe...@gmail.com wrote: Ok, 2PM Thursday is fine with me. On Tue, Nov 5, 2013 at 6:49 AM, Kyle Mestery (kmestery) kmest...@cisco.comwrote: How about if we do a developers lounge chat at 2PM Thursday? On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com 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 beyo...@gmail.com 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 isaku.yamah...@gmail.com ___ 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 isaku.yamah...@gmail.com ___ 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 isaku.yamah...@gmail.com On Thu, Oct 31, 2013 at 10:21:20PM +, Jiang, Yunhong yunhong.ji...@intel.com 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 image-id --nic net-id=net,pci-alias=alias,sriov=direct|macvtap,port-profile=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 image-id --nic net-id=net -- to create a Nova instance with SRIOV port: nova boot -flavor m1.large -image image-id --nic net-id=net,pci-alias=alias,sriov=direct|macvtap,port-profile=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 product_id, vendor_id with an alias name. This will no longer be sufficient. But it can be enhanced to achieve our goal. For example, the PCI device domain, bus (if their mapping to vNIC is fixed across boot) may be added into the alias, and the alias name should be corresponding to a list of tuples. Another consideration
Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
On Wed, Oct 30, 2013 at 04:14:40AM +, Jiang, Yunhong yunhong.ji...@intel.com 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 isaku.yamah...@gmail.com ___ 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
Hi Erik and Li. Unconference at the next summit? On Mon, Oct 28, 2013 at 02:34:28PM -0700, beyounn beyo...@gmail.com 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-api in 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 isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Re: Service VM discussion - mgmt ifs
On Thu, Oct 03, 2013 at 11:33:35PM +, Regnier, Greg J greg.j.regn...@intel.com wrote: RE: vlan trunking support for network tunnels Copying to dev mailing list. - Greg -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Thursday, October 03, 2013 6:33 AM To: Bob Melander (bmelande) Cc: Regnier, Greg J Subject: Re: Service VM discussion - mgmt ifs On Oct 3, 2013, at 1:56 AM, Bob Melander (bmelande) bmela...@cisco.com wrote: The N1kv plugin only uses VXLAN but for that tunneling method the VLAN trunking is supported. The way it works is that each VXLAN is mapped to a *link local* VLAN. That technique is pretty much amenable to any tunneling method. There is a blueprint for trunking support in Neutron written by Kyle (https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api). I think that it would be very useful for the service VM framework if at least the ML2 and OVS plugins would implement the above blueprint. I think this blueprint would be worth shooting for in Icehouse. I can flesh it out a bit more so there is more to see on it and we can target it for Icehouse if you guys think this makes sense. I think not only would it help the service VM approach being taken here, but for running OpenStack on OpenStack deployments, having a trunk port to the VM makes a lot of sense and enables more networking options for that type of testing. Thanks, Kyle Hi Kyle. Can you please elaborate on how service VM sees packets from such ports? Say, in case of VLAN trunking, service VM should understand VLAN tag? By looking at the BP, I don't understand the relation of network interface in guests, OVS ports(in case of OVS plugin), and neutron port you are proposing. (Maybe this is the reason of this discussion, though) So far they are 1:1:1, but you'd like to make it more flexible, I guess. thanks, We actually have an implementation also for the OVS plugin that supports its tunneling methods. But we have not yet attempted to upstream it. Thanks, Bob Ps. Thanks for inserting the email comments into the document. If we can extend it further in the coming weeks to get a full(er) picture then during summit we can identify/discuss suitable pieces to implement in phases during Iceberg timeframe. 3 okt 2013 kl. 01:13 skrev Regnier, Greg J greg.j.regn...@intel.com: Hi Bob, Does the VLAN trunking solution work with tenant networks that use (VxLAN, NVGRE) tunnels? Thanks, Greg From: Bob Melander (bmelande) [mailto:bmela...@cisco.com] Sent: Wednesday, September 25, 2013 2:57 PM To: Regnier, Greg J; Sumit Naiksatam; Rudrajit Tapadar (rtapadar); David Chang (dwchang); Joseph Swaminathan; Elzur, Uri; Marc Benoit; Sridar Kandaswamy (skandasw); Dan Florea (dflorea); Kanzhe Jiang; Kuang-Ching Wang; Gary Duan; Yi Sun; Rajesh Mohan; Maciocco, Christian; Kyle Mestery (kmestery) Subject: Re: Service VM discussion - mgmt ifs ... The service VM framework scheduler should preferably also allow selection of VIFs to host a logical resource's logical interfaces. To clarify the last statement, one use case could be to spin up a VM with more VIFs than are needed initially (e.g., if the VM does not support vif hot-plugging). Another use case is if the plugin supports VLAN trunking and attachement of the logical resource's logical interface to a network corresponds to trunking of a network on a VIF. There are at least three (or four) ways to dynamically plug a logical service resource inside a VM to networks: - Create a VM VIF on demand for the logical interface of the service resource (hot-plugging) - Pre-populate the VM with a set of VIFs that can be allocated to logical interfaces of the service resources - Create a set of VM VIFs (on demand or during VM creation) that carry VLAN trunks for which logical (VLAN) interfaces are created and allocated to service resources. ___ 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
