[openstack-dev] No DVR meeting this week

Hi Folks, No DVR meeting this week. 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

[openstack-dev] [python-novaclient] [python-client] Queries regarding how to run test cases of python-client in juno release

Hi I am unable to find script for run test cases of python-clients in juno release. novaclients are shilfed into dist-packages but there is no script for run the test cases. Please help me to come out from this problem. Thanks, Regards Amandeep Rattenpal Asst. System Engineer, Mail to: ra

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On Tue, Feb 24, 2015, at 04:28, Kashyap Chamarthy wrote: > > Along with the below, if push comes to shove, OpenStack Foundation could > probably try a milder variant (obviously, not all activities can be > categorized as 'critical path') of Linux Foundation's "Critical > Infrastructure Protection

Re: [openstack-dev] [Nova][Tempest] Tempest will deny extra properties on Nova v2/v2.1 API

Hi David, > -Original Message- > From: David Kranz [mailto:dkr...@redhat.com] > Sent: Wednesday, February 25, 2015 4:19 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Nova][Tempest] Tempest will deny extra > properties on Nova v2/v2.1

Re: [openstack-dev] [infra] Infra cloud: infra running a cloud for nodepool

I think this is really neat. As a 3rd party ci operator managing a small nodepool cloud, leveraging #3 would be really great! Ramy -Original Message- From: James E. Blair [mailto:cor...@inaugust.com] Sent: Tuesday, February 24, 2015 1:19 PM To: openstack-in...@lists.openstack.org Cc: op

[openstack-dev] Name field marked mandatory on Horizon

Hello all, For creating Networks, Images, Volumes etc, the name field is marked as mandatory on the Horizon UI whereas, in their corresponding create commands on the cli it is an optional field ( which is as per the API reference documents) Why is this inconsistency? Secondly, when we create

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 24/02/15 19:27, Daniel P. Berrange wrote: > On Tue, Feb 24, 2015 at 12:05:17PM +0100, Thierry Carrez wrote: >> Daniel P. Berrange wrote: >>> [...] First, Daniel, thank you for the well-written and thought-through post. I have some comments on translation specifically which I hope can shed some

Re: [openstack-dev] [cinder] some questions about bp "filtering-weighing-with-driver-supplied-functions"

Hi Duncan, Really thanks for replying and sorry for my delayed response due to Chinese new year. > 1) Driver authors tend, in my experience, to know more than admins, so > drivers should be able (where useful) to be able to set a default value to > either filter expression or weighting expressio

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On 02/24/2015 05:46 PM, Jeremy Stanley wrote: On 2015-02-24 10:00:51 -0800 (-0800), Johannes Erdfelt wrote: [...] Recently, I have spent a lot more time waiting on reviews than I have spent writing the actual code. That's awesome, assuming what you mean here is that you've spent more time revi

Re: [openstack-dev] Kerberos in OpenStack

I replied to almost exactly this email off-list and so thought i would copy my reply to -dev. - Original Message - > From: "Jamie Lennox" > To: "Sanket Lawangare" > Sent: Wednesday, February 25, 2015 6:39:14 AM > Subject: Re: Kerberos in OpenStack > > > > - Original Message

Re: [openstack-dev] [Fuel] Bug statuses definition in Fuel

Mike, I introduced the Fuel specific bug priority descriptions in June 2014 [0], which may be why you were having trouble finding it in the recent changes. [0] https://wiki.openstack.org/w/index.php?title=Fuel%2FHow_to_contribute&diff=56952&oldid=56951 I think you're using a weird definition of

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

So are we talking about using script to eliminate unnecessary new vif types? Then, a little confusion that why this BP[1] is postponed to L, and this BP[2] is merged in K. [1] https://review.openstack.org/#/c/146914/ [2] https://review.openstack.org/#/c/148805/ In fact [2] can be replaced by [

[openstack-dev] [manuals] Training guide issue

Hi I am trying to just get started with openstack commits and wanted to start by fixing some documentation bugs. I assigned 3 bugs which seem to be in the same file/area https://bugs.launchpad.net/openstack-training-guides/+bug/1380153 https://bugs.launchpad.net/openstack-training-guides/+bug/1

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

