Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic

2018-10-01 Thread Isaku Yamahata
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

2018-07-16 Thread Isaku Yamahata
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

2018-03-19 Thread Isaku Yamahata
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

2018-02-20 Thread Isaku Yamahata
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

2018-01-15 Thread Isaku Yamahata
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

2017-11-27 Thread Isaku Yamahata
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

2017-09-13 Thread Isaku Yamahata
+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

2017-09-08 Thread Isaku Yamahata
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

2017-09-07 Thread Isaku Yamahata
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

2017-06-16 Thread Isaku Yamahata
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

2017-06-12 Thread Isaku Yamahata
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

2017-02-19 Thread Isaku Yamahata
+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

2017-02-08 Thread Isaku Yamahata

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

2016-12-09 Thread Isaku Yamahata
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

2016-10-18 Thread Isaku Yamahata
+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?

2016-06-07 Thread Isaku Yamahata
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

2015-05-11 Thread Isaku Yamahata
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

2015-04-16 Thread Isaku Yamahata
-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

2015-02-13 Thread Isaku Yamahata
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

2014-11-17 Thread Isaku Yamahata
 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-)

2014-11-17 Thread Isaku Yamahata
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

2014-11-12 Thread Isaku Yamahata
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

2014-11-12 Thread Isaku Yamahata
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!

2014-11-03 Thread Isaku Yamahata
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)

2014-10-24 Thread Isaku Yamahata
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-)

2014-09-07 Thread Isaku Yamahata
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

2014-08-04 Thread Isaku Yamahata
-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?

2014-07-29 Thread Isaku Yamahata
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

2014-07-22 Thread Isaku Yamahata
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

2014-07-21 Thread Isaku Yamahata
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

2014-07-21 Thread Isaku Yamahata

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

2014-07-14 Thread Isaku Yamahata
 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-)

2014-06-25 Thread Isaku Yamahata
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-)

2014-06-23 Thread Isaku Yamahata
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

2014-06-19 Thread Isaku Yamahata
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

2014-06-18 Thread Isaku Yamahata
.
   
[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

2014-06-18 Thread Isaku Yamahata
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

2014-06-18 Thread Isaku Yamahata
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-)

2014-06-16 Thread Isaku Yamahata
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-)

2014-06-10 Thread Isaku Yamahata
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-)

2014-06-09 Thread Isaku Yamahata
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-)

2014-06-05 Thread Isaku Yamahata
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

2014-06-04 Thread Isaku Yamahata
  
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  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-)

2014-06-03 Thread Isaku Yamahata
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 ?

2014-05-30 Thread Isaku Yamahata

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-)

2014-05-30 Thread Isaku Yamahata
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


[openstack-dev] [neutron][ironic] topology as a service (physical network topology): design summit follow up

2014-05-26 Thread Isaku Yamahata
Hi. As discussed at the summit[1], there are much requirement for
topology as a service that stores/provides information of physical
network topology in one place.

In order to make progress, I'd like to discuss issues which were raised
at the summit. I also created etherpad page and wiki page for this[2][3].

- IRC meeting
  For starter, how about having IRC meeting?
  I propose this time slot
  June 4 Wednesday: 5:00am UTC- #openstack-meeting-3
  My time zone is JST(UTC+9)

- Should this service be a separated service from Neutron?
  Although I originally created blueprint/specs for neutron extension[4][5],
  it was argued that this service should be a separated service from neutron
  because it is useful not only for neutron, but also for nova, ironic, gantt
  and so on without neutron.

  To be honest I don't have strong opinion on this and I'm fine to
  start incubation process.
  Are there anyone who helps as core-reviewer? I need help for
  incubation process. Otherwise I have no choice except staying in
  Neutron.

- TripleO link aggrigation
   TripleO has a need to configure link aggregation. Will this
   provide enough info/capability? - ChuckC
  Chuck, could you please elaborate on it and/or provide any pointers for it?

  http://lists.openstack.org/pipermail/openstack-dev/2014-February/026868.html
  I found only the pointer.
  As long as I understand from this link, what TripleO needs is something like
  - compute-node has multiple nics
  - those nics are connected to same switch
  - the configuration of the switch (properly configured)

- API and data models are under review as [5]


[1] https://etherpad.openstack.org/p/hierarchical_network_topology
[2] https://wiki.openstack.org/wiki/Topology-as-a-service
[3] https://etherpad.openstack.org/p/topology-as-a-service
[4] https://blueprints.launchpad.net/neutron/+spec/physical-network-topology
[5] https://review.openstack.org/#/c/91275/

thanks,
-- 
Isaku Yamahata 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

