Re: [openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

On Thu, Mar 16, 2017 at 12:46 PM, Morgan Fainberg <morgan.fainb...@gmail.com > wrote: > > > On Mar 16, 2017 07:28, "Jeremy Stanley" <fu...@yuggoth.org> wrote: > > On 2017-03-16 08:34:58 -0500 (-0500), Lance Bragstad wrote: > [...] > > These sec

Re: [openstack-dev] [keystone] [tripleo] [deployment] Keystone Fernet keys rotations spec

I think the success of this, or a revived fernet-backend spec, is going to have a hard requirement on the outcome of the configuration opts discussion [0]. When we attempted to introduce an abstraction for fernet keys previously, it led down a rabbit hole of duplicated work across implementations,

Re: [openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

On Thu, Mar 16, 2017 at 8:07 AM, Jeremy Stanley wrote: > On 2017-03-15 13:46:42 +1300 (+1300), Adrian Turjak wrote: > > See, subdomains I can kind of see working, but the problem I have with > > all this in general is that it is kind of silly to try and stop access > > down

Re: [openstack-dev] [ptls] Project On-Boarding Rooms

I would love to have one for on-boarding new identity developers. On Wed, Mar 15, 2017 at 1:43 PM, Michał Jastrzębski wrote: > One for Kolla too please:) > > On 15 March 2017 at 11:35, Чадин Александр (Alexander Chadin) > wrote: > > +1 for Watcher > >

Re: [openstack-dev] [keystone] slide deck

Of course I would make changes to the template *right* after sending this email. I'll just share the presentation that I have [0]. https://docs.google.com/presentation/d/1s9BNHI4aHs_fEcCYuekDCFwMg1VTsKCHMkSko92Gqco/edit?usp=sharing On Tue, Mar 14, 2017 at 8:54 PM, Lance Bragstad <lbr

[openstack-dev] [keystone] slide deck

Hi all, With the forum approaching, I threw together a slide deck that incorporates the new mascot. I wanted to send this out in enough advance for folks to use them at the forum. This is in no way our *official* deck and you're not required to use it for keystone related talks or presentations.

[openstack-dev] [keystone] Pike deadlines

Hello, Sending out a quick announcement that we've merged our project-specific deadlines for the Pike release schedule [0]. Our first deadline this release is spec proposal freeze which is going to be R-20 (April 14th). Thanks! [0] https://releases.openstack.org/pike/schedule.html

Re: [openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

Rodrigo, Isn't what you just described the reseller use case [0]? Was that work ever fully finished? I thought I remember having discussions in Tokyo about it. [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html On Tue, Mar 14, 2017 at 7:38 AM, Rodrigo

Re: [openstack-dev] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

On Fri, Mar 10, 2017 at 8:49 AM, Andrea Frittoli <andrea.fritt...@gmail.com> wrote: > > > On Fri, Mar 10, 2017 at 2:24 PM Doug Hellmann <d...@doughellmann.com> > wrote: > >> Excerpts from Ghanshyam Mann's message of 2017-03-10 10:55:25 +0900: >> > On Fr

Re: [openstack-dev] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

On Thu, Mar 9, 2017 at 3:46 PM, Doug Hellmann wrote: > Excerpts from Andrea Frittoli's message of 2017-03-09 20:53:54 +: > > Hi folks, > > > > I'm trying to figure out what's the best approach to fade out testing of > > deprecated API versions. > > We currently host in

Re: [openstack-dev] [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

>From a keystone-perspective, I'm fine killing keystone.openstack.org. Unless another team member with more context/history has a reason to keep it around. On Wed, Mar 8, 2017 at 9:12 AM, Monty Taylor wrote: > Hey all, > > We have a set of old vanity redirect URLs from

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

[Openstack-operators] [keystone][defcore][refstack] Removal of the v2.0 API

During the PTG, Morgan mentioned that there was the possibility of keystone removing the v2.0 API [0]. This thread is a follow up from that discussion to make sure we loop in the right people and do everything by the books. The result of the session [1] listed the following work items: - Figure

[openstack-dev] [keystone][defcore][refstack] Removal of the v2.0 API

During the PTG, Morgan mentioned that there was the possibility of keystone removing the v2.0 API [0]. This thread is a follow up from that discussion to make sure we loop in the right people and do everything by the books. The result of the session [1] listed the following work items: - Figure

Re: [openstack-dev] [nova][keystone] Pike PTG recap - quotas

FWIW - There was a lengthy discussion in #openstack-dev yesterday regarding this [0]. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-02-28.log.html#t2017-02-28T17:39:48 On Wed, Mar 1, 2017 at 5:42 AM, John Garbutt wrote: > On 27

Re: [openstack-dev] [keystone] Pike PTG Summary

On Tue, Feb 28, 2017 at 7:04 PM, Clark Boylan <cboy...@sapwetik.org> wrote: > On Tue, Feb 28, 2017, at 04:53 PM, Lance Bragstad wrote: > > I took some time to consolidate my notes from the PTG [0]. Let me know if > > there are big things I've missed, or if you have

[openstack-dev] [keystone] Pike PTG Summary

I took some time to consolidate my notes from the PTG [0]. Let me know if there are big things I've missed, or if you have summaries of your own. Thanks to everyone who attended and participated! [0] http://lbragstad.com/keystone-pike-ptg-summary/

Re: [openstack-dev] [keystone][api] Changing devstack to not set up keystone on :5000 and :35357

Nice! Thanks for revisiting this, Brant. Was this a cross-project goal/discussion at the PTG? On Fri, Feb 24, 2017 at 9:24 AM, Brant Knudson wrote: > > At the PTG there was some discussion about changing services to not listen > on ports[0]. I'd been working on this for devstack

Re: [openstack-dev] [keystone]PKI token VS Fernet token

On Sat, Feb 25, 2017 at 12:47 AM, Clint Byrum wrote: > Excerpts from joehuang's message of 2017-02-25 04:09:45 +: > > Hello, Matt, > > > > Thank you for your reply, just as what you mentioned, for the slow > changed data, aync. replication should work. My concerns is that

[openstack-dev] [keystone] User survey feedback

As you may have noticed from other threads, we have some early feedback available from the User Survey. It hasn't closed yet - and I'm sure we'll get updated results once that happens, but the early feedback will be nice to have going into project discussions at the PTG. The question and

Re: [openstack-dev] [keystone] PTG schedule

Also - I just got word that keystone's project room for Wednesday through Friday will be Georgia 13 located on the first floor. I've updated the schedule with the location for all sessions we plan to have in that room. On Mon, Feb 20, 2017 at 8:50 AM, Lance Bragstad <lbrags...@gmail.com>

Re: [openstack-dev] [keystone] PTG schedule

with another project). Don't hesitate to ping me if you have any questions about the schedule and safe travels to Atlanta! [0] https://etherpad.openstack.org/p/keystone-pike-ptg On Thu, Feb 16, 2017 at 1:40 PM, Lance Bragstad <lbrags...@gmail.com> wrote: > Based on early feedback I've brok

Re: [openstack-dev] [keystone]PKI token VS Fernet token

On Fri, Feb 17, 2017 at 11:22 AM, Clint Byrum wrote: > Excerpts from 王玺源's message of 2017-02-17 14:08:30 +: > > Hi David: > > > > We have not find the perfect solution to solve the fernet performance > > issue, we will try the different crypt strength setting with fernet

Re: [openstack-dev] [keystone]PKI token VS Fernet token

to let me know. [0] https://etherpad.openstack.org/p/keystone-pike-ptg > > On Wed, Feb 15, 2017 at 9:08 AM Lance Bragstad <lbrags...@gmail.com> > wrote: > >> In addition to what David said, have you played around with caching in >> keystone [0]? After the initial

Re: [openstack-dev] [keystone] PTG schedule

the feedback coming. Thanks! [0] https://etherpad.openstack.org/p/pike-ptg-keystone-ocata-carry-over On Wed, Feb 15, 2017 at 10:24 PM, Lance Bragstad <lbrags...@gmail.com> wrote: > Hi all, > > I tried to get most of our things shuffled around into some-what of a > schedu

[openstack-dev] [keystone] PTG schedule

Hi all, I tried to get most of our things shuffled around into some-what of a schedule [0]. Everything that was on the list was eventually refactored into the agenda. I've broken the various topics out into their own etherpads and linked them back to the main schedule. We should have the freedom

Re: [openstack-dev] Hierarchical quotas at the PTG?

On Wed, Feb 15, 2017 at 1:11 PM, Matt Riedemann wrote: > On 2/15/2017 12:07 PM, Sajeesh Cimson Sasi wrote: > >> Hi Matt, Andrey, >> CERN-BARC team was working on nested quota >> implementation in Nova some 3 years back.But at that time, it was decided

[openstack-dev] [keystone] 2017-02-22 weekly policy meeting cancelled

Since a bunch of us are going to be at the PTG next week, we can hold policy discussions face-to-face. Our next policy meeting will take place on March 1st. Safe travels! __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [keystone]PKI token VS Fernet token

In addition to what David said, have you played around with caching in keystone [0]? After the initial implementation of fernet landed, we attempted to make it the default token provider. We ended up reverting the default back to uuid because we hit several issues. Around the Liberty and Mitaka

[openstack-dev] [keystone] 2017-02-21 weekly meeting cancelled

Hi all, I wanted to remind everyone that we won't have our weekly meeting next week (2017-02-21), since most of us with either be at the PTG or in transit. Anything we need to talk about will be done in person. We will pick back up on the 26th. Thanks, Lance

[openstack-dev] [keystone] mascot

Good news! We just got the final revision for our official keystone mascot [0]! I have a note on my todo list to put together a basic chart deck with them. I'll send out a link for folks to use when I get them done. [0] https://www.dropbox.com/sh/0owldvy0u5y4yk9/AAB5Q95wYj- oaiisneKbnEiDa?dl=0

[openstack-dev] [keystone] Pike PTG scheduling

Hey folks, We've had an etherpad [0] floating for the last few weeks collecting ideas for PTG sessions. I spent today finalizing several of the existing topics and porting others from various sources. While I think this is a pretty exhaustive list, I'm leaving it open for any last minute

Re: [openstack-dev] [All] IRC Mishaps

The fact that I'm prone to off-by-one errors (particularly when typing spaces) has reconditioned me to no longer use "got it" in chat conversation. On Thu, Feb 9, 2017 at 3:37 PM, Matt Riedemann wrote: > On 2/9/2017 9:47 AM, Hayes, Graham wrote: > >> >> I have also had some

[openstack-dev] [keystone] ocata backport potential tag

Hi all, Now that Pike is open for development, I've create an official ocata-backport-potential bug tag. In the event you see a bug that affects Ocata, feel free to use the tag. Thanks! __ OpenStack Development Mailing List

Re: [openstack-dev] [Oslo][all] Pike PTG idea & discussion

Not sure how much time it would require at the PTG - but I'd really like to discuss the ability to add in-code descriptions of oslo.policy objects, and eventually whatever we need to advertise new defaults. I'm hoping this will help OpenStack as a whole move towards providing better policy

Re: [openstack-dev] [keystone] removing Guang Yee (gyee) from keystone-core

Guang, it's been a pleasure working with you and getting to know you as a person. Best of luck in your new endeavors! On Thu, Feb 2, 2017 at 8:16 AM, Rodrigo Duarte wrote: > Thanks for everything Guang! We are already missing you. > > On Thu, Feb 2, 2017 at 10:13 AM,

Re: [openstack-dev] [keystone] Field 'domain_id' doesn't have a default value

Hi Eduardo, Master should populate the domain_id for a user before it gets to the sql layer [0] [1]. Do you have `[identity] default_domain_id` specified in your keystone.conf? Can you give some specifics on the upgrade scenario? Number of nodes? Specific request you're making to create users?

Re: [openstack-dev] Planning for the Pike PTG

I think the keystone team is in the same spot. We have an etherpad [0] for jotting down ideas, but we haven't parsed it or grouped it in into topics yet. I think we were going to start working on that next week since we're still in the middle of wrapping up the last few bits for ocata-3. I was

[openstack-dev] [keystone] [ptl] PTL candidacy for Pike

Greetings, I want to run for keystone PTL to facilitate an environment for others to grow and make meaningful changes so that we continue to build keystone into a more stable, scalable and performant project [0]. January marks my fifth anniversary working with OpenStack. In that time I've had

Re: [Openstack-operators] [openstack-dev] [keystone] 2017-1-11 policy meeting

s to maintain in tree and > everything would be in code.’ Without this file, how can we define > policies? Can user configure policies? > > Ruan > > > > *From:* Lance Bragstad [mailto:lbrags...@gmail.com] > *Sent:* mercredi 18 janvier 2017 23:16 > *To:* OpenStac

Re: [openstack-dev] [keystone] 2017-1-11 policy meeting

s to maintain in tree and > everything would be in code.’ Without this file, how can we define > policies? Can user configure policies? > > Ruan > > > > *From:* Lance Bragstad [mailto:lbrags...@gmail.com] > *Sent:* mercredi 18 janvier 2017 23:16 > *To:* OpenStac

Re: [Openstack-operators] What would you like in Pike?

Hi Sam, I've been trying to wrangle folks into discussions to see how we can improve policy as a whole across OpenStack [0] [1]. So far, we've had some involvement from a couple operators, but more feedback would be even better. My goal is to try and generate a bunch of discussion prior to the

Re: [Openstack-operators] [keystone] 2017-1-11 policy meeting

Looping this into the operator's list, too! On Wed, Jan 18, 2017 at 2:13 PM, Lance Bragstad <lbrags...@gmail.com> wrote: > Thanks to Morgan in today's policy meeting [0], we were able to shed some > light on the reasons for keystone having two policy files. The main reason > a sec

Re: [openstack-dev] [keystone] 2017-1-11 policy meeting

Looping this into the operator's list, too! On Wed, Jan 18, 2017 at 2:13 PM, Lance Bragstad <lbrags...@gmail.com> wrote: > Thanks to Morgan in today's policy meeting [0], we were able to shed some > light on the reasons for keystone having two policy files. The main reason > a sec

Re: [openstack-dev] [keystone] 2017-1-11 policy meeting

[2] https://github.com/openstack/keystone/blob/7f2b7e58e74c79e5a09bd5c20e0de9c15d9eabd0/etc/policy.json On Wed, Jan 11, 2017 at 11:28 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > Hey folks, > > In case you missed the policy meeting today, we had a good discussion [0] > aro

Re: [openstack-dev] [devstack][keystone] DRaaS for Keystone

Hi Wasiq! On Tue, Jan 17, 2017 at 1:34 PM, Wasiq Noor wrote: > Hello, > > I am Wasiq from Namal College Mianwali, Pakistan. Following the link: > https://wiki.openstack.org/wiki/DisasterRecovery, I have developed a > disaster recovery solution for Keystone for various

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

I would consider that to be something that spans further than just barbican and keystone. The ability to restrict a token to a single service/operation/resource is a super interesting problem especially when you start to consider operational dependencies between the services. If the approach spans

Re: [openstack-dev] [release] subscribe to the OpenStack release calendar

This is awesome! I pretty much just 'Select All' deleted my other calendars I use for tracking this kind of information. Thank you, Doug! On Thu, Jan 12, 2017 at 12:41 PM, Emilien Macchi wrote: > On Wed, Jan 11, 2017 at 1:51 PM, Doug Hellmann >

[openstack-dev] [keystone] 2017-1-11 policy meeting

Hey folks, In case you missed the policy meeting today, we had a good discussion [0] around incorporating keystone's policy into code using the Nova approach. Keystone is in a little bit of a unique position since we maintain two different policy files [1] [2], and there were a lot of questions

Re: [openstack-dev] [keystone] office hours starting January 6th

something that both keystone and the > community will benefit! :) > > On Wed, Dec 21, 2016 at 4:22 PM, Steve Martinelli <s.martine...@gmail.com> > wrote: > >> Thanks for setting this up Lance! >> >> You can count on me to join and smash some bugs. >> >

[openstack-dev] [keystone] documenting policy guidelines

We had another healthy discussion about policy today [0] and most of it revolved around documenting policy guidelines. The question of the day was where should these guidelines live? To answer that we highlighted the following criteria: - Guidelines should be proposed and reviewed in small

Re: [openstack-dev] [keystone] Feedback for upcoming user survey questionnaire

++ to the suggestions Boris threw out. Answers to any of those would be valuable. In addition to that, I'd find any information about policy useful. Maybe something along the lines of "what changes to the policy files are you making, if any". This could be something that is asked OpenStack-wide

[openstack-dev] [keystone] office hours starting January 6th

Hi folks! If you remember, last year we started a weekly bug day [0]. The idea was to dedicate one day a week to managing keystone's bug queue by triaging, fixing, and reviewing bugs. This was otherwise known as keystone's office hours. I'd like to remind everyone that we are starting up this

[openstack-dev] [keystone] 2016-12-21 policy meeting

Sending a note to summarize the policy meeting we had today [0]. Also to remind folks that our next policy meeting will be Wednesday, January 4th. Hope everyone has a safe and happy holiday season! [0] http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-21-16.01.log.html

Re: [openstack-dev] [keystone] Custom ProjectID upon creation

I put myself in Boris' camp on this one. This can open up the opportunity for negative user-experience, purely based on where I authenticate and which token I happen to authenticate with. A token would no longer be something I can assume to be properly validated against any node in my deployment.

Re: [openstack-dev] [keystone] Custom ProjectID upon creation

The ability to specify IDs at project creation time was proposed as a specification last summer [0]. The common theme from the discussion in that thread was to use shadow mapping [1] to solve that problem. [0] https://review.openstack.org/#/c/323499/ [1]

Re: [openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

FWIW - i'm seeing a common error in several of the rally failures [0] [1] [2] [3]. Dims also pointed out a few bugs in rally for keystone v3 support [4]. I checked with the folks in #openstack-containers to see if they were experiencing anymore fallout, but it looks like the magnum gate is under

[openstack-dev] [keystone] 2016-11-23 policy meeting summary

We had a useful discussion today [0]. I attempted to summarize the meeting in the etherpad [1], crossed off things we accomplished, and documented our action items to complete by next week, which I'll echo below: *ACTION ITEM:* group to review https://review.openstack.org/#/c/391624/ and continue

Re: [openstack-dev] [keystone] Stepping down from keystone core

Thanks for all your hard work, Marek. It's been a pleasure working with you. Best of luck and hopefully our paths cross in the future! On Tue, Nov 22, 2016 at 7:57 PM, Steve Martinelli wrote: > Marek, thanks for everything you've done in Keystone. It was loads of fun >

Re: [openstack-dev] [keystone] Pike PTL

Steve, thanks for all the hard work and dedication over the last 3 cycles. I hope you have a nice break and I look forward to working with you on Pike! Enjoy you're evenings :) On Mon, Nov 21, 2016 at 1:38 PM, Steve Martinelli wrote: > one of these days i'll learn how

Re: [openstack-dev] [keystone] Weekly Policy Meeting

-16.log.html#t2016-11-16T16:01:43 [1] https://review.openstack.org/#/c/398500/ [2] https://etherpad.openstack.org/p/keystone-policy-meeting On Wed, Nov 16, 2016 at 8:32 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > Just sending out a reminder that we'll be having our first meet

Re: [openstack-dev] [keystone] Weekly Policy Meeting

/call/pd36j4qv5zfbldmhxeeatq6f7ae On Fri, Nov 11, 2016 at 8:33 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > I've added some initial content to the etherpad [0], to get things > rolling. Since this is going to be a recurring thing, I'd like our first > meeting to level set th

[openstack-dev] [keystone] meeting format poll

Hey folks, In today's keystone meeting, Morgan mentioned that we had the ability to go back to using OpenStack Wikis for meeting agendas. I created a poll to get feedback [0]. Let's keep it open for the week and look at the results as a team at our next meeting. Thanks! [0]

Re: [openstack-dev] [keystone] Weekly Policy Meeting

ards compatible. > > On Thu, Nov 10, 2016 at 3:30 PM, Lance Bragstad <lbrags...@gmail.com> > wrote: > >> Hi folks, >> >> After hearing the recaps from the summit, it sounds like policy was a hot >> topic (per usual). This is also reinforced by the fact every r

Re: [openstack-dev] [Openstack-operators] [keystone][tripleo][ansible][puppet][all] changing default token format

/operators. Generally they'll want to publish it there first then > you follow-up with your blog post a few days later. > > On Mon, Nov 7, 2016 at 8:17 AM, Lance Bragstad <lbrags...@gmail.com> > wrote: > >> That's a good idea. Is there a page detailing the process for &

Re: [Openstack-operators] [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

/operators. Generally they'll want to publish it there first then > you follow-up with your blog post a few days later. > > On Mon, Nov 7, 2016 at 8:17 AM, Lance Bragstad <lbrags...@gmail.com> > wrote: > >> That's a good idea. Is there a page detailing the process for &

[openstack-dev] [keystone] Weekly Policy Meeting

Hi folks, After hearing the recaps from the summit, it sounds like policy was a hot topic (per usual). This is also reinforced by the fact every release we have specifications proposed to re-do policy in some way. It's no doubt policy in OpenStack needs work. Let's dedicate an hour a week to

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

t; a blog post on the OpenStack sore might be good. superuser? there are > folks reading this who can help > > Sent from HUAWEI AnyOffice > *From:*Lance Bragstad > *To:*OpenStack Development Mailing List (not for usage questions), > openstack-operat...@lists.openstack.org, &

Re: [Openstack-operators] [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

t; a blog post on the OpenStack sore might be good. superuser? there are > folks reading this who can help > > Sent from HUAWEI AnyOffice > *From:*Lance Bragstad > *To:*OpenStack Development Mailing List (not for usage questions), > openstack-operators@lists.openstack.org, &

Re: [Openstack-operators] [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

I totally agree with communicating this the best we can. I'm adding the operator list to this thread to increase visibility. If there are any other methods folks think of for getting the word out, outside of what we've already done (release notes, email threads, etc.), please let me know. I'd be

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

I totally agree with communicating this the best we can. I'm adding the operator list to this thread to increase visibility. If there are any other methods folks think of for getting the word out, outside of what we've already done (release notes, email threads, etc.), please let me know. I'd be

Re: [openstack-dev] [keystone] new keystone core (breton)

Great work Boris. Welcome to the team! On Mon, Oct 31, 2016 at 2:50 PM, Kristi Nikolla wrote: > Congrats Boris! Well deserved! > > Kristi > > On 10/31/2016 03:46 PM, Steve Martinelli wrote: > > I want to welcome Boris Bobrov (breton) to the keystone core team. Boris > > has

Re: [openstack-dev] [keystone] new core reviewer (rderose)

+1! He has been doing some great work. Welcome to the team, Ron! On Thu, Sep 1, 2016 at 9:44 AM, Steve Martinelli wrote: > I want to welcome Ron De Rose (rderose) to the Keystone core team. In a > short time Ron has shown a very positive impact. Ron has contributed >

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

Since the encrypted credential work is currently based on triggers, I spent most of today documenting a walk-though migration from Mitaka to Newton [0]. Regardless of the outcome discussed here - figured it would be worth sharing since it's relevant to the thread. Most of the gist contains stuff

Re: [openstack-dev] [requirements] race in keystone unit tests

/freezegun On Tue, Aug 2, 2016 at 9:21 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > Hi Sean, > > Thanks for the information. This obviously looks Fernet-related and I > would be happy to spend some cycles on it. We recently landed a bunch of > refactors in keystone to improve

Re: [openstack-dev] [requirements] race in keystone unit tests

Hi Sean, Thanks for the information. This obviously looks Fernet-related and I would be happy to spend some cycles on it. We recently landed a bunch of refactors in keystone to improve Fernet test coverage. This could be related to those refactors. Just double checking - but you haven't opened a

Re: [openstack-dev] [keystone] Can anyone share some experience for how to configure keystone work with https

There are several upstream deployment projects that have SSL support baked in [0] [1], in case you want to pick through and see exactly how they deploy keystone with SSL. [0] https://github.com/openstack/openstack-ansible-os_keystone [1] https://github.com/openstack/puppet-keystone On Mon, Jul

Re: [openstack-dev] [keystone][all] Incorporating performance feedback into the review process

review the >Rally test cases that we proposed to them > > > Best regards, > Boris Pavlovic > > On Mon, Jun 6, 2016 at 10:45 AM, Clint Byrum <cl...@fewbar.com> wrote: > >> Excerpts from Brant Knudson's message of 2016-06-03 15:16:20 -0500: >>

Re: [openstack-dev] [keystone][all] Incorporating performance feedback into the review process

2016 at 2:35 PM, Lance Bragstad <lbrags...@gmail.com> > wrote: > > > > > Hey all, > > > > > > I have been curious about impact of providing performance feedback as > part > > > of the review process. From what I understand, keystone used to have a >

Re: [openstack-dev] [keystone][all] Incorporating performance feedback into the review process

published publicly (nice to have) On Fri, Jun 3, 2016 at 3:16 PM, Brant Knudson <b...@acm.org> wrote: > > > On Fri, Jun 3, 2016 at 2:35 PM, Lance Bragstad <lbrags...@gmail.com> > wrote: > >> Hey all, >> >> I have been curious about impact of providing

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash <henryna...@mac.com> wrote: > > On 3 Jun 2016, at 16:38, Lance Bragstad <lbrags...@gmail.com> wrote: > > > > On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <henryna...@mac.com> wrote: > >> >> On 3 Jun 2

[openstack-dev] [keystone][all] Incorporating performance feedback into the review process

Hey all, I have been curious about impact of providing performance feedback as part of the review process. From what I understand, keystone used to have a performance job that would run against proposed patches (I've only heard about it so someone else will have to keep me honest about its

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash wrote: > > On 3 Jun 2016, at 01:22, Adam Young wrote: > > On 06/02/2016 07:22 PM, Henry Nash wrote: > > Hi > > As you know, I have been working on specs that change the way we handle > the uniqueness of project

Re: [openstack-dev] [keystone] New Core Reviewer (sent on behalf of Steve Martinelli)

Congratulations Rodrigo! Thank you for all the continued and consistent reviews. On Tue, May 24, 2016 at 1:28 PM, Morgan Fainberg wrote: > I want to welcome Rodrigo Duarte (rodrigods) to the keystone core team. > Rodrigo has been a consistent contributor to keystone

Re: [openstack-dev] [keystone] Token providers and Fernet as the default

If we were to write a uuid/fernet hybrid provider, it would only be expected to support something like stable/liberty to stable/mitaka, right? This is something that we could contribute to stackforge, too. On Tue, May 3, 2016 at 9:21 AM, Adam Young wrote: > On 05/03/2016

Re: [openstack-dev] [Keystone] State of Fernet Token deployment

It looks like it does [0]. [0] https://github.com/openstack-dev/devstack/blob/4e7804431ada7e2cc0db63bd4c52b17782d33b5b/lib/keystone#L494-L497 On Mon, Apr 18, 2016 at 10:20 AM, Matt Fischer wrote: > On Mon, Apr 18, 2016 at 8:29 AM, Brant Knudson wrote: > >>

Re: [openstack-dev] [keystone] Newton midycle planning

++ Nice to see this planning happening early! R-14 would probably be a no-go for me. R-12 and R-11 fit my schedule. On Thu, Apr 14, 2016 at 9:11 AM, Henry Nash wrote: > Hi Morgan, > > Great to be planning this ahead of time!!! > > For me either of the July dates are fine -

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

I think we need to ask who we are lowering the barrier of entry for. Are we going down this path because we want developers to have less things to do to stand up a development environment? Or do we want to make it easy for people to realistically test? If you're going to realistically vet magnum,

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

Keystone's credential API pre-dates barbican. We started talking about having the credential API back to barbican after it was a thing. I'm not sure if any work has been done to move the credential API in this direction. From a security perspective, I think it would make sense for keystone to back

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

In response to point 2.2, the progress with Fernet in the last year has exposed performance pain points in keystone. Finding sensible solutions for those issues is crucial in order for people to adopt Fernet. In Mitaka we had a lot of discussion that resulted in landing several performance related

Re: [openstack-dev] Is keystone support combined authentication in release L?

Keystone introduced TOTP authentication this release [0]. Like Adam said, in Newton we will build multi-factor authentication on top of TOTP and existing plugins. [0] http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/totp-auth.html On Sun, Mar 13, 2016 at 4:05 PM, Adam Young

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

On Tue, Mar 8, 2016 at 10:58 AM, Adam Young wrote: > On 03/08/2016 11:06 AM, Matt Fischer wrote: > > This would be complicated to setup. How would the Openstack services > validate the token? Which keystone node would they use? A better question > is why would you want to do

[Openstack-operators] [keystone] Usage of trusts with v2.0 authentication

When trusts were implemented, they were designed to work as an extension under the version 3 API. The implementation didn't prevent the use of a trust to authenticate against version 2.0, which was never officially documented in the v2.0 API docs. The keystone team is curious if there is anyone

[openstack-dev] [keystone] Usage of trusts with v2.0 authentication

When trusts were implemented, they were designed to work as an extension under the version 3 API. The implementation didn't prevent the use of a trust to authenticate against version 2.0, which was never officially documented in the v2.0 API docs. The keystone team is curious if there is anyone

Re: [openstack-dev] [keystone] changes to keystone-core!

++ I'm happy to see this go through! Samuel and Dave have been helping me out a lot lately. Both make great additions to the team! On Thu, Jan 28, 2016 at 9:12 AM, Brad Topol wrote: > CONGRATULATIONS Dave and Samuel. Very well deserved!!! > > --Brad > > > Brad Topol, Ph.D. >

Re: [openstack-dev] [keystone] Let's get together and fix all the bugs

And hope I can put some other folks in too. > > Em sáb, 10 de out de 2015 às 12:03, Lance Bragstad <lbrags...@gmail.com> > escreveu: > >> On Sat, Oct 10, 2015 at 8:07 AM, Boris Bobrov <bbob...@mirantis.com> >> wrote: >> >>> On Saturday 1

Re: [openstack-dev] 答复: [keystone] Is "domain" a mapping to real-world cloud tenant?

Interesting. The paper says that the implementation was based on the Havana release. Just out of curiosity, does anyone know if the code is public? On Mon, Dec 14, 2015 at 6:38 PM, darren wang wrote: > Hi Dolph, > > > > Here it is, >

Re: [Openstack-operators] [keystone] Request for Feedback: Online database migrations

Hey all, I wanted to send out a follow up on this. Yesterday in the keystone meeting we voted on Mitaka specs that we would like to commit to. The online-migration spec was accepted as something we would definitely like to see [0]. On the other hand, the development team doesn't really have

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On Tue, Dec 1, 2015 at 6:05 AM, Sean Dague wrote: > On 12/01/2015 01:57 AM, Steve Martinelli wrote: > > Trying to summarize here... > > > > - There isn't much interest in keeping eventlet around. > > - Folks are OK with running keystone in a WSGI server, but feel they are > >

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

I think one of the benefits of the current model was touched on earlier by dstanek. If someone is working on something for their organization, they typically bounce ideas of others they work with closely. This tends to be people within the same organization. The groups developing the feature might

<    1   2   3   4   5   6   >