[openstack-dev] How to change the email address for openstack Id ?

Hi guys, Anyone know how to change the email address for openstack id ? I have already changed the "Preferred Email" at https://review.openstack.org/#/settings/contact, and it should worked, the new email already showed on https://review.openstack.org/#/settings/. But, when I try to login to

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

Excerpts from Kevin Carter's message of 2015-11-09 22:24:16 -0800: > Hello all, > > The rational behind using a solution like zookeeper makes sense however in > reviewing the thread I found myself asking if there was a better way to > address the problem without the addition of a Java based sol

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

>I believe Clint already linked to >https://aphyr.com/posts/309-knossos-redis-and-linearizability or >similar - but 'known for general ease of use and reliability' is uhm, >a bold claim. Its worth comparing that (and the other redis writeups) >to this one: https://aphyr.com/posts/291-call-me-maybe-

[openstack-dev] [Barbican] Enabling GET of secrets to work irrespective of Tenant name in login

Hi, Can we enable GET of secrets to work irrespective of Tenant name in the login? Consider there is an "admin" with "admin" role in "demo" tenant. I tried to query the "demo" tenant's secret using a login token which was generated from "admin" user & "admin" tenant. And I am getting a Forbid

[openstack-dev] [horizon][infra] Horizon gate currently broken

Hello, it looks like Horizon gate jobs (esp. the npm-run-lint jobs) are currently timing out, and it looks like a networking issue. I opened https://bugs.launchpad.net/horizon/+bug/1514734 to track this. Matthias __ OpenStac

Re: [openstack-dev] Introducing Lwood - a weekly summary of openstack-dev traffic

Hugh Blemings wrote: > Thankyou for the positive feedback received thus far for Lwood [1] > > I won't trouble the list with ongoing weekly posts for each edition but > did want to flag the existence of the summaries one more time being > mindful of the vagaries of reading the list during Summit :)

[openstack-dev] [vitrage] Next vitrage meeting

Hi, Vitrage next weekly meeting will be tomorrow, Wednesday at 9:00 UTC, on #openstack-meeting-3 channel. A link to the agenda: https://wiki.openstack.org/wiki/Meetings/Vitrage Ifat. __ OpenStack Development Mailing List (n

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

Clint, > While I'm sure it works a lot of the time, when it breaks it will break > in very mysterious, and possibly undetectable way. > For some things, this would be no big deal. But in some it may result in > total disaster, like two conductors trying to both own a single Ironic > node and one

[openstack-dev] [Ironic] Quick poll: OpenStackClient command for provision action

Hi all! I'd like to seek consensus (or at least some opinions) on patch https://review.openstack.org/#/c/206119/ It proposed the following command: openstack baremetal provision state --provide UUID (where --provide can also be --active, --deleted, --inspect, etc). I have several issues wi

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

Bartolomiej, it's customer-related patches, they, I think, have to be done for 6.1 prior to 8+ release. Dmitry, it's nice to hear about it. Did you consider to use linux capabilities on fuel-related processes instead of just using non-extended POSIX privileged/non-privileged permission checks? On

Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team

Matthew Treinish wrote: > [...] > The discussion here is about the cross project effort around stable branches, > which by design is a more limited scope now. Right now the cross project > effort > around stable branch policy is really 2 things (both of which ttx already > mentioned): > > 1. Keep

Re: [openstack-dev] [fuel] Using upstream packages & modules

Hello Alex! On Mon, Nov 9, 2015 at 9:29 PM, Alex Schultz wrote: > Hey folks, > > I'm testing[0] out flipping our current method of consuming upstream > puppet modules from using pinned versions hosted on fuel-infra to be > able to use the ones directly from upstream (master). This work is > pri

Re: [openstack-dev] [Ironic] Quick poll: OpenStackClient command for provision action

Hi, > Let's have a quick poll, which would you prefer and why: > > 1. openstack baremetal provision state --provide UUID > 2. openstack baremetal provision --provide UUID > 3. openstack baremetal provide UUID > 4. openstack baremetal set provision state --provide UUID > 5. openstack baremetal set