2014-05-26 Thread Isaku Yamahata
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

2014-05-25 Thread Isaku Yamahata
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

2014-05-25 Thread Isaku Yamahata
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

2014-05-22 Thread Isaku Yamahata
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

2014-05-21 Thread Isaku Yamahata
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-)

2014-05-19 Thread Isaku Yamahata
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-))

2014-05-07 Thread Isaku Yamahata
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-))

2014-05-06 Thread Isaku Yamahata
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-)

2014-05-01 Thread Isaku Yamahata
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

2014-04-27 Thread Isaku Yamahata
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

2014-04-23 Thread Isaku Yamahata
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

2014-04-09 Thread Isaku Yamahata
Hello developers.


As discussed many times so far[1], there are many projects that needs
to propagate RPC messages into VMs running on OpenStack. Neutron in my case.

My idea is to relay RPC messages from management network into tenant
network over file-like object. By file-like object, I mean virtio-serial,
unix domain socket, unix pipe and so on.
I've wrote some code based on oslo.messaging[2][3] and a documentation
on use cases.[4][5]
Only file-like transport and proxying messages would be in oslo.messaging
and agent side code wouldn't be a part of oslo.messaging.


use cases:([5] for more figures)
file-like object: virtio-serial, unix domain socket, unix pipe

  server - AMQP - agent in host -virtio serial- guest agent in VM
  per VM

  server - AMQP - agent in host -unix socket/pipe-
 agent in tenant network - guest agent in VM


So far there are security concerns to forward oslo.messaging from management
network into tenant network. One approach is to allow only cast-RPC from
server to guest agent in VM so that guest agent in VM only receives messages
and can't send anything to 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

2014-04-09 Thread Isaku Yamahata
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

2014-04-09 Thread isaku yamahata
 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)

2014-04-06 Thread Isaku Yamahata
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

2014-03-30 Thread Isaku Yamahata
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)

2014-03-19 Thread Isaku Yamahata

* 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

2014-03-18 Thread Isaku Yamahata
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

2014-03-18 Thread Isaku Yamahata
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?

2014-03-11 Thread Isaku Yamahata
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?

2014-03-05 Thread Isaku Yamahata
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

2014-02-16 Thread Isaku Yamahata
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?

2014-02-10 Thread Isaku Yamahata

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?

2014-02-09 Thread Isaku Yamahata
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?

2014-02-09 Thread Isaku Yamahata
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?

2014-02-09 Thread Isaku Yamahata
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?

2014-02-09 Thread Isaku Yamahata
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

2014-01-16 Thread Isaku Yamahata
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

2014-01-13 Thread Isaku Yamahata
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

2014-01-09 Thread Isaku Yamahata
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

2014-01-07 Thread Isaku Yamahata
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

2014-01-06 Thread Isaku Yamahata
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

2014-01-06 Thread Isaku Yamahata
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

2013-12-18 Thread Isaku Yamahata

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

2013-12-16 Thread Isaku Yamahata
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

2013-12-10 Thread Isaku Yamahata
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

2013-12-10 Thread Isaku Yamahata
On Tue, Dec 10, 2013 at 06:35:38PM +0900,
Maru Newby ma...@redhat.com wrote:

 
 On Dec 10, 2013, at 4:47 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
 
  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.
 
 If the agent is not connected, it is either down (needs_resync will be set to 
 True on launch) or experiencing a loss of connectivity to the amqp service 
 (needs_resync will have been set to True on error).  The loss of 
 notifications is not a problem in either case.

I agree in launch case.
But suppose only port_xxx_end notifications are sent. No change of network nor
subnet. In that case I don't see code path that sets needs_resync = True
unless dhcp driver fails.
-- 
Isaku Yamahata 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

2013-12-10 Thread Isaku Yamahata
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

2013-12-09 Thread Isaku Yamahata
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

2013-12-09 Thread Isaku Yamahata
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

2013-12-09 Thread Isaku Yamahata
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

2013-12-07 Thread Isaku Yamahata
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

2013-12-05 Thread Isaku Yamahata
 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

2013-11-25 Thread Isaku Yamahata
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

2013-11-21 Thread Isaku Yamahata
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

2013-11-20 Thread Isaku Yamahata
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

2013-11-20 Thread Isaku Yamahata
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

2013-11-19 Thread Isaku Yamahata
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

2013-11-15 Thread Isaku Yamahata
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

2013-11-04 Thread Isaku Yamahata
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

2013-11-02 Thread Isaku Yamahata
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

2013-10-30 Thread Isaku Yamahata
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

2013-10-28 Thread Isaku Yamahata
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


  1   2   >