Re: [openstack-dev] [nova] Is the BP approval process broken?

Joe Gordon wrote: > On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh > mailto:alan.kavan...@ericsson.com>> wrote: > >> I share Donald's points here, I believe what would help is to >> clearly describe in the Wiki the process and workflow for the BP >> approval process and build in this p

Re: [openstack-dev] [nova] Is the BP approval process broken?

On Thu, Aug 28, 2014 at 03:44:25PM -0400, Jay Pipes wrote: > On 08/27/2014 09:04 PM, Dugger, Donald D wrote: > >I’ll try and not whine about my pet project but I do think there is a > >problem here. For the Gantt project to split out the scheduler there is > >a crucial BP that needs to be implemen

Re: [openstack-dev] [nova] Is the BP approval process broken?

On Thu, Aug 28, 2014 at 04:27:59PM -0600, Chris Friesen wrote: > On 08/28/2014 04:01 PM, Joe Gordon wrote: > > > > > > > >On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh > >mailto:alan.kavan...@ericsson.com>> wrote: > > > >I share Donald's points here, I believe what would help is to > >clea

Re: [openstack-dev] [all] Design Summit reloaded

Sean Dague wrote: > On 08/28/2014 03:06 PM, Jay Pipes wrote: >> On 08/28/2014 02:21 PM, Sean Dague wrote: >>> On 08/28/2014 01:58 PM, Jay Pipes wrote: On 08/27/2014 11:34 AM, Doug Hellmann wrote: > On Aug 27, 2014, at 8:51 AM, Thierry Carrez > wrote: >> Day 1. Cross-project sessio

Re: [openstack-dev] [all] Design Summit reloaded

Anne Gentle wrote: > On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez > wrote: > > Hi everyone, > > I've been thinking about what changes we can bring to the Design Summit > format to make it more productive. I've heard the feedback from the > mid-cyc

Re: [openstack-dev] [nova] Is the BP approval process broken?

On Fri, Aug 29, 2014 at 11:07:33AM +0200, Thierry Carrez wrote: > Joe Gordon wrote: > > On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh > > mailto:alan.kavan...@ericsson.com>> wrote: > > > >> I share Donald's points here, I believe what would help is to > >> clearly describe in the Wiki the

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

James Polley wrote: > > > However, Thierry pointed > > to https://wiki.openstack.org/wiki/Governance/Foundation/Structure > which > > still refers to Project Technical Leads and says explicitly that they > > lead individual projects, not programs. I actually have edit access to

[openstack-dev] [Neutron][stable] How to backport database schema fixes

Hi, all It seems that currently it's hard to backport any database schema fix to Neutron [1] which uses alembic to manage db schema version. Nova has the same issue before and a workaround is to put some placeholder files before each release. So first do we allow db schema fixes to be backport to

Re: [openstack-dev] [oslo] change to deprecation policy in the incubator

That all makes sense to me. Doug Hellmann wrote: > Before Juno we set a deprecation policy for graduating libraries that said > the incubated versions of the modules would stay in the incubator repository > for one full cycle after graduation. This gives projects time to adopt the > libraries a

Re: [openstack-dev] [Horizon] Some thoughts about Horizon's test suite

On 29/08/14 04:22, Richard Jones wrote: > Very recently I attempted to fix a simple bug in which a Panel was being > displayed when it shouldn't have been. The resultant 5-line fix ended up > breaking 498 of the 1048 unit tests in the suite. I estimated that it > would take about a week's effort

Re: [openstack-dev] [oslo] change to deprecation policy in the incubator

On 08/28/2014 06:14 PM, Doug Hellmann wrote: > Before Juno we set a deprecation policy for graduating libraries that said > the incubated versions of the modules would stay in the incubator repository > for one full cycle after graduation. This gives projects time to adopt the > libraries and st

Re: [openstack-dev] Review change to nova api pretty please?

On 08/29/2014 07:52 AM, Alex Leonhardt wrote: > Hi All, > > Could someone please do the honor > :) https://review.openstack.org/#/c/116472/ ? > PEP8 failed, but thats not my fault ;) hehe > Please, abstain to send review requests to the mailing list. Thanks! http://lists.openstack.org/piperm

