Re: [openstack-dev] [Neutron] Bug squashing day
Hi Eugene, I dig into few medium priority bugs yesterday and today. Have added comments there. I started from the bottom in the list at etherpad. I will continue to go in the reverse order on daily basis as and when I get time. Let me know if you need any specific help wrt this. ping me on irc (rms_13) or send me an email. Thanks, Ronak ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][policy] Group Based Policy - Renaming
Hi, Following a very interesting and vocal thread on GBP for last couple of days and the GBP meeting today, GBP sub-team proposes following name changes to the resource. policy-point for endpoint policy-group for endpointgroup (epg) Please reply if you feel that it is not ok with reason and suggestion. I hope that it wont be another 150 messages thread :) Ronak ___ 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 and the way forward
We have diverged our attention towards nova-network- neutron parity on this thread unnecessarily. Can we discuss and collectively decide on what is the way forward for GBP in Juno release? Efforts have been made by the subteam starting from throwing PoC at last summit to spec approval to code review. There are usefulness to this feature and I think everyone is on the same page there. Let us not discourage the effort by bringing in existing neutron issue in play. Yes, we has a neutorn community needs to fix that with highest priority. But this is orthogonal effort. If endpoint is not a likeable preferred name than lets propose more meaningful alternative. Let us try to find a middle ground on how this feature can be made generally available. Thanks, Ronak ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Requesting a spec review exception
Hi all, Towards the end of the SAD one of my spec ( https://review.openstack.org/#/c/104378/) did not make it on Sunday; understandably because there were flurry of specs getting reviewed in burst. I would like to ask cores to take a look at this very basic change and see if it can be made in. Please consider my request. Thanks, Ronak ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.
Hi Vikash, Currently this is not supported. the NIC not only needs to be in different subnet, they have to be in different network as well (container for the subnet) Thanks Ronak On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar vikash.ku...@oneconvergence.com wrote: *With 'interfaces' I mean 'nics' of VM*. On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar vikash.ku...@oneconvergence.com wrote: Hi, I want to launch one VM which will have two Ethernet interfaces with IP of single subnet. Is this supported now in openstack ? Any suggestion ? Thanx ___ 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] [policy] Let's make topics mandatory for openstack-dev
I like the proposal and I share the pain of checking for the important emails in the pile of all and potentially missing on some in timely fashion. My 2 cents on top of creating an automated rule: Most of the people (not all) I see on dev-list are active on either 1 or 2 project specific discussions. Why not create openstack-dev-project lists and have people subsribe to project list(s) that they are interested in. Biggest advantage I see with this approach is that one can actively participate by getting individual emails for the project mailing list that they are working on. In parallel they can opt for digest for rest of the project(s) where they act only in read-only mode. Thoughts? Ronak On Thu, Dec 5, 2013 at 3:05 PM, Roman Prykhodchenko rprikhodche...@mirantis.com wrote: Hi folks, Open Stack community grows continuously bringing more people and so new initiatives and new projects. This growing amount of people, initiatives and projects causes increasing the amount of discussions in our mailing list. The problem which I'm talking about is that controlling the mailing list gets harder with the growth of the community. It takes too much time to check for important emails and delete/archive the rest even now. And it does not tend to get any easier in the future. Most of the email services and email clients support filtering incoming emails. So one can automatically get rid of certain emails by creating appropriate filters. Topics in subjects seem to be the best objects for creating rules, i.e., when someone is interested only in Keystone he can create an email filter for '[keystone]' substring in the subject. The problem with the topics is that a lot of emails in openstack-dev do not contain topics in their subjects, which makes this kind of filtering very ineffective. My proposal is to create an automated rule that rejects new emails, if they do not contain any topic in their subject. What do you guys think? - Roman Prykhodchenko - romcheg on freenode.net ___ 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] - api_extensions_path setting
Hi, If a plugin has its own extension, what is the correct way to set api_extensions_path. I can see at multiple places that the practice is this: api_extensions_path=neutron/plugin/extensions/name But if you do that problem mentioned in the following bug starts appearing. https://bugs.launchpad.net/neutron/+bug/1209042 I believe the bug was rejected because of some other reason but the crust of the problem is still true. should I fix it or am I missing something here? Thanks, Ronak ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] - python-neutronclient build failing for latest code reviews
Hi,
I can see on following link that many of the latest code reviews are
reporting build failure at the same point?
https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient,n,z
The backtrace looks liike:
ft46.1: tests.unit.test_shell.ShellTest.test_auth_StringException:
Traceback (most recent call last):
File
/home/jenkins/workspace/gate-python-neutronclient-python26/tests/unit/test_shell.py,
line 71, in setUp
_shell = openstack_shell.NeutronShell('2.0')
File
/home/jenkins/workspace/gate-python-neutronclient-python26/neutronclient/shell.py,
line 244, in __init__
command_manager=commandmanager.CommandManager('neutron.cli'), )
File
/home/jenkins/workspace/gate-python-neutronclient-python26/.tox/py26/lib/python2.6/site-packages/cliff/app.py,
line 72, in __init__
self._set_streams(stdin, stdout, stderr)
File
/home/jenkins/workspace/gate-python-neutronclient-python26/.tox/py26/lib/python2.6/site-packages/cliff/app.py,
line 89, in _set_streams
self.stdin = stdin or codecs.getreader(encoding)(sys.stdin)
File
/home/jenkins/workspace/gate-python-neutronclient-python26/.tox/py26/lib64/python2.6/codecs.py,
line 984, in getreader
return lookup(encoding).streamreader
TypeError: lookup() argument 1 must be string, not None
Does anyone already looking into it?
Thanks,
Ronak
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
