Re: [openstack-dev] [Infra][Neutron] How to verify link to logs for disabled third-party CI
Thanks Joshua. I will give it a try. Gary On Wed, Sep 3, 2014 at 1:21 AM, Joshua Hesketh wrote: > On 9/3/14 12:11 PM, Gary Duan wrote: > > Hi, > > Our CI system is disabled due to a running bug and wrong log link. I > have manually verified the system with sandbox and two Neutron testing > patches. However, with CI disabled, I am not able to see its review comment > on any patch. > > Is there a way that I can see what the comment will look like when CI is > disabled? > > > Hi Gary, > > If you are using zuul you can use the smtp reporter[0] to email you a > report in the format as it will appear in gerrit. Otherwise you'll need to > look at what you'll be posting via ssh (if communicating directly with the > gerrit api). > > Cheers, > Josh > > [0] http://ci.openstack.org/zuul/reporters.html#smtp > > > Thanks, > Gary > > > ___ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://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] [Infra][Neutron] How to verify link to logs for disabled third-party CI
Hi, Our CI system is disabled due to a running bug and wrong log link. I have manually verified the system with sandbox and two Neutron testing patches. However, with CI disabled, I am not able to see its review comment on any patch. Is there a way that I can see what the comment will look like when CI is disabled? Thanks, Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Group-based Policy code sprint
Hi, Sumit, I'd like to be there. How long the sprint will be? Thanks, Gary On Tue, Jul 15, 2014 at 12:33 PM, Sumit Naiksatam wrote: > Hi All, > > The Group Policy team is planning to meet on July 24th to focus on > making progress with the pending items for Juno, and also to > facilitate the vendor drivers. The specific agenda will be posted on > the Group Policy wiki: > https://wiki.openstack.org/wiki/Neutron/GroupPolicy > > Prasad Vellanki from One Convergence has graciously offered to host > this for those planning to attend in person in the bay area: > Address: > 2290 N First Street > Suite # 304 > San Jose, CA 95131 > > Time: 9.30 AM > > For those not being able to attend in person, we will post remote > attendance details on the above Group Policy wiki. > > Thanks for your participation. > > ~Sumit. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] A question about firewall
Xurong, Firewall is colocated with router. You need to create a router, then the firewall state will be updated. Gary On Thu, Jun 5, 2014 at 2:48 AM, Xurong Yang wrote: > Hi, Stackers > My use case: > > under project_id A: > 1.create firewall rule default(share=false). > 2.create firewall policy default(share=false). > 3.attach rule to policy. > 4.update policy(share=true) > > under project_id B: > 1.create firewall with policy(share=true) based on project A. > then create firewall fail and suspend with status=PENDING_CREATE > > openstack@openstack03:~/Vega$ neutron firewall-policy-list > +--+--++ > | id | name | firewall_rules > | > +--+--++ > | 7884fb78-1903-4af6-af3f-55e5c7c047c9 | Demo | > [d5578ab5-869b-48cb-be54-85ee9f15d9b2] | > | 949fef5c-8dd5-4267-98fb-2ba17d2b0a96 | Test | > [8679da8d-200e-4311-bb7d-7febd3f46e37, | > | | | > 86ce188d-18ab-49f2-b664-96c497318056] | > +--+--++ > openstack@openstack03:~/Vega$ neutron firewall-rule-list > +--+--+--++-+ > | id | name | firewall_policy_id >| summary| enabled | > +--+--+--++-+ > | 8679da8d-200e-4311-bb7d-7febd3f46e37 | DenyOne | > 949fef5c-8dd5-4267-98fb-2ba17d2b0a96 | ICMP, | True > | > | | | >| source: none(none), | | > | | | >| dest: 192.168.0.101/32(none), | | > | | | >| deny | | > | 86ce188d-18ab-49f2-b664-96c497318056 | AllowAll | > 949fef5c-8dd5-4267-98fb-2ba17d2b0a96 | ICMP, | True > | > | | | >| source: none(none), | | > | | | >| dest: none(none), | | > | | | >| allow | | > +--+--+--++-+ > openstack@openstack03:~/Vega$ neutron firewall-create --name Test > Demo*Firewall Rule d5578ab5-869b-48cb-be54-85ee9f15d9b2 could not be found.* > openstack@openstack03:~/Vega$ neutron firewall-show Test > ++--+ > | Field | Value| > ++--+ > | admin_state_up | True | > | description| | > | firewall_policy_id | 7884fb78-1903-4af6-af3f-55e5c7c047c9 | > | id | 7c59c7da-ace1-4dfa-8b04-2bc6013dbc0a | > | name | Test | > | status | *PENDING_CREATE* | > | tenant_id | a0794fca47de4631b8e414beea4bd51b | > ++--+ > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Flavors] Flavor framework implementation questions
Hi, Marios,
STF stands for 'service type framework'. It's the current way to dispatch
calls to different drivers based on 'provider' attribute of the LBaaS
service instance. Firewall and VPN implementations were not upstreamed as
we want to move to Flavor Framework.
I think the flavor framework does allow the operator to expose vendor names
if the operator chooses to.
Thanks,
Gary
On Thu, May 29, 2014 at 5:38 AM, mar...@redhat.com wrote:
> On 29/05/14 00:48, Eugene Nikanorov wrote:
> > Hi,
> >
> > I have two questions that previously were briefly discussed. Both of them
> > still cause discussions within advanced services community, so I'd like
> to
> > make final clarification in this email thread.
> >
> > 1. Usage of "Service Type Framework"
> > I think right now there is a consensus that letting user to choose a
> vendor
> > is not what neutron should do. To be more specific, having public
> > 'provider' attribute on a resource may create certain problems
> > for operators because it binds resource and implementation too tightly
> that
> > it can't be maintained without changing user configuration.
> > The question that was discussed is if it's ok to remove this public
> > attribute and still use the rest of framework?
> > I think the answer is yes: the binding between resource and implementing
> > driver is ok if it's read-only and visible only to admin. This still
> serves
> > as hint for dispatching requests to driver and also may help operator to
> > troubleshoot issues.
> > I'd like to hear other opinions on this because there are patches for vpn
> > and fwaas that use STF with the difference described above.
>
> pardon my ignorance, I don't know what STF is. I missed the summit
> discussions ('provider attribute' on resources must have come up there).
> My take on the 'specific vendor' issue is that there isn't one, given
> the current proposal. From the discussion there I think there is a use
> case for a user saying 'i want a firewall from foo_vendor' and as you
> said it's just a specialised use-case of the flavor framework.
>
> Furthermore, right now the 'capabilities' for Flavors are very loosely
> defined (just key:value tags on Flavor resource). Why can't we just also
> define a 'vendor:foo' capability and use it for that purpose. I imagine
> I'm oversimplifying somewhere but would that not address the concerns?
>
> marios
>
> >
> > 2. Choosing implementation and backend
> > This topic was briefly touched at design session dedicated to flavors.
> >
> > Current proposal that was discussed on advanced services meetings was to
> > employ 2-step scheduling as described in the following sample code:
> >
> https://review.openstack.org/#/c/83055/7/neutron/tests/unit/test_flavors.pyline
> > 38-56
> >
> > In my opinion the proposed way has the following benefits:
> > - it delegates actual backend choosing to a driver.
> > This way different vendors may not be required to agree on how to bind
> > resource to a backend or any kind of other common implementation stuff
> that
> > usually leads to lots of discussions.
> > - allows different configurable vendor-specific algorithms to be used
> when
> > binding resource to a backend
> > - some drivers don't have notion of a backend because external entities
> > manage backends for them
> >
> > Another proposal is to have single-step scheduling where each driver
> > exposes the list of backends
> > and then scheduling just chooses the backend based on capabilities in the
> > flavor.
> >
> > I'd like to better understand the benefits of the second approach (this
> is
> > all implementation so from user standpoint it doesn't make difference)
> >
> > So please add your opinions on those questions.
> >
> > My suggestion is also to have a short 30 min meeting sometime this or
> next
> > week to finalize those questions. There are several patches and
> blueprints
> > that depend on them.
> >
> > Thanks,
> > Eugene.
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...
Hi, Paul, If the backend driver maintains its own database, I think the pre_commit and post_commit approach has an advantage. The typical code flow is able to keep the driver and plugin database consistent. Regarding question 1, where validation methods should be added, I am leaning towards A, but I also agree validation hooks can be added later when they are needed. It's more important to get provider and flavor logic officially supported for services. Thanks, Gary On Fri, May 23, 2014 at 7:24 AM, Paul Michali (pcm) wrote: > Hi, > > I’m working on a task for a BP to separate validation from persistence > logic in L3 services code (VPN currently), so that providers can > override/extend the validation logic (before persistence). > > So I’ve separated the code for one of the create APIs, placed the default > validation into an ABC class (as a non-abstract method) that the service > drivers inherit from, and modified the plugin to invoke the validation > function in the service driver, before doing the persistence step. > > The flow goes like this… > > def create_vpnservice(self, context, vpnservice): > driver = self._get_driver_for_vpnservice(vpnservice) > *driver.validate_create_vpnservice(context, vpnservice)* > super(VPNDriverPlugin, self).create_vpnservice(context, vpnservice) > driver.apply_create_vpnservice(context, vpnservice) > > If the service driver has a validation routine, it’ll be invoked, > otherwise, the default method in the ABC for the service driver will be > called and will handle the “baseline” validation. I also renamed the > service driver method that is used for applying the changes to the device > driver as apply_* instead of using the same name as is used for persistence > (e.g. create_vpnservice -> apply_create_vpnservice). > > The questions I have is… > > 1) Should I create new validation methods A) for every create (and > update?) API (regardless of whether they currently have any validation > logic, B) for resources that have some validation logic already, or C) only > for resources where there are providers with different validation needs? I > was thinking (B), but would like to hear peoples’ thoughts. > > 2) I’ve added validation_* and modified the other service driver call to > apply_*. Should I instead, use the ML2 terminology of pre commit_* and post > commit_*? I personally favor the former, as it is more descriptive of what > is happening in the methods, but I understand the desire for consistency > with other code. > > 3) Should I create validation methods for code, where defaults are being > set for missing (optional) information? For example, VPN IKE Policy > lifetime being set to units=seconds, value=3600, if not set. Currently, > provider implementations have same defaults, but *could* potentially use > different defaults. The alternative is to leave this in the persistence > code and not allow it to be changed. This could be deferred, if 1C is > chosen above. > > Looking forward to your thoughts... > > > Thanks! > > PCM (Paul Michali) > > MAIL …..…. p...@cisco.com > IRC ……..… pcm_ (irc.freenode.com) > TW ………... @pmichali > GPG Key … 4525ECC253E31A83 > 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 > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...
I guess you need bind the port you just create. Also, the port need to be
plugged into the VM, right? I don't see that in the code. Maybe you are
doing it outside of OpenStack.
Thanks,
Gary
On Fri, Mar 28, 2014 at 3:15 PM, Paul Michali (pcm) wrote:
> Hi,
>
> I have a VM that I start up outside of OpenStack (as a short term
> solution, until we get it working inside a Nova VM), using KVM. It has
> scrips associated with the three interfaces that are created, to hook this
> VM into Neutron. One I/F is on br-ex (connected to the "public" network for
> DevStack), another to br-int (connected to a management network that is
> created), and a third is connected to br-int (connected to the "private"
> network for DevStack). It's understood these are hacks to get things going
> and can be brittle. With DevStack, I have a vanilla localrc, so using ML2,
> without any ML2 settings specified.
>
> Now, the first two scripts use internal Neutron client calls to create
> the port, and then plug the VIF. The third, uses Neutron to create the
> port, and then Nova to plug the VIF. I don't know why - I inherited the
> scripts.
>
> On one system, where Nova is based on commit b3e2e05 (10 days ago), this
> all works just peachy. Interfaces are hooked in and I can ping to my hearts
> content. On another system, that I just reimaged today, using the latest
> and greatest OpenStack projects, the third script fails.
>
> I talked to Nova folks, and the vic is now an object, instead of a plain
> dict, and therefore calls on the object fail (as the script just provides a
> dict). I started trying to convert the vif to an object, but in discussing
> with a co-worker, we thought that we could too use Neutron calls for all of
> the setup of this third interface.
>
> Well, I tried, and the port is created, but unlike the other system, the
> port is DOWN, and I cannot ping to or from it (the other ports still work
> fine, with this newer OpenStack repo). One difference is that the port is
> showing {"port_filter": true, "ovs_hybrid_plug": true} for
> binding:vif_details, in the neutron port-show output. On the older system
> this is empty (so must be new changes in Neutron?)
>
>
> Here is the Neutron based code (trimmed) to do the create and plugging:
>
> import neutron.agent.linux.interface as vif_driver
> from neutronclient.neutron import client as qclient
>
> qc = qclient.Client('2.0', auth_url=KEYSTONE_URL, username=user,
> tenant_name=tenant, password=pw)
>
> prefix, net_name = interface.split('__')
> port_name = net_name + '_p'
> try:
> nw_id = qc.list_networks(name=net_name)['networks'][0]['id']
> except qcexp.NeutronClientException as e:
> ...
>
> p_spec = {'port': {'admin_state_up': True,
>'name': port_name,
>'network_id': nw_id,
>'mac_address': mac_addr,
>'binding:host_id': hostname,
>'device_id': vm_uuid,
>'device_owner': 'compute:None'}}
>
> try:
> port = qc.create_port(p_spec)
> except qcexp.NeutronClientException as e:
> ...
>
> port_id = port['port']['id']
> br_name = 'br-int'
>
> conf = cfg.CONF
> config.register_root_helper(conf)
> conf.register_opts(vif_driver.OPTS)
>
> driver = vif_driver.OVSInterfaceDriver(cfg.CONF)
> driver.plug(nw_id, port_id, interface, mac_addr, br_name)
>
> Finally, here are the questions (hope you stuck with the long message)...
>
> *Any idea why the neutron version is not working?* I know there were a
> bunch of recent changes.
> *Is there a way for me to turn off the ova_hybrid_plug and port_filter
> flags? Should I?*
> *Should I go back to using Nova and build a VIF object?*
> *If so, any reason why the Neutron version would not work?*
> *Is there a way to do a similar thing, but via using Northbound APIs (so
> it isn't as brittle)?*
>
> Thanks in advance!
>
> PCM (Paul Michali)
>
> MAIL . p...@cisco.com
> IRC ... pcm_ (irc.freenode.com)
> TW @pmichali
> GPG Key ... 4525ECC253E31A83
> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor Framework
Hi, Eugene, What are the parameters that will be part of flavor definition? As I am thinking of it now, the parameter could be performance and capacity related, for example, throughput, max. session number and so on; or capability related, for example, HA, L7 switching. Compared to # of CPU and memory size in Nova flavor, these parameters don't seem to have exact definitions across different implementations. Or, you think it is not something we need worry about. It's totally operator's decision of how to rate different drivers? Thanks, Gary On Thu, Feb 27, 2014 at 10:19 PM, Eugene Nikanorov wrote: > Hi Jay, > > Thanks for looking into this. > > >> 1) I'm not entirely sure that a provider attribute is even necessary to >> expose in any API. What is important is for a scheduler to know which >> drivers are capable of servicing a set of attributes that are grouped >> into a "flavor". >> > Well, provider becomes read-only attribute and for admin only (jsut to see > which driver actually handles the resources), not too much of API > visibility. > > >> 2) I would love to see the use of the term "flavor" banished from >> OpenStack APIs. Nova has moved from flavors to "instance types", which >> clearly describes what the thing is, without the odd connotations that >> the word "flavor" has in different languages (not to mention the fact >> that flavor is spelled flavour in non-American English). >> >> How about using the term "load balancer type", "VPN type", and "firewall >> type" instead? >> > Oh... I don't have strong opinion on the name of the term. > "Flavor" was used several time in our discussions and is short. > "*Instance* Type" however seems also fine. Another option is probably a > "Service Offering". > > >> >> 3) I don't believe the FlavorType (public or internal) attribute of the >> flavor is useful. We want to get away from having any vendor-specific >> attributes or objects in the APIs (yes, even if they are "hidden" from >> the normal user). See point #1 for more about this. A scheduler should >> be able to match a driver to a request simply by matching the set of >> required capabilities in the requested flavor (load balancer type) to >> the set of capabilities advertised by the driver. >> > ServiceType you mean? If you're talking about ServiceType then it mostly > for the user to filter flavors (I'm using short term for now) by service > type. Say, when user wants to create new loadbalancer, horizon will show > only flavors related to the lb. > That could be also solved by having different names live you suggested > above: "Lb type", "VPN type", etc. > On other hand that would be similar objects with different names - does it > make much sense? > > I'm not sure what you think 'vendor-specific' attributes are, I don't > remember to have plan of exposing any kind of vendor-related parameters. > The parameters that flavor represents are capabilities of the service in > terms that user care about: latency, throughput, topology, technology, etc. > > > >> 4) A minor point... I think it would be fine to group the various >> "types" into a single database table behind the scenes (like you have in >> the Object model section). However, I think it is useful to have the >> public API expose a /$servie-types resource endpoint for each service >> itself, instead of a generic /types (or /flavors) endpoint. So, folks >> looking to set up a load balancer would call GET /balancer-types, or >> call neutron balancer-type-list, instead of calling >> GET /types?service=load-balancer or neutron flavor-list >> --service=load-balancer >> > I'm fine with this suggestion. > > >> >> 5) In the section on Scheduling, you write "Scheduling is a process of >> choosing provider and a backend for the resource". As mentioned above, I >> think this could be changed to something like this: "Scheduling is a >> process of matching the set of requested capabilities -- the flavor >> (type) -- to the set of capabilities advertised by a driver for the >> resource". That would put Neutron more in line with how Nova handles >> this kind of thing. >> > I agree, I actually meant this and nova example is how I think it should > work. > But more important is what is the result of scheduling. > We discussed that yesterday with Mark and I think we got so the point > where we could not find agreement for now. > In my opinion the result of scheduling is binding resource to the driver > (at least) > So further calls to the resource go to the same driver because of that > binding. > That's pretty much the same how agent scheduling works. > > By the way I'm thinking about getting rid of 'provider' term and using > 'driver' instead. Currently 'provider' is just a user-facing representation > of the driver. Once we introduce flavors/service types/etc, we can use term > 'driver' for implementation means. > > Thanks, > Eugene. > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > htt
Re: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services?
I'm interested in the discussion. UTC-8. Gary On Wed, Feb 12, 2014 at 10:22 AM, Mandeep Dhami wrote: > > I would be interested as well (UTC-8). > > Regards, > Mandeep > > > > On Wed, Feb 12, 2014 at 8:18 AM, Eugene Nikanorov > wrote: > >> I'd be interested too. >> >> Thanks, >> Eugene. >> >> >> On Wed, Feb 12, 2014 at 7:51 PM, Carl Baldwin wrote: >> >>> Paul, >>> >>> I'm interesting in joining the discussion. UTC-7. Any word on when >>> this will take place? >>> >>> Carl >>> >>> On Mon, Feb 3, 2014 at 3:19 PM, Paul Michali wrote: >>> > I'd like to see if there is interest in discussing vendor plugins for >>> L3 >>> > services. The goal is to strive for consistency across vendor >>> > plugins/drivers and across service types (if possible/sensible). Some >>> of >>> > this could/should apply to reference drivers as well. I'm thinking >>> about >>> > these topics (based on questions I've had on VPNaaS - feel free to add >>> to >>> > the list): >>> > >>> > How to handle vendor specific validation (e.g. say a vendor has >>> restrictions >>> > or added capabilities compared to the reference drivers for >>> attributes). >>> > Providing "client" feedback (e.g. should help and validation be >>> extended to >>> > include vendor capabilities or should it be delegated to server >>> reporting?) >>> > Handling and reporting of errors to the user (e.g. how to indicate to >>> the >>> > user that a failure has occurred establishing a IPSec tunnel in device >>> > driver?) >>> > Persistence of vendor specific information (e.g. should new tables be >>> used >>> > or should/can existing reference tables be extended?). >>> > Provider selection for resources (e.g. should we allow --provider >>> attribute >>> > on VPN IPSec policies to have vendor specific policies or should we >>> rely on >>> > checks at connection creation for policy compatibility?) >>> > Handling of multiple device drivers per vendor (e.g. have service >>> driver >>> > determine which device driver to send RPC requests, or have agent >>> determine >>> > what driver requests should go to - say based on the router type) >>> > >>> > If you have an interest, please reply to me and include some >>> days/times that >>> > would be good for you, and I'll send out a notice on the ML of the >>> time/date >>> > and we can discuss. >>> > >>> > Looking to hearing form you! >>> > >>> > PCM (Paul Michali) >>> > >>> > MAIL p...@cisco.com >>> > IRCpcm_ (irc.freenode.net) >>> > TW@pmichali >>> > GPG key4525ECC253E31A83 >>> > Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 >>> > >>> > >>> > ___ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'
Oleg, Thanks for the suggestion. I will give it a try. Gary On Wed, Feb 12, 2014 at 12:12 AM, Oleg Bondarev wrote: > Hi Gary, > > please see my comments on the review. > > Thanks, > Oleg > > > On Wed, Feb 12, 2014 at 5:52 AM, Gary Duan wrote: > >> Hi, >> >> The patch I submitted for L3 service framework integration fails on >> jenkins test, py26 and py27. The console only gives following error message, >> >> 2014-02-12 00:45:01.710 | FAIL: process-returncode >> 2014-02-12 00:45:01.711 | tags: worker-1 >> >> and at the end, >> >> 2014-02-12 00:45:01.916 | ERROR: InvocationError: >> '/home/jenkins/workspace/gate-neutron-python27/.tox/py27/bin/python -m >> neutron.openstack.common.lockutils python setup.py testr --slowest >> --testr-args=' >> 2014-02-12 00:45:01.917 | ___ summary >> >> 2014-02-12 00:45:01.918 | ERROR: py27: commands failed >> >> I wonder what might be the reason for the failure and how to debug this >> problem? >> >> The patch is at, https://review.openstack.org/#/c/59242/ >> >> The console output is, >> http://logs.openstack.org/42/59242/7/check/gate-neutron-python27/e395b06/console.html >> >> Thanks, >> >> Gary >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'
Clark, You are right. The test must have been bailed out. The question is what I should look for. Even a successful case has a lot of Traceback, ERROR log in subunit_log.txt. Thanks, Gary On Tue, Feb 11, 2014 at 7:19 PM, Clark Boylan wrote: > On Tue, Feb 11, 2014 at 7:05 PM, Gary Duan wrote: > > Hi, Clark, > > > > Thanks for your reply. > > > > I thought the same thing at first, but the page by default only shows the > > failed cases. The other 1284 cases were OK. > > > > Gary > > > > > > On Tue, Feb 11, 2014 at 6:07 PM, Clark Boylan > > wrote: > >> > >> On Tue, Feb 11, 2014 at 5:52 PM, Gary Duan wrote: > >> > Hi, > >> > > >> > The patch I submitted for L3 service framework integration fails on > >> > jenkins > >> > test, py26 and py27. The console only gives following error message, > >> > > >> > 2014-02-12 00:45:01.710 | FAIL: process-returncode > >> > 2014-02-12 00:45:01.711 | tags: worker-1 > >> > > >> > and at the end, > >> > > >> > 2014-02-12 00:45:01.916 | ERROR: InvocationError: > >> > '/home/jenkins/workspace/gate-neutron-python27/.tox/py27/bin/python -m > >> > neutron.openstack.common.lockutils python setup.py testr --slowest > >> > --testr-args=' > >> > 2014-02-12 00:45:01.917 | ___ summary > >> > > >> > 2014-02-12 00:45:01.918 | ERROR: py27: commands failed > >> > > >> > I wonder what might be the reason for the failure and how to debug > this > >> > problem? > >> > > >> > The patch is at, https://review.openstack.org/#/c/59242/ > >> > > >> > The console output is, > >> > > >> > > http://logs.openstack.org/42/59242/7/check/gate-neutron-python27/e395b06/console.html > >> > > >> > Thanks, > >> > > >> > Gary > >> > > >> > > >> > ___ > >> > OpenStack-dev mailing list > >> > OpenStack-dev@lists.openstack.org > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > >> > >> I haven't dug into this too far but > >> > >> > http://logs.openstack.org/42/59242/7/check/gate-neutron-python27/e395b06/testr_results.html.gz > >> seems to offer some clues. Not sure why the console output doesn't > >> show the additional non exit code errors (possibly a nonstandard > >> formatter? or a bug?). > >> > >> Also, cases like this tend to be the test framework completely dying > >> due to a sys.exit somewhere or similar. This kills the tests and runs > >> only a small subset of them which seems to be the case here. > >> > >> Clark > >> > >> ___ > >> 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 > > > > I picked a different neutron master change and it ran 10k py27 > unittests. Pretty sure the test framework is bailing out early here. > > Clark > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'
Hi, Clark, Thanks for your reply. I thought the same thing at first, but the page by default only shows the failed cases. The other 1284 cases were OK. Gary On Tue, Feb 11, 2014 at 6:07 PM, Clark Boylan wrote: > On Tue, Feb 11, 2014 at 5:52 PM, Gary Duan wrote: > > Hi, > > > > The patch I submitted for L3 service framework integration fails on > jenkins > > test, py26 and py27. The console only gives following error message, > > > > 2014-02-12 00:45:01.710 | FAIL: process-returncode > > 2014-02-12 00:45:01.711 | tags: worker-1 > > > > and at the end, > > > > 2014-02-12 00:45:01.916 | ERROR: InvocationError: > > '/home/jenkins/workspace/gate-neutron-python27/.tox/py27/bin/python -m > > neutron.openstack.common.lockutils python setup.py testr --slowest > > --testr-args=' > > 2014-02-12 00:45:01.917 | ___ summary > > > > 2014-02-12 00:45:01.918 | ERROR: py27: commands failed > > > > I wonder what might be the reason for the failure and how to debug this > > problem? > > > > The patch is at, https://review.openstack.org/#/c/59242/ > > > > The console output is, > > > http://logs.openstack.org/42/59242/7/check/gate-neutron-python27/e395b06/console.html > > > > Thanks, > > > > Gary > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > I haven't dug into this too far but > > http://logs.openstack.org/42/59242/7/check/gate-neutron-python27/e395b06/testr_results.html.gz > seems to offer some clues. Not sure why the console output doesn't > show the additional non exit code errors (possibly a nonstandard > formatter? or a bug?). > > Also, cases like this tend to be the test framework completely dying > due to a sys.exit somewhere or similar. This kills the tests and runs > only a small subset of them which seems to be the case here. > > Clark > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'
Hi, The patch I submitted for L3 service framework integration fails on jenkins test, py26 and py27. The console only gives following error message, 2014-02-12 00:45:01.710 | FAIL: process-returncode 2014-02-12 00:45:01.711 | tags: worker-1 and at the end, 2014-02-12 00:45:01.916 | ERROR: InvocationError: '/home/jenkins/workspace/gate-neutron-python27/.tox/py27/bin/python -m neutron.openstack.common.lockutils python setup.py testr --slowest --testr-args=' 2014-02-12 00:45:01.917 | ___ summary 2014-02-12 00:45:01.918 | ERROR: py27: commands failed I wonder what might be the reason for the failure and how to debug this problem? The patch is at, https://review.openstack.org/#/c/59242/ The console output is, http://logs.openstack.org/42/59242/7/check/gate-neutron-python27/e395b06/console.html Thanks, Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] disable_security_group_extension_if_noop_driver() function in plugins
Hi, I'm not sure if this question has been asked, but I wonder what is the purpose to have the following function in ovs, linuxbridge and ml2 plugins. disable_security_group_extension_if_noop_driver() With this logic, if I set neutron to use NOOP firewall, creating a Nova instance will fail, because the 'security_group' resource doesn't exist. If I comment out this line, set firewall driver in both Neutron and Nova to be NOOP driver, everything seems working fine. Thanks, Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron Distributed Virtual Router
Regarding using 'provider' in L3 router, for the BP 'L3 service integration with service framework', I've submitted some code for review, which is using 'provider' in a same notion as other advanced services. I am not sure if it can be reused to describe 'centralized' and 'distributed' behavior. https://review.openstack.org/#/c/59242/ Thanks, Gary On Wed, Dec 11, 2013 at 2:17 AM, Salvatore Orlando wrote: > I generally tend to agree that once the distributed router is available, > nobody would probably want to use a centralized one. > Nevertheless, I think it is correct that, at least for the moment, some > advanced services would only work with a centralized router. > There might also be unforeseen scalability/security issues which might > arise from the implementation, so it is worth giving users a chance to > choose what router's they'd like. > > In the case of the NSX plugin, this was provided as an extended API > attribute in the Havana release with the aim of making it the default > solution for routing in the future. > One thing that is worth adding is that at the time it was explored the > ability of leveraging service providers for having a "centralized router > provider" and a "distributed" one; we had working code, but then we > reverted to the extended attribute. Perhaps it would be worth exploring > whether this is a feasible solution, and whether it might be even possible > to define "flavors" which characterise how routers and advanced services > are provided. > > Salvatore > > > On 10 December 2013 18:09, Nachi Ueno wrote: > >> I'm +1 for 'provider'. >> >> 2013/12/9 Akihiro Motoki : >> > Neutron defines "provider" attribute and it is/will be used in advanced >> services (LB, FW, VPN). >> > Doesn't it fit for a distributed router case? If we can cover all >> services with one concept, it would be nice. >> > >> > According to this thread, we assumes at least two types "edge" and >> "distributed". >> > Though "edge" and "distributed" is a type of implementations, I think >> they are some kind of "provider". >> > >> > I just would like to add an option. I am open to "provider" vs >> "distirbute" attributes. >> > >> > Thanks, >> > Akihiro >> > >> > (2013/12/10 7:01), Vasudevan, Swaminathan (PNB Roseville) wrote: >> >> Hi Folks, >> >> >> >> We are in the process of defining the API for the Neutron Distributed >> Virtual Router, and we have a question. >> >> >> >> Just wanted to get the feedback from the community before we implement >> and post for review. >> >> >> >> We are planning to use the “distributed” flag for the routers that are >> supposed to be routing traffic locally (both East West and North South). >> >> This “distributed” flag is already there in the “neutronclient” API, >> but currently only utilized by the “Nicira Plugin”. >> >> We would like to go ahead and use the same “distributed” flag and add >> an extension to the router table to accommodate the “distributed flag”. >> >> >> >> Please let us know your feedback. >> >> >> >> Thanks. >> >> >> >> Swaminathan Vasudevan >> >> Systems Software Engineer (TC) >> >> HP Networking >> >> Hewlett-Packard >> >> 8000 Foothills Blvd >> >> M/S 5541 >> >> Roseville, CA - 95747 >> >> tel: 916.785.0937 >> >> fax: 916.785.1815 >> >> email: swaminathan.vasude...@hp.com > swaminathan.vasude...@hp.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 >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting
I will be joining IRC too. Thanks, Gary On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana wrote: > Also joining! > Looking forward to hearing your ideas folks! > > Edgar > > On 12/10/13 10:16 AM, "Nachi Ueno" wrote: > > >+1 ! I'll join. > >I'm also working on investigating how to use openstack gating system. > >(This document is still draft version) > > > https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e > >efQalL5Q0/edit#slide=id.p > > > >2013/12/10 Ivar Lazzaro : > >> +1 for 1700UTC Thursday on IRC > >> > >> -Original Message- > >> From: Kyle Mestery [mailto:mest...@siliconloons.com] > >> Sent: Tuesday, December 10, 2013 9:21 AM > >> To: OpenStack Development Mailing List (not for usage questions) > >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin > >>testing meeting > >> > >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony" > >> wrote: > >>> -Original Message- > >>> From: Kyle Mestery > >>> Reply-To: "OpenStack Development Mailing List (not for usage > >>>questions)" > >>> > >>> Date: Tuesday, December 10, 2013 10:48 > >>> To: "OpenStack Development Mailing List (not for usage questions)" > >>> > >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing > >>> meeting > >>> > Last week I took an action item to organize a meeting for everyone > who is doing third-party testing in Neutron for plugins, whether this > is vendor or Open Source based. The idea is to share ideas around > setups and any issues people hit. I'd like to set this meeting up for > this week, Thursday at 1700UTC. I would also like to propose we make > this a dial in meeting using the Infrastructure Conferencing bridges > [1]. If this time works, I'll set something up and reply to this > thread with the dial in information. > >>> > >>> +1 for the meeting time. Any particular reason for voice over IRC? > >>> > >> We kind of decided that doing this over voice initially would be > >>expedient, but I am fine with moving to IRC. If I don't hear objections, > >>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt. > >> > >> > > Also, I've started a etherpad page [2] with information. It would be > good for people to add information to this etherpad as well. I've > coupled this pad with information around multi-node gate testing for > Neutron as well, as I suspect most of the third-party testing will > require multiple nodes as well. > >>> > >>> I'll start filling out our setup. I have some questions around > >>> Third-Party Testing in particular, and look forward to this discussion. > >>> > >> Awesome, thanks Anthony! > >> > > Thanks! > Kyle > > [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing > [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest > > ___ > 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
Re: [openstack-dev] [Neutron] L3 router service integration with Service Type Framework
FYI, I pushed code review for the blueprint. The patch is missing unitest and tempest. It's only submitted for discussion. The patch implements two-step commit process similar to ML2, but it's not intended to solve all race conditions. Another thing I think worth discussing is how to work with agent scheduler. Thanks, Gary On Thu, Oct 24, 2013 at 11:56 AM, Gary Duan wrote: > Hi, > > I've registered a BP for L3 router service integration with service > framework. > > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type > > In general, the implementation will align with how LBaaS is integrated > with the framework. One consideration we heard from several team members is > to be able to support vendor specific features and extensions in the > service plugin. > > Any comment is welcome. > > Thanks, > Gary > > > ___ 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
See inline, On Thu, Nov 21, 2013 at 2:19 AM, Isaku Yamahata wrote: > On Wed, Nov 20, 2013 at 10:16:46PM -0800, > Gary Duan wrote: > > > Hi, Isaku and Edgar, > > Hi. > > > > As part of the effort to implement L3 router service type framework, I > have > > reworked L3 plugin to introduce a 2-step process, precommit and > postcommit, > > similar to ML2. If you plan to work on L3 code, we can collaborate. > > Sure, let's collaborate. This is discussion phase at this moment. > I envisage that our plan will be > - 1st step: introduce 2-step transition to ML2 plugin > (and hope other simple plugin will follow) > - 2nd step: introduce locking protocol or any other mechanism like > async update similar NVP, or taskflow... > (design and implementation) > ... > - Nth step: introduce debugging/test framework > e.g. insert hooks to trigger artificial sleep or context switch > in debug mode in order to make race more likely to happen > > > > > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type-framework > > Is there any code publicly available? > > > I will do some clean up and post the patch for discussion. > > 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... > > 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. 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. Thanks, Gary > thanks, > -- > Isaku Yamahata > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation
Hi, Isaku and Edgar,
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.
https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type-framework
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.
Thanks,
Gary
On Wed, Nov 20, 2013 at 8:55 AM, Edgar Magana wrote:
> Let me take a look and circle back to you in a bit. This is a very
> sensitive part of the code, so we need to
> Handle properly any change.
>
> Thanks,
>
> Edgar
>
> On 11/20/13 5:46 AM, "Isaku Yamahata" wrote:
>
> >On Tue, Nov 19, 2013 at 08:59:38AM -0800,
> >Edgar Magana wrote:
> >
> >> Do you have in mind any implementation, any BP?
> >> We could actually work on this together, all plugins will get the
> >>benefits
> >> of a better implementation.
> >
> >Yes, let's work together. Here is my blueprint (it's somewhat old.
> >So needs to be updated.)
> >
> https://blueprints.launchpad.net/neutron/+spec/fix-races-of-db-based-plugi
> >n
> >https://docs.google.com/file/d/0B4LNMvjOzyDuU2xNd0piS3JBMHM/edit
> >
> >Although I've thought of status change(adding more status) and locking
> >protocol so far, TaskFlow seems something to look at before starting and
> >another possible approach is decoupling backend process from api call
> >as Salvatore suggested like NVP plugin.
> >Even with taskflow or decoupling approach, some kind of enhancing status
> >change/locking protocol will be necessary for performance of creating
> >many ports at once.
> >
> >thanks,
> >
> >>
> >> Thanks,
> >>
> >> Edgar
> >>
> >> On 11/19/13 3:57 AM, "Isaku Yamahata" wrote:
> >>
> >> >On Mon, Nov 18, 2013 at 03:55:49PM -0500,
> >> >Robert Kukura wrote:
> >> >
> >> >> On 11/18/2013 03:25 PM, Edgar Magana wrote:
> >> >> > Developers,
> >> >> >
> >> >> > This topic has been discussed before but I do not remember if we
> >>have
> >> >>a
> >> >> > good solution or not.
> >> >>
> >> >> The ML2 plugin addresses this by calling each MechanismDriver twice.
> >>The
> >> >> create_network_precommit() method is called as part of the DB
> >> >> transaction, and the create_network_postcommit() method is called
> >>after
> >> >> the transaction has been committed. Interactions with devices or
> >> >> controllers are done in the postcommit methods. If the postcommit
> >>method
> >> >> raises an exception, the plugin deletes that partially-created
> >>resource
> >> >> and returns the exception to the client. You might consider a similar
> >> >> approach in your plugin.
> >> >
> >> >Splitting works into two phase, pre/post, is good approach.
> >> >But there still remains race window.
> >> >Once the transaction is committed, the result is visible to outside.
> >> >So the concurrent request to same resource will be racy.
> >> >There is a window after pre_xxx_yyy before post_xxx_yyy() where
> >> >other requests can be handled.
> >> >
> >> >The state machine needs to be enhanced, I think. (plugins need
> >> >modification)
> >> >For example, adding more states like pending_{create, delete, update}.
> >> >Also we would like to consider serializing between operation of ports
> >> >and subnets. or between operation of subnets and network depending on
> >> >performance requirement.
> >> >(Or carefully audit complex status change. i.e.
> >> >changing port during subnet/network update/deletion.)
> >> >
> >> >I think it would be useful to establish reference locking policy
> >> >for ML2 plugin for SDN controllers.
> >> >Thoughts or comments? If this is considered useful and acceptable,
> >> >I'm willing to help.
> >> >
> >> >thanks,
> >> >Isaku Yamahata
> >> >
> >> >> -Bob
> >> >>
> >> >> > Basically, if concurrent API calls are sent to Neutron, all of them
> >> >>are
> >> >> > sent to the plug-in level where two actions have to be made:
> >> >> >
> >> >> > 1. DB transaction ? No just for data persistence but also to
> >>collect
> >> >>the
> >> >> > information needed for the next action
> >> >> > 2. Plug-in back-end implementation ? In our case is a call to the
> >> >>python
> >> >> > library than consequentially calls PLUMgrid REST GW (soon SAL)
> >> >> >
> >> >> > For instance:
> >> >> >
> >> >> > def create_port(self, context, port):
> >> >> > with context.session.begin(subtransactions=True):
> >> >> > # Plugin DB - Port Create and Return port
> >> >> > port_db = super(NeutronPluginPLUMgridV2,
> >> >> > self).create_port(context,
> >> >> >
> >> >> port)
> >> >> > device_id = port_db["device_id"]
> >> >> > if port_db["device_owner"] == "network:router_gateway":
> >> >> > router_db = self._get_router(context, device_id)
> >> >> > else:
> >> >> > router_db = None
> >> >> > try
Re: [openstack-dev] [Neutron] L3 router service integration with Service Type Framework
I just wrote a short spec on the wiki page and link it to the blueprint. I should have done this when we registered the BP. Please let me know if you have any question. Thanks, Gary On Thu, Oct 24, 2013 at 5:35 PM, Gary Duan wrote: > Hi, Geoff, > > This is because I haven't added spec to the BP yet. > > Gary > > > On Thu, Oct 24, 2013 at 4:51 PM, Geoff Arnold wrote: > >> I’m getting a *“**Not allowed here”* error when I click through to the >> BP. (Yes, I’m subscribed.) >> >> On Oct 24, 2013, at 11:56 AM, Gary Duan wrote: >> >> Hi, >> >> I've registered a BP for L3 router service integration with service >> framework. >> >> https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type >> >> In general, the implementation will align with how LBaaS is integrated >> with the framework. One consideration we heard from several team members is >> to be able to support vendor specific features and extensions in the >> service plugin. >> >> Any comment is welcome. >> >> Thanks, >> Gary >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] L3 router service integration with Service Type Framework
Hi, Salvatore, I guess 'router_service_type' extension is used together with 'router_service_insertion'. The purpose of this blueprint is to allow multiple vendor's routing services coexist in a network. One router can be implemented by L3 agent, another one might be from vArmour, NVP or Cisco, for example. Thanks, Gary On Thu, Oct 24, 2013 at 4:13 PM, Salvatore Orlando wrote: > Gary, > > In the context of the nvp plugin we use a mechanism for enabling > 'advanced' capabilities of a router leveraging a 'router_service_type' > extension. > this allow us to configure two types of routers, one which does just L3 > forwarding, NAT and a few other things, and another one which also has the > capability of hosting adv services such as firewall and load balancing. > > Is this similar to what you want to achieve with this blueprint? > > Regards, > Salvatore > > > On 25 October 2013 01:03, Gary Duan wrote: > >> Hi, Oda-san, >> >> Thanks for your response. >> >> L3 agent function should remain the same, as one driver implementation of >> L3 router plugin. >> >> My understanding is your lbaas driver can be running on top of L3 agent >> and LVS' own routing services. Is my understanding correct? >> >> Thanks, >> Gary >> >> >> On Thu, Oct 24, 2013 at 3:16 PM, Itsuro ODA wrote: >> >>> Hi, >>> >>> We are going to implement 2-arm type lbaas using LVS, and have submitted >>> the following BPs. >>> >>> >>> https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion >>> https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver >>> https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features >>> >>> Maybe the first one is same as yours. >>> We are happy if we just concentrate making a provider driver. >>> >>> Thanks. >>> Itsuro Oda >>> >>> On Thu, 24 Oct 2013 11:56:53 -0700 >>> Gary Duan wrote: >>> >>> > Hi, >>> > >>> > I've registered a BP for L3 router service integration with service >>> > framework. >>> > >>> > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type >>> > >>> > In general, the implementation will align with how LBaaS is integrated >>> with >>> > the framework. One consideration we heard from several team members is >>> to >>> > be able to support vendor specific features and extensions in the >>> service >>> > plugin. >>> > >>> > Any comment is welcome. >>> > >>> > Thanks, >>> > Gary >>> >>> -- >>> Itsuro ODA >>> >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] L3 router service integration with Service Type Framework
Hi, Geoff, This is because I haven't added spec to the BP yet. Gary On Thu, Oct 24, 2013 at 4:51 PM, Geoff Arnold wrote: > I’m getting a *“**Not allowed here”* error when I click through to the > BP. (Yes, I’m subscribed.) > > On Oct 24, 2013, at 11:56 AM, Gary Duan wrote: > > Hi, > > I've registered a BP for L3 router service integration with service > framework. > > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type > > In general, the implementation will align with how LBaaS is integrated > with the framework. One consideration we heard from several team members is > to be able to support vendor specific features and extensions in the > service plugin. > > Any comment is welcome. > > Thanks, > Gary > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] L3 router service integration with Service Type Framework
Hi, Oda-san, Thanks for your response. L3 agent function should remain the same, as one driver implementation of L3 router plugin. My understanding is your lbaas driver can be running on top of L3 agent and LVS' own routing services. Is my understanding correct? Thanks, Gary On Thu, Oct 24, 2013 at 3:16 PM, Itsuro ODA wrote: > Hi, > > We are going to implement 2-arm type lbaas using LVS, and have submitted > the following BPs. > > > https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion > https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver > https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features > > Maybe the first one is same as yours. > We are happy if we just concentrate making a provider driver. > > Thanks. > Itsuro Oda > > On Thu, 24 Oct 2013 11:56:53 -0700 > Gary Duan wrote: > > > Hi, > > > > I've registered a BP for L3 router service integration with service > > framework. > > > > https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type > > > > In general, the implementation will align with how LBaaS is integrated > with > > the framework. One consideration we heard from several team members is to > > be able to support vendor specific features and extensions in the service > > plugin. > > > > Any comment is welcome. > > > > Thanks, > > Gary > > -- > Itsuro ODA > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] L3 router service integration with Service Type Framework
Hi, I've registered a BP for L3 router service integration with service framework. https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type In general, the implementation will align with how LBaaS is integrated with the framework. One consideration we heard from several team members is to be able to support vendor specific features and extensions in the service plugin. Any comment is welcome. Thanks, Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Common requirements for services' discussion
I am sorry that I missed this morning's meeting. Reading through the log, one thing that was briefly touch upon is to support Service Type Framework for L3 router service. As all other services (vpn, fw, lb, metering) will be integrated to the service framework in I-release, L3 router service, as a major building block, shouldn't be missed. What we are thinking is to make L3 agent as one of plugin-drivers of L3 router services. This seems to align with comments during the meeting. I wonder if there are enough interests to push this forward. Thanks, Gary On Tue, Oct 22, 2013 at 9:55 AM, Sumit Naiksatam wrote: > Hi All, > > Here is a log of today's discussion: > > > http://eavesdrop.openstack.org/meetings/networking_advanced_services/2013/networking_advanced_services.2013-10-22-15.32.log.html > > (some action items for a few folks who were present, we will follow up in > the next meeting.) > > Thanks, > > ~Sumit. > > > > > On Mon, Oct 21, 2013 at 11:08 PM, Sumit Naiksatam < > sumitnaiksa...@gmail.com> wrote: > >> Hi All, >> >> This is a reminder for the next IRC meeting on Tuesday (Oct 22nd) 15.30 >> UTC (8.30 AM PDT) on the #openstack-meeting-alt channel. >> >> The proposed agenda is: >> * Service insertion and chaining >> * Service agents >> * Service VMs - mechanism >> * Service VMs - policy >> * Extensible APIs for services >> and anything else you may want to discuss in this context. >> >> Meeting wiki page (has pointer to the first meeting logs): >> https://wiki.openstack.org/wiki/Meetings/AdvancedServices >> >> Thanks, >> ~Sumit. >> >> On Thu, Oct 17, 2013 at 12:02 AM, Sumit Naiksatam < >> sumitnaiksa...@gmail.com> wrote: >> >>> Hi All, >>> >>> We will have the "advanced services" and the common requirements IRC >>> meeting on Tuesdays 15.30 UTC (8.30 AM PDT) on the >>> #openstack-meeting-alt channel. The meeting time was chosen to >>> accommodate requests by folks in Asia and will hopefully suit most people >>> involved. Please note that this is the alternate meeting channel. >>> >>> The agenda will be a continuation of discussion from the previous >>> meeting with some additional agenda items based on the sessions already >>> proposed for the summit. The current discussion is being captured in this >>> etherpad: >>> https://etherpad.openstack.org/p/NeutronAdvancedServices >>> >>> Hope you can make it and participate. >>> >>> Thanks, >>> ~Sumit. >>> >>> >>> On Mon, Oct 14, 2013 at 8:15 PM, Sumit Naiksatam < >>> sumitnaiksa...@gmail.com> wrote: >>> Thanks all for attending the IRC meeting today for the Neutron "advanced services" discussion. We have an etherpad for this: https://etherpad.openstack.org/p/NeutronAdvancedServices It was also felt that we need to have more ongoing discussions, so we will have follow up meetings. We will try to propose a more convenient time for everyone involved for a meeting next week. Meanwhile, we can continue to use the mailing list, etherpad, and/or comment on the specific proposals. Thanks, ~Sumit. On Tue, Oct 8, 2013 at 8:30 PM, Sumit Naiksatam < sumitnaiksa...@gmail.com> wrote: > Hi All, > > We had a VPNaaS meeting yesterday and it was felt that we should have > a separate meeting to discuss the topics common to all services. So, in > preparation for the Icehouse summit, I am proposing an IRC meeting on Oct > 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common > aspects related to the FWaaS, LBaaS, and VPNaaS. > > We will begin with service insertion and chaining discussion, and I > hope we can collect requirements for other common aspects such as service > agents, services instances, etc. as well. > > Etherpad for service insertion & chaining can be found here: > > https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining > > Hope you all can join. > > Thanks, > ~Sumit. > > > >>> >> > > ___ > 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