Re: [openstack-dev] [nova] Is the BP approval process broken?

Going a bit further up the thread where we are still talking about spec reviews and not code reviews... On 28 August 2014 21:42, Dugger, Donald D wrote: > I would contend that that right there is an indication that there's a problem > with the process. We got two nova-core reviewer sponsors, to

Re: [openstack-dev] [Horizon] Some thoughts about Horizon's test suite

Thanks for your thoughts Radomir. The nova api in question is memoized so it'll only be called once per request. Caching it for longer would be a very good idea, but that then brings into play deeper knowledge than I have about how long to cache things like nova extension configuration. Also, I loo

Re: [openstack-dev] [nova] Is the BP approval process broken?

On 28 August 2014 21:58, Chris Friesen wrote: > On 08/28/2014 02:25 PM, Jay Pipes wrote: >> On 08/28/2014 04:05 PM, Chris Friesen wrote: >>> The overall "scheduler-lib" Blueprint is marked with a "high" priority >>> at "http://status.openstack.org/release/";. Hopefully that would apply >>> to sub

Re: [openstack-dev] [Neutron][stable] How to backport database schema fixes

If you are running version from a stable branch, changes in DB migrations should generally be forbidden as the policy states since those migrations are not likely to be executed again. Downgrading and then upgrading again is extremely risky and I don't think anybody would ever do that. However, if

[openstack-dev] [magnetodb] Backup procedure for Cassandra backend

Hello, stackers. I'd like to start thread related to backuping procedure for MagnetoDB, to be precise, for Cassandra backend. In order to accomplish backuping procedure for Cassandra we need to understand how does backuping work. To perform backuping: 1. We need to SSH into each node 2

Re: [openstack-dev] [neutron] VPNaaS pending state handling

Comments in-line @PCM PCM (Paul Michali) MAIL …..…. p...@cisco.com IRC ……..… pcm_ (irc.freenode.com) TW ………... @pmichali GPG Key … 4525ECC253E31A83 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 On Aug 28, 2014, at 11:57 AM, Sridhar Ramaswamy wrote: > > https://bugs.launc

[openstack-dev] [Ceilometer] Complex resource_metadata could fail to store in MongoDB

Hi, folks. I was interested in the problem with storing of samples, that contain complex resource_metadata, in MongoDB database [1]. If data is a dict that has a key(s) with dots (i.e. .), dollar signs (i.e. $), or null characters, it wouldn't be stored. It is happened because these characters a

Re: [openstack-dev] [Openstack-stable-maint] [Neutron][stable] How to backport database schema fixes

> It seems that currently it's hard to backport any database schema fix to > Neutron [1] which uses alembic to manage db schema version. Nova has the > same issue before > and a workaround is to put some placeholder files before each release. > So first do we allow db schema fixes to be backport to

Re: [openstack-dev] [Neutron][stable] How to backport database schema fixes

On 08/29/2014 06:54 AM, Salvatore Orlando wrote: > If you are running version from a stable branch, changes in DB > migrations should generally be forbidden as the policy states since > those migrations are not likely to be executed again. Downgrading and > then upgrading again is extremely risky a

[openstack-dev] [bashate] .bashateignore

Integrating bashate into something as complicated as devstack, the file ignore problem has come up. We seem to have 3 approaches out under review right now: https://review.openstack.org/#/c/117425 : --exclude-dirs https://review.openstack.org/#/c/115794 : --exclude-dirs (different implementation)

Re: [openstack-dev] [all] Design Summit reloaded

On Fri, 2014-08-29 at 11:23 +0200, Thierry Carrez wrote: > Anne Gentle wrote: > > On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez > > wrote: > > > > Hi everyone, > > > > I've been thinking about what changes we can bring to the Design Summit > > format

Re: [openstack-dev] [bashate] .bashateignore

On Fri, Aug 29, 2014 at 7:42 AM, Sean Dague wrote: > Integrating bashate into something as complicated as devstack, the file > ignore problem has come up. > > We seem to have 3 approaches out under review right now: > > https://review.openstack.org/#/c/117425 : --exclude-dirs > https://review.ope

