Re: [openstack-dev] [Manila] Expected Manila behavior for creation of share from snapshot

On Tue, Jun 2, 2015 at 4:42 PM, Valeriy Ponomaryov wrote: > Deepak, > > "transfer-*" is not suitable in this particular case. Usage of share > networks causes creation of resources, when "transfer" does not. Also in > this topic we have "creation" of new share based on some snapshot. > In the or

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

John Garbutt wrote: >> I support moving nova to intermediate release, but not this cycle. > > +1 > > My main motivation here is actually making it clear how useful a > milestone release can be to get access to a feature you really, really > need much more quickly. > > Its a shame its called a "b

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/03/2015 11:23 AM, Thomas Goirand wrote: i On 06/03/2015 12:41 AM, James E. Blair wrote: Hi, This came up at the TC meeting today, and I volunteered to provide an update from the discussion. I've just read the IRC logs. And there's one thing I would like to make super clear. We, ie: Deb

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

2015-06-03 17:23 GMT+02:00 Thomas Goirand : > i > On 06/03/2015 12:41 AM, James E. Blair wrote: >> Hi, >> >> This came up at the TC meeting today, and I volunteered to provide an >> update from the discussion. > > I've just read the IRC logs. And there's one thing I would like to make > super clear

[openstack-dev] Kilo v3 identity problems

Hi guys, I have installed Kilo and try to use identity v3. I am using v3 policy file. I changed the domain_id for cloud admin as "default". As cloud admin, I tried "openstack domain list" and got the error message saying that I was not authorized. The part I changed in policy.json: "cloud_admin"

Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting

On 06/03/2015 06:47 AM, Sean Dague wrote: Where I get fuzzy on what I've read / discussed on Dynamic Policy right now is the fact that every API call is going to need another round trip to Keystone for a policy check (which would be db calls in keystone?) Which, maybe is fine, but it seems like t

[openstack-dev] [Cinder] Getting `ValueError: Field `volume_id' cannot be None`

Hi All, I am hitting a strange issue when running Cinder unit tests against my patch @ https://review.openstack.org/#/c/172808/5 I have spent 1 day and haven't been successfull at figuring how/why my patch is causing it! All tests failing are part of VolumeTestCase suite and from the error (see

Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting

I definitely buy the idea of layering policies on top of each other. But I'd worry about the long-term feasibility of putting default policies into code mainly because it ensures we'll never be able to provide any tools that help users (or other services like Horizon) know what the effective polic

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/03/2015 07:22 AM, Thomas Goirand wrote: > > However, talking with James Page (from Canonical, head of their server > team which does the OpenStack packaging), we believe it's best if we had > 2 different distinct teams: one for Fedora/SuSe/everything-rpm, and one > for Debian based distribut

Re: [openstack-dev] [cinder][third-party] CI FC passthrough scripts now available on stackforge

Ramy and Patrick - thank you for your work on this. This piece is definitely a challenge for any FC vendors setting up third party CI. On 06/03/2015 09:59 AM, Asselin, Ramy wrote: For anyone working on 3^rd party CI FC drivers: Patrick East and I have been working on making “FC pass-through”

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

On 3 June 2015 at 15:22, Doug Hellmann wrote: > Excerpts from John Garbutt's message of 2015-06-03 14:24:40 +0100: >> On 3 June 2015 at 14:09, Thierry Carrez wrote: >> > John Garbutt wrote: >> >> Given we are thinking Liberty is moving to semantic versioning, maybe >> >> it could look like this:

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

On 3 June 2015 at 15:37, Daniel P. Berrange wrote: > On Wed, Jun 03, 2015 at 10:26:03AM -0400, Doug Hellmann wrote: >> Excerpts from Daniel P. Berrange's message of 2015-06-03 14:28:01 +0100: >> > On Wed, Jun 03, 2015 at 03:09:28PM +0200, Thierry Carrez wrote: >> > > John Garbutt wrote: >> > > > G

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On Wed, 2015-06-03 at 17:45 +0300, Boris Pavlovic wrote: > James B. > > One more time. > Everybody makes mistakes and it's perfectly OK. > I don't want to punish anybody and my goal is to make system > that catch most of them (human mistakes) no matter how it is complicated. I'm not saying never

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

