Re: [openstack-dev] DevStack program change
On Fri, Aug 01, 2014 at 03:50:53PM -0500, Anne Gentle wrote: On Fri, Aug 1, 2014 at 10:48 AM, Dean Troyer dtro...@gmail.com wrote: I propose we de-program DevStack and consolidate it into the QA program. Some of my concerns about doing this in the beginning have proven to be a non-issue in practice. Also, I believe a program's focus can and should be wider than we have implemented up to now and this a step toward consolidating narrowly defined programs. Sounds like a good idea to me, as long as QA PTL Matt is good with it. Thanks Dean for your service! Anne Yes, I fully support this idea as well. The scope of the 2 programs' missions are very much aligned, and the two teams are already working closely together. So I think that consolidating the DevStack progam into the QA program is a good idea moving forward. I read the QA mission statement to already include DevStack's purpose so no change should be required there. I'll propose the governance changes following a few days of discussion. This is purely a program-level change, I do not anticipate changes to the DevStack project itself. -Matt Treinish ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core
+1 On 8/1/14, 7:15 PM, Mitsuhiro Tanino mitsuhiro.tan...@hds.com wrote: +1 Regards, Mitsuhiro Tanino mitsuhiro.tan...@hds.com HITACHI DATA SYSTEMS c/o Red Hat, 314 Littleton Road, Westford, MA 01886 -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: Thursday, July 31, 2014 7:58 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core On 07/30/2014 05:10 PM, Russell Bryant wrote: On 07/30/2014 05:02 PM, Michael Still wrote: Greetings, I would like to nominate Jay Pipes for the nova-core team. Jay has been involved with nova for a long time now. He's previously been a nova core, as well as a glance core (and PTL). He's been around so long that there are probably other types of core status I have missed. Please respond with +1s or any concerns. +1 Further, I'd like to propose that we treat all of existing +1 reviews as +2 (once he's officially added to the team). Does anyone have a problem with doing that? I think some folks would have done that anyway, but I wanted to clarify that it's OK. -- Russell Bryant ___ 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] Status of A/A HA for neutron-metadata-agent?
Hi, Happy you asked about this. This is an idea that we have: Below is a suggestion on how we can improve the metadata service. This can be done by leveraging the a Load balancers supports X-Forwarded-For.The following link has two diagrams. The first is the existing support (may be a little rusty here, so please feel free to correct) and the second is the proposal. https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBR C-0E/edit?usp=sharing Metadata proxy support: the proxy will receive the HTTP request. It will then perform a query to the Neutron service (1) to retrieve the tenant id and the instance id from the neutron service. A proxy request will be sent to Nova for the metadata details (2). Proposed support: 1. There will be a load balancer vip 254.169.254.169 (this can be reached either via the L3 agent of the DG on the DHCP. 2. The LB will have a server farm of all of the Nova API's (this makes the soon highly available) 1. Replace the destination IP and port with the Nova metadata IP and port 2. Replace the source IP with the interface IP 3. Insert the header X-Fowarded-For (this will have the original source IP of the VM) 1. When the Nova metadata service receives the request, according to a configuration variable (https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.py #L134), will interface with the neutron service to get the instance_id and the tenant id. This will be done by using a new extension. With the details provided by Neutron Nova will provide the correct metadata for the instance 2. A new extension will be added to Neutron that will enable a port lookup. The port lookup will have two input values and will return the port which has the instance id and the tenant id. 1. LB source IP this is the LB source IP that interfaces with the Nova API. When we create the edge router for the virtual network we will have a mapping of the edge LB ip - network id. This will enable us to get the virtual network for the port 2. Fixed port IP this with the virtual network will enable us to get the specific port. Hopefully in the coming days a spec will be posted that will provide more details Thanks Gary On 8/1/14, 6:11 PM, mar...@redhat.com mandr...@redhat.com wrote: Hi all, I have been asked by a colleague about the status of A/A HA for neutron-* processes. From the 'HA guide' [1], l3-agent and metadata-agent are the only neutron components that can't be deployed in A/A HA (corosync/pacemaker for a/p is documented as available 'out of the box' for both). The l3-agent work is approved for J3 [4] but I am unaware of any work on the metadata-agent and can't see any mention in [2][3]. Is this someone has looked at, or is planning to (though ultimately K would be the earliest right?)? thanks! marios [1] http://docs.openstack.org/high-availability-guide/content/index.html [2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan [3] https://urldefense.proofpoint.com/v1/url?u=https://launchpad.net/neutron/% 2Bmilestone/juno-3k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6h goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5cN I73%2B0jJ8%3D%0As=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19da 3d88681da [4] http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-h igh-availability.rst ___ 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] Step by step OpenStack Icehouse Installation Guide
Dear All, I want to share with you our OpenStack Icehouse Installation Guide for Ubuntu 14.04. https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst An additional guide for Heat service installation is also available ;) https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/OpenStack-Heat-Installation.rst Hope this manuals will be helpful and simple ! Your contributions are welcome, as are questions and suggestions :) Regards, Chaima Ghribi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] Support for Django 1.7: there's a bit of work, though it looks fixable to me...
Hi, The Debian maintainer of Django would like to upload Django 1.7 before Jessie is frozen on the 5th of November. As for OpenStack, I would like Icehouse to be in Jessie, since it will be supported by major companies (RedHat and Canonical both will use Icehouse as LTS, and will work on security for a longer time than previously planned in the OpenStack community). Though Horizon Icehouse doesn't currently work with Django 1.7. The first thing to fix would be the TEMPLATE_DIRS thing: ./run_tests.sh -N -P || true Running Horizon application tests Traceback (most recent call last): File /home/zigo/sources/openstack/icehouse/horizon/build-area/horizon-2014.1.1/manage.py, line 25, in module execute_from_command_line(sys.argv) File /usr/lib/python2.7/dist-packages/django/core/management/__init__.py, line 385, in execute_from_command_line utility.execute() [... not useful stack dump ...] File /usr/lib/python2.7/dist-packages/django/conf/__init__.py, line 42, in _setup self._wrapped = Settings(settings_module) File /usr/lib/python2.7/dist-packages/django/conf/__init__.py, line 110, in __init__ Please fix your settings. % setting) django.core.exceptions.ImproperlyConfigured: The TEMPLATE_DIRS setting must be a tuple. Please fix your settings. Running openstack_dashboard tests WARNING:root:No local_settings file found. Then of course, the rest of the tests are completely broken because there's no local_settings. Adding a comma at the end of: TEMPLATE_DIRS = (os.path.join(ROOT_PATH, 'tests', 'templates')) in horizon/test/settings.py fixes the issue. Note that this works in both Django 1.6 and 1.7. Some other TEMPLATE_DIRS declaration already have the comma, so I guess it's fine to add it. Which is why I did this: https://review.openstack.org/111561 FYI, there's this document that talks about it: https://docs.djangoproject.com/en/1.7/releases/1.7/#backwards-incompatible-changes-in-1-7 Then, after fixing this, I get this error: == ERROR: Failure: TypeError (Error when calling the metaclass bases function() argument 1 must be code, not str) -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nose/loader.py, line 414, in loadTestsFromName addr.filename, addr.module) File /usr/lib/python2.7/dist-packages/nose/importer.py, line 47, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/python2.7/dist-packages/nose/importer.py, line 94, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File /home/zigo/sources/openstack/icehouse/horizon/build-area/horizon-2014.1.1/horizon/test/tests/tables.py, line 28, in module from horizon.test import helpers as test File /home/zigo/sources/openstack/icehouse/horizon/build-area/horizon-2014.1.1/horizon/test/helpers.py, line 184, in module class JasmineTests(SeleniumTestCase): TypeError: Error when calling the metaclass bases function() argument 1 must be code, not str There's the same issue in the definition of SeleniumTestCase() in openstack_dashboard/test/helpers.py (line 365 in Icehouse). Since I don't really care about selenium (it can't be tested in Debian because it's non-free), I commented out the class JasmineTests(SeleniumTestCase), then I get more errors. A few instances of this one: File /home/zigo/sources/openstack/icehouse/horizon/build-area/horizon-2014.1.1/horizon/tables/base.py, line 206, in lambda average: lambda data: sum(data, 0.0) / len(data) TypeError: unsupported operand type(s) for +: 'float' and 'str' I'm not a Django expert, so I it'd be awesome to get help on this. Best would be that: 1/ Support for Django 1.7 is added to Juno 2/ The changes are backported to Icehouse (even if this doesn't make it into the stable branch because of let's stay safe, I can add the patches as Debian specific). Thoughts from the Horizon team would be welcome. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?
Hi, The link below is broken. Please see - https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBR C-0E/edit In short this will give a highly available service without the need for the metadata proxy. It will also have one less hop = better performance. Thanks Gary On 8/3/14, 1:07 PM, Gary Kotton gkot...@vmware.com wrote: Hi, Happy you asked about this. This is an idea that we have: Below is a suggestion on how we can improve the metadata service. This can be done by leveraging the a Load balancers supports X-Forwarded-For.The following link has two diagrams. The first is the existing support (may be a little rusty here, so please feel free to correct) and the second is the proposal. https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfB R C-0E/edit?usp=sharing Metadata proxy support: the proxy will receive the HTTP request. It will then perform a query to the Neutron service (1) to retrieve the tenant id and the instance id from the neutron service. A proxy request will be sent to Nova for the metadata details (2). Proposed support: 1. There will be a load balancer vip 254.169.254.169 (this can be reached either via the L3 agent of the DG on the DHCP. 2. The LB will have a server farm of all of the Nova API's (this makes the soon highly available) 1. Replace the destination IP and port with the Nova metadata IP and port 2. Replace the source IP with the interface IP 3. Insert the header X-Fowarded-For (this will have the original source IP of the VM) 1. When the Nova metadata service receives the request, according to a configuration variable (https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.p y #L134), will interface with the neutron service to get the instance_id and the tenant id. This will be done by using a new extension. With the details provided by Neutron Nova will provide the correct metadata for the instance 2. A new extension will be added to Neutron that will enable a port lookup. The port lookup will have two input values and will return the port which has the instance id and the tenant id. 1. LB source IP this is the LB source IP that interfaces with the Nova API. When we create the edge router for the virtual network we will have a mapping of the edge LB ip - network id. This will enable us to get the virtual network for the port 2. Fixed port IP this with the virtual network will enable us to get the specific port. Hopefully in the coming days a spec will be posted that will provide more details Thanks Gary On 8/1/14, 6:11 PM, mar...@redhat.com mandr...@redhat.com wrote: Hi all, I have been asked by a colleague about the status of A/A HA for neutron-* processes. From the 'HA guide' [1], l3-agent and metadata-agent are the only neutron components that can't be deployed in A/A HA (corosync/pacemaker for a/p is documented as available 'out of the box' for both). The l3-agent work is approved for J3 [4] but I am unaware of any work on the metadata-agent and can't see any mention in [2][3]. Is this someone has looked at, or is planning to (though ultimately K would be the earliest right?)? thanks! marios [1] http://docs.openstack.org/high-availability-guide/content/index.html [2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan [3] https://urldefense.proofpoint.com/v1/url?u=https://launchpad.net/neutron/ % 2Bmilestone/juno-3k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6 h goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5c N I73%2B0jJ8%3D%0As=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19d a 3d88681da [4] http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3- h igh-availability.rst ___ 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] [nova][qa] turbo-hipster seems very unhappy
Hey Matt, You're absolutely right. We've been having trouble since a change to nova requirements was merged. We release we're a long way behind and are working on getting things back to normal as soon as possible. My apologies for the inconvenience. Cheers, Josh From: Matt Riedemann [mrie...@linux.vnet.ibm.com] Sent: Wednesday, July 30, 2014 8:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][qa] turbo-hipster seems very unhappy I've seen t-h failing on many patches today, most that aren't touching the database migrations, but it's primarily catching my attention because of the failure on this change: https://review.openstack.org/#/c/109660/ It looks like a pretty simple issue of the decorator package not being in whatever pypi mirror that t-h is using. -- Thanks, Matt Riedemann ___ 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] Step by step OpenStack Icehouse Installation Guide
On Sun, Aug 3, 2014 at 1:49 PM, chayma ghribi chaym...@gmail.com wrote: Dear All, I want to share with you our OpenStack Icehouse Installation Guide for Ubuntu 14.04. https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst An additional guide for Heat service installation is also available ;) https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/OpenStack-Heat-Installation.rst All this docs are awesome! Great work! But what about Trove(incubated and integrated) installation guide? Hope this manuals will be helpful and simple ! Your contributions are welcome, as are questions and suggestions :) Regards, Chaima Ghribi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Best regards, Denis Makogon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Step by step OpenStack Icehouse Installation Guide
Hi Denis ! Thank you for your interest ! We will share the Trove installation guide as soon as it's ready ;) Regards, Chaima Ghribi 2014-08-03 17:21 GMT+02:00 Denis Makogon dmako...@mirantis.com: On Sun, Aug 3, 2014 at 1:49 PM, chayma ghribi chaym...@gmail.com wrote: Dear All, I want to share with you our OpenStack Icehouse Installation Guide for Ubuntu 14.04. https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst An additional guide for Heat service installation is also available ;) https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/OpenStack-Heat-Installation.rst All this docs are awesome! Great work! But what about Trove(incubated and integrated) installation guide? Hope this manuals will be helpful and simple ! Your contributions are welcome, as are questions and suggestions :) Regards, Chaima Ghribi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Best regards, Denis Makogon ___ 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] [TripleO] Strategy for merging Heat HOT port
On 01/08/14 12:19, Steve Baker wrote: The changes to port tripleo-heat-templates to HOT have been rebased to the current state and are ready to review. They are the next steps in blueprint tripleo-juno-remove-mergepy. However there is coordination needed to merge since every existing tripleo-heat-templates change will need to be rebased and changed after the port lands (lucky you!). Here is a summary of the important changes in the series: https://review.openstack.org/#/c/105327/ Low risk and plenty of +2s, just needs enough validation from CI for an approve Merged https://review.openstack.org/#/c/105328/ Scripted conversion to HOT. Converts everything except Fn::Select This is now: - rebased against 82c50c1 Fix swift memcache and device properties - switched to heat_template_version: 2014-10-16 to get list_join - is now passing CI https://review.openstack.org/#/c/105347/ Manual conversion of Fn::Select to extended get_attr I'd like to suggest the following approach for getting these to land: * Any changes which really should land before the above 3 get listed in this mail thread (vlan?) * Reviews of the above 3 changes, and local testing of change 105347 * All other tripleo-heat-templates need to be rebased/reworked to be after 105347 (and maybe -2 until they are?) I'm available for any questions on porting your changes to HOT. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS][Tempest] LBaaS API Tempest testing status update
Hi, Today I have confirmed with a Tempest api test script that all the operations for loadbalancers, listeners, healthmonitors and pools for the new LBaaS v2.0 work correctly. As for members, POST, PUT and GET operations also work correctly. The only exception is the DELETE operation. The test script failed with it. I will investigate the cause tomorrow Cheers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Marconi][Zaqar] Adding Victoria Martínez de la Cruz (vkmc) to Zaqar's core team
+1 ! On Fri, Aug 1, 2014 at 11:27 PM, Sriram Madapusi Vasudevan sriram.madapusiva...@rackspace.com wrote: +1 for sure! :D Sriram Madapusi Vasudevan On Aug 1, 2014, at 10:21 AM, Malini Kamalambal malini.kamalam...@rackspace.com wrote: A HUGE +1 ! On 8/1/14 10:11 AM, Flavio Percoco fla...@redhat.com wrote: Greetings, I'd like to propose adding Victoria Martínez de la Cruz (vkmc) to zaqar's core team. Victoria has been part of the community for several months now. During this time, she's been contributing to many different areas: - Docs - Code - Community Support - Research (amazing work on the amqp side) She's a great asset of Zaqar's community. If no one objects, I'll proceed and add her in a week from now. Flavio -- @flaper87 Flavio Percoco ___ 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 -- Cheers Best regards, Peng Fei Wang (王鹏飞) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [marconi] Proposal to add Victoria Martínez de la Cruz as a core reviewer
+1, welcome join the team, vkmc! On 02/08/14 05:17, Kurt Griffiths wrote: Hi crew, I'd like to propose Vicky (vkmc) be added to Marconi's core reviewer team. She is a regular contributor in terms of both code and reviews, is an insightful and regular participant in team discussions, and leads by example in terms of quality of work, treating others as friends and family, and being honest and constructive in her community participation. Marconi core reviewers, please respond with +1 or -1 per your vote on adding Vicky. -- Kurt G. (kgriffs) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cheers Best regards, Fei Long Wang (???) -- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
+1 I think your suggestions are admirable and would be good if this is taken on board, having a timeframe around items would definitely help focus and ensure reviews in a timely manner. /Alan From: Rudra Rugge [mailto:ru...@contrailsystems.com] Sent: July-31-14 6:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21 Hi Kyle, I also agree with Mandeep's suggestion of putting a time frame on the lingering -2 if the addressed concerns have been taken care of. In my experience also a sticky -2 detracts other reviewers from reviewing an updated patch. Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review. Regards, Rudra On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.commailto:dh...@noironetworks.com wrote: Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.commailto:yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not approved yet); May, 21 - first part of Neutron code [2] is found generally OK by reviewers; May, 21 - first version of Oslo spec is published at [4]; May, 29 - a version of the second part of Neutron code [3] is published that later raises only minor comments by reviewers; Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark because BP isn't approved yet; Jun, 23 - Oslo spec [4] is mostly ironed out; Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2; Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change requests; Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception; Jul, 31 - I'm getting final decision as follows: Your BP will extremely unlikely get to Juno. Do you see what I see? Code and spec is mostly finished in May (!) where the mostly part is lack of reviewers because of that Mark's -2. And 1 month later when all bureaucratic reasons fall off nothing happens. Don't think I didn't try to approach Mark. Don't think I didn't approach Kyle on this issue. Because I did. But nothing happens and another month passes by and I get You know, may be later general response. Noone (but those who knew about it originally) even looks at my code for 2 months already because Mark doesn't think (I hope he did think) he should lift -2 and I'm getting why not wait another 3 months? What the hell is that? You don't want to land features that doesn't have code 2 weeks before Juno-3, I get
[openstack-dev] [Cinder] Bug 1224972 When createing a volume from an image - nova leaves the volume name empty
Hi, I just need a suggestion to fix this bug. Link to the bug : https://bugs.launchpad.net/nova/+bug/1224972 This bug says that the name of the volume is not set when an instance is booted from a new volume giving image as the source. Fix for this bug could be at the Nova side wherein we append the name of the image as the volume name and call cinder api to create volume with it. Would the fix for this bug be better handled if it is done at the cinder level? If the request to create a volume comes without a name, a default (image or vol name from which it is created - this is how horizon behaves) name can be given as display name for volume creation. Thanks, Sandhya. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
