Re: [openstack-dev] [keystone][nova] Struggling with non-admin user on Queens install

It appears this is to do with Keystone v3-created users not having any role assignment by default. Big thanks to lbragstad for helping me to understand this on IRC; he also provided this link as historical context for this situation: https://bugs.launchpad.net/keystone/+bug/1662911. In detail, I

[openstack-dev] [keystone][nova] Struggling with non-admin user on Queens install

I'd like to create a non-admin project and user that are able to do nova.images.list(), in a Queens install. IIUC, all users should be able to do that. I'm afraid I'm pretty lost and would appreciate any help. Define a function to test whether a particular set of credentials can do nova.images.l

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On 02/02/2018 11:56 AM, Lance Bragstad wrote: > I apologize for using the "baremetal/VM" name, but I wanted to get an > etherpad rolling sooner rather than later [0], since we're likely going > to have to decide on a new name in person. I ported the initial ideas > Colleen mentioned when she star

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

I apologize for using the "baremetal/VM" name, but I wanted to get an etherpad rolling sooner rather than later [0], since we're likely going to have to decide on a new name in person. I ported the initial ideas Colleen mentioned when she started this thread, added links to previous etherpads from

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On 30/01/18 10:33, Colleen Murphy wrote: At the last PTG we had some time on Monday and Tuesday for cross-project discussions related to baremetal and VM management. We don't currently have that on the schedule for this PTG. There is still some free time available that we can ask for[1]. Should w

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

> > Fair point. When the "VM/baremetal workgroup" was originally formed, > the goal was more about building clouds with both types of resources, > making them behave similarly from a user perspective, etc. Somehow > we got into talking applications and these other topics came up, which > seemed mor

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On Wed, Jan 31, 2018 at 12:22 PM, Dmitry Tantsur wrote: > On 01/31/2018 06:15 PM, Matt Riedemann wrote: > >> On 1/30/2018 9:33 AM, Colleen Murphy wrote: >> >>> At the last PTG we had some time on Monday and Tuesday for >>> cross-project discussions related to baremetal and VM management. We >>> d

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On Wed, Jan 31, 2018 at 6:46 PM, Graham Hayes wrote: > On 31/01/18 17:22, Dmitry Tantsur wrote: >> On 01/31/2018 06:15 PM, Matt Riedemann wrote: >>> On 1/30/2018 9:33 AM, Colleen Murphy wrote: [snip] >>> >>> These all seem like good topics for big cross-project issues. >>> >>> I've never liked the

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On 31/01/18 17:22, Dmitry Tantsur wrote: > On 01/31/2018 06:15 PM, Matt Riedemann wrote: >> On 1/30/2018 9:33 AM, Colleen Murphy wrote: >>> At the last PTG we had some time on Monday and Tuesday for >>> cross-project discussions related to baremetal and VM management. We >>> don't currently have th

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On 01/31/2018 06:15 PM, Matt Riedemann wrote: On 1/30/2018 9:33 AM, Colleen Murphy wrote: At the last PTG we had some time on Monday and Tuesday for cross-project discussions related to baremetal and VM management. We don't currently have that on the schedule for this PTG. There is still some fr

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On 1/30/2018 9:33 AM, Colleen Murphy wrote: At the last PTG we had some time on Monday and Tuesday for cross-project discussions related to baremetal and VM management. We don't currently have that on the schedule for this PTG. There is still some free time available that we can ask for[1]. Shoul

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On 01/30/2018 09:33 AM, Colleen Murphy wrote: > At the last PTG we had some time on Monday and Tuesday for > cross-project discussions related to baremetal and VM management. We > don't currently have that on the schedule for this PTG. There is still > some free time available that we can ask for

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

+1 to Jim, I'm specifically interested in app creds and RBAC as I'd like to find a way to pass some of API access creds to the ironic deploy ramdisk, and it seems one of those could help. Let's discuss :) Cheers, On Tue, Jan 30, 2018 at 6:03 PM, Jim Rollenhagen wrote: > On Tue, Jan 30, 2018 at

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On Tue, Jan 30, 2018 at 10:33 AM, Colleen Murphy wrote: > At the last PTG we had some time on Monday and Tuesday for > cross-project discussions related to baremetal and VM management. We > don't currently have that on the schedule for this PTG. There is still > some free time available that we c

[openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

At the last PTG we had some time on Monday and Tuesday for cross-project discussions related to baremetal and VM management. We don't currently have that on the schedule for this PTG. There is still some free time available that we can ask for[1]. Should we try to schedule some time for this? From

Re: [openstack-dev] [keystone][nova] Persistent application credentials

ave to go prevision a bunch of stuff themselves before passing stuff to > the form, game over. Likewise, if they have to look at yaml, game over. How > do app credentials fit into this? > > Thanks, > Kevin > > ____ > From: Zane Bitter [zbi

Re: [openstack-dev] [keystone][nova] Persistent application credentials

s before passing stuff to the form, game over. Likewise, if they have to look at yaml, game over. How do app credentials fit into this? Thanks, Kevin From: Zane Bitter [zbit...@redhat.com] Sent: Monday, October 09, 2017 9:39 AM To: openstack-dev@lists.o

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On Mon, Oct 9, 2017 at 6:39 PM, Zane Bitter wrote: > On 12/09/17 18:58, Colleen Murphy wrote: > >> While it's fresh in our minds, I wanted to write up a short recap of >> where we landed in the Application Credentials discussion in the BM/VM room >> today. For convenience the (as of yet unrevised

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 12/09/17 18:58, Colleen Murphy wrote: While it's fresh in our minds, I wanted to write up a short recap of where we landed in the Application Credentials discussion in the BM/VM room today. For convenience the (as of yet unrevised) spec is here: Thanks so much for staying on this Colleen, i

Re: [openstack-dev] [keystone] [nova] [neutron] [cinder] [ironic] [glance] [swift] Baremetal/VM SIG PTG Schedule/Etherpad

Looks like the Baremetal/VM SIG (#compute) will meet in Ballroom B, Banquet Level. I've updated the etherpad with the room information [0]. [0] https://etherpad.openstack.org/p/queens-PTG-vmbm On 09/07/2017 10:01 AM, Lance Bragstad wrote: > I spoke with John a bit today in IRC and we have a roug

Re: [openstack-dev] [keystone] [nova] [neutron] [cinder] [ironic] [glance] [swift] Baremetal/VM SIG PTG Schedule/Etherpad

I spoke with John a bit today in IRC and we have a rough schedule worked out for the Baremetal/VM SIG. All the sessions/ideas/carry-over topics from Boston have been filtered into a schedule and is available in the etherpad [0]. Each entry should have a "lead" to drive the discussion and a "goal"

[openstack-dev] [keystone] [nova] [neutron] [cinder] [ironic] [glance] [swift] Baremetal/VM SIG PTG Schedule/Etherpad

Hi all, Keystone has a few cross-project topics we'd like to share with a wider group, like the Baremetal/VM SIG. As a result, I attempted to dust off some of the Baremetal/VM sessions [0][1] from Boston and port the popular topics over to the etherpad for the PTG [2]. Maybe it will kick start som

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On Thu, Jul 20, 2017 at 8:02 PM, Zane Bitter wrote: > > * If Keystone supported either a public-key or a Kerberos-style > authentication mechanism to get a token Keystone (via support for accepting authentication from the web server hosting it) can be configured to accept X.509 and kerberos, se

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 19/07/17 23:19, Monty Taylor wrote: Instance users do not solve this. Instance users can be built with this- but instance users are themselves not sufficient. Instance users are only sufficient in single-cloud ecosystems where it is possible to grant permissions on all the resources in the

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 19/07/17 22:27, Monty Taylor wrote: I propose we set aside time at the PTG to dig in to this. Between Zane and I and the Keystone core team I have confidence we can find a way out. This may be a bad time to mention that regrettably I won't be attending the PTG, due to (happy!) family reason

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 07/19/2017 09:27 PM, Monty Taylor wrote: > On 07/19/2017 12:18 AM, Zane Bitter wrote: >> On 18/07/17 10:55, Lance Bragstad wrote: Would Keystone folks be happy to allow persistent credentials once we have a way to hand out only the minimum required privileges?

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 07/19/2017 10:00 PM, Adrian Turjak wrote: > The problem is then entirely procedural within a team. Do they rotate > all keys when one person leaves? Anything less is the same problem. All > we can do is make rotation less of a pain, but it will still be painful > no matter what, and depending on

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 07/19/2017 12:11 AM, Zane Bitter wrote: On 17/07/17 23:12, Lance Bragstad wrote: Would Keystone folks be happy to allow persistent credentials once we have a way to hand out only the minimum required privileges? If I'm understanding correctly, this would make application credential

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 07/19/2017 12:18 AM, Zane Bitter wrote: On 18/07/17 10:55, Lance Bragstad wrote: Would Keystone folks be happy to allow persistent credentials once we have a way to hand out only the minimum required privileges? If I'm understanding correctly, this would make application credentia

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 19/07/17 01:23, Colleen Murphy wrote: > On Tue, Jul 18, 2017 at 1:39 AM, Zane Bitter > wrote: > > So the application credentials spec has merged - huge thanks to > Monty and the Keystone team for getting this done: > > https://review.openstack.org/#/c/45

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 18/07/17 10:55, Lance Bragstad wrote: Would Keystone folks be happy to allow persistent credentials once we have a way to hand out only the minimum required privileges? If I'm understanding correctly, this would make application credentials dependent on several cycles of policy wor

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 17/07/17 23:12, Lance Bragstad wrote: Would Keystone folks be happy to allow persistent credentials once we have a way to hand out only the minimum required privileges? If I'm understanding correctly, this would make application credentials dependent on several cycles of policy work

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 07/17/2017 10:12 PM, Lance Bragstad wrote: > > > On Mon, Jul 17, 2017 at 6:39 PM, Zane Bitter > wrote: > > So the application credentials spec has merged - huge thanks to > Monty and the Keystone team for getting this done: > > https://review.openstack.o

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On Tue, Jul 18, 2017 at 1:39 AM, Zane Bitter wrote: > So the application credentials spec has merged - huge thanks to Monty and > the Keystone team for getting this done: > > https://review.openstack.org/#/c/450415/ > http://specs.openstack.org/openstack/keystone-specs/specs/ > keystone/pike/appl

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On Mon, Jul 17, 2017 at 6:39 PM, Zane Bitter wrote: > So the application credentials spec has merged - huge thanks to Monty and > the Keystone team for getting this done: > > https://review.openstack.org/#/c/450415/ > http://specs.openstack.org/openstack/keystone-specs/specs/ > keystone/pike/appl

[openstack-dev] [keystone][nova] Persistent application credentials

So the application credentials spec has merged - huge thanks to Monty and the Keystone team for getting this done: https://review.openstack.org/#/c/450415/ http://specs.openstack.org/openstack/keystone-specs/specs/keystone/pike/application-credentials.html However, it appears that there was a d

Re: [openstack-dev] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

-dev] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness I'd like to fill in a little more context here. I see three options with the current two proposals. Option 1 Use a special admin project to denote elevated privileges. For those unfamiliar with the approac

Re: [openstack-dev] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On 25/05/17 07:47, Lance Bragstad wrote: > *Option 2* > > Implement global role assignments in keystone. > / > / > /How it works:/ > / > / > Role assignments in keystone can be scoped to global context. Users > can then ask for a globally scoped token > > Pros: > - This approach represents a mo

Re: [openstack-dev] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

I'd like to fill in a little more context here. I see three options with the current two proposals. *Option 1* Use a special admin project to denote elevated privileges. For those unfamiliar with the approach, it would rely on every deployment having an "admin" project defined in configuration [0

[openstack-dev] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

Hey all, To date we have two proposed solutions for tackling the admin-ness issue we have across the services. One builds on the existing scope concepts by scoping to an admin project [0]. The other introduces global role assignments [1] as a way to denote elevated privileges. I'd like to get som

[openstack-dev] [keystone][nova][cinder][policy] policy meeting tomorrow

Hey folks, Sending out a reminder that we will have the policy meeting tomorrow [0]. The agenda [1] is already pretty full but we are going to need cross-project involvement tomorrow considering the topics and impacts. I'll be reviewing policy things in the morning so if anyone has questions or w

[openstack-dev] [keystone][nova][policy] policy goals and roadmap

Hi all, I spent some time today summarizing a discussion [0] about global roles. I figured it would help build some context for next week as there are a couple cross project policy/RBAC sessions at the Forum. The first patch is a very general document trying to nail down our policy goals [1]. The

[openstack-dev] [keystone][nova][neutron][cinder] Limiting RPC traffic with keystoneauth

Post PTG there has been some discussion regarding quotas as well as limits. While most of the discussion has been off and on in #openstack-dev, we also have a mailing list thread on the topic [0]. I don't want to derail the thread on quotas and limits with this thread, but today's discussion [1] h

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

On Mon, 27 Feb 2017, Sean Dague wrote: However, when there is magic applied it means that stops being true. And now folks think the APIs work like the magic works, not realizing it's all client side magic, and when they try to do this in node next month, it will all fall apart. +many It's goo

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

On 27 February 2017 at 08:56, Sean Dague wrote: > We recently implemented a Nova feature around validating that project_id > for quotas we real in keystone. After that merged, trippleo builds > started to fail because their undercloud did not specify the 'identity' > service as the unversioned en

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

On 02/27/2017 10:49 AM, Monty Taylor wrote: > On 02/27/2017 09:36 AM, Morgan Fainberg wrote: >> >> >> On Mon, Feb 27, 2017 at 7:26 AM, Sean Dague > > wrote: >> >> On 02/27/2017 10:22 AM, Morgan Fainberg wrote: >> >> > I agree we should kill the discovery hack, ho

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

On 02/27/2017 09:36 AM, Morgan Fainberg wrote: > > > On Mon, Feb 27, 2017 at 7:26 AM, Sean Dague > wrote: > > On 02/27/2017 10:22 AM, Morgan Fainberg wrote: > > > I agree we should kill the discovery hack, however that is a break in > > the keystoneauth c

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

On Mon, Feb 27, 2017 at 7:26 AM, Sean Dague wrote: > On 02/27/2017 10:22 AM, Morgan Fainberg wrote: > > > I agree we should kill the discovery hack, however that is a break in > > the keystoneauth contract. Simply put, we cannot. Keystoneauth is one of > > the few things (similar to how shade wo

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

On Mon, Feb 27, 2017 at 5:56 AM, Sean Dague wrote: > We recently implemented a Nova feature around validating that project_id > for quotas we real in keystone. After that merged, trippleo builds > started to fail because their undercloud did not specify the 'identity' > service as the unversioned

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

On 02/27/2017 10:22 AM, Morgan Fainberg wrote: > I agree we should kill the discovery hack, however that is a break in > the keystoneauth contract. Simply put, we cannot. Keystoneauth is one of > the few things (similar to how shade works) where behavior, exposed > elements, etc are considered a s

[openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

We recently implemented a Nova feature around validating that project_id for quotas we real in keystone. After that merged, trippleo builds started to fail because their undercloud did not specify the 'identity' service as the unversioned endpoint. https://github.com/openstack/nova/blob/8b498ce199

Re: [openstack-dev] [keystone] [nova] [glance] [oslo] webob 1.7

On Thu, Jan 19, 2017 at 9:50 PM, Corey Bryant wrote: > > > On Thu, Jan 19, 2017 at 8:29 PM, Joshua Harlow > wrote: > >> Corey Bryant wrote: >> >>> >>> Added [nova] and [oslo] to the subject. This is also affecting nova and >>> oslo.middleware. I know Sean's initial response on the thread was t

Re: [openstack-dev] [keystone] [nova] [glance] [oslo] webob 1.7

On Thu, Jan 19, 2017 at 8:29 PM, Joshua Harlow wrote: > Corey Bryant wrote: > >> >> Added [nova] and [oslo] to the subject. This is also affecting nova and >> oslo.middleware. I know Sean's initial response on the thread was that >> this shouldn't be a priority for ocata but we're completely bl

Re: [openstack-dev] [keystone] [nova] [glance] [oslo] webob 1.7

Corey Bryant wrote: Added [nova] and [oslo] to the subject. This is also affecting nova and oslo.middleware. I know Sean's initial response on the thread was that this shouldn't be a priority for ocata but we're completely blocked by it. Would those teams be able to prioritize a fix for this?

Re: [openstack-dev] [keystone] [nova] [glance] [oslo] webob 1.7

On Thu, Jan 19, 2017 at 11:34 AM, Corey Bryant wrote: > > > On Thu, Jan 19, 2017 at 10:46 AM, Ian Cordasco > wrote: > >> -Original Message- >> From: Corey Bryant >> Reply: OpenStack Development Mailing List (not for usage questions) >> >> Date: January 19, 2017 at 08:52:25 >> To: OpenS

Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone

: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone Hi, I think one of the issues we're trying to solve here is duplication reducing. Quotas in OpenStack commonly contain two parts: limits management and limits enforcement. If we're talking about library

Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone

>best regards, > sajeesh > > From: Jay Pipes [jaypi...@gmail.com] > Sent: 13 December 2016 18:55:14 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and > limits in t

Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone

On 12/13/2016 11:27 AM, Sajeesh Cimson Sasi wrote: Hi, There was an ongoing project of delimiter for Cross Project Quota Management. But I don't know the current status. Kindly have a look at it. https://review.openstack.org/#/c/284454/ More discussions are required on this.A

Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone

k.org Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone On 12/13/2016 08:09 AM, Kseniya Tychkova wrote: > Hi, > I would like to share a spec [1] with you. > The main idea of this spec is to start a discussion about quota > management in the Open

Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone

On 12/13/2016 08:09 AM, Kseniya Tychkova wrote: Hi, I would like to share a spec [1] with you. The main idea of this spec is to start a discussion about quota management in the OpenStack. Quotas are scattered across OpenStack services. Each service defines it's own model and API for managing res

[openstack-dev] [keystone][nova]Quotas: Store resources and limits in the Keystone

Hi, I would like to share a spec [1] with you. The main idea of this spec is to start a discussion about quota management in the OpenStack. Quotas are scattered across OpenStack services. Each service defines it's own model and API for managing resource's limits. Because of that, there are several

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On Tue, Nov 8, 2016 at 4:12 PM, Gage Hugo wrote: > The idea is that a cloud admin could define a list of keys that they need > for their setup within keystone's configuration file, then only those keys > will be valid for storing values in the project properties table. Then each > call would chec

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On 11/8/2016 7:14 PM, Adrian Turjak wrote: On 09/11/16 11:12, Gage Hugo wrote: This spec was discussed at the keystone meeting today and during the conversation that continued afterwards, an idea of using the keystone configuration to set a list of keys was mentioned. The idea is that a cloud

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On 09/11/16 11:12, Gage Hugo wrote: > This spec was discussed at the keystone meeting today and during the > conversation that continued afterwards, an idea of using the keystone > configuration to set a list of keys was mentioned. > > The idea is that a cloud admin could define a list of keys th

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On 11/8/2016 4:12 PM, Gage Hugo wrote: This spec was discussed at the keystone meeting today and during the conversation that continued afterwards, an idea of using the keystone configuration to set a list of keys was mentioned. The idea is that a cloud admin could define a list of keys that the

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On 04/11/16 08:15 PM, Steve Martinelli wrote: > > We have somewhat had support for this, we have an "extras" column > defined in our database schema, whatever a user puts in a request that > doesn't match up with our API, those key-values are dumped into the > "extras" column. It's not a pleasant

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

This spec was discussed at the keystone meeting today and during the conversation that continued afterwards, an idea of using the keystone configuration to set a list of keys was mentioned. The idea is that a cloud admin could define a list of keys that they need for their setup within keystone's

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On 11/4/2016 7:15 PM, Steve Martinelli wrote: The keystone team has a new spec being proposed for the Ocata release, it essentially boils down to adding properties / metadata for projects (for now) [1]. We have somewhat had support for this, we have an "extras" column defined in our database sch

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On 06/11/16 13:17, Steve Martinelli wrote: > > Interesting, I'll add this to the review and see how some if the folks > proposing the new APIs would find that as suitable for their use > cases. For reference: http://developer.openstack.org/api-ref/compute/ For our use case, I need key:value pairin

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On Sat, Nov 5, 2016 at 6:15 PM, Jay Pipes wrote: > On 11/05/2016 01:15 AM, Steve Martinelli wrote: > >> The keystone team has a new spec being proposed for the Ocata release, >> it essentially boils down to adding properties / metadata for projects >> (for now) [1]. >> > > Yes, I'd seen that part

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On 11/05/2016 01:15 AM, Steve Martinelli wrote: The keystone team has a new spec being proposed for the Ocata release, it essentially boils down to adding properties / metadata for projects (for now) [1]. Yes, I'd seen that particular spec review and found it interesting in a couple ways. W

[openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

The keystone team has a new spec being proposed for the Ocata release, it essentially boils down to adding properties / metadata for projects (for now) [1]. We have somewhat had support for this, we have an "extras" column defined in our database schema, whatever a user puts in a request that does

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

ed in the DB via a two-way trigger. Regards, Alex -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Friday, October 14, 2016 1:56 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database trigger

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 10/16/2016 11:52 AM, Duncan Thomas wrote: > On 14 October 2016 at 23:55, Jay Pipes > wrote: > > The primary thing that, to me at least, differentiates rolling > upgrades of distributed software is that different nodes can > contain multiple versions of the

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 14 October 2016 at 23:55, Jay Pipes wrote: > The primary thing that, to me at least, differentiates rolling upgrades of > distributed software is that different nodes can contain multiple versions > of the software and continue to communicate with other nodes in the system > without issue. > >

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Excerpts from Jay Pipes's message of 2016-10-14 16:55:39 -0400: > Alex, so sorry for the long delayed response! :( This just crept to > the back of my inbox unfortunately. Answer inline... > > On 09/14/2016 07:24 PM, Bashmakov, Alexander wrote: > >> Glance and Keystone do not participate in a roll

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Alex, so sorry for the long delayed response! :( This just crept to the back of my inbox unfortunately. Answer inline... On 09/14/2016 07:24 PM, Bashmakov, Alexander wrote: Glance and Keystone do not participate in a rolling upgrade, because Keystone and Glance do not have a distributed componen

Re: [openstack-dev] [keystone][nova] "admin" role and "rule:admin_or_owner" confusion

I am still confused how the "cloud admin" role is fulfilled in Liberty release. For example, I used "nova --debug delete" to see how the project:admin/user:admin deletes an instance of the demo project. Basically, we use the project:admin/user:admin token to get a list of instances for all tena

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Excerpts from Henry Nash's message of 2016-09-15 00:29:44 +0100: > Jay, > > I agree with your distinction - and when I am referring to rolling upgrades > for keystone I am referring to when you are running a cluster of keystones > (for performance and/or redundancy), and you want to roll the upg

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Jay, I agree with your distinction - and when I am referring to rolling upgrades for keystone I am referring to when you are running a cluster of keystones (for performance and/or redundancy), and you want to roll the upgrade across the cluster without creating downtime of the overall keystone

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

> Glance and Keystone do not participate in a rolling upgrade, because > Keystone and Glance do not have a distributed component architecture. > Online data migrations will reduce total downtime experienced during an > *overall upgrade procedure* for an OpenStack cloud, but Nova, Neutron and > Cind

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 09/01/2016 05:29 AM, Henry Nash wrote: So as the person who drove the rolling upgrade requirements into keystone in this cycle (because we have real customers that need it), and having first written the keystone upgrade process to be “versioned object ready” (because I assumed we would do this

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Excerpts from Mike Bayer's message of 2016-09-02 17:58:42 -0400: > > On 09/02/2016 01:53 PM, Doug Hellmann wrote: > > Excerpts from Thierry Carrez's message of 2016-09-02 12:15:33 +0200: > >> Sean Dague wrote: > >>> Putting DB trigger failure analysis into the toolkit required to manage > >>> an u

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

> > On 09/02/2016 01:53 PM, Doug Hellmann wrote: > >> Excerpts from Thierry Carrez's message of 2016-09-02 12:15:33 +0200: > > I agree with Sean: increasing the variety of technologies used increases >>> the system complexity, which in turn requires more skills to fully >>> understand and maintain

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 09/02/2016 01:53 PM, Doug Hellmann wrote: Excerpts from Thierry Carrez's message of 2016-09-02 12:15:33 +0200: Sean Dague wrote: Putting DB trigger failure analysis into the toolkit required to manage an upgrade failure is a really high bar for new ops. I agree with Sean: increasing the

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Excerpts from Thierry Carrez's message of 2016-09-02 12:15:33 +0200: > Sean Dague wrote: > > Putting DB trigger failure analysis into the toolkit required to manage > > an upgrade failure is a really high bar for new ops. > > I agree with Sean: increasing the variety of technologies used increases

Re: [openstack-dev] [keystone][nova] "admin" role and "rule:admin_or_owner" confusion

On Sep 2, 2016 09:39, "rezroo" wrote: > > Hello - I'm using Liberty release devstack for the below scenario. I have created project "abcd" with "john" as Member. I've launched one instance, I can use curl to list the instance. No problem. > > I then modify /etc/nova/policy.json and redefine "admin

[openstack-dev] [keystone][nova] "admin" role and "rule:admin_or_owner" confusion

Hello - I'm using Liberty release devstack for the below scenario. I have created project "abcd" with "john" as Member. I've launched one instance, I can use curl to list the instance. No problem. I then modify /etc/nova/policy.json and redefine "admin_or_owner" as follows: "admin_or_own

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Sean Dague wrote: > Putting DB trigger failure analysis into the toolkit required to manage > an upgrade failure is a really high bar for new ops. I agree with Sean: increasing the variety of technologies used increases the system complexity, which in turn requires more skills to fully understand

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On Thursday, September 1, 2016, Jeremy Stanley wrote: > > I don't read that at all as suggesting "the problem is solved, go > away" but rather "help us make it better for everyone, don't just > take one project off in a new direction and leave the others > behind." I can clarify. I don't work

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Excerpts from Robert Collins's message of 2016-09-01 20:45:22 +1200: > On 31 August 2016 at 01:57, Clint Byrum wrote: > > > > > > It's simple, these are the holy SQL schema commandments: > > > > Don't delete columns, ignore them. > > Don't change columns, create new ones. > > When you create a col

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 2016-09-01 10:39:09 -0400 (-0400), Mike Bayer wrote: > On 08/31/2016 06:18 PM, Monty Taylor wrote: [...] > >OpenStack is One Project > > > > > > Nova and Neutron have an approach for this. It may or may not be > > ideal - but it exists right now. While it can be satisfyin

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 09/01/2016 11:52 AM, Dan Smith wrote: The indirection service is really unrelated to this discussion, IMHO. If you take RPC out of the picture, all you have left is a direct-to-the-database facade to handle the fact that schema has expanded underneath you. As Clint (et al) have said -- desi

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

> So that is fine. However, correct me if I'm wrong but you're > proposing just that these projects migrate to also use a new service > layer with oslo.versionedobjects, because IIUC Nova/Neutron's > approach is dependent on that area of indirection being present. > Otherwise, if you meant som

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 09/01/2016 09:45 AM, David Stanek wrote: > On Thu, Aug 25 at 13:13 -0400, Steve Martinelli wrote: >> The keystone team is pursuing a trigger-based approach to support rolling, >> zero-downtime upgrades. The proposed operator experience is documented here: >> >> http://docs.openstack.org/develo

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 09/01/2016 08:29 AM, Henry Nash wrote: From a purely keystone perspective, my gut feeling is that actually the trigger approach is likely to lead to a more robust, not less, solution - due to the fact that we solve the very specific problems of a given migration (i.e. need to keep column A

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 08/31/2016 06:18 PM, Monty Taylor wrote: I said this the other day in the IRC channel, and I'm going to say it again here. I'm going to do it as bluntly as I can - please keeping in mind that I respect all of the humans involved. I think this is a monstrously terrible idea. There are MANY

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On Wed, Aug 31 at 17:18 -0500, Monty Taylor wrote: > > Nova and Neutron have an approach for this. It may or may not be ideal - > but it exists right now. While it can be satisfying to discount the > existing approach and write a new one, I do not believe that is in the > best interests of OpenSta

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On Thu, Aug 25 at 13:13 -0400, Steve Martinelli wrote: > The keystone team is pursuing a trigger-based approach to support rolling, > zero-downtime upgrades. The proposed operator experience is documented here: > > http://docs.openstack.org/developer/keystone/upgrading.html > I wanted to menti

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

So as the person who drove the rolling upgrade requirements into keystone in this cycle (because we have real customers that need it), and having first written the keystone upgrade process to be “versioned object ready” (because I assumed we would do this the same as everyone else), and subseque

  1   2   >