Re: [openstack-dev] [kuryr] Current status of docker python lib supports for libnetwork

On Mon, Nov 9, 2015 at 3:07 AM, Baohua Yang wrote: > Hi, kuryr guys > I may not attend tmr's IRC meeting, hence make a quick sync here. > One task is to investigate the docker python lib support to libnetwork. > I checked the code here at https://github.com/docker/docker-py. > The

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

On 11/10/2015 10:28 AM, Lucas Alvares Gomes wrote: Hi, Let's have a quick poll, which would you prefer and why: 1. openstack baremetal provision state --provide UUID 2. openstack baremetal provision --provide UUID 3. openstack baremetal provide UUID 4. openstack baremetal set provision state -

[openstack-dev] [heat][keystone] How to handle request for global admin in policy.json?

Hi all, Seeking some guidance (particularly from the keystone folks) ref this bug: https://bugs.launchpad.net/heat/+bug/1466694 tl;dr - Heat has historically been careful to make almost all requests scoped to exactly one project. Being aware of the long-standing bug #968696, we've deliberately

Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team

> -Original Message- > From: Matthew Treinish [mailto:[email protected]] > Sent: Tuesday, November 10, 2015 3:12 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [stable] Making stable maintenance its own > OpenStack project team > > O

Re: [openstack-dev] [fuel] Using upstream packages & modules

Hi Simon, using 'include' in HAProxy is damn conveniently, I don't think it should die. There is just one way I know to use haproxy with several different conf's - to construct looong command line with all of them - and it's really inconvenient. On Tue, Nov 10, 2015 at 12:20 PM, Simon Pas

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

> It's still not 100% consistent, "power" is a noun, "provision" is a verb. > Not sure it matters, though, adding OSC folks so that they can weigh in. > "provision" can also be a noun [1]. But since the OSC syntax suggest having a verb we could have something like: $ openstack baremetal set power

Re: [openstack-dev] [heat][keystone] How to handle request for global admin in policy.json?

Steve, Currently, your best option is to use something similar to the policy.v3cloudsample.json, where you basically “bless” a project (or domain) as being the “cloud admin project/domain”. Having a role on that gives you super-powers. The only trouble with this right now is that you have to

Re: [openstack-dev] [heat][keystone] How to handle request for global admin in policy.json?

Steve, Currently, your best option is to use something similar to the policy.v3cloudsample.json, where you basically “bless” a project (or domain) as being the “cloud admin project/domain”. Having a role on that gives you super-powers. The only trouble with this right now is that you have to

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

Kevin Carter wrote: >> I believe Clint already linked to >> https://aphyr.com/posts/309-knossos-redis-and-linearizability or >> similar - but 'known for general ease of use and reliability' is uhm, >> a bold claim. Its worth comparing that (and the other redis writeups) >> to this one: https://aphy

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

Hi, I like the last variant by Lucas, and agree we need to ensure the CLI interface is consistent between power and provision commands. Best regards, On Tue, Nov 10, 2015 at 12:00 PM Lucas Alvares Gomes wrote: > > It's still not 100% consistent, "power" is a noun, "provision" is a verb. > > Not

Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team

Kuvaja, Erno wrote: > [...] > The Stable Branch Policy, lets not put it in any repo. Doing that would give > indication that we expect changes into it and I'd prefer that policy mostly > staying stable as well. It actually already is in a repo: http://git.openstack.org/cgit/openstack/project-te

[openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

Hi, At Tokyo, we discussed quickly what to do with cliutils.py of oslo-incubator, but for me the plan is not really concrete. https://etherpad.openstack.org/p/mitaka-oslo-incubator-cleanup I don't like dims' suggestion to move code inside clients, it means duplicating 280 lines of python in

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

How about below format? #openstack baremetal Example: #openstack baremetal provision provide #openstack baremetal power on/off I think it is easy to understand and remember:) On Tue, Nov 10, 2015 at 6:17 PM, Pavlo Shchelokovskyy < [email protected]> wrote: > Hi, > I like th

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

On Tue, Nov 10 2015, Victor Stinner wrote: > It was also proposed to reuse openstackclient or the openstack SDK. I don't > understand how novaclient can use openstackclient, since openstackclient > depends on python-novaclient... The OpenStack SDK project is also a large > library no? (I don't kno

[openstack-dev] Regarding Designate Issues

Hi All, I am trying to install Designate using Devstack-Kilo but facing the following issues while starting its services- WARNING keystone.common.wsgi [-] Could not find service: dns WARNING keystone.common.wsgi [-] Could not find project: service DEBUG keystone.middleware.core [-] Auth token no

[openstack-dev] [Ironic][Nova][Neutron] Multi-tenancy support

Hello community, I would like to start preliminary testing of Ironic multi-tenant network setup which is supported by Neutron in Liberty according to [1]. I found the following patches that are on review. Also neutron ML2 plugin is needed. I can't find any plugin that supports multi-tenancy and Ci

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

On 11/09/2015 07:44 AM, Dmitry Tantsur wrote: > Hi OOO'ers, hopefully the subject caught your attentions :) > > Currently, tripleoclient exposes several commands in "openstack > baremetal" and "openstack baremetal introspection" namespaces belonging > to ironic and ironic-inspector accordingly.

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

Openstack baremetal provision provide or -provide Just doesn't feel right to me, it feels like I am typing more that I need to and it feels like I'm telling it to do the same action twice. I would much rather see: Openstack baremetal provide UUID Openstack baremetal activate UUID Openstack bare

Re: [openstack-dev] [Neutron] Reminder: Team meeting on Monday at 2100 UTC

Take all the time you need, Neutron can wait, family is more important. Take care. -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?sub

Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team

>> The Stable Branch Policy, lets not put it in any repo. >> Doing that would give indication that we expect changes into it and I'd >> prefer that policy mostly staying stable as well. What indication did it give when it was in wiki? :) > It actually already is in a repo: > http://git.openstack

Re: [openstack-dev] [Ironic][Nova][Neutron] Multi-tenancy support

On Tue, Nov 10, 2015 at 06:05:50AM EST, Vasyl Saienko wrote: > Hello community, > > I would like to start preliminary testing of Ironic multi-tenant network > setup which is supported by Neutron in Liberty according to [1]. I found > the following patches that are on review. Also neutron ML2 plugi

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

Hi Sam, Yes, I understand your format is： #openstack baremetal so these can cover all 'node' operations however if we want to cover support port/chassis/driver and more ironic resources, so how about below proposal? #openstack baremetal The resource/target can be one item in following lis

Re: [openstack-dev] [oslo] Graduate apiclient library

Hi, Le 10/11/2015 07:29, Kekane, Abhishek a écrit : We have done extensive analysis to figure out the differences of usages of different oslo-incubator/openstack/common/apiclient modules used in the respective Openstack python client libraries and added all our observations in the google spreads

Re: [openstack-dev] [Nova] live migration sub-team meeting

Thank you for the prompting Michael. I was chasing up a couple of key people to make sure they were available. The IRC meeting should be Tuesdays at 1400 UTC on #openstack-meeting-3 starting next week (too late for today). I will get that sorted out with infra and send another email to confirm.

Re: [openstack-dev] [fuel] Using upstream packages & modules

Alex That's great to hear that. But be aware - making all of the components work exactly the way they work within MOS is actually identical to upstreaming MOS. We are using some components of different versions to satisfy many requirements for our Reference Architecutre implementation. It will not

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

On 11/10/2015 12:26 PM, John Trowbridge wrote: On 11/09/2015 07:44 AM, Dmitry Tantsur wrote: Hi OOO'ers, hopefully the subject caught your attentions :) Currently, tripleoclient exposes several commands in "openstack baremetal" and "openstack baremetal introspection" namespaces belonging to i

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

So you would end up with a set of commands that look like this: Openstack baremetal [node/driver/chassis] list Openstack baremetal port list [-node uuid] <- replicate node-port-list Openstack baremetal [node/port/driver] show UUID Openstack baremetal chassis show [-nodes] UUID <- replicate chass

Re: [openstack-dev] [heat] Questions about BP for enable/disable heat-engine

Ethan, I can see, that it was assigned on Kanagaraj, but he is now in vacation (afaik). Also corresponding patch with specification was abandoned by his request, so I suggest wait answer here or may be ping him in IRC directly on the next week. On 8 November 2015 at 17:26, Ethan Lynn wrote: > Hi

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

Julien, Victor, How about - oslo.cli = apiclient/*.py + cliutils.py - since we already have a spec for a new library for apiclient -- Dims On Tue, Nov 10, 2015 at 5:58 AM, Julien Danjou wrote: > On Tue, Nov 10 2015, Victor Stinner wrote: > >> It was also proposed to reuse openstackclient or the

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

On Tue, Nov 10 2015, Davanum Srinivas wrote: > Julien, Victor, > > How about - oslo.cli = apiclient/*.py + cliutils.py - since we already > have a spec for a new library for apiclient I may be lacking context here, but we built a new complete client recently (python-gnocchiclient) without apiclie

Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit

On 11/10/2015 01:39 AM, David Pursehouse wrote: > On Mon, Nov 9, 2015 at 2:03 PM James E. Blair > wrote: > > Khai Do and I attended the Gerrit User Summit this weekend. It was a > very busy weekend indeed with quite a lot of activity in all areas > related

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

Julien, That's exactly what i want as well. We should just let whoever has copies to do whatever they want with them and drop our oversight of it. Since they are mature and haven't been touched for a while, i really don't see the need to take care of them. -- dims On Tue, Nov 10, 2015 at 7:41 AM

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

On 11/10/2015 07:41 AM, Julien Danjou wrote: > On Tue, Nov 10 2015, Davanum Srinivas wrote: > >> Julien, Victor, >> >> How about - oslo.cli = apiclient/*.py + cliutils.py - since we already >> have a spec for a new library for apiclient > > I may be lacking context here, but we built a new comple

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

On Tue, Nov 10 2015, Davanum Srinivas wrote: > Julien, > > That's exactly what i want as well. We should just let whoever has > copies to do whatever they want with them and drop our oversight of > it. Since they are mature and haven't been touched for a while, i > really don't see the need to tak

Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit

David Pursehouse wrote on 11/10/2015 07:39:32 AM: > From: David Pursehouse > To: OpenStack Development Mailing List > Cc: [email protected] > Date: 11/10/2015 07:40 AM > Subject: Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit > [...] > We're looking in

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

>It was also proposed to reuse openstackclient or the openstack SDK. Openstack SDK was proposed a long time ago(it looks like it was several cycles ago) as "alternative" for cliutils and apiclient, but I don't know any client which use it yet. Maybe openstacksdk cores should try to port any client

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On Mon, Nov 09, 2015 at 07:58:34AM EST, Jay Pipes wrote: > In short, my preference, in order, would be: > > 1) Enhance/evolve the existing security-groups and security-group-rules API > in Neutron to support more generic classification of traffic from L2 to L7, > using mostly the modeling that Sea

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

These changes are fine to me. I'm not so sure about the idea that we can't "hijack" other projects namespaces. If only ironic is allowed to use the prefix "baremetal", then the prefix should not have been "baremetal" in the first place, it should have been "ironic". Which of course means it would

Re: [openstack-dev] [murano] [glare] Visibility consistency for packages and images

Thanks for summing this up. We’ve already merged the client patch so I believe we should merge the dashboard one as well, to keep things consistent among GUI and CLI. Anyway your concerns are as relevant for dashboard as they are for client. Keeping dependency graph visibility consistent (i.e.

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

yes +1000 to keystoneauth1 + cliff (we can easily make OSC plugins/extensions this way). Existing clients using cliutils.py can continue to use their local sync'ed copies. I really didn't want to see library for apiclient/* since all the files in there are marked as deprecated!! https://github.c

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

Le 10/11/2015 14:01, Davanum Srinivas a écrit : That's exactly what i want as well. We should just let whoever has copies to do whatever they want with them and drop our oversight of it. Since they are mature and haven't been touched for a while, i really don't see the need to take care of them.

[openstack-dev] [ec2api] stable/liberty release?

Hi, are there plans to release a stable/liberty tarball of the ec2api ? There is a stable/kilo branch but I can't find one for liberty. Cheers, Tom __ OpenStack Development Mailing List (not for usage questions) Unsubscri

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

On 11/10/2015 02:42 PM, Lennart Regebro wrote: These changes are fine to me. I'm not so sure about the idea that we can't "hijack" other projects namespaces. If only ironic is allowed to use the prefix "baremetal", then the prefix should not have been "baremetal" in the first place, it should ha

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

- Original Message - > From: "Lennart Regebro" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Tuesday, 10 November, 2015 1:42:52 PM > Subject: Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other > projects' OSC namespaces > > These changes

[openstack-dev] [nova] Welcome to contribute on improvement the nova API documentation

Hi, At Tokyo summit, we decided the API documentation is hight priority and focus on Mitaka release. We really need better API documentation to help user to use our API easily. Those API doc works are also good for new contributors, it is good chance to get familiar with nova. So if you are inter

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

2015/11/10 21:19、Sam Betts (sambetts) のメッセージ: > So you would end up with a set of commands that look like this: > > Openstack baremetal [node/driver/chassis] list > Openstack baremetal port list [―node uuid] <― replicate node-port-list > > Openstack baremetal [node/port/driver] show UUID > O

Re: [openstack-dev] Learning to Debug the Gate

Here's another one to watch (embedded video by Sean Dague & blog post by Elizabeth K. Joseph): https://www.elastic.co/blog/openstack-elastic-recheck-powered-elk-stack --diana On Tue, Oct 27, 2015 at 11:14 AM, Matt Riedemann wrote: > > On 10/27/2015 4:08 AM, Anita Kuno wrote: >> https://www.

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

On 11/10/2015 08:24 AM, Andrey Kurilin wrote: >>It was also proposed to reuse openstackclient or the openstack SDK. > > Openstack SDK was proposed a long time ago(it looks like it was several > cycles ago) as "alternative" for cliutils and apiclient, but I don't > know any client which use it yet.

[openstack-dev] [oslo] XxxOpt classes "kept for backward-compatibility" in oslo.config

Hi, In oslo_config/cfg.py, there is a main Opt class which takes an optional type parameter (default is oslo_config.types.String). But there is also a long list of XxxOpt classes: StrOpt, BoolOpt, FloatOpt, ListOpt, IPOpt, etc. Recently I saw *new* classes added with the "kept for backward-co

Re: [openstack-dev] [oslo] XxxOpt classes "kept for backward-compatibility" in oslo.config

+1 Victor. On Tue, Nov 10, 2015 at 9:30 AM, Victor Stinner wrote: > Hi, > > In oslo_config/cfg.py, there is a main Opt class which takes an optional > type parameter (default is oslo_config.types.String). But there is also a > long list of XxxOpt classes: StrOpt, BoolOpt, FloatOpt, ListOpt, IPOpt

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

So I don't know the intricacies of the baremetal APIs, but hopefully I can shed some light on best practices. Do try to reuse the existing actions ( http://docs.openstack.org/developer/python-openstackclient/commands.html#actions ) Do use "create", "delete", "set", "show" and "list" for basic CRU

Re: [openstack-dev] [oslo] XxxOpt classes "kept for backward-compatibility" in oslo.config

Excerpts from Victor Stinner's message of 2015-11-10 15:30:18 +0100: > Hi, > > In oslo_config/cfg.py, there is a main Opt class which takes an optional > type parameter (default is oslo_config.types.String). But there is also > a long list of XxxOpt classes: StrOpt, BoolOpt, FloatOpt, ListOpt,

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

On 11/10/2015 05:12 AM, Thierry Carrez wrote: > Kevin Carter wrote: >>> I believe Clint already linked to >>> https://aphyr.com/posts/309-knossos-redis-and-linearizability or >>> similar - but 'known for general ease of use and reliability' is uhm, >>> a bold claim. Its worth comparing that (and th

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

Excerpts from Davanum Srinivas (dims)'s message of 2015-11-10 08:01:50 -0500: > Julien, > > That's exactly what i want as well. We should just let whoever has > copies to do whatever they want with them and drop our oversight of > it. Since they are mature and haven't been touched for a while, i >

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

Excerpts from Julien Danjou's message of 2015-11-10 14:18:43 +0100: > On Tue, Nov 10 2015, Davanum Srinivas wrote: > > > Julien, > > > > That's exactly what i want as well. We should just let whoever has > > copies to do whatever they want with them and drop our oversight of > > it. Since they are

Re: [openstack-dev] [oslo] XxxOpt classes "kept for backward-compatibility" in oslo.config

Le 10/11/2015 15:33, Davanum Srinivas a écrit : +1 Victor. Ok thanks for the confirmation. The comment disturbed me a lot :-D Here is a simple change to remove the comment: https://review.openstack.org/243630 Victor __ O

Re: [openstack-dev] [OpenStack-Infra] Configure gerrit to have two reviewers giving +2

On 2015-11-10 07:02:49 + (+), GROSZ, Maty (Maty) wrote: > How do I configure gerrit to have two reviewers giving +2 for a change? By telling everyone who has approval control on your project to only approve changes with more than one +2 vote (or phrased differently: we don't have configura

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

On Tue, Nov 10, 2015 at 8:42 AM, Lennart Regebro wrote: > These changes are fine to me. > > I'm not so sure about the idea that we can't "hijack" other projects > namespaces. If only ironic is allowed to use the prefix "baremetal", > then the prefix should not have been "baremetal" in the first pl

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

On Mon, Nov 9, 2015 at 7:44 AM, Dmitry Tantsur wrote: > Hi OOO'ers, hopefully the subject caught your attentions :) > > Currently, tripleoclient exposes several commands in "openstack baremetal" > and "openstack baremetal introspection" namespaces belonging to ironic and > ironic-inspector accordi

[openstack-dev] [Group-based-policy]

Dear sirs, I'm a student trying to testing Group Based Policy functionalities. I have some questions about it, because from the documentation is not clear to me what role assume opendaylight in the plug-in. I can use gbp only with openstack or is mandatory to use it with opendaylight? And next, if

[openstack-dev] [tripleo] Location of TripleO REST API

Hi all, At the last IRC meeting it was agreed that the new TripleO REST API should forgo the Tuskar name, and simply be called... the TripleO API. There's one more point of discussion: where should the API live? There are two possibilities: a) Put it in tripleo-common, where the business logic

Re: [openstack-dev] [TripleO] Proposing Ian Wienand as core reviewer on diskimage-builder

On Tue, 2015-11-03 at 15:25 +, Gregory Haynes wrote: > Hello everyone, > > I would like to propose adding Ian Wienand as a core reviewer on the > diskimage-builder project. Ian has been making a significant number > of > contributions for some time to the project, and has been a great help > i

[openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Hi, while we continue discussion about the future of stable branches in general and stable/juno in particular, I'd like to execute the current plan which was[1] 2014.2.4 (eol) early November, 2015. release manager: apevec Iff there's enough folks interested (I'm not) in keep Juno alive longer, t

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

Renat Akhmerov @ Mirantis Inc. > On 06 Nov 2015, at 00:09, Clint Byrum wrote: > > Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800: >> Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500: >>> Can people help me work through the right set of tools for this use cas

Re: [openstack-dev] [tripleo] Location of TripleO REST API

On 11/10/2015 04:08 PM, Tzu-Mainn Chen wrote: Hi all, At the last IRC meeting it was agreed that the new TripleO REST API should forgo the Tuskar name, and simply be called... the TripleO API. There's one more point of discussion: where should the API live? There are two possibilities: a) Put

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

On Tue, Nov 10, 2015 at 6:19 AM, Sam Betts (sambetts) wrote: > So you would end up with a set of commands that look like this: > > Openstack baremetal [node/driver/chassis] list > Openstack baremetal port list [—node uuid] <— replicate node-port-list > > Openstack baremetal [node/port/driver] sho

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

On Tue, Nov 10, 2015 at 9:32 AM, Steve Martinelli wrote: > > So I don't know the intricacies of the baremetal APIs, but hopefully I can > shed some light on best practices. > > Do try to reuse the existing actions > (http://docs.openstack.org/developer/python-openstackclient/commands.html#action

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

> On 09 Nov 2015, at 20:43, Adam Young wrote: > > On 11/06/2015 06:28 PM, Tim Hinrichs wrote: >> Congress allows users to write a policy that executes an action under >> certain conditions. >> >> The conditions can be based on any data Congress has access to, which >> includes nova servers,

Re: [openstack-dev] [fuel] Using upstream packages & modules

Hey Vladimir, On Tue, Nov 10, 2015 at 5:56 AM, Vladimir Kuklin wrote: > Alex > > That's great to hear that. But be aware - making all of the components work > exactly the way they work within MOS is actually identical to upstreaming > MOS. We are using some components of different versions to sat

Re: [openstack-dev] How to change the email address for openstack Id ?

On 2015-11-10 16:23:29 +0800 (+0800), lichen.hangzhou wrote: > Anyone know how to change the email address for openstack id ? > > I have already changed the "Preferred Email" at > https://review.openstack.org/#/settings/contact, and it should > worked, the new email already showed on > https://rev

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

> On 09 Nov 2015, at 21:57, Tim Hinrichs wrote: > > Congress happens to have the capability to run a script/API call under > arbitrary conditions on the state of other OpenStack projects, which sounded > like what you wanted. Or did I misread your original question? > > Congress and Mistral

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

> On 10 Nov 2015, at 21:29, Renat Akhmerov wrote: > > >> On 09 Nov 2015, at 21:57, Tim Hinrichs wrote: >> >> Congress happens to have the capability to run a script/API call under >> arbitrary conditions on the state of other OpenStack projects, which sounded >> like what you wanted. Or di

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

> On 06 Nov 2015, at 03:41, Doug Hellmann wrote: > > Excerpts from Adam Young's message of 2015-11-05 15:14:03 -0500: >> On 11/05/2015 01:09 PM, Clint Byrum wrote: >>> Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800: Excerpts from Adam Young's message of 2015-11-05 12:34:

Re: [openstack-dev] [Zaqar] OpenStack Tokyo Summit Summary

On 11/06/2015 01:36 PM, Doug Hellmann wrote: Excerpts from Fei Long Wang's message of 2015-11-07 01:31:09 +1300: Greetings, Firstly, thank you for everyone joined Zaqar sessions at Tokyo summit. We definitely made some great progress for those working sessions. Here are the high level summary a

Re: [openstack-dev] [Ironic] Quick poll: OpenStackClient command for provision action

On Tue, Nov 10, 2015 at 4:09 AM, Dmitry Tantsur wrote: > Hi all! > > I'd like to seek consensus (or at least some opinions) on patch > https://review.openstack.org/#/c/206119/ > It proposed the following command: > > openstack baremetal provision state --provide UUID > > (where --provide can als

[openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

Hi all, I want to announce that there is an informal group of folks who plan to work on upgrade story for Neutron during Mitaka: getting grenade partial aka sideways up; extending grenade resource migration checks; adopting oslo.versionedobjects for more resources; providing guidance to oth

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

On Tue, Nov 10, 2015 at 7:42 AM, Lennart Regebro wrote: > I'm not so sure about the idea that we can't "hijack" other projects > namespaces. If only ironic is allowed to use the prefix "baremetal", > then the prefix should not have been "baremetal" in the first place, > it should have been "ironi

Re: [openstack-dev] [tripleo] Location of TripleO REST API

On 11/10/2015 04:16 PM, Dmitry Tantsur wrote: On 11/10/2015 04:08 PM, Tzu-Mainn Chen wrote: Hi all, At the last IRC meeting it was agreed that the new TripleO REST API should forgo the Tuskar name, and simply be called... the TripleO API. There's one more point of discussion: where should the

Re: [openstack-dev] [oslo] Graduate cliutils.py into oslo.utils

+1000 Doug. On Tue, Nov 10, 2015 at 9:49 AM, Doug Hellmann wrote: > Excerpts from Julien Danjou's message of 2015-11-10 14:18:43 +0100: >> On Tue, Nov 10 2015, Davanum Srinivas wrote: >> >> > Julien, >> > >> > That's exactly what i want as well. We should just let whoever has >> > copies to do wh

[openstack-dev] [Infra] grafana.openstack.org now online

Greetings, If you are not aware, we now have a Grafana service running[1] under OpenStack Infra. What is Grafana? "The leading graph and dashboard builder for visualizing time series metrics"[2]. The cool thing about our Grafana service, like Jenkins, all of our dashboards are managed via our Ger

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

On Tue, Nov 10, 2015 at 9:03 AM, Brad P. Crochet wrote: > Actually, the 'baremetal' namespace is exactly what it should be, > based on other OSC clients. For instance, Neutron uses 'network', Nova > uses 'server', etc. The idea is that the client should use the service > type, not the codename of

Re: [openstack-dev] Learning to Debug the Gate

On 11/9/2015 3:54 PM, Anita Kuno wrote: On 11/05/2015 07:45 PM, Anita Kuno wrote: On 11/03/2015 05:30 PM, Anita Kuno wrote: On 11/02/2015 12:39 PM, Anita Kuno wrote: On 10/29/2015 10:42 PM, Anita Kuno wrote: On 10/29/2015 08:27 AM, Anita Kuno wrote: On 10/28/2015 12:14 AM, Matt Riedemann w

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

On 11/10/2015 03:32 PM, Steve Martinelli wrote: So I don't know the intricacies of the baremetal APIs, but hopefully I can shed some light on best practices. Do try to reuse the existing actions (http://docs.openstack.org/developer/python-openstackclient/commands.html#actions) Do use "create", "

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

On 11/10/2015 05:26 AM, John Trowbridge wrote: > > > On 11/09/2015 07:44 AM, Dmitry Tantsur wrote: >> Hi OOO'ers, hopefully the subject caught your attentions :) >> >> Currently, tripleoclient exposes several commands in "openstack >> baremetal" and "openstack baremetal introspection" namespaces

Re: [openstack-dev] [tripleo] Location of TripleO REST API

On 11/10/2015 04:37 PM, Giulio Fidente wrote: On 11/10/2015 04:16 PM, Dmitry Tantsur wrote: On 11/10/2015 04:08 PM, Tzu-Mainn Chen wrote: Hi all, At the last IRC meeting it was agreed that the new TripleO REST API should forgo the Tuskar name, and simply be called... the TripleO API. There's

Re: [openstack-dev] [tripleo] Location of TripleO REST API

On 11/10/2015 10:37 AM, Giulio Fidente wrote: > On 11/10/2015 04:16 PM, Dmitry Tantsur wrote: >> On 11/10/2015 04:08 PM, Tzu-Mainn Chen wrote: >>> Hi all, >>> >>> At the last IRC meeting it was agreed that the new TripleO REST API >>> should forgo the Tuskar name, and simply be called... the Trip

[openstack-dev] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

Folks I wanted to raise awareness about one of the things I captured while doing reviews recently - we are sacrificing quality to bugfixing and feature development velocity, essentially moving from one heap to another - from bugs/features to 'tech-debt' bugs. I understand that we all have deadlin

  1   2   3   >