On 24 February 2015 at 01:07, Salvatore Orlando wrote: > Lazy-Stacker summary: ... > In the medium term, there are a few things we might consider for Neutron's > "built-in IPAM". > 1) Move the allocation logic out of the driver, thus making IPAM an > independent service. The API workers will then

Re: [openstack-dev] [Neutron] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

There is a -2 (from me). And this was done from the auto-abandon script which I try to run once a month. As Kevin said, the suggestion multiple times was to do a StackForge project for this work, that's the best way forward here. On Tue, Feb 24, 2015 at 5:01 PM, CARVER, PAUL wrote: > Maybe I'm

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

Hi, I am new to OpenStack (and am particularly interested in networking). I am getting a bit confused by this discussion. Aren’t there already a few monolithic plugins (that is what I could understand from reading the Networking chapter of the OpenStack Cloud Administrator Guide. Table 7.3 Avai

Re: [openstack-dev] ECMP on Neutron virtual router

On Wed, Feb 25, 2015 at 3:11 AM, Kevin Benton wrote: > I wonder if there is a way we can easily abuse the extra routes extension to > do this? Maybe two routes to the same network would imply ECMP. > It's a good idea, and we deploy a system with similar concept(by extra routes) by a tiny patch on

Re: [openstack-dev] [oslo] Graduating oslo.reports: Request to review "clean copy"

> Those scripts have mostly moved into oslotest, so they don't need to be > synced any more to be used. If you have all of your code, and it follows > the cookiecutter template, we can look at it and propose post-import > tweaks. What's the URL for the repository? Heh, whoops. I should probably

Re: [openstack-dev] Kerberos in OpenStack

Thanks a lot for taking out time and replying back Tim. Will let you know if i have any further questions. On Tue, Feb 24, 2015 at 1:22 PM, Tim Bell wrote: > You may also get some information from how we set up Kerberos at CERN at > http://openstack-in-production.blogspot.fr/2014/10/kerberos-an

Re: [openstack-dev] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

On 2015-02-25 01:02:07 +0530 (+0530), Bharat Kumar wrote: [...] > After running 971 test cases VM inaccessible for 569 ticks [...] Glad you're able to reproduce it. For the record that is running their 8GB performance flavor with a CentOS 7 PVHVM base image. The steps to recreate are http://paste.

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

Folks, A great discussion. I am not expert at OVN, hence, want to ask a question. The answer may make a case that it should probably be a ML2 driver as oppose to monolithic plugin. Say a customer want to deploy an OVN based solution and use HW devices from one vendor for L2 and L3 (e.g. Arista o

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 25 February 2015 at 13:13, Jeremy Stanley wrote: > On 2015-02-24 11:27:05 + (+), Daniel P. Berrange wrote: > [...] >> It would be reasonable for the vulnerability team to take the decision >> that they'll support fixes for master, and any branches that the stable >> team decide to suppo

[openstack-dev] [Ironic] Stepping down from Ironic Core

Like with TripleO, I've not been pulling my weight as a core reviewer for a bit; I'd be very hesitant to +A in the project as a result. I'm still very interested in Ironic, but its not where my immediate focus is. Cheers, Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 2015-02-24 11:27:05 + (+), Daniel P. Berrange wrote: [...] > It would be reasonable for the vulnerability team to take the decision > that they'll support fixes for master, and any branches that the stable > team decide to support. [...] Well, it's worth noting that the VMT doesn't even

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 25 February 2015 at 00:05, Thierry Carrez wrote: > Daniel P. Berrange wrote: >> [...] > > I think you're judging the cycle from the perspective of developers > only. You said that in the other thread, and I think its false. There is a very good case to be made that the release cycle is direct

Re: [openstack-dev] [Neutron] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

I think Kyle's auto-abandon script made a mistake in this case, unless it was seeing into the future and saw it's own -2... :) More seriously, have you considered starting a tap-as-a-service project on stackforge now that the services split has established a framework for advanced services? Upload

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On 2015-02-24 10:00:51 -0800 (-0800), Johannes Erdfelt wrote: [...] > Recently, I have spent a lot more time waiting on reviews than I > have spent writing the actual code. That's awesome, assuming what you mean here is that you've spent more time reviewing submitted code than writing more. That's

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 24 February 2015 at 22:53, Daniel P. Berrange wrote: > I was writing this mail for the past few days, but the nova thread > today prompted me to finish it off & send it :-) ++ > The first two observations strongly suggest that the choice of 6 > months as a cycle length is a fairly arbitr