Re: [openstack-dev] [Openstack-stable-maint] [Neutron][stable] How to backport database schema fixes

On Aug 29, 2014, at 7:23 AM, Alan Pevec wrote: >> It seems that currently it's hard to backport any database schema fix to >> Neutron [1] which uses alembic to manage db schema version. Nova has the >> same issue before >> and a workaround is to put some placeholder files before each release. >>

Re: [openstack-dev] [cinder]pylint errors with hashlib

Already done by xing-yang: https://review.openstack.org/#/c/117685/. Thanks for raising this topic. Regards, Ivan Kolodyazhny, Software Engineer, Mirantis Inc. On Fri, Aug 29, 2014 at 7:40 AM, John Griffith wrote: > > > > On Mon, Aug 25, 2014 at 8:47 PM, Clark Boylan > wrote: > >> On Mon, Aug

Re: [openstack-dev] [nova] [neutron] Specs for K release

On Thu, Aug 28, 2014 at 11:12 PM, Brandon Logan wrote: > Kyle, > Does this apply to blueprints that are destined for the incubator as > well? I assume the incubator does require a spec process too. > Incubator code still requires a spec, yes. For the things which are incubator candidates, I have

Re: [openstack-dev] [magnetodb] Backup procedure for Cassandra backend

Hello Denis, Thank you for very useful knowledge sharing. But I have one more question. As far as I understood if we have replication factor 3 it means that our backup may contain three copies of the same data. Also it may contain some not compacted sstables set. Do we have any ability to compact

Re: [openstack-dev] [bashate] .bashateignore

On 08/29/2014 08:53 AM, Dean Troyer wrote: > On Fri, Aug 29, 2014 at 7:42 AM, Sean Dague > wrote: > > Integrating bashate into something as complicated as devstack, the file > ignore problem has come up. > > We seem to have 3 approaches out under review right n

