Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core
Thank you! From: "Armando M." <arma...@gmail.com<mailto:arma...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, December 15, 2016 at 2:57 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core On 15 December 2016 at 09:50, Akihiro Motoki <amot...@gmail.com<mailto:amot...@gmail.com>> wrote: +1 Welcome to the team Abhishek! 2016-12-14 10:22 GMT+09:00 Armando M. <arma...@gmail.com<mailto:arma...@gmail.com>>: Hi folks, Abhishek Raut's recent involvement in OSC and python-neutronclient has helped moving a few efforts along in the right direction. I would like to suggest we double down on core firepower for the neutronclient repo alongside Akihiro [1]. This not only will help speed up our transition to OSC CLI, but also improve the number of folks who can effectively liasion with the OSC team, and look after the needs of neutron's client repo. Many thanks, Armando [1] https://review.openstack.org/#/c/410485/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] BGP support
I think what Gary is talking about is BGP and the Border Gateway API spec[1] in L2 GW repo. [1] https://review.openstack.org/#/c/270786/ -Abhishek Raut From: "Tidwell, Ryan" <ryan.tidw...@hpe.com<mailto:ryan.tidw...@hpe.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, March 30, 2016 at 4:52 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron] BGP support Gary, I'm not sure I understand the relationship you're drawing between BGP and L2 GW, could you elaborate? The BGP code that landed in Mitaka is mostly geared toward the use case where you want to directly route your tenant networks without any NAT (ie no floating IP's, no SNAT). Neutron peers with upstream routers and announces prefixes that tenants allocate dynamically. We have talked about how we could build on what was merged in Mitaka to support L3 VPN in the future, but to my knowledge no concrete plan has emerged as of yet. -Ryan From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Sunday, March 27, 2016 11:36 PM To: OpenStack List Subject: [openstack-dev] [Neutron] BGP support Hi, In the M cycle BGP support was added in tree. I have seen specs in the L2 GW project for this support too. Are we planning to consolidate the efforts? Will the BGP code be moved from the Neutron git to the L2-GW project? Will a new project be created? Sorry, a little in the dark here and it would be nice if someone could please provide some clarity here. It would be a pity that there were competing efforts and my take would be that the Neutron code would be the single source of truth (until we decide otherwise). I think that the L2-GW project would be a very good place for that service code to reside. It can also have MPLS etc. support. So it may be a natural fit. Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][neutron-lib] Proposal for callback mechanism migration
Subject changed from [neutorn] to [neutron] so that it reaches correct folders via rules ;) -Abhishek Raut From: Paul Michali <p...@michali.net<mailto:p...@michali.net>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, January 12, 2016 at 8:11 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [neutorn][neutron-lib] Proposal for callback mechanism migration I wanted to float two ideas related to the neutron callback mechanism that is being moved to neutron-lib. 1) API The current API uses kwargs as a way for the notifier to pass information to the subscribers listening (callbacks). One issue with this, is that the actual keyword arguments used, could clash with the positional argument names. To address this, I'm proposing that we do the same as is done in the Requests package to pass a payload to the get() method, where a 'params' positional argument is used to hold a dict with the arguments to be passed to the callback. I've pushed a commit to neutron-lib for review https://review.openstack.org/265997. Please provide your comments on that as a proposed solution. 2) Migrating callbacks in neutron to use neutron-lib I was thinking that the following plan (A) could work, as a way to migrate to using the callback mechanism in neutron-lib: 1. In neutron, where callback notifications are performed, add a duplicate notification to the neutron-lib callback notification. 2. In each client repo, change the subscription to subscribe to the neutron-lib version of the resource/event tuple. At this time, the clients could be altered to use the new 'params' positional argument 3. Once all the client repos have been updated, remove the old notification calls from neutron, the callback code, and callback UTs. An alternative proposal (B), *may* be to: 1. Change the notification wrapper method in registry.py to call both the existing callback notify() and the one in neutron_lib. For the latter, the kwargs would need to be stored in the params dict. 2. This and next step are the same as in proposal (A). I think plan A gives more flexibility in converting kwargs into a param dict, at the expense of more of a change impact (32 places/9 files). Looking forward to community feedback on this... Regards, Paul Michali (pc_m) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions
There is this review[1] trying to solve exactly what you¹re asking for. I think it makes sense for the exceptions to be propagated all the way back to the user instead of swallowing them and then roll back the transaction. Does it even make sense to continue after a failure? [1] https://review.openstack.org/#/c/202061/ ‹Abhishek Raut On 8/4/15, 3:02 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, in feature/qos, we use ml2 extension drivers to handle additional qos_policy_id field that can be provided thru API: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2 /extensions/qos.py?h=feature/qos What we do in qos extension is we create a database 'binding' object between the updated port and the QoS policy that corresponds to qos_policy_id. So we access the database. It means there may be some complications there, f.e. the policy object is not available for the tenant, or just does not exist. In that case, we raise an exception from the extension, assuming that ml2 will propagate it to the user in some form. But it does not work. This is because _call_on_ext_drivers swallows exceptions: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2 /managers.py#n766 It makes me ask some questions: - - first, do we use extensions as was expected? Can we extend extensions to cover our use case? - - second, what would be the right way to go assuming we want to support the case? Should we just reraise? Or maybe postpone till all extension drivers are called, and then propagate an exception top into the stack? (Probably some extension manager specific exception?) Or maybe we want extensions to claim whether they may raise, and handle them accordingly? - - alternatively, if we abuse the API and should stop doing it, which other options do we have to achieve similar behaviour without relying on ml2 extensions AND without polluting ml2 driver with qos specific cod e? Thanks for your answers, Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwI29AAoJEC5aWaUY1u57yLYH/jhYmu4aR+ewZwSzDYXMcfdz tD5BSYKD/YmDMIAYprmVCqOlk1jaioesFPMUOrsycpacZZWjg5tDSrpJ2Iz5/ZPw BYLIPGaYF3Pu87LHrUKhIz4f2TfSWve/7GBCZ6AK6zVqCXky8A9MRfWrf774a8oF kexP7qQVbyrOcXxZANDa1bJuLDsb4TiTcuuDizPtuUWlMfzmtZeauyieji/g1smq HBO5h7zUFQ87YvBqq7ed2KhlRENxo26aSrpxTFkyyxJU9xH1J8q9W1gWO7Tw1uCV psaijDmlxU/KySR97Ro8m5teu+7Pcb2cg/s57WaHWuAvPNW1CmfYc/XDn2I9KlI= =Fo++ -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-dev][neutron] A question about cisco network_profiles.xxxx uri
Hello,
Fix for the issue mentioned below has been committed and merged into the master
repository. https://review.openstack.org/#/c/109149/
Your patch should be good to go after a rebase.
Thanks,
Abhishek Raut
From: Yangxurong yangxur...@huawei.commailto:yangxur...@huawei.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wed, 23 Jul 2014 12:02:05 +
To:
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [OpenStack-dev][neutron] A question about cisco
network_profiles. uri
Hi folks,
I’m planning to fix bug/1330095[1], which aims to solve the invalid suffix uri
as follow, but I hit a problem of cisco n1kv plugin testing case[2].
[1]https://bugs.launchpad.net/neutron/+bug/1330095
When submitting a REST request as follow:
POST http://localhost:9696/v2.0/routers.@@@xxx
body:
{
router:{
name: ddd
}
}
the request finishes without error.
Generally the string following . in the request path will be matched as the
format which specifies the format of the request body, like xml or json. I
think we need to check the validity of the suffix and filter out invalid format
like @@@xxx.
I hit one testing case failure in cisco n1kv plugin when I submit my
patch:https://review.openstack.org/108683
[2] the issues in network_profiles.xxx uri test case:
/network_profiles.{'network_profile': {'segment_range': '1-10010',
'segment_type': 'overlay', 'name': 'netp1', 'tenant_id': 'some_tenant',
'sub_type': 'enhanced', 'multicast_ip_range': '224.1.1.1-224.1.1.10'}}
So the content in the dictionary was matched as the format. This test case
expects to catch a HTTP 400 exception. I am not sure whether this test case is
testing an invalid request path, or cisco n1kv plugin supports such path, it's
some mistakes in the dictionary that cause the exception.
Any good idea or suggestion about this issue?
Regards,
XuRong Yang
___ OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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