Re: [openstack-dev] client library release versions

On 25 February 2015 at 11:18, Matt Riedemann wrote: > > > I was hoping to do a sqlalchemy-migrate release this week so I'm interested > in not screwing that up. :) > > The current release is 0.9.4 and there was one change to requirements.txt, > cee9136, since then, so if I'm reading this correctl

[openstack-dev] [Fuel] Bug statuses definition in Fuel

Hi Dmitry, thanks for extending info on what is different in Fuel for Confirmed & Fix Released statuses [1] It is pretty hard to go in history of the page now, but I think I like original OpenStack Imporance description in [2], than Fuel-specific [3]: > - Critical = can't deploy anything and ther

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On 23/02/15 19:14, Joe Gordon wrote: Was: http://lists.openstack.org/pipermail/openstack-dev/2015-February/057578.html There has been frustration with our current 6 month development cadence. This is an attempt to explain those frustrations and propose a very rough outline of a possible alternat

Re: [openstack-dev] [all][oslo] Dealing with database connection sharing issues

On 23 February 2015 at 13:54, Michael Bayer wrote: > Correct me if I'm wrong but the register_after_fork seems to apply only to > the higher level Process abstraction. If someone calls os.fork(), as is > the case now, there's no hook to use. > > Hence the solution I have in place right now, whi

[openstack-dev] [Neutron] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

Maybe I'm misreading review.o.o, but I don't see the -2. There was a -2 from Salvatore Orlando with the comment "The -2 on this patch is only to deter further comments" and a link to 140292, but 140292 has a comment from Kyle saying it's been abandoned in favor of going back to 96149. Are we in

Re: [openstack-dev] [oslo] Graduating oslo.reports: Request to review "clean copy"

On Tue, Feb 24, 2015, at 04:42 PM, Solly Ross wrote: > Hello All, > > I've finally had some time to finish up the graduation work for > oslo.reports (previously > openstack.common.report), and it should be ready for review by the Oslo > team. The only thing > that I was unclear about was the "s

Re: [openstack-dev] [OpenStack-Infra] [infra] Infra cloud: infra running a cloud for nodepool

cor...@inaugust.com (James E. Blair) writes: > A group of folks from HP is interested in starting an effort to run a > cloud as part of the Infrastructure program with the purpose of > providing resources to nodepool for OpenStack testing. HP is supplying > two racks of machines, and we will oper

Re: [openstack-dev] client library release versions

On 2/24/2015 3:34 PM, Robert Collins wrote: Hi, in the cross project meeting a small but important thing came up. Most (all?) of our client libraries run with semver: x.y.z version numbers. http://semver.org/ and http://docs.openstack.org/developer/pbr/semver.html However we're seeing recent

Re: [openstack-dev] [nova] novaclient functional test guidelines

On Tue, Feb 24, 2015 at 1:18 PM, melanie witt wrote: > On Feb 24, 2015, at 9:47, Sean Dague wrote: > > > I'm happy if there are other theories about how we do these things, > > being the first functional test in the python-novaclient tree that > > creates and destroys real resources, there isn't

Re: [openstack-dev] [nova] novaclient functional test guidelines

On Tue, Feb 24, 2015 at 12:30 PM, Sean Dague wrote: > On 02/24/2015 03:28 PM, Ed Leafe wrote: > > On Feb 24, 2015, at 1:49 PM, Sean Dague wrote: > > > >>> IMHO the CLI should have an option to returned raw JSON back instead of > >>> pretty tabled results as well. > >> > >> Um... isn't that just

[openstack-dev] [oslo] Graduating oslo.reports: Request to review "clean copy"

Hello All, I've finally had some time to finish up the graduation work for oslo.reports (previously openstack.common.report), and it should be ready for review by the Oslo team. The only thing that I was unclear about was the "sync required tools from oslo-incubator" part. oslo.reports does not

