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 joshua.hesk...@rackspace.com 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 sumitnaiksa...@gmail.com 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 ido...@gmail.com 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 mandr...@redhat.comwrote:
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) p...@cisco.com 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) p...@cisco.com 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 enikano...@mirantis.comwrote: 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
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 obonda...@mirantis.comwrote: Hi Gary, please see my comments on the review. Thanks, Oleg On Wed, Feb 12, 2014 at 5:52 AM, Gary Duan garyd...@gmail.com 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] 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 dh...@noironetworks.comwrote: I would be interested as well (UTC-8). Regards, Mandeep On Wed, Feb 12, 2014 at 8:18 AM, Eugene Nikanorov enikano...@mirantis.com wrote: I'd be interested too. Thanks, Eugene. On Wed, Feb 12, 2014 at 7:51 PM, Carl Baldwin c...@ecbaldwin.net 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 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 ___ 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] [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
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 clark.boy...@gmail.comwrote: On Tue, Feb 11, 2014 at 5:52 PM, Gary Duan garyd...@gmail.com 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
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 clark.boy...@gmail.comwrote: On Tue, Feb 11, 2014 at 7:05 PM, Gary Duan garyd...@gmail.com 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 clark.boy...@gmail.com wrote: On Tue, Feb 11, 2014 at 5:52 PM, Gary Duan garyd...@gmail.com 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
[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 sorla...@nicira.comwrote: 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 na...@ntti3.com wrote: I'm +1 for 'provider'. 2013/12/9 Akihiro Motoki mot...@da.jp.nec.com: 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 mailto: 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 emag...@plumgrid.com wrote: Also joining! Looking forward to hearing your ideas folks! Edgar On 12/10/13 10:16 AM, Nachi Ueno na...@ntti3.com 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 i...@embrane.com: +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 anthony_ve...@cable.comcast.com wrote: -Original Message- From: Kyle Mestery mest...@siliconloons.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, December 10, 2013 10:48 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org 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 gd...@varmour.com 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 isaku.yamah...@gmail.comwrote: 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? 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 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
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 emag...@plumgrid.com 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 isaku.yamah...@gmail.com wrote:
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-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 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
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 gd...@varmour.com 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 ge...@geoffarnold.comwrote: 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 gd...@varmour.com 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
[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] 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 o...@valinux.co.jp 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 gd...@varmour.com 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 o...@valinux.co.jp ___ 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 ge...@geoffarnold.com 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 gd...@varmour.com 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] 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 sumitnaiksa...@gmail.comwrote: 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