i On 06/03/2015 12:41 AM, James E. Blair wrote: > Hi, > > This came up at the TC meeting today, and I volunteered to provide an > update from the discussion. I've just read the IRC logs. And there's one thing I would like to make super clear. We, ie: Debian & Ubuntu folks, are very much clear on

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On 06/03/2015 02:43 PM, Boris Pavlovic wrote: > > I don't believe even my self, because I am human and I make mistakes. > My goal on the PTL position is to make such process that stops "human" > mistakes before they land in master. In other words everything should be > automated and pre not post

[openstack-dev] [cinder][third-party] CI FC passthrough scripts now available on stackforge

For anyone working on 3rd party CI FC drivers: Patrick East and I have been working on making “FC pass-through” scripts. The main use case of these scripts is to present the FC HBAs directly inside a VM in order to test your FC cinder driver. Now available in stackforge [1] Link available in cin

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/03/2015 04:15 PM, Derek Higgins wrote: > o Tools to build packages in CI jobs should provide a consistent > interface regardless of packaging being built Sure, we can have *some* of the tooling converging. But I don't see Debian/Ubuntu using anything else than git-buildpackage and sbuild (as

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On 2015-06-03 17:15:43 +0300 (+0300), Boris Pavlovic wrote: > I can't talk for other projects, so let's talk about Rally specific. > > We have single .git in root for whole project. > > We have 4 subdir that can have own maintainers: > - rally/deploy > - rally/verify > - rally/benchmark > - rally

Re: [openstack-dev] [infra][qa] Empty "Build succeeded" when filtering jobs