[openstack-dev] client library release versions

Hi, in the cross project meeting a small but important thing came up. Most (all?) of our client libraries run with semver: x.y.z version numbers. http://semver.org/ and http://docs.openstack.org/developer/pbr/semver.html However we're seeing recent releases that are bumping .z inappropriately. T

Re: [openstack-dev] [nova] novaclient functional test guidelines

On Feb 24, 2015, at 9:47, Sean Dague wrote: > I'm happy if there are other theories about how we do these things, > being the first functional test in the python-novaclient tree that > creates and destroys real resources, there isn't an established pattern > yet. But I think doing all CLI calls i

[openstack-dev] [infra] Infra cloud: infra running a cloud for nodepool

A group of folks from HP is interested in starting an effort to run a cloud as part of the Infrastructure program with the purpose of providing resources to nodepool for OpenStack testing. HP is supplying two racks of machines, and we will operate each as an independent cloud. I think this is a re

[openstack-dev] [Fuel] Tag bugs with features from current release

During bugs triage and release notes preparation we often need to find out whether a bug is a regression introduced by new code in the current release, or may have been present in previous releases. In the latter case, depending on its severity, it may need to be reflected in the release notes, and

Re: [openstack-dev] [nova] novaclient functional test guidelines

On Feb 24, 2015, at 2:30 PM, Sean Dague wrote: > Right, I think to some degree novaclient is legacy code, and we should > focus on specific regressions and bugs without doing to much code change. > > The future should be more focussed on openstacksdk and openstackclient. IMO, openstackclient ha

Re: [openstack-dev] [nova] novaclient functional test guidelines

On 02/24/2015 03:28 PM, Ed Leafe wrote: > On Feb 24, 2015, at 1:49 PM, Sean Dague wrote: > >>> IMHO the CLI should have an option to returned raw JSON back instead of >>> pretty tabled results as well. >> >> Um... isn't that just the API calls? >> >> I'm not sure creating a 3rd functional surface

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On Feb 24, 2015, at 1:50 PM, Joe Gordon wrote: >> I think the release candidate >> period is the only thing that makes your code drops actually usable. >> It's the only moment in the cycle where integrators test. It's the only >> moment in the cycle where developers work on bugs they did not file

Re: [openstack-dev] [nova] novaclient functional test guidelines

On Feb 24, 2015, at 1:49 PM, Sean Dague wrote: >> IMHO the CLI should have an option to returned raw JSON back instead of >> pretty tabled results as well. > > Um... isn't that just the API calls? > > I'm not sure creating a 3rd functional surface is really the answer > here, because we still n

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 02/24/2015 03:21 PM, Joe Gordon wrote: > > > On Tue, Feb 24, 2015 at 6:57 AM, Daniel P. Berrange > wrote: > > On Tue, Feb 24, 2015 at 08:50:45AM -0500, Sean Dague wrote: > > On 02/24/2015 07:48 AM, Russell Bryant wrote: > > > On 02/24/2015 12:54 PM, Da

Re: [openstack-dev] python-ceilometerclient 1.0.13 broke the gate

We saw the same issue elsewhere, and Doug had great explanation on how it broke semver https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg46533.html On Tue, Feb 24, 2015 at 12:11 PM, Matt Riedemann wrote: > https://bugs.launchpad.net/python-ceilometerclient/+bug/1425262 > > mtrei

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On Tue, Feb 24, 2015 at 6:57 AM, Daniel P. Berrange wrote: > On Tue, Feb 24, 2015 at 08:50:45AM -0500, Sean Dague wrote: > > On 02/24/2015 07:48 AM, Russell Bryant wrote: > > > On 02/24/2015 12:54 PM, Daniel P. Berrange wrote: > > >> On Tue, Feb 24, 2015 at 11:48:29AM +, Chris Dent wrote: > >

[openstack-dev] python-ceilometerclient 1.0.13 broke the gate

