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

On 02/06/2015 23:34, Morgan Fainberg wrote: > Hi Henrique, > > I don't think we need to specifically call out that we want a domain, we > should always reference the namespace as we do today. Basically, if we > ask for a project name we need to also provide it's namespace (your > option #1). Thi

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

> -Original Message- > From: John Garbutt [mailto:j...@johngarbutt.com] > Sent: Monday, June 1, 2015 7:41 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug > fix or not? > > On 31 May 2015

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

> -Original Message- > From: Jens Rosenboom [mailto:j.rosenb...@x-ion.de] > Sent: Wednesday, June 3, 2015 2:17 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug > fix or not? > > 2015-06-0

Re: [openstack-dev] [nova] I think nova behaves poorly when booting multiple instances

Le 02/06/2015 22:36, Andrew Laski a écrit : On 06/02/15 at 11:28am, Alexis Lee wrote: Andrew Laski said on Mon, Jun 01, 2015 at 09:26:33AM -0400: However what these parameters give users, versus orchestrating outside of Nova, is the ability to have the instances all scheduled as a single bloc

Re: [openstack-dev] [nova] I think nova behaves poorly when booting multiple instances

Le 03/06/2015 04:17, Chris Friesen a écrit : On 06/02/2015 07:48 PM, Jay Pipes wrote: On 06/02/2015 07:25 PM, Chris Friesen wrote: In many cases only nova-compute can resolve races (resource tracking of specific CPU cores, specific PCI devices, etc. in the face of parallel scheduling) so un

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

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. -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info signature.asc Description: PGP signature

Re: [openstack-dev] [nova] I think nova behaves poorly when booting multiple instances

(I unfortunately need to quote a second time since Chris cut half of the message below) Le 03/06/2015 03:48, Jay Pipes a écrit : On 06/02/2015 07:25 PM, Chris Friesen wrote: On 06/02/2015 02:36 PM, Andrew Laski wrote: There used to be a project that I think was looking for an API like this t

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

> -Original Message- > From: Xu, Hejie [mailto:hejie...@intel.com] > Sent: Wednesday, June 3, 2015 3:34 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug > fix or not? > > > > > -Ori

Re: [openstack-dev] [qa] SafeConfigParser.write duplicates defaults: bug or feature?

Hi David, it looks like a bug for me (as a user) just because I don't want to get 'dirty' config in the result. And looks like it should be easy to fix, we can just verify parameters from DEFAULT section and add them to the specific section only if we need to set another value for this parameter.

[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

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

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] [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 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] [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 -

[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

[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

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

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] [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] [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] [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] [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] [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] [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] [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

[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] 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

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] [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] [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] [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] [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] [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] [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

[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] [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.

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] [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] [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] [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

[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] [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

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] [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]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] [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

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] [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

[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] [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

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

[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][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

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

[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] [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 --

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] [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 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

[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] [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

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)

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] [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] [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] [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] [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] [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

[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] 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] [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] [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] [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] [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] 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

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

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][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] [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] [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 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

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] [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] [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] [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] [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] [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, 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] [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 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] [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

[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] [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

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 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] [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] [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] [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”

  1   2   3   >