Evgeny Antyshev writes: > Some CIs like to narrow their scope to a certain set of files. > For that, they specify file mask on per-job basis. So there appear > annoying comments with only "Build succeeded". > (an example complaint: > http://lists.openstack.org/pipermail/openstack-dev/2015-June/06

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On Wed, 2015-06-03 at 09:29 +0300, Boris Pavlovic wrote: > *- Why not just trust people* > > People get tired and make mistakes (very often). > That's why we have blocking CI system that checks patches, > That's why we have rule 2 cores / review (sometimes even 3,4,5...)... > > In ideal work Lieu

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

James B. One more time. Everybody makes mistakes and it's perfectly OK. I don't want to punish anybody and my goal is to make system that catch most of them (human mistakes) no matter how it is complicated. Best regards, Boris Pavlovic On Wed, Jun 3, 2015 at 5:33 PM, James Bottomley < james.bot

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On Wed, Jun 3, 2015 at 9:33 AM, James Bottomley < james.bottom...@hansenpartnership.com> wrote: > On Wed, 2015-06-03 at 09:29 +0300, Boris Pavlovic wrote: > > *- Why not just trust people* > > > > People get tired and make mistakes (very often). > > That's why we have blocking CI system that check

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

On Wed, Jun 03, 2015 at 10:26:03AM -0400, Doug Hellmann wrote: > Excerpts from Daniel P. Berrange's message of 2015-06-03 14:28:01 +0100: > > On Wed, Jun 03, 2015 at 03:09:28PM +0200, Thierry Carrez wrote: > > > John Garbutt wrote: > > > > Given we are thinking Liberty is moving to semantic version

Re: [openstack-dev] [nova] RequestSpec object and Instance model

Le 03/06/2015 15:15, Nikola Đipanov a écrit : On 06/02/2015 03:14 PM, Sylvain Bauza wrote: Hi, Currently working on implementing the RequestSpec object BP [1], I had some cool comments on my change here : https://review.openstack.org/#/c/145528/12/nova/objects/request_spec.py,cm Since we did

Re: [openstack-dev] [packaging] Source RPMs for RDO Kilo?

2015-06-03 12:59 GMT+02:00 Neil Jerram : > Many thanks, Haïkel, that looks like the information that my team needed. > > Neil > Feel free to ask or join us on our downstream irc channel (#rdo @ freenode) if you have further questions. We also hold weekly public irc meetings about downstrea

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/03/2015 06:47 AM, Sean Dague wrote: > On 06/02/2015 10:40 PM, Matthew Thode wrote: >> On 06/02/2015 05:41 PM, James E. Blair wrote: >>> Hi, >>> >>> This came up at the TC meeting today, and I volunteered to provide an >>> update from the discussion. >>> >>> In general, I think there is a lot

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

Excerpts from Daniel P. Berrange's message of 2015-06-03 14:28:01 +0100: > On Wed, Jun 03, 2015 at 03:09:28PM +0200, Thierry Carrez wrote: > > John Garbutt wrote: > > > Given we are thinking Liberty is moving to semantic versioning, maybe > > > it could look like this: > > > * 12.0.1 (liberty-1) wi

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi James B., Thanks for this reply. As you asked for ACK from all parts, my words will be very much like the ones of James P. (I've just read his message, and I'm jealous of his nice native-English wording...:)). On 06/03/2015 12:41 AM, James E. B

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

Excerpts from John Garbutt's message of 2015-06-03 14:24:40 +0100: > On 3 June 2015 at 14:09, Thierry Carrez wrote: > > John Garbutt wrote: > >> Given we are thinking Liberty is moving to semantic versioning, maybe > >> it could look like this: > >> * 12.0.1 (liberty-1) will have some features (ho

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

Le 03/06/2015 16:02, Nikola Đipanov a écrit : On 06/03/2015 02:13 PM, John Garbutt wrote: On 3 June 2015 at 13:53, Ed Leafe wrote: On Jun 2, 2015, at 5:58 AM, Alexis Lee wrote: If you allocate all the memory of a box to high-mem instances, you may not be billing for all the CPU and disk w

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Jeremy, Except that reorganizing files in a repo so that you can have sane > pattern matches across them for different review subteams is > _exactly_ this. The question is really one of "do you have a > separate .git in each of the directory trees for your subteams or > only one .git in the paren

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

On Jun 3, 2015, at 9:10 AM, Doug Hellmann wrote: > These numbers don't match the meaning of semver, though. Semver > describes clearly why you increment each part of the version number > [1]. We can't call it semver and then make up our own completely > different rules. Heh, I was just about to

[openstack-dev] Targeting icehouse-eol?

Following on the thread about no longer doing stable point releases [1] at the summit we talked about doing icehouse-eol pretty soon [2]. I scrubbed the open stable/icehouse patches last week and we're down to at least one screen of changes now [3]. My thinking was once we've processed that l

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

Excerpts from Thierry Carrez's message of 2015-06-03 15:09:28 +0200: > John Garbutt wrote: > > Given we are thinking Liberty is moving to semantic versioning, maybe > > it could look like this: > > * 12.0.1 (liberty-1) will have some features (hopefully), and will be a tag > > * 12.0.2.dev1 is the

[openstack-dev] [TC] [All] [searchlight] Proposal for Project Searchlight

Hello TC members and fellow stackers! We have just submitted a review for project Searchlight to the OpenStack governance projects list [1]. Searchlight is a new project being split out of Glance based on the Glance Catalog Index Service, which was developed and released in Kilo [2]. We received c

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 02/06/15 23:41, James E. Blair wrote: Hi, This came up at the TC meeting today, and I volunteered to provide an update from the discussion. In general, I think there is a lot of support for a packaging effort in OpenStack. The discussion here has been great; we need to answer a few questi

[openstack-dev] [Murano] Discuss simulated-execution-mode-murano-engine blueprint

Hi all! I'd like to discuss first implementation thoughts about this [1] blueprint, that we want to implement in Liberty. This feature is supposed to increase the speed of application development. Now engine interacts with API to get input task and packages. Items, planned to implement first wou

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

Excerpts from John Garbutt's message of 2015-06-03 14:01:06 +0100: > Hi, > > (To be clear, this is a proposal to be discussed and not a decision.) > > The version number can help us communicate that: > * you can consume a milestone release > ** ... but the docs and translations may not be totally

[openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic Policy

I gave a presentation on Dynamic Policy for Access Control at the Summit. https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/dynamic-policy-for-access-control My slides are here: http://adam.younglogic.com/presentations/dynamic_policy.pp.pdf My original blog post attemp

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

On 06/03/2015 02:13 PM, John Garbutt wrote: > On 3 June 2015 at 13:53, Ed Leafe wrote: >> On Jun 2, 2015, at 5:58 AM, Alexis Lee wrote: >> >>> If you allocate all the memory of a box to high-mem instances, you may >>> not be billing for all the CPU and disk which are now unusable. That's >>> why

Re: [openstack-dev] [openstackclient] Image create-or-update

Hi Steve, yes, it makes sense, thanks for clarification. Flag --or-update for image create cmd looks as a good solution. Marek On 2.6.2015 23:34 Steve Martinelli wrote: I'm thinking that the current approach is probably how we want to keep things. I can't imagine many other projects being oka

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On Wed, Jun 03 2015, Boris Pavlovic wrote: > And I don't understand "what" so serious problem we have. > We were not able to do reverts so we build CI that doesn't allow us to > break master > so we don't need to do reverts. I really don't see here any big problems. Doing revert does not mean b

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi James On 02/06/15 23:41, James E. Blair wrote: > This came up at the TC meeting today, and I volunteered to provide > an update from the discussion. Thankyou - much appreciated. > In general, I think there is a lot of support for a packaging >

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

Hi David, You mean creating some kind of "delimiter" attribute in the domain entity? That seems like a good idea, although it does not solve the problem Morgan's mentioned that is the global hierarchy delimiter. Henrique Em qua, 3 de jun de 2015 às 04:21, David Chadwick escreveu: > > > On 02/0

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On 2015-06-03 09:29:38 +0300 (+0300), Boris Pavlovic wrote: > I will try to summarize all questions and reply on them: > > *- Why not splitting repo/plugins?* > > I don't want to make "architectural" decisions based on "social" or > "not enough good tool for review" issues. [...] Except that

Re: [openstack-dev] [Neutron] Functional tests coverage

Hi Serge, ... tox -e cover is not really efficient for functional tests ... You can start with dhcp, as there is already a base (abandoned change[1] from Marios). Regards, Cedric/ZZelle [1] https://review.openstack.org/136834 On Wed, Jun 3, 2015 at 3:21 PM, Andreas Jaeger wrote: > On 06/0

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Julien, If I were on you shoes I would pick words more carefully. When you are saying: > Reverting patches is unacceptable for Rally project. > Then you have a more serious problem than the rest of OpenStack. "you" means Rally community which is quite large. http://stackalytics.com/?release=li

[openstack-dev] [Manila] Changing DB regarding IDs for future migration/replication/AZ support

Hello guys, I would like to bring everyone up to speed on this topic, since we have a weekly meeting tomorrow and I would like to further discuss this, either here or tomorrow at the meeting, since this is something that is a pre-requisite for future features planned for liberty. We had a discuss

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

On Wed, Jun 03, 2015 at 03:09:28PM +0200, Thierry Carrez wrote: > John Garbutt wrote: > > Given we are thinking Liberty is moving to semantic versioning, maybe > > it could look like this: > > * 12.0.1 (liberty-1) will have some features (hopefully), and will be a tag > > * 12.0.2.dev1 is the first

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

On Wed, Jun 03, 2015 at 02:01:06PM +0100, John Garbutt wrote: > Hi, > > (To be clear, this is a proposal to be discussed and not a decision.) > > The version number can help us communicate that: > * you can consume a milestone release > ** ... but the docs and translations may not be totally up t

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

On 3 June 2015 at 14:09, Thierry Carrez wrote: > John Garbutt wrote: >> Given we are thinking Liberty is moving to semantic versioning, maybe >> it could look like this: >> * 12.0.1 (liberty-1) will have some features (hopefully), and will be a tag >> * 12.0.2.dev1 is the first commit after 12.0.1

Re: [openstack-dev] [Neutron] Functional tests coverage

On 06/03/2015 03:13 PM, Sergey Belous wrote: Hi All, I want to write the functional tests for Neutron. But the first I want to know the current coverage. How to measure test coverage of code? Where to look and what to start? "tox -e cover" should run the coverage tests of neutron, Andreas --

[openstack-dev] [infra][qa] Empty "Build succeeded" when filtering jobs

Some CIs like to narrow their scope to a certain set of files. For that, they specify file mask on per-job basis. So there appear annoying comments with only "Build succeeded". (an example complaint: http://lists.openstack.org/pipermail/openstack-dev/2015-June/065367.html) Moreover, most of CIs w

Re: [openstack-dev] [nova] RequestSpec object and Instance model

On 06/02/2015 03:14 PM, Sylvain Bauza wrote: > Hi, > > Currently working on implementing the RequestSpec object BP [1], I had > some cool comments on my change here : > https://review.openstack.org/#/c/145528/12/nova/objects/request_spec.py,cm > > Since we didn't discussed on how to persist that

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

On 3 June 2015 at 13:53, Ed Leafe wrote: > On Jun 2, 2015, at 5:58 AM, Alexis Lee wrote: > >> If you allocate all the memory of a box to high-mem instances, you may >> not be billing for all the CPU and disk which are now unusable. That's >> why flavors were introduced, afaik, and it's still a va

[openstack-dev] [Neutron] Functional tests coverage

Hi All, I want to write the functional tests for Neutron. But the first I want to know the current coverage. How to measure test coverage of code? Where to look and what to start? -- Best Regards, Sergey Belous __ OpenStack

Re: [openstack-dev] [Nova] Release versioning proposal for Liberty

John Garbutt wrote: > Given we are thinking Liberty is moving to semantic versioning, maybe > it could look like this: > * 12.0.1 (liberty-1) will have some features (hopefully), and will be a tag > * 12.0.2.dev1 is the first commit after 12.0.1 and does not get a tag > * 12.0.2.dev1234 would be th

Re: [openstack-dev] [nova][security] Enable user password complexity verification

On Wed, Jun 3, 2015 at 7:49 PM, David Stanek wrote: > > On Wed, Jun 3, 2015 at 6:04 AM liusheng wrote: >> >> Thanks for this topic, also, I think it is similar situation when talking >> about keystone users, not only the instances's password. >> > > In the past we've talked about having more adva

[openstack-dev] [Nova] Release versioning proposal for Liberty

Hi, (To be clear, this is a proposal to be discussed and not a decision.) The version number can help us communicate that: * you can consume a milestone release ** ... but the docs and translations may not be totally up to date * you can consume any commit ** ... but there is no formal tracking o

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

So yeah, that's precisely what we discussed at the cross-project workshop about In-team scaling in Vancouver (led by Kyle and myself). For those not present, I invite you to read the notes: https://etherpad.openstack.org/p/liberty-cross-project-in-team-scaling The conclusion was to explore splitt

Re: [openstack-dev] [all]Big Tent Mode within respective projects

THX Jay :) On Jun 3, 2015 8:41 PM, "Jay Pipes" wrote: > On 06/03/2015 08:25 AM, Zhipeng Huang wrote: > >> Hi All, >> >> As I understand, Neutron by far has the clearest big tent mode via its >> in-tree/out-of-tree decomposition, thanks to Kyle and other Neutron team >> members effort. >> >> So my

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

On Jun 2, 2015, at 5:58 AM, Alexis Lee wrote: > If you allocate all the memory of a box to high-mem instances, you may > not be billing for all the CPU and disk which are now unusable. That's > why flavors were introduced, afaik, and it's still a valid need. So we had a very good discussion at t

Re: [openstack-dev] [all]Big Tent Mode within respective projects

On 06/03/2015 08:25 AM, Zhipeng Huang wrote: Hi All, As I understand, Neutron by far has the clearest big tent mode via its in-tree/out-of-tree decomposition, thanks to Kyle and other Neutron team members effort. So my question is, is it the same for the other projects? For example, does Nova a

Re: [openstack-dev] [puppet] openstacklib::db::sync proposal

On 06/02/2015 07:05 PM, Mathieu Gagné wrote: On 2015-06-02 12:41 PM, Yanis Guenane wrote: The openstacklib::db::sync[2] is currently only a wrapper around an exec that does the actual db sync, this allow to make any modification to the exec into a single place. The main advantage IMO is that a

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On Wed, Jun 03 2015, Boris Pavlovic wrote: > Reverting patches is unacceptable for Rally project. Then you have a more serious problem than the rest of OpenStack. > This means that we merged bug and this is epic fail of PTL of project. Your code is already full of bugs and misfeatures, like the

Re: [openstack-dev] [nova][api] New micro-version needed for api bug fix or not?

On 3 June 2015 at 12:52, Jay Pipes wrote: > On 06/03/2015 02:34 AM, Chris Friesen wrote: >> >> On 06/03/2015 12:16 AM, Jens Rosenboom wrote: >> >>> I'm wondering though whether the current API behaviour here should be >>> changed more generally. Is there a plausible reason to silently >>> discard

[openstack-dev] [all]Big Tent Mode within respective projects

Hi All, As I understand, Neutron by far has the clearest big tent mode via its in-tree/out-of-tree decomposition, thanks to Kyle and other Neutron team members effort. So my question is, is it the same for the other projects? For example, does Nova also have the project-level Big Tent Mode Neutro

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/03/2015 01:56 PM, Boris Pavlovic wrote: > Ihar, > > Reverting patches is unacceptable for Rally project. This means > that we merged bug and this is epic fail of PTL of project. > That's a bar set too high. Though I don't believe Rally team

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Ihar, Reverting patches is unacceptable for Rally project. This means that we merged bug and this is epic fail of PTL of project. Let's take a look from other side, Ihar would you share with me your password of your email? You can believe me I won't do anything wrong with it. And "yes" I don't

Re: [openstack-dev] [nova][api] New micro-version needed for api bug fix or not?

On 06/03/2015 02:34 AM, Chris Friesen wrote: On 06/03/2015 12:16 AM, Jens Rosenboom wrote: I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would m

Re: [openstack-dev] [nova][security] Enable user password complexity verification

On Wed, Jun 3, 2015 at 6:04 AM liusheng wrote: > Thanks for this topic, also, I think it is similar situation when talking > about keystone users, not only the instances's password. > > In the past we've talked about having more advanced password management features in Keystone (complexity check

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/02/2015 10:40 PM, Matthew Thode wrote: > On 06/02/2015 05:41 PM, James E. Blair wrote: >> Hi, >> >> This came up at the TC meeting today, and I volunteered to provide an >> update from the discussion. >> >> In general, I think there is a lot of support for a packaging effort in >> OpenStack.

[openstack-dev] [release][oslo] stevedore release 1.5.0 (liberty)

We are excited to announce the release of: stevedore 1.5.0: Manage dynamic plugins for Python applications This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/stevedore For more details, please see the git log history below

Re: [openstack-dev] [Global Requirements] Adding apscheduler to global requirements

From: Renat Akhmerov Subject: Re: [openstack-dev] [Global Requirements] Adding apscheduler to global requirements Date: 3 Jun 2015 16:48:08 GMT+6 To: "OpenStack Development Mailing List (not for usage questions)" Thanks Doug, got it. >Limor, can you please explain why exactly do you need this

Re: [openstack-dev] [puppet] Change abandonment policy

On 06/02/2015 08:39 PM, Colleen Murphy wrote: 4) Auto-abandon after N months/weeks if patch has a -1 or -2 ``` If a change is given a -2 and the author has been unresponsive for at least 3 months, a script will automatically abandon the change, leaving a message about how the author can resto

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/03/2015 08:29 AM, Boris Pavlovic wrote: > Guys, > > I will try to summarize all questions and reply on them: > > *- Why not splitting repo/plugins?* > > I don't want to make "architectural" decisions based on "social" or > "not enough good

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On 06/03/2015 12:32 PM, Boris Pavlovic wrote: Guys, One more time it's NOT about reputation and it's NOT about believing somebody. It's about human nature. We are all making mistakes. And if we do, we can always revert a patch. System that checks can code review merge patch is just extra ch

Re: [openstack-dev] [packaging] Source RPMs for RDO Kilo?

Many thanks, Haïkel, that looks like the information that my team needed. Neil On 03/06/15 11:18, Haïkel wrote: Hi Neil, We're already having this discussion on the downstream list. RDO is currently moving packages publication for RHEL/CentOS over CentOS mirrors. That's just a matter

Re: [openstack-dev] [fuel] [HA] How long we need to wait for cloud recovery after some destructive scenarios?

Timur, some numbers and devs recommendations you can find by link[0], it is our HA Guid, feel free to contribute. Nastya. [0] https://wiki.openstack.org/wiki/HAGuideImprovements/TOC#HA_Intro_and_Concepts On Wed, Jun 3, 2015 at 1:06 PM, Timur Nurlygayanov < tnurlygaya...@mirantis.com> wrote: > L

Re: [openstack-dev] [Global Requirements] Adding apscheduler to global requirements

Thanks Doug, got it. Limor, can you please explain why exactly do you need this library? Renat Akhmerov @ Mirantis Inc. > On 02 Jun 2015, at 18:45, Doug Hellmann wrote: > > Excerpts from Renat Akhmerov's message of 2015-06-02 18:26:40 +0600: >> Any comments from TC on that? What is the typic

Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting

On 06/02/2015 06:27 PM, Morgan Fainberg wrote: > > > On Tue, Jun 2, 2015 at 12:09 PM, Adam Young > wrote: > > Since this a cross project concern, sending it out to the wider > mailing list: > > We have a sub-effort in Keystone to do better access control p

[openstack-dev] when trove-mgmt-client can be ready?

When trove-mgmt-client can be ready? -- Best Li Tianqing__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Guys, One more time it's NOT about reputation and it's NOT about believing somebody. It's about human nature. We are all making mistakes. System that checks can code review merge patch is just extra check to avoid unintentional mistakes of core reviewers and make things self organized. Best re

Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team

On 06/02/2015 06:16 PM, David Lyle wrote: > The Horizon project also uses the nova policy.json file to do role based > access control (RBAC) on the actions a user can perform. If the defaults > are hidden in the code, that makes those checks a lot more difficult to > perform. Horizon will then get

Re: [openstack-dev] [packaging] Source RPMs for RDO Kilo?

Hi Neil, We're already having this discussion on the downstream list. RDO is currently moving packages publication for RHEL/CentOS over CentOS mirrors. That's just a matter of time and finish the tooling automating the publication process for source packages. In the mean time, you can find source

Re: [openstack-dev] [Sahara] Can't upload jar file to Job Binaries from Horizon

Hi, This issues was introduced when python-sahara client moved to using keystone-client sessions. The keystone client has debug logs enabled and tries to log all requests and responses. So when uploading a job binary the request body has a binary content which is not printable from python’s per

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

Doesn’t this overlap with the work done for the OSProfiler ? More comments inline. Miguel Ángel Ajo On Wednesday, 3 de June de 2015 at 11:43, Kekane, Abhishek wrote: > Hi Devs, > > So for I have got following responses on the proposed solutions: > > Solution 1: Return tuple containing

Re: [openstack-dev] [fuel] [HA] How long we need to wait for cloud recovery after some destructive scenarios?

Looks like I forgot to add the link to [1] in the first email: [1] https://github.com/stackforge/haos On Wed, Jun 3, 2015 at 12:50 PM, Timur Nurlygayanov < tnurlygaya...@mirantis.com> wrote: > Hi team, > > I'm working on HA / destructive / recovery automated tests [1] for > OpenStack clouds and

Re: [openstack-dev] [nova][security] Enable user password complexity verification

Thanks for this topic, also, I think it is similar situation when talking about keystone users, not only the instances's password. 在 2015/6/3 17:48, 郑振宇 写道: Hi All, The current OpenStack does not provide user password complexity verification option. When performing actions such as create i

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Robert Collins said on Wed, Jun 03, 2015 at 11:12:35AM +1200: > So I'd like us to really get our heads around the idea that folk are > able to make promises ('I will only commit changes relevant to the DB > abstraction/transaction management') and honour them. And if they > don't - well, remove the

Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team

Hello Sean! +1 on defaults, resource-url style entries, hierarchy But, in the interest of staying "declarative", I am not comfortable with having default policies in code. I would rather have a default nova policy.json file in the nova code base and if no policy.json is supplied, have the nova

[openstack-dev] [fuel] [HA] How long we need to wait for cloud recovery after some destructive scenarios?

Hi team, I'm working on HA / destructive / recovery automated tests [1] for OpenStack clouds and I want to get some expectations from users, operators and developers for the speed of OpenStack recovery after some destructive actions. For example, how long cluster should be unavailable if one of th

[openstack-dev] [nova][security] Enable user password complexity verification

Hi All, The current OpenStack does not provide user password complexity verification option. When performing actions such as create instances, evacuate instances, rebuild instances, rescue instances and update instances' admin password. The complexity of user provided admin password has not been

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

Hi Devs, So for I have got following responses on the proposed solutions: Solution 1: Return tuple containing headers and body from - 3 +1 Solution 2: Use thread local storage to store 'x-openstack-request-id' returned from headers - 0 +1 Solution 3: Unique request-id across OpenStack Services -

Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team

On 2 June 2015 at 17:22, Sean Dague wrote: > Nova has a very large API, and during the last release cycle a lot of > work was done to move all the API checking properly into policy, and not > do admin context checks at the database level. The result is a very > large policy file - > https://github

Re: [openstack-dev] [Murano] Nominating Filip Blaha for murano-core

Great thanks for your votes! Thanks for trust in this challenging role. I don't know what to say more :-) Regards Filip On 06/02/2015 05:17 PM, Serg Melikyan wrote: Filip, my congratulations! Welcome! On Tue, Jun 2, 2015 at 5:34 PM, Stan Lagun > wrote: +1

Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team

On 2 June 2015 at 23:48, Kevin L. Mitchell wrote: > On Tue, 2015-06-02 at 16:16 -0600, David Lyle wrote: >> The Horizon project also uses the nova policy.json file to do role >> based access control (RBAC) on the actions a user can perform. If the >> defaults are hidden in the code, that makes tho

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On Wed, Jun 03, 2015 at 10:22:59AM +0200, Julien Danjou wrote: > On Wed, Jun 03 2015, Robert Collins wrote: > > > We *really* don't need a technical solution to a social problem. > > I totally agree. The trust issues is not going to be solve with a tool. +1 I can not believe people will commit s

[openstack-dev] [packaging] Source RPMs for RDO Kilo?

Where are the source RPMs that correspond to the binary RPMs at https://repos.fedorapeople.org/repos/openstack/openstack-kilo/el7/ ? I guess that https://repos.fedorapeople.org/repos/openstack/openstack-kilo/testing/source/ might be quite close - but the 'testing' in this URL suggests that ht

[openstack-dev] [nova] Should we add instance action event to live migration?

Hi all: We have the instance action and action event for most of the instance operations, exclude: live-migration. In the current master code, when we do live-migration, the instance action is recorded, but the action event for live-migration is lost. I'm not sure that it's a bug or design

<    1   2   3   >