https://bugs.launchpad.net/python-ceilometerclient/+bug/1425262 mtreinish adjusted the cap on stable/icehouse here: https://review.openstack.org/#/c/158842/ jogo now has a change to explicitly pin all clients in stable/icehouse to the version currently gated on: https://review.openstack.org/

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On Tue, Feb 24, 2015 at 2:59 AM, Daniel P. Berrange wrote: > On Mon, Feb 23, 2015 at 04:14:36PM -0800, Joe Gordon wrote: > > Was: > > > http://lists.openstack.org/pipermail/openstack-dev/2015-February/057578.html > > > > There has been frustration with our current 6 month development cadence. > >

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On Tue, Feb 24, 2015 at 10:00 AM, Johannes Erdfelt wrote: > On Tue, Feb 24, 2015, Thierry Carrez wrote: > > Agree on the pain of maintaining milestone plans though, which is why I > > propose we get rid of most of it in Liberty. That will actually be > > discussed at the cross-project meeting to

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On Tue, Feb 24, 2015 at 2:38 AM, Thierry Carrez wrote: > Joe Gordon wrote: > > [...] > > I think a lot of the frustration with our current cadence comes out of > > the big stop everything (development, planning etc.), and stabilize the > > release process. Which in turn isn't really making things

Re: [openstack-dev] [stable] New to project stable maintenance, question on requirements changes

Sean, thanks! I feel better already. I'll check out the review. Trevor On Tue, 2015-02-24 at 14:39 -0500, Sean Dague wrote: > On 02/24/2015 02:34 PM, Trevor McKay wrote: > > Hi folks, > > > > I've just joined the stable maintenance team for Sahara. > > > > We have this review here, from Ope

Re: [openstack-dev] [nova] novaclient functional test guidelines

On 02/24/2015 01:47 PM, Joe Gordon wrote: > > > On Tue, Feb 24, 2015 at 9:47 AM, Sean Dague > wrote: > > Towards the end of merging the regression test for the nova > volume-attach bug - https://review.openstack.org/#/c/157959/ there was a > discussion around

Re: [openstack-dev] [stable] New to project stable maintenance, question on requirements changes

On 02/24/2015 02:34 PM, Trevor McKay wrote: > Hi folks, > > I've just joined the stable maintenance team for Sahara. > > We have this review here, from OpenStack proposal bot: > > https://review.openstack.org/158775/ > > Since it came from the proposal bot, there's no justification in the >

[openstack-dev] [stable] New to project stable maintenance, question on requirements changes

Hi folks, I've just joined the stable maintenance team for Sahara. We have this review here, from OpenStack proposal bot: https://review.openstack.org/158775/ Since it came from the proposal bot, there's no justification in the commit message and no cherry pick. I didn't see this case cove

Re: [openstack-dev] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

Ran the job manually on rax VM, provided by Jeremy. (Thank you Jeremy). After running 971 test cases VM inaccessible for 569 ticks, then continues... (Look at the console.log [1]) And also have a look at dstat log. [2] The summary is: == Totals == Ran: 1125 tests in 5835. sec. - P

Re: [openstack-dev] Kerberos in OpenStack

On 02/24/2015 01:53 PM, Sanket Lawangare wrote: Hello Everyone, My name is Sanket Lawangare. I am a graduate Student studying at The University of Texas, at San Antonio.For my Master’s Thesis I am working on the Identity component of OpenStack. My research is to investigate external authenti

Re: [openstack-dev] Kerberos in OpenStack

You may also get some information from how we set up Kerberos at CERN at http://openstack-in-production.blogspot.fr/2014/10/kerberos-and-single-sign-on-with.html From my understanding, the only connection is between Keystone and KDC. There is a standard Keystone token issues based off the Kerber

Re: [openstack-dev] [Fuel] tracking bugs superseded by blueprints

I think it is better to keep such bugs open. Please see https://blueprints.launchpad.net/fuel/+spec/granular-network-functions . There are some related bugs here. One is fixed, another one is in progress, two are closed. If bug is strictly coherent with blueprint (like https://bugs.launchpad.net/fu

Re: [openstack-dev] [Nova][Tempest] Tempest will deny extra properties on Nova v2/v2.1 API