Re: [openstack-dev] [nova][neutron] Migration from nova-network to Neutron for large production clouds

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/08/14 12:59, Tim Bell wrote: >> -Original Message- From: Michael Still >> [mailto:mi...@stillhq.com] Sent: 26 August 2014 22:20 To: >> OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [nova][

[openstack-dev] [qa] Lack of consistency in returning response from tempest clients

While reviewing patches for moving response checking to the clients, I noticed that there are places where client methods do not return any value. This is usually, but not always, a delete method. IMO, every rest client method should return at least the response. Some services return just the re

Re: [openstack-dev] [magnetodb] Backup procedure for Cassandra backend

On Fri, Aug 29, 2014 at 4:29 PM, Dmitriy Ukhlov wrote: > Hello Denis, > Thank you for very useful knowledge sharing. > > But I have one more question. As far as I understood if we have > replication factor 3 it means that our backup may contain three copies of > the same data. Also it may contain

Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

On 08/29/2014 10:19 AM, David Kranz wrote: While reviewing patches for moving response checking to the clients, I noticed that there are places where client methods do not return any value. This is usually, but not always, a delete method. IMO, every rest client method should return at least the

Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

On 08/29/2014 10:19 AM, David Kranz wrote: > While reviewing patches for moving response checking to the clients, I > noticed that there are places where client methods do not return any value. > This is usually, but not always, a delete method. IMO, every rest client > method should return at leas

Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

On 08/29/2014 10:56 AM, Sean Dague wrote: On 08/29/2014 10:19 AM, David Kranz wrote: While reviewing patches for moving response checking to the clients, I noticed that there are places where client methods do not return any value. This is usually, but not always, a delete method. IMO, every res

Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

Yeah, Sean's proposal looks great to me On Fri, Aug 29, 2014 at 10:13 AM, David Kranz wrote: > On 08/29/2014 10:56 AM, Sean Dague wrote: > >> On 08/29/2014 10:19 AM, David Kranz wrote: >> >>> While reviewing patches for moving response checking to the clients, I >>> noticed that there are plac

Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes

Yair, I am very well plugged-in to this project and feeding the necessary information to the weekly Tempest IRC meeting. In fact, since a few weeks ago, I've made a point of sharing weekly with the Tempest team what I am doing with the LBaaS team from the Tempest point of view. Cheers On Thu, A

Re: [openstack-dev] [all] Design Summit reloaded

Hayes, Graham wrote: >>> Yep, I think this works in theory, the tough part will be when all the >>> incubating projects realize they're sending people for a single day? >>> Maybe it'll work out differently than I think though. It means fitting >>> ironic, barbican, designate, manila, marconi in a d

Re: [openstack-dev] [zaqar] [marconi] Removing GET message by ID in v1.1 (Redux)

On Aug 28, 2014, at 3:08 AM, Flavio Percoco wrote: > Unfortunately, as Nataliia mentioned, we can't just get rid of it in > v1.1 because that implies a major change in the API, which would require > a major release. What we can do, though, is start working on a spec for > the V2 of the API. +1

Re: [openstack-dev] [neutron][lbaas][octavia]

Stephen See inline comments. Susanne - Susanne-- I think you are conflating the difference between "OpenStack incubation" and "Neutron incubator." These are two very different matters and should be treated separately. So, addressing each one in

Re: [openstack-dev] [Neutron][LBass] Design sessions for Neutron LBaaS. What do we want/need?

I agree with Brandon that it will be difficult to find spaces for Octavia, and the pod is a valid option. Nevertheless it is always worth trying. For the "traditional" load balancing service instead I reckon #1 is a very good thing to discuss. Problem is that it is also hard to conclude anything i

Re: [openstack-dev] [nova] Is the BP approval process broken?

On 28/08/14 17:02, Jay Pipes wrote: I understand your frustration about the silence, but the silence from core team members may actually be a loud statement about where their priorities are. I don't know enough about the Nova review situation to say if the process is broken or not. But I can s

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

I've updated the spec: https://review.openstack.org/#/c/116874/ Major change in this spec: get rid of unpacked upgrade tarball. Use only lrzipped archives. It will save disk space and network traffic, it will make upgrade process longer, it will make our upgrade tests longer as well, it will make

Re: [openstack-dev] [nova] Is the BP approval process broken?

On 08/29/2014 12:25 PM, Zane Bitter wrote: On 28/08/14 17:02, Jay Pipes wrote: I understand your frustration about the silence, but the silence from core team members may actually be a loud statement about where their priorities are. I don't know enough about the Nova review situation to say i

Re: [openstack-dev] [neutron][lbaas][octavia]

Kyle, I am confused. So basically you (and Mark) are saying: 1) We deprecate Neutron LBaaS v1 2) We spin out Neutron LBaaS v2 into it's own project in stackforge 3) Users don't have an OpenStack LBaaS any longer until we graduate from OpenStack incubation (as opposed Neutron incubation) I am ho

Re: [openstack-dev] [nova] Is the BP approval process broken?

Well, I think that there is a sign of a broken (or at least bent) process and that's what I'm trying to expose. Especially given the ongoing conversations over Gantt it seems wrong that ultimately it was rejected due to silence. Maybe rejecting the BP was the right decision but the way the dec

Re: [openstack-dev] [nova] Is the BP approval process broken?

I think the point is that if there were discussions that lead to uncertainty about the split, they should have resulted in a - 1/-2 on the spec instead of letting it sit there. On Aug 29, 2014 9:46 AM, "Jay Pipes" wrote: > On 08/29/2014 12:25 PM, Zane Bitter wrote: > >> On 28/08/14 17:02, Jay Pip

Re: [openstack-dev] [nova] Is the BP approval process broken?

I think this is now more about code reviews, but this is important... On 29 August 2014 10:30, Daniel P. Berrange wrote: > On Fri, Aug 29, 2014 at 11:07:33AM +0200, Thierry Carrez wrote: >> Joe Gordon wrote: >> > On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh >> > mailto:alan.kavan...@ericsson.co

Re: [openstack-dev] Status of Neutron IPv6 dual stack

Hi Dane, Just wondering if you've made some progression on the matter :) Regards, Harm op 19-08-14 19:08, Dane Leblanc (leblancd) schreef: > > Hi Harm: > > > > Unfortunately I haven't had time to complete the changes yet. Even > if/when these changes are completed, it's unlikely that this blue

Re: [openstack-dev] [nova] Is the BP approval process broken?

