Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
Are there any parity features you are aware of that aren't receiving adequate developer/reviewer time? I'm not aware of any parity features that are in a place where throwing more engineers at them is going to speed anything up. Maybe Mark McClain (Nova parity leader) can provide some better

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Gary Kotton
On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote: On 08/05/2014 01:23 PM, Gary Kotton wrote: Ok, thanks for the clarification. This means that it will not be done automagically as it is today ­ the tenant will need to create a Neutron port and then pass that through. FWIW, that's

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Gary Kotton
Correct, this work is orthogonal to the parity work, which I understand is coming along very nicely. Do new features in Nova also require parity - https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks (for example enables the MTU to be configured instead of via a

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

2014-08-06 Thread Jesse Pretorius
In many cases the users I've spoken to who are looking for a live path out of nova-network on to neutron are actually completely OK with some API service downtime (metadata service is an API service by their definition). A little 'glitch' in the network is also OK for many of them. Contrast

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton gkot...@vmware.com wrote: On 8/5/14, 8:53 PM, Russell Bryant rbry...@redhat.com wrote: On 08/05/2014 01:23 PM, Gary Kotton wrote: Ok, thanks for the clarification. This means that it will not be done automagically as it is today ­ the tenant

Re: [openstack-dev] [Neutron] l2pop problems

2014-08-06 Thread Mathieu Rohon
Hi Zang, On Tue, Aug 5, 2014 at 1:18 PM, Zang MingJie zealot0...@gmail.com wrote: Hi Mathieu: We have deployed the new l2pop described in the previous mail in our environment, and works pretty well. It solved the timing problem, and also reduces lots of l2pop rpc calls. I'm going to file a

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Masakazu Shinohara
Hi, I'm Masakazu Shinohara of Cyberagent corporation in Japan. I am a representative of our new cloud network project. We have a lot of services such as on line games blogs or all kind of web services. Now we have been testing Openstack and Cisco ACI. It is a really important thing that they

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
On Tue, Aug 5, 2014 at 11:46 PM, Gary Kotton gkot...@vmware.com wrote: Correct, this work is orthogonal to the parity work, which I understand is coming along very nicely. Agree Gary and Kevin. I think the topic of Nova integration has created confusion in people’s mind (at least the

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Gary Kotton
From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, August 6, 2014 at 10:09 AM To: OpenStack List

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Martin Geisler
Ben Nemec openst...@nemebean.com writes: On 08/05/2014 03:14 PM, Yuriy Taraday wrote: When you're developing some big change you'll end up with trying dozens of different approaches and make thousands of mistakes. For reviewers this is just unnecessary noise (commit title Scratch my last

Re: [openstack-dev] [Neutron][oslo] Problem installing oslo.config-1.4.0.0a3 from .whl files

2014-08-06 Thread Matthieu Huin
Thank you so much ! I had the same problem yesterday and was out of ideas to solve this. Matthieu Huin m...@enovance.com - Original Message - From: Alexei Kornienko alexei.kornie...@gmail.com To: openstack-dev@lists.openstack.org Sent: Tuesday, August 5, 2014 10:08:45 PM Subject:

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote: From: Aaron Rosen aaronoro...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Wednesday, August 6, 2014 at 10:09 AM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re:

Re: [openstack-dev] [Fuel] Blueprints process

2014-08-06 Thread Mike Scherbakov
As we are before next milestone, let's get back to this excellent (in my opinion) proposal from Dmitry. Current situation is the following: there are 121 blueprints targeted for 6.0. Most of them miss a header with QA/reviewers/developers information, basically those are incomplete blueprints

[openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Stefano Santini
Hi, In my company (Vodafone), we (DC network architecture) are following very closely the work happening on Group Based Policy since we see a great value on the new paradigm to drive network configurations with an advanced logic. We're working on a new production project for an internal private

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Yuriy Taraday
I'd like to stress this to everyone: I DO NOT propose squashing together commits that should belong to separate change requests. I DO NOT propose to upload all your changes at once. I DO propose letting developers to keep local history of all iterations they have with a change request. The history

Re: [openstack-dev] [Fuel] Blueprints process

2014-08-06 Thread Sergii Golovatiuk
Hi, I really like what Mike proposed. It will help us to keep milestone clean and accurate. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Wed, Aug 6, 2014 at 11:26 AM, Mike Scherbakov mscherba...@mirantis.com wrote: As we are before next milestone, let's get back to this

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Gary Kotton
From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, August 6, 2014 at 11:11 AM To: OpenStack List

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Sylvain Bauza
Le 06/08/2014 10:35, Yuriy Taraday a écrit : I'd like to stress this to everyone: I DO NOT propose squashing together commits that should belong to separate change requests. I DO NOT propose to upload all your changes at once. I DO propose letting developers to keep local history of all

Re: [openstack-dev] backport fixes to old branches

2014-08-06 Thread Osanai, Hisashi
On Tuesday, August 05, 2014 8:57 PM, Ihar Hrachyshka wrote: Thanks. To facilitate quicker backport, you may also propose the patch for review yourself. It may take time before stable maintainers or other interested parties get to the bug and do cherry-pick. Thank you for your advice. I

Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process

2014-08-06 Thread Lucas Alvares Gomes
Already agreed with the idea at the midcycle, but just making it public: +1 On Tue, Aug 5, 2014 at 8:54 PM, Roman Prykhodchenko rprikhodche...@mirantis.com wrote: Hi! I think this is a nice idea indeed. Do you plan to use this process starting from Juno or as soon as possible? It will start

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Yuriy Taraday
On Wed, Aug 6, 2014 at 12:55 PM, Sylvain Bauza sba...@redhat.com wrote: Le 06/08/2014 10:35, Yuriy Taraday a écrit : I'd like to stress this to everyone: I DO NOT propose squashing together commits that should belong to separate change requests. I DO NOT propose to upload all your changes

[openstack-dev] Tox run failure during installation of dependencies in requirements

2014-08-06 Thread Narasimhan, Vivekanandan
Hi, Recently , the Tox runs started to fail in my workspace. It fails consistently during installing dependencies with the following. Downloading/unpacking PrettyTable=0.7,0.8 (from python-keystoneclient=0.10.0--r /home/narasimv/dev/bug1350485/neutron/requirements.txt (line 22)) Cleaning

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Christopher Yeoh
On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen aaronoro...@gmail.com wrote: On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote: From: Aaron Rosen aaronoro...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Wednesday, August 6, 2014 at 10:09

Re: [openstack-dev] Tox run failure during installation of dependencies in requirements

2014-08-06 Thread Matthieu Huin
Hi, Can you reach pypi.python.org ? Matthieu Huin m...@enovance.com - Original Message - From: Vivekanandan Narasimhan vivekanandan.narasim...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, August 6, 2014

Re: [openstack-dev] Tox run failure during installation of dependencies in requirements

2014-08-06 Thread Igor Degtiarov
Hi, Actually the same question, what is wrong with Tox now? -- Igor On Wed, Aug 6, 2014 at 1:19 PM, Narasimhan, Vivekanandan vivekanandan.narasim...@hp.com wrote: Hi, Recently , the Tox runs started to fail in my workspace. It fails consistently during installing dependencies with

Re: [openstack-dev] [Openstack] OpenStack Heat installation guide and Heat utilisation manual

2014-08-06 Thread marwen mechtri
Thank you for your suggestion. I will investigate it and see how to integrate the trust model in the heat template (if possible). Regards, Marouen Mechtri 2014-08-06 5:23 GMT+02:00 Don Waterloo don.water...@gmail.com: On 5 August 2014 18:10, marwen mechtri mechtri.mar...@gmail.com wrote:

Re: [openstack-dev] Tox run failure during installation of dependencies in requirements

2014-08-06 Thread Chmouel Boudjnah
On Wed, Aug 6, 2014 at 12:19 PM, Narasimhan, Vivekanandan vivekanandan.narasim...@hp.com wrote: Timeout: (pip._vendor.requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x37e4790, 'Connection to pypi.python.org timed out. (connect timeout=15)') I think this error

Re: [openstack-dev] [Openstack] OpenStack Heat installation guide and Heat utilisation manual

2014-08-06 Thread Andreas Jaeger
On 08/06/2014 05:23 AM, Don Waterloo wrote: On 5 August 2014 18:10, marwen mechtri mechtri.mar...@gmail.com wrote: Hi all, I want to present you our OpenStack Heat installation guide for Icehouse release.

Re: [openstack-dev] [Neutron][LBaaS] status in entities

2014-08-06 Thread Vijay Venkatachalam
I agree. the current status can reflect the deployment status and we can add a new attribute to reflect operational status. I also agree that adminstate_up should definitely affect operational status. But driver could choose to unprovision when admin state is set to false. In which case status

[openstack-dev] [horizon] Package python-django-pyscss dependencies on CentOS

2014-08-06 Thread Timur Sufiev
Hi! Here is the link: http://koji.fedoraproject.org/koji/rpminfo?rpmID=5239113 The question is whether the python-pillow package really needed for proper compiling css from scss in Horizon or is it an optional requirement which can be safely dropped? The problem with python-pillow is that it

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kyle Mestery
On Wed, Aug 6, 2014 at 3:11 AM, Aaron Rosen aaronoro...@gmail.com wrote: On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton gkot...@vmware.com wrote: From: Aaron Rosen aaronoro...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Wednesday, August 6, 2014 at 10:09 AM

Re: [openstack-dev] Step by step OpenStack Icehouse Installation Guide

2014-08-06 Thread chayma ghribi
Hi stefano ! Yes, it's a pleasure to contribute and to join the documentation team. Ok! I will send announcements to the other mailing list ;) Regards, Chaima 2014-08-06 1:15 GMT+02:00 Stefano Maffulli stef...@openstack.org: On 08/03/2014 03:49 AM, chayma ghribi wrote: I want to share

Re: [openstack-dev] [TripleO][Nova][Neutron] multiple hypervisors on one compute host - neutron agent and compute hostnames

2014-08-06 Thread Kyle Mestery
On Tue, Aug 5, 2014 at 6:17 PM, Robert Collins robe...@robertcollins.net wrote: Hi! James has run into an issue implementing the multi-hypervisor spec (http://git.openstack.org/cgit/openstack/tripleo-specs/tree/specs/juno/tripleo-juno-deploy-cloud-hypervisor-type.rst) which we're hoping to

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Russell Bryant
On 08/05/2014 05:24 PM, Sumit Naiksatam wrote: On Tue, Aug 5, 2014 at 1:41 PM, Jay Pipes jaypi...@gmail.com wrote: On 08/05/2014 04:26 PM, Stephen Wong wrote: Agreed with Kevin and Sumit here. As a subgroup we talked about Nova integration, and the preliminary idea, as Bob alluded to, is to

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Russell Bryant
On 08/05/2014 06:13 PM, Kevin Benton wrote: That makes sense. It's not quite a fair analogy though to compare to reintroducing projects or tenants because Keystone endpoints aren't 'user-facing' so to speak. i.e. a regular user (application deployer, instance operator, etc) should never have

Re: [openstack-dev] [Openstack] OpenStack Heat installation guide and Heat utilisation manual

2014-08-06 Thread marwen mechtri
Hi Andreas, It's pleasure to work together on the OpenStack heat templates documentation. In our manual, we provide two templates with the associated descriptions (and pictures). The first one is useful when we deploy 2 interconnected VMs and the second one can be used to update the template

Re: [openstack-dev] Which program for Rally

2014-08-06 Thread Russell Bryant
On 08/06/2014 06:30 AM, Thierry Carrez wrote: Hi everyone, At the TC meeting yesterday we discussed Rally program request and incubation request. We quickly dismissed the incubation request, as Rally appears to be able to live happily on top of OpenStack and would benefit from having a

Re: [openstack-dev] Tox run failure during installation of dependencies in requirements

2014-08-06 Thread Narasimhan, Vivekanandan
Hi Igor /Matthieu, I am getting random connection timeouts to pypi.python.org with my machine behind the proxy when trying to run Tox –e pep8 Dependency installation fails with the stack trace posted below. However, similar issue does not occur when I use run_tests.sh to run the same set

Re: [openstack-dev] Which program for Rally

2014-08-06 Thread Sean Dague
On 08/06/2014 09:11 AM, Russell Bryant wrote: On 08/06/2014 06:30 AM, Thierry Carrez wrote: Hi everyone, At the TC meeting yesterday we discussed Rally program request and incubation request. We quickly dismissed the incubation request, as Rally appears to be able to live happily on top of

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Carlino, Chuck (OpenStack TripleO, Neutron)
On Aug 6, 2014, at 1:11 AM, Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com wrote: I agree, I had actually proposed this here: https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port :), though there are some issues we need to solve in neutron first --

[openstack-dev] [Murano] New keyword to recheck commits

2014-08-06 Thread Dmitry Teselkin
Hi all, Please note that we've changed keywords used to trigger recheck action in murano-ci to 'retrigger murano-ci'. We decided to do this in order to prevent OpenStack CI from triggering a build each time a comment 'recheck murano-ci' is added. The main cause of this is the regexp in

Re: [openstack-dev] Which program for Rally

2014-08-06 Thread Russell Bryant
On 08/06/2014 09:44 AM, Sean Dague wrote: Something that we need to figure out is given where we are in the release cycle do we want to ask the QA team to go off and do Rally deep dive now to try to pull it apart into the parts that make sense for other programs to take in. There are always

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Ben Nemec
On 08/06/2014 03:35 AM, Yuriy Taraday wrote: I'd like to stress this to everyone: I DO NOT propose squashing together commits that should belong to separate change requests. I DO NOT propose to upload all your changes at once. I DO propose letting developers to keep local history of all

Re: [openstack-dev] [heat] Stack update and raw_template backup

2014-08-06 Thread Anant Patil
On 30-Jul-14 23:24, Zane Bitter wrote: On 30/07/14 02:21, Anant Patil wrote: On 28-Jul-14 22:37, Clint Byrum wrote: Excerpts from Zane Bitter's message of 2014-07-28 07:25:24 -0700: On 26/07/14 00:04, Anant Patil wrote: When the stack is updated, a diff of updated template and current

[openstack-dev] Too long stack delete method.

2014-08-06 Thread Anant Patil
Hi, I see that the stack delete method is too long to comprehend easily without going to-and-fro few times. I think we should refactor it and move out the UpdateReplace related logic for backup stack to another method. We can also move the user credentials deletion related logic to another

[openstack-dev] [heat] Too long stack delete method

2014-08-06 Thread Anant Patil
Hi, I see that the stack delete method is too long to comprehend easily without going to-and-fro few times. I think we should refactor it and move out the UpdateReplace related logic for backup stack to another method. We can also move the user credentials deletion related logic to another

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Joe Gordon
On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton blak...@gmail.com wrote: Are there any parity features you are aware of that aren't receiving adequate developer/reviewer time? I'm not aware of any parity features that are in a place where throwing more engineers at them is going to speed

Re: [openstack-dev] [Heat] Too long stack delete method.

2014-08-06 Thread Zane Bitter
On 06/08/14 10:37, Anant Patil wrote: Hi, I see that the stack delete method is too long to comprehend easily without going to-and-fro few times. I think we should refactor it and move out the UpdateReplace related logic for backup stack to another method. We can also move the user credentials

[openstack-dev] [Tripleo] Release report

2014-08-06 Thread mar...@redhat.com
This was my first run so if I missed something please ping me, esp if you are in need of a stable branch (for those projects we do that for), 1. os-apply-config: no changes, 0.1.19 2. os-refresh-config: no changes, 0.1.7 3. os-collect-config: no changes, 0.1.25 4.

[openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-06 Thread Eoghan Glynn
Folks, It's come to our attention that some key individuals are not fully up-to-date on gnocchi activities, so it being a good and healthy thing to ensure we're as communicative as possible about our roadmap, I've provided a high-level overview here of our thinking. This is intended as a

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes
On 08/06/2014 02:12 AM, Kevin Benton wrote: Given that, pointing to the Nova parity work seems a bit like a red herring. This new API is being developed orthogonally to the existing API endpoints You see how you used the term endpoints there? :P -jay

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Ben Nemec
On 08/06/2014 12:41 AM, Yuriy Taraday wrote: On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec openst...@nemebean.com wrote: On 08/05/2014 03:14 PM, Yuriy Taraday wrote: On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst...@nemebean.com wrote: On 08/05/2014 10:51 AM, ZZelle wrote: Hi, I like

Re: [openstack-dev] [Heat] Too long stack delete method.

2014-08-06 Thread Anant Patil
On 06-Aug-14 20:20, Zane Bitter wrote: On 06/08/14 10:37, Anant Patil wrote: Hi, I see that the stack delete method is too long to comprehend easily without going to-and-fro few times. I think we should refactor it and move out the UpdateReplace related logic for backup stack to another

[openstack-dev] [sahara] team meeting Aug 7 1800 UTC

2014-08-06 Thread Sergey Lukjanov
Hi folks, We'll be having the Sahara team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20140807T18 -- Sincerely yours, Sergey Lukjanov

Re: [openstack-dev] [all] The future of the integrated release

2014-08-06 Thread Eoghan Glynn
Hi everyone, With the incredible growth of OpenStack, our development community is facing complex challenges. How we handle those might determine the ultimate success or failure of OpenStack. With this cycle we hit new limits in our processes, tools and cultural setup. This resulted in

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Hi Joe, Are you suggesting to stop/remove everything that is not related to Nova Parity for the Juno release? Because then I fail to see why this and Mark's proposal are targeted only to GBP. In my humble opinion, these kind of concerns should be addressed at BP approval time. Otherwise the

Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process

2014-08-06 Thread Jay Faulkner
Similarly, I appreciated this idea when we discussed it at the mid-cycle and doing so here. +1 -Jay Faulkner From: Lucas Alvares Gomes lucasago...@gmail.com Sent: Wednesday, August 06, 2014 2:34 AM To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [all] The future of the integrated release

2014-08-06 Thread Matt Joyce
On Wed, Aug 06, 2014 at 11:51:27AM -0400, Eoghan Glynn wrote: You've touched on multiple trains-of-thought that could indeed justify separate threads of their own. I agree with your read on the diverging growth rates in the strategic versus the tactical elements of the community. I

[openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

2014-08-06 Thread Luke Gorrie
Howdy! Rumor has it that it's easy to distribute ML2 mech drivers as out-of-tree add-on modules. Is this true? Has it been done? Where would one find an example? Cheers! -Luke ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
It sounds to me like you are describing how a developer uses Keystone, not a user. My reference to 'application deployer' was to someone trying to run something like a mail server on an openstack cloud. On Aug 6, 2014 7:07 AM, Russell Bryant rbry...@redhat.com wrote: On 08/05/2014 06:13 PM,

Re: [openstack-dev] [nova] so what do i do about libvirt-python if i'm on precise?

2014-08-06 Thread Matt Riedemann
On 8/5/2014 12:39 PM, Solly Ross wrote: Just to add my two cents, while I get that people need to run on older versions of software, at a certain point you have to bump the minimum version. Even libvirt 0.9.11 is from April 3rd 2012. That's two and a third years old at this point. I think

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
In the weekly neutron meetings it hasn't been mentioned that any of these items are at risk due to developer shortage. That's why I wanted Mark McClain to reply here because he has been leading the parity effort. On Aug 6, 2014 8:56 AM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Aug 6,

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
As a cloud admin one needs to make sure the endpoints in keystone publicurl, internalurl and adminurl all map to the right places in the infrastructure. As a cloud user (for example when using the HP/RAX public cloud that has multiple regions/endpoints) a user needs to be aware of which region

Re: [openstack-dev] [Fuel] Blueprints process

2014-08-06 Thread Tomasz Napierala
On 06 Aug 2014, at 10:41, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I really like what Mike proposed. It will help us to keep milestone clean and accurate. +1 for Mike’s proposal. New members will also benefit from that move: clean picture will make easier to pick up features

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ronak Shah
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

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

2014-08-06 Thread Joe Gordon
On Tue, Aug 5, 2014 at 8:25 PM, Tom Fifield t...@openstack.org wrote: On 06/08/14 03:54, Jay Pipes wrote: On 08/05/2014 03:23 PM, Collins, Sean wrote: On Tue, Aug 05, 2014 at 12:50:45PM EDT, Monty Taylor wrote: However, I think the cost to providing that path far outweighs the benefit in

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
What I was referring to was also not Keystone's definition of an endpoint. It's almost as if the term has many uses and was not invented for Keystone. :-) http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html Did a similar discussion occur when Heat wanted to use the word

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Zane Bitter
On 04/08/14 19:18, Yuriy Taraday wrote: Hello, git-review users! I'd like to gather feedback on a feature I want to implement that might turn out useful for you. I like using Git for development. It allows me to keep track of current development process, it remembers everything I ever did with

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Joe Gordon
On Aug 6, 2014 10:21 AM, Ronak Shah ronak.malav.s...@gmail.com wrote: 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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sridar Kandaswamy (skandasw)
Hi All: +1 Ivar. Yes the timing of the alternate proposal does make the notion of spec reviews seem like a process tick mark with no seeming benefit. It is indeed unfair to the folks who have put in a lot of effort with an approved spec to have a workflow change pulled on them so late in the

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Edgar Magana
This is the consequence of a proposal that is not following the standardized terminology (IETF - RFC) for any Policy-based System: http://tools.ietf.org/html/rfc3198 Well, I did bring this point during the Hong Kong Summit but as you can see my comments were totally ignored:

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Which kind of uncertainty are you referring to? Given that the blueprint was approved long ago, and the code has been ready and under review following those specs... I think GBP is probably the patch with the least effort to be merged right now. Ivar. On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

2014-08-06 Thread Jay Pipes
On 08/06/2014 01:40 AM, Tom Fifield wrote: On 06/08/14 13:30, Robert Collins wrote: On 6 August 2014 17:27, Tom Fifield t...@openstack.org wrote: On 06/08/14 13:24, Robert Collins wrote: What happened to your DB migrations then? :) Sorry if I misunderstood, I thought we were talking

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Salvatore Orlando
As Ronak said, this thread is starting to move in a lot of different directions, ranging from correctness of the blueprint approval process to nova/neutron integration, which are rather off topic. In particular it seems things are being skewed towards a discussion around nova parity, whereas

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes
On 08/06/2014 01:22 PM, Kevin Benton wrote: What I was referring to was also not Keystone's definition of an endpoint. It's almost as if the term has many uses and was not invented for Keystone. :-) http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html Did a similar discussion

[openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

2014-08-06 Thread Jay Pipes
Hi Stackers! So, Liyi Meng has an interesting patch up for Nova: https://review.openstack.org/#/c/104876 that changes the way that the interval and number of retries is calculated for a piece of code that waits around for a block device mapping to become active. Namely, the patch discards

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
Edgar, you seemed to have +2'ed this patch on July 2nd [1]: Edgar Magana Jul 2 8:42 AM Patch Set 13: Code-Review+2 All looks good to me! I am not approving yet because Nachi was also reviewing this code and I would like to see his opinion as well. That would suggest that you were happy with

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Salvatore, Can you expand on point 2? Not sure what means in this case to 'treat it accordingly'. Thanks, Ivar. On Wed, Aug 6, 2014 at 7:44 PM, Salvatore Orlando sorla...@nicira.com wrote: As Ronak said, this thread is starting to move in a lot of different directions, ranging from

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes
On 08/06/2014 04:30 AM, Stefano Santini wrote: Hi, In my company (Vodafone), we (DC network architecture) are following very closely the work happening on Group Based Policy since we see a great value on the new paradigm to drive network configurations with an advanced logic. We're working on

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Edgar Magana
That is the beauty of the open source projects, there is always a smartest reviewer catching out the facts that you don¹t. Edgar On 8/6/14, 10:55 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Edgar, you seemed to have +2'ed this patch on July 2nd [1]: Edgar Magana Jul 2 8:42 AM Patch

Re: [openstack-dev] Which program for Rally

2014-08-06 Thread Duncan Thomas
I'm not following here - you complain about rally being monolithic, then suggest that parts of it should be baked into tempest - a tool that is already huge and difficult to get into. I'd rather see tools that do one thing well and some overlap than one tool to rule them all. On 6 August 2014

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
Not sure what you are talking about? You claim now that you had suggestion which was not considered, yet you +2'ed a patch, by stating that All looks good to me!. On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana edgar.mag...@workday.com wrote: That is the beauty of the open source projects, there

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Yapeng Wu
Hi, Salvatore, Thanks listing out the options. Can you elaborate more on your 2nd option? Do you mean merge the patches and mark the API as ‘experimental’? Yapeng From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Wednesday, August 06, 2014 1:44 PM To: OpenStack Development Mailing

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
Hi, I've made my way through the group based policy code and blueprints and I'd like ask several questions about it. My first question really is what is the advantage that the new proposed group based policy model buys us? Bobs says, The group-based policy BP approved for Juno addresses the

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Yuriy Taraday
On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com wrote: On 08/06/2014 03:35 AM, Yuriy Taraday wrote: I'd like to stress this to everyone: I DO NOT propose squashing together commits that should belong to separate change requests. I DO NOT propose to upload all your changes

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ryan Moats
Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM: [snip] AFAICT, there is nothing that can be done with the GBP API that cannot be done with the low-level regular Neutron API. I'll take you up on that, Jay :) How exactly do I specify behavior between two collections of ports

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Ben Nemec
On 08/06/2014 01:42 PM, Yuriy Taraday wrote: On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com wrote: On 08/06/2014 03:35 AM, Yuriy Taraday wrote: I'd like to stress this to everyone: I DO NOT propose squashing together commits that should belong to separate change requests. I

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
Hi Aaron, These are good questions, but can we move this to a different thread labeled what is the point of group policy? I don't want to derail this one again and we should stick to Salvatore's options about the way to move forward with these code changes. On Aug 6, 2014 12:42 PM, Aaron Rosen

[openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

2014-08-06 Thread Stefano Maffulli
On 08/06/2014 11:19 AM, Edgar Magana wrote: That is the beauty of the open source projects, there is always a smartest reviewer catching out the facts that you don¹t. And yet, the specification clearly talks about 'endpoints' and nobody caught it where it supposed to be caught so I fear that

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

2014-08-06 Thread Kyle Mestery
On Wed, Aug 6, 2014 at 2:07 PM, Stefano Maffulli stef...@openstack.org wrote: On 08/06/2014 11:19 AM, Edgar Magana wrote: That is the beauty of the open source projects, there is always a smartest reviewer catching out the facts that you don¹t. And yet, the specification clearly talks about

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
Hi Ryan, On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats rmo...@us.ibm.com wrote: Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM: [snip] AFAICT, there is nothing that can be done with the GBP API that cannot be done with the low-level regular Neutron API. I'll take you up

Re: [openstack-dev] [git-review] Supporting development in local branches

2014-08-06 Thread Yuriy Taraday
On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec openst...@nemebean.com wrote: On 08/06/2014 12:41 AM, Yuriy Taraday wrote: On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec openst...@nemebean.com wrote: On 08/05/2014 03:14 PM, Yuriy Taraday wrote: On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Henry Fourie
+1 From: Edgar Magana [mailto:edgar.mag...@workday.com] Sent: Wednesday, August 06, 2014 10:40 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward This is the consequence of a proposal that is not

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
Hi Kevin, I think we should keep these threads together as we need to understand the benefit collectively before we move forward with what to do. Aaron On Wed, Aug 6, 2014 at 12:03 PM, Kevin Benton blak...@gmail.com wrote: Hi Aaron, These are good questions, but can we move this to a

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Salvatore Orlando
As long as the discussion stays focused on how group policies are beneficial for the user community and how the Neutron developer community should move forward, I reckon it's fine to keep the discussion in this thread. Salvatore Il 06/ago/2014 21:18 Aaron Rosen aaronoro...@gmail.com ha scritto:

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Hi Aaron, Please note that the user using the current reference implementation doesn't need to create Networks, Ports, or anything else. As a matter of fact, the mapping is done implicitly. Also, I agree with Kevin when he says that this is a whole different discussion. Thanks, Ivar. On Wed,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote: Hi Aaron, Please note that the user using the current reference implementation doesn't need to create Networks, Ports, or anything else. As a matter of fact, the mapping is done implicitly. The user still needs to

[openstack-dev] [UX] [Horizon] [Heat] Merlin project (formerly known as cross-project UI library for Heat/Mistral/Murano/Solum) plans for PoC and more

2014-08-06 Thread Timur Sufiev
Hi, folks! Two months ago there was an announcement in ML about gathering the requirements for cross-project UI library for Heat/Mistral/Murano/Solum [1]. The positive feedback in related googledoc [2] and some IRC chats and emails that followed convinced me that I'm not the only person

Re: [openstack-dev] [neutron] make mac address updatable: which plugins?

2014-08-06 Thread Carlino, Chuck (OpenStack TripleO, Neutron)
Yamamoto has reviewed the changes for this, and has raised the following issue (among others). * iirc mellanox uses mac address as port identifier. what happens on address change? Can someone who knows mellanox please comment, either here or in the review? Thanks, Chuck On Aug 5, 2014,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
I believe the referential security group rules solve this problem (unless I'm not understanding): I think the disconnect is that you are comparing the way to current mapping driver implements things for the reference implementation with the existing APIs. Under this light, it's not going to look

  1   2   3   >