On 02/24/2015 06:55 AM, Ken'ichi Ohmichi wrote: Hi Ghanshyam, 2015-02-24 20:28 GMT+09:00 GHANSHYAM MANN : On Tue, Feb 24, 2015 at 6:48 PM, Ken'ichi Ohmichi wrote: Hi Nova team is developing Nova v2.1 API + microversions in this cycle, and the status of Nova v2.1 API has been changed to CURRE

Re: [openstack-dev] ECMP on Neutron virtual router

I wonder if there is a way we can easily abuse the extra routes extension to do this? Maybe two routes to the same network would imply ECMP. If not, maybe this can fit into a larger refactoring for route management (dynamic routing, etc). On Feb 24, 2015 11:02 AM, "Carl Baldwin" wrote: > It does

Re: [openstack-dev] [Congress][Delegation] Initial workflow design

Hi Tim, Thanks for your updated doc on Delegation from Congress to a domain-specific policy engine, in this case, you are planning to build a LP-based VM-Placement engine to be the domain specific policy engine. I agree your main goal is to first get the delegation interface sorted out. It wil

Re: [openstack-dev] ECMP on Neutron virtual router

It doesn't support this at this time. There are no current plans to make it work. I'm curious to know how you would like for this to work in your deployment. Carl On Tue, Feb 24, 2015 at 11:32 AM, NAPIERALA, MARIA H wrote: > Does Neutron router support ECMP across multiple static routes to the

[openstack-dev] Kerberos in OpenStack

Hello Everyone, My name is Sanket Lawangare. I am a graduate Student studying at The University of Texas, at San Antonio. For my Master’s Thesis I am working on the Identity component of OpenStack. My research is to investigate external authentication with Identity(keystone) using Kerberos. Base

Re: [openstack-dev] [nova] novaclient functional test guidelines

On Tue, Feb 24, 2015 at 9:47 AM, Sean Dague wrote: > Towards the end of merging the regression test for the nova > volume-attach bug - https://review.openstack.org/#/c/157959/ there was a > discussion around what style the functional tests should take. > Especially as that had a mix of CLI and AP

Re: [openstack-dev] [thirdpartyCI][cinder] Question about certification

On 12:47 Tue 24 Feb , Eduard Matei wrote: > The question is: does the CI need voting rights (validated) , or just > check/comment to be considered "working"? See: https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#When_thirdparty_CI_voting_will_be_required.3F -- Mike Perez

[openstack-dev] ECMP on Neutron virtual router

Does Neutron router support ECMP across multiple static routes to the same destination network but with different next-hops? Maria __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-re

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On Tue, Feb 24, 2015, Thierry Carrez wrote: > Agree on the pain of maintaining milestone plans though, which is why I > propose we get rid of most of it in Liberty. That will actually be > discussed at the cross-project meeting today: > > https://wiki.openstack.org/wiki/Release_Cycle_Management/L

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 02/24/2015 12:33 PM, John Griffith wrote: > > > On Tue, Feb 24, 2015 at 10:04 AM, David Kranz > wrote: > > On 02/24/2015 09:37 AM, Chris Dent wrote: > > On Tue, 24 Feb 2015, Sean Dague wrote: > > That also provides a very concrete answer to

[openstack-dev] [nova] novaclient functional test guidelines

Towards the end of merging the regression test for the nova volume-attach bug - https://review.openstack.org/#/c/157959/ there was a discussion around what style the functional tests should take. Especially as that had a mix of CLI and API calls in it. Here are my thoughts for why that test ended

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

Hello all, We now have a work-in-progress patch up for review: https://review.openstack.org/#/c/158697/ Feedback on our approach is much appreciated. Many thanks, John Davidge OpenStack@Cisco On 20/02/2015 18:28, "Ihar Hrachyshka" wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 >

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

Johannes Erdfelt wrote: > On Mon, Feb 23, 2015, Joe Gordon wrote: >> What this actually means: >> >>- Stop approving blueprints for specific stable releases, instead just >>approve them and target them to milestones. >> - Milestones stop becoming Kilo-1, Kilo-2, Kilo-3 etc. and just

Re: [openstack-dev] [TripleO] Midcycle Summary