All good points but I want to add an observation. IRC seems to be the generic answer to all problems and, personally, I don't think that's a good medium. Having to depend upon who just might be on IRC at a particular moment seems rather hit or miss. I much prefer something like email where I

Re: [openstack-dev] [nova] refactoring of resize/migrate

On 28 August 2014 09:50, Markus Zoeller wrote: > Jay Pipes wrote on 08/27/2014 08:57:08 PM: > >> From: Jay Pipes >> To: openstack-dev@lists.openstack.org >> Date: 08/27/2014 08:59 PM >> Subject: Re: [openstack-dev] [nova] refactoring of resize/migrate >> >> On 08/27/2014 06:41 AM, Markus Zoeller

Re: [openstack-dev] [bashate] .bashateignore

On Fri, Aug 29, 2014 at 9:02 AM, Sean Dague wrote: > If pathspec did the right thing, pulling in the extra dep would be fine, > but it doesn't seem like it does. > After looking at it with fresh eyes, the issue could be resolved by combining two methods from pathspec and still leveraging the reg

Re: [openstack-dev] [nova] Kilo Specs Schedule

On 28 August 2014 23:53, Joe Gordon wrote: > We just finished discussing when to open up Kilo specs at the nova meeting > today [0], and Kilo specs will open right after we cut Juno RC1 (around Sept > 25th [1]). Additionally, the spec template will most likely be revised. > > We still have a huge

Re: [openstack-dev] [nova] nova backup not working in stable/icehouse?

On 08/29/2014 02:48 AM, Preston L. Bannister wrote: Looking to put a proper implementation of instance backup into OpenStack. Started by writing a simple set of baseline tests and running against the stable/icehouse branch. They failed! https://github.com/dreadedhill-work/openstack-backup-script

Re: [openstack-dev] [nova] Is the BP approval process broken?

On 29 August 2014 18:48, Dugger, Donald D wrote: > All good points but I want to add an observation. > > IRC seems to be the generic answer to all problems and, personally, I don't > think that's a good medium. Having to depend upon who just might be on IRC > at a particular moment seems rather

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

On 08/26/2014 10:14 AM, Zane Bitter wrote: Steve Baker has started the process of moving Heat tests out of the Tempest repository and into the Heat repository, and we're looking for some guidance on how they should be packaged in a consistent way. Apparently there are a few projects already packa

Re: [openstack-dev] [neutron] VPNaaS pending state handling

Thanks Paul for your thoughts. See inline [SridharR] ... On Fri, Aug 29, 2014 at 4:19 AM, Paul Michali (pcm) wrote: > Comments in-line @PCM > > > PCM (Paul Michali) > > MAIL …..…. p...@cisco.com > IRC ……..… pcm_ (irc.freenode.com) > TW ………... @pmichali > GPG Key … 4525ECC253E31A83 > Fingerprint

Re: [openstack-dev] [neutron] python-neutronclient, launchpad, and milestones

On 7/29/2014 4:12 PM, Kyle Mestery wrote: On Tue, Jul 29, 2014 at 3:50 PM, Nader Lahouti wrote: Hi Kyle, I have a BP listed in https://blueprints.launchpad.net/python-neutronclient and looks like it is targeted for 3.0 (it is needed fro juno-3) The code is ready and in the review. Can it be

Re: [openstack-dev] [neutron] python-neutronclient, launchpad, and milestones

On Fri, Aug 29, 2014 at 1:40 PM, Matt Riedemann wrote: > > > On 7/29/2014 4:12 PM, Kyle Mestery wrote: >> >> On Tue, Jul 29, 2014 at 3:50 PM, Nader Lahouti >> wrote: >>> >>> Hi Kyle, >>> >>> I have a BP listed in >>> https://blueprints.launchpad.net/python-neutronclient >>> and looks like it is t

[openstack-dev] Rally scenario Issue

Hi I am trying to run the Rally scenario boot-runcommand-delete. This scenario has the following code def boot_runcommand_delete(self, image, flavor, script, interpreter, username, fixed_network="private",

[openstack-dev] [third-party] [infra] New mailing lists for third party announcements and account requests

Hi everyone, In an effort to move the third party work into its own space, we've created two new mailing lists: Third-party-announce This is where we will send announcements that third party operators need to know about and when the OpenStack Infrastructure team disables your account, with the r

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

Drago, It sounds like you convinced me to give D3.js a second chance :). I'll experiment with what can be achieved using force-directed graph layout combined with some composable svg object, hopefully this will save me from placing objects on the canvas on my own. I've read the barricade_Spec.js

Re: [openstack-dev] [OpenStack-Infra] [third-party] [infra] New mailing lists for third party announcements and account requests

On Fri 29 Aug 2014 12:47:00 PM PDT, Elizabeth K. Joseph wrote: > Third-party-request > > This list is the new place to request the creation or modification of > your third party account. Note that old requests sent to the > openstack-infra mailing list don't need to be resubmitted, they are > alrea

Re: [openstack-dev] Rally scenario Issue

Hi Ajay, looks like you need to use NeutronContext feature to configure Neutron Networks during the benchmarks execution. We now working on merge of two different comits with NeutronContext implementation: https://review.openstack.org/#/c/96300 and https://review.openstack.org/#/c/103306 could y

Re: [openstack-dev] Rally scenario Issue

Timur, Thanks for pointing Ajay. Ajay, Also I cannot see this failure unless I run rally with –v –d object. Actually rally is sotring information about all failures. To get information about them you can run next command: *rally task results --pprint* It will display all information about a

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

On 29/08/14 14:27, Jay Pipes wrote: On 08/26/2014 10:14 AM, Zane Bitter wrote: Steve Baker has started the process of moving Heat tests out of the Tempest repository and into the Heat repository, and we're looking for some guidance on how they should be packaged in a consistent way. Apparently t

Re: [openstack-dev] [OpenStack-Infra] [third-party] [infra] New mailing lists for third party announcements and account requests

On Fri, Aug 29, 2014 at 1:03 PM, Stefano Maffulli wrote: > On Fri 29 Aug 2014 12:47:00 PM PDT, Elizabeth K. Joseph wrote: >> Third-party-request >> >> This list is the new place to request the creation or modification of >> your third party account. Note that old requests sent to the >> openstack-

Re: [openstack-dev] [rally]Rally scenario Issue

Does this look right. { "VMTasks.boot_runcommand_delete": [ { "args": { "flavor": { "name": "m1.small" }, "image": { "name": "Ubuntu Server 14.04" },

Re: [openstack-dev] [OpenStack-Infra] [third-party] [infra] New mailing lists for third party announcements and account requests

Stefano Maffulli writes: > On Fri 29 Aug 2014 12:47:00 PM PDT, Elizabeth K. Joseph wrote: >> Third-party-request >> >> This list is the new place to request the creation or modification of >> your third party account. Note that old requests sent to the >> openstack-infra mailing list don't need t

Re: [openstack-dev] [rally]Rally scenario Issue

Sorry here is the context "context": { "users": { "tenants": 1, "users_per_tenant": 1 } "neutron_network": { "network_cidr": "10.%s.0.0/16", } } Because

Re: [openstack-dev] [rally]Rally scenario Issue

Issue fixed small syntax mistake in scenario file Will now look into more details Thx From: akalambu mailto:akala...@cisco.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, August 29, 2014 at 3:03 PM To: "OpenS

Re: [openstack-dev] [oslo] change to deprecation policy in the incubator

On 08/28/2014 11:14 AM, Doug Hellmann wrote: > Before Juno we set a deprecation policy for graduating libraries that said > the incubated versions of the modules would stay in the incubator repository > for one full cycle after graduation. This gives projects time to adopt the > libraries and st

Re: [openstack-dev] [oslo.messaging] Request to include AMQP 1.0 support in Juno-3

On 08/28/2014 12:34 PM, Doug Hellmann wrote: > > On Aug 28, 2014, at 8:36 AM, Mark McLoughlin wrote: > >> On Thu, 2014-08-28 at 13:24 +0200, Flavio Percoco wrote: >>> On 08/27/2014 03:35 PM, Ken Giusti wrote: Hi All, I believe Juno-3 is our last chance to get this feature [1] incl

Re: [openstack-dev] [TripleO] Heat AWS WaitCondition's count

There are still a few lingering wait conditions. They should probably be cleaned up from tripleo-heat-templates. Excerpts from Pavlo Shchelokovskyy's message of 2014-08-28 02:26:16 -0700: > Hi all, > > the AWS::CloudFormation::WaitCondition resource in Heat allows to update > the 'count' property

Re: [openstack-dev] Rally scenario Issue

Hi Timur With this I was able to create networks and attach VM to those networks. Would I now be able to ssh to this and run command what I am looking for is a unification of boot-runcommand-delete and this neutron_network so create network attach to router associate floating ip and ssh to it Aj

Re: [openstack-dev] [neutron][lbaas][octavia]

On Fri, Aug 29, 2014 at 11:51 AM, Eichberger, German wrote: > Kyle, > > I am confused. So basically you (and Mark) are saying: > > 1) We deprecate Neutron LBaaS v1 > 2) We spin out Neutron LBaaS v2 into it's own project in stackforge > 3) Users don't have an OpenStack LBaaS any longer until we gra

Re: [openstack-dev] [nova] Is the BP approval process broken?

Sorry folks, I just had a new daughter since Thursday so I'm on PTO until Monday, so thanks to the people who discussed about the blueprint I created and how we can avoid the problem raised by Don for Kilo. Answers inline. Le 29/08/2014 19:42, John Garbutt a écrit : I think this is now more

Re: [openstack-dev] [nova] Is the BP approval process broken?

On Aug 29, 2014 10:42 AM, "Dugger, Donald D" wrote: > > Well, I think that there is a sign of a broken (or at least bent) process and that's what I'm trying to expose. Especially given the ongoing conversations over Gantt it seems wrong that ultimately it was rejected due to silence. Maybe rejec

Re: [openstack-dev] [vmware] Canonical list of os types

- Original Message - > From: "Matthew Booth" > > On 14/08/14 12:41, Steve Gordon wrote: > > - Original Message - > >> From: "Matthew Booth" > >> To: "OpenStack Development Mailing List (not for usage questions)" > >> > >> > >> I've just spent the best part of a day tracking down

[openstack-dev] [Mistral] how to make Mistral build after keystone-pythonclient

Once we got dependencies on keystone-python client, Mistral doesn’t build for me on Mac. Before, I installed a new openssl (1.0.1h) - keystone authentication didn’t work with out it, remember? enykeev suggested to return to the old stock openssl, it worked. but this sort of sucks to switch

Re: [openstack-dev] [nova] nova backup not working in stable/icehouse?

The current "backup" APIs in OpenStack do not really make sense (and apparently do not work ... which perhaps says something about usage and usability). So in that sense, they could be removed. Wrote out a bit as to what is needed: http://bannister.us/weblog/2014/08/21/cloud-application-backup-and

Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

On Fri, 29 Aug 2014 11:13:39 -0400 David Kranz wrote: > On 08/29/2014 10:56 AM, Sean Dague wrote: > > On 08/29/2014 10:19 AM, David Kranz wrote: > >> While reviewing patches for moving response checking to the > >> clients, I noticed that there are places where client methods do > >> not return a

Re: [openstack-dev] [nova] nova backup not working in stable/icehouse?

I think the purpose of nova VM is not for persistent usage, and it should be used for stateless. However, there are use cases to use VM to replace bare metal applications, and it requires the same coverage, which I think VMware did pretty well. The nova backup is snapshot indeed, so it should be re

Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

+1 keeping the body as a ~dict will help with all existing asserts comparing dicts in tests. Andrea On 30 Aug 2014 06:45, "Christopher Yeoh" wrote: > On Fri, 29 Aug 2014 11:13:39 -0400 > David Kranz wrote: > > > On 08/29/2014 10:56 AM, Sean Dague wrote: > > > On 08/29/2014 10:19 AM, David Kran

Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

+1. That will also help full for API coming up with microversion like Nova. On Fri, Aug 29, 2014 at 11:56 PM, Sean Dague wrote: > On 08/29/2014 10:19 AM, David Kranz wrote: > > While reviewing patches for moving response checking to the clients, I > > noticed that there are places where client m