Thanks for the summary. A couple of comments inline. On 02/24/2015 08:48 AM, James Slagle wrote: > Hi Everyone, > > TripleO held a midcycle meetup from February 18th-20th in Seattle. Thanks to > HP > for hosting the event! I wanted to send out a summary of what went on. We also > captured some

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On Tue, Feb 24, 2015 at 10:04 AM, David Kranz wrote: > On 02/24/2015 09:37 AM, Chris Dent wrote: > >> On Tue, 24 Feb 2015, Sean Dague wrote: >> >> That also provides a very concrete answer to "will people show up". >>> Because if they do, and we get this horizontal refactoring happening, >>> the

Re: [openstack-dev] [api] [glance] conclusion needed on functional API

On 02/24/2015 03:09 AM, Flavio Percoco wrote: On 22/02/15 22:43 -0500, Jay Pipes wrote: On 02/18/2015 06:37 PM, Brian Rosmaita wrote: Thanks for your comment, Miguel. Your suggestion is indeed very close to the RESTful ideal. However, I have a question for the entire API-WG. Our (proposed) m

Re: [openstack-dev] [TripleO] Midcycle Summary

On 02/24/2015 07:48 AM, James Slagle wrote: > Hi Everyone, > > TripleO held a midcycle meetup from February 18th-20th in Seattle. Thanks to > HP > for hosting the event! I wanted to send out a summary of what went on. We also > captured some notes on an etherpad[0]. > > The first order of business

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 02/24/2015 09:37 AM, Chris Dent wrote: On Tue, 24 Feb 2015, Sean Dague wrote: That also provides a very concrete answer to "will people show up". Because if they do, and we get this horizontal refactoring happening, then we get to the point of being able to change release cadences faster. If

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

I think we're speculating a lot about what would be best for OVN whereas we should probably just expose pro and cons of ML2 drivers vs standalone plugin (as I said earlier on indeed it does not necessarily imply monolithic *) I reckon the job of the Neutron community is to provide a full picture t

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

Kyle, What happened to the long-term potential goal of ML2 driver APIs becoming neutron's core APIs? Do we really want to encourage new monolithic plugins? ML2 is not a control plane - its really just an integration point for control planes. Although co-existence of multiple mechanism drivers

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

OVN implementing it's own control plane isn't a good reason to make it a monolithic plugin. Many of the ML2 drivers are for technologies with their own control plane. Going with the monolithic plugin only makes sense if you are certain that you never want interoperability with other technologies a

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

On Tue, Feb 24, 2015 at 3:19 AM, Salvatore Orlando wrote: > On 24 February 2015 at 01:34, Kyle Mestery wrote: > >> Russel and I have already merged the initial ML2 skeleton driver [1]. >> > The thinking is that we can always revert to a non-ML2 driver if needed. >> > > If nothing else an authori

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On Tue, Feb 24, 2015, Thierry Carrez wrote: > Joe Gordon wrote: > > [...] > > I think a lot of the frustration with our current cadence comes out of > > the big stop everything (development, planning etc.), and stabilize the > > release process. Which in turn isn't really making things more stable

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On Mon, Feb 23, 2015, Joe Gordon wrote: > What this actually means: > >- Stop approving blueprints for specific stable releases, instead just >approve them and target them to milestones. > - Milestones stop becoming Kilo-1, Kilo-2, Kilo-3 etc. and just > become 1,2,3,4,5,6,7,8

[openstack-dev] [Fuel][Library][Fuel-CI] verify-fuel-library-python job enabled

Hi everyone, we've enabled job verify-fuel-library-python (see [1]) to test Python scripts in Fuel Library code. It is triggered for all commits to master branch in stackforge/fuel-library Master currently passes the test, see [2]. Please check and rebase your patchsets for this job to work. In c

[openstack-dev] [Glance] [all] Vancouver Summit: Glance Friday Sprint

Hi, For those who are interested and are planning to book travel soon, please do keep in mind that Glance team is planning to have a halfday sprint on Friday of the week of the summit. Besides, we will have fishbowl and work sessions during the week. Please feel free to reach out to me, if you

Re: [openstack-dev] [infra] [cinder] CI via infra for the DRBD Cinder driver

Anita Kuno writes: > I'd like to make sure that if Infra is saying that CI jobs on drivers > can gate that this is a substantial difference from what I have been > saying for a year, specifically that they can't and won't. For the purposes of this conversation, the distinction between drivers an

Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

Tony Breeds wrote on 02/21/2015 08:35:32 AM: > From: Tony Breeds > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 02/21/2015 08:41 AM > Subject: Re: [openstack-dev] [nova] bp serial-ports *partly* implemented? > > On Fri, Feb 20, 2015 at 06:03:46PM +0100, Markus

Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

Sahid Orentino Ferdjaoui wrote on 02/23/2015 11:13:12 AM: > From: Sahid Orentino Ferdjaoui > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 02/23/2015 11:17 AM > Subject: Re: [openstack-dev] [nova] bp serial-ports *partly* implemented? > > On Fri, Feb 20, 2015

Re: [openstack-dev] [stable][requirements] External dependency caps introduced in 499db6b

On Mon, Feb 23, 2015, at 06:31 PM, Joe Gordon wrote: > On Mon, Feb 23, 2015 at 11:04 AM, Doug Hellmann > wrote: > > > > > > > On Mon, Feb 23, 2015, at 12:26 PM, Joe Gordon wrote: > > > On Mon, Feb 23, 2015 at 8:49 AM, Ihar Hrachyshka > > > wrote: > > > > > > > -BEGIN PGP SIGNED MESSAGE

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On Tue, Feb 24, 2015 at 08:50:45AM -0500, Sean Dague wrote: > On 02/24/2015 07:48 AM, Russell Bryant wrote: > > On 02/24/2015 12:54 PM, Daniel P. Berrange wrote: > >> On Tue, Feb 24, 2015 at 11:48:29AM +, Chris Dent wrote: > >>> On Tue, 24 Feb 2015, Daniel P. Berrange wrote: > >>> > need t

[openstack-dev] [TripleO] Midcycle Summary

Hi Everyone, TripleO held a midcycle meetup from February 18th-20th in Seattle. Thanks to HP for hosting the event! I wanted to send out a summary of what went on. We also captured some notes on an etherpad[0]. The first order of business was that I volunteered to serve as PTL of TripleO for the

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On Tue, 24 Feb 2015, Sean Dague wrote: That also provides a very concrete answer to "will people show up". Because if they do, and we get this horizontal refactoring happening, then we get to the point of being able to change release cadences faster. If they don't, we remain with the existing sy

Re: [openstack-dev] [infra] [cinder] CI via infra for the DRBD Cinder driver

On 02/24/2015 04:40 AM, Duncan Thomas wrote: > For cinder, we don't want to gate on drivers, and will be unhappy if that > gets turned on, so the story hasn't changed, Anita. > > I think Jim was pointing out the technical possibility, which is a fine and > valid thing to point out. Cinder core are

Re: [openstack-dev] [thirdpartyCI][cinder] Question about certification

Thanks Duncan. It's commenting and it works (meaning it runs and it's able to detect errors). Sometimes it gives a FAILURE but that's either due to the patch (rare) or due to devstack (often). Also logs are visible and included in the comment. Eduard On Tue, Feb 24, 2015 at 2:31 PM, Duncan Thoma

Re: [openstack-dev] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

On Fri, Feb 20, 2015 at 10:49:29AM -0800, Joe Gordon wrote: > On Fri, Feb 20, 2015 at 7:29 AM, Deepak Shetty wrote: > > > Hi Jeremy, > > Couldn't find anything strong in the logs to back the reason for OOM. > > At the time OOM happens, mysqld and java processes have the most RAM hence > > OOM s

Re: [openstack-dev] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

FWIW, we tried to run our job in a rax provider VM (provided by ianw from his personal account) and we ran the tempest tests twice, but the OOM did not re-create. Of the 2 runs, one of the run used the same PYTHONHASHSEED as we had in one of the failed runs, still no oom. Jeremy graciously agreed

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 24/02/15 11:02 +, Daniel P. Berrange wrote: On Tue, Feb 24, 2015 at 10:44:57AM +, Chris Dent wrote: On Tue, 24 Feb 2015, Daniel P. Berrange wrote: >I was writing this mail for the past few days, but the nova thread >today prompted me to finish it off & send it :-) Thanks for doing t

  1   2   >