Re: [openstack-dev] [keystone] office hours report 2017-7-7

On 07/11/2017 09:28 PM, Mathieu Gagné wrote: > Hi, > > So this email is relevant to my interests as an operator. =) Glad to hear it! > > On Tue, Jul 11, 2017 at 9:35 PM, Lance Bragstad <lbrags...@gmail.com > <mailto:lbrags...@gmail.com>> wrote: > >

[openstack-dev] [keystone] office hours report 2017-7-7

Hey all, This is a summary of what was worked on today during office hours. Full logs of the meeting can be found below: http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-07-11-19.00.log.html *The future of the templated catalog backend * Some issues were uncovered,

Re: [Openstack-operators] [openstack-dev] [keystone] deprecating and removing tools/sample_data.sh

#L331 On 07/05/2017 04:28 PM, Colleen Murphy wrote: > On Wed, Jul 5, 2017 at 9:36 PM, Lance Bragstad <lbrags...@gmail.com > <mailto:lbrags...@gmail.com>> wrote: > > Hi all, > > Keystone has a script to perform some bootstrapping operations > [0]. It'

Re: [openstack-dev] [keystone] deprecating and removing tools/sample_data.sh

#L331 On 07/05/2017 04:28 PM, Colleen Murphy wrote: > On Wed, Jul 5, 2017 at 9:36 PM, Lance Bragstad <lbrags...@gmail.com > <mailto:lbrags...@gmail.com>> wrote: > > Hi all, > > Keystone has a script to perform some bootstrapping operations > [0]. It'

[openstack-dev] [keystone] office hours reminder

Hey all, Just a quick reminder that today we will be holding office hours after the keystone meeting [0]. See you there! Thanks, Lance [0] http://eavesdrop.openstack.org/#Keystone_Team_Meeting signature.asc Description: OpenPGP digital signature

Re: [openstack-dev] [keystone] We still have a not identical HEAD response

Based on the comments and opinions in the original thread, I think a fix for this is justified. I wouldn't mind running this by the TC to double check that nothing has changed from the first time we had to fix this issue though. On 07/11/2017 06:03 AM, Attila Fazekas wrote: > Hi all, > > Long

[Openstack-operators] [keystone] deprecating and removing tools/sample_data.sh

Hi all, Keystone has a script to perform some bootstrapping operations [0]. It's not really tested and its purpose has been superseded by using the `keystone-manage bootstrap` command. Based on codesearch, only openstack/rpm-packaging references the script [1]. Is anyone opposed to the

[openstack-dev] [keystone] deprecating and removing tools/sample_data.sh

Hi all, Keystone has a script to perform some bootstrapping operations [0]. It's not really tested and its purpose has been superseded by using the `keystone-manage bootstrap` command. Based on codesearch, only openstack/rpm-packaging references the script [1]. Is anyone opposed to the

[openstack-dev] [keystone] Queens PTG Planning

Hey all, I've started an etherpad [0] for us to collect topics and ideas for the PTG in September. I hope to follow the same planning format as last time. Everyone has the opportunity to add topics to the agenda and after some time we'll group related topics and start building a formal schedule.

Re: [openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

On 06/30/2017 04:38 AM, Thierry Carrez wrote: > Mike Perez wrote: >> [...] >> What do people think before we bikeshed on the name? Would having a >> champion volunteer to each goal to help? > It feels like most agree that having champions would help. Do we have > any volunteer for the

[openstack-dev] [keystone] no policy meeting today

Hey all, Given the empty agenda [0] and the holiday, we will cancel the policy meeting this week. We'll pick up again next week. Thanks [0] https://etherpad.openstack.org/p/keystone-policy-meeting signature.asc Description: OpenPGP digital signature

[openstack-dev] [keystone] stable/newton is broken

Keystone's stable/newton gate is broken [0] [1]. The TL;DR is that our keystone_tempest_plugin is validating federated mappings before updating the protocol [2]. The lack of validation was a bug [3] that was fixed in Ocata, but the fix [4] was never backported. Since stable/newton is in Phase II,

Re: [openstack-dev] [keystone] removing domain configuration upload via keystone-manage

t; >> On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad >> <lbrags...@gmail.com <mailto:lbrags...@gmail.com>> wrote: >> >> Hi all, >> >> Keystone has deprecated the domain configuration upload >>

Re: [openstack-dev] [TripleO][keystone] Pt. 2 of Passing along some field feedback

On 06/28/2017 03:20 PM, Ben Nemec wrote: > > > On 06/28/2017 02:47 PM, Lance Bragstad wrote: >> >> >> On 06/28/2017 02:29 PM, Fox, Kevin M wrote: >>> I think everyone would benefit from a read-only role for keystone >>> out of the box. Can we get this

Re: [openstack-dev] [TripleO][keystone] Pt. 2 of Passing along some field feedback

On 06/28/2017 02:29 PM, Fox, Kevin M wrote: > I think everyone would benefit from a read-only role for keystone out of the > box. Can we get this into keystone rather then in the various distro's? Yeah - I think that would be an awesome idea. John Garbutt had some good work on this earlier in

Re: [openstack-dev] [keystone] removing domain configuration upload via keystone-manage

d, Jun 28, 2017 at 2:00 AM, Lance Bragstad <lbrags...@gmail.com > <mailto:lbrags...@gmail.com>> wrote: > > Hi all, > > Keystone has deprecated the domain configuration upload capability > provided through `keystone-manage`. We discussed it's removal in

[openstack-dev] [keystone] office-hours tag

Hey all, I've created a new official tag, 'office-hours' [0]. If you're reviewing or triaging bugs and come across one that would be a good fit for us to tackle during office hours, please feel free to tag it. I was maintaining lists locally, and I'm sure you were, too. This should help reduce

[Openstack-operators] [keystone] removing domain configuration upload via keystone-manage

Hi all, Keystone has deprecated the domain configuration upload capability provided through `keystone-manage`. We discussed it's removal in today's meeting [0] and wanted to send a quick note to the operator list. The ability to upload a domain config into keystone was done as a stop-gap until

[openstack-dev] [keystone] removing domain configuration upload via keystone-manage

Hi all, Keystone has deprecated the domain configuration upload capability provided through `keystone-manage`. We discussed it's removal in today's meeting [0] and wanted to send a quick note to the operator list. The ability to upload a domain config into keystone was done as a stop-gap until

[openstack-dev] [keystone] documentation migration and consolidation

Hey all, We recently merged the openstack-manuals admin-guide into keystone [0] and there is a lot of duplication between the admin-guide and keystone's "internal" operator-guide [1]. I've started proposing small patches to consolidate the documentation from the operator-guide to the official

Re: [openstack-dev] [keystone] New Office Hours Proposal

According to the poll results, office hours will be moved to Tuesday 19:00 - 22:00 UTC. We'll officially start tomorrow after the keystone meeting. Thanks for putting together and advertising the poll, Harry! On 06/20/2017 02:30 PM, Harry Rybacki wrote: > Greetings All, > > We would like to

Re: [openstack-dev] [tc][all] Move away from meeting channels

On 06/26/2017 08:58 AM, Chris Dent wrote: > On Mon, 26 Jun 2017, Flavio Percoco wrote: > >> So, should we let teams to host IRC meetings in their own channels? > > Yes. +1 > >> Thoughts? > > I think the silo-ing concern is, at least recently, not relevant on > two fronts: IRC was never a good

Re: [openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

On 06/22/2017 12:57 PM, Mike Perez wrote: > Hey all, > > In the community wide goals, we started as a group discussing goals at > the OpenStack Forum. Then we brought those ideas to the mailing list > to continue the discussion and include those that were not able to be > at the forum. The

Re: [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

On 06/21/2017 11:55 AM, Matt Riedemann wrote: > On 6/21/2017 11:17 AM, Shamail Tahir wrote: >> >> >> On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez >> > wrote: >> >> Shamail Tahir wrote: >> > In the past, governance has helped (on

Re: [openstack-dev] [all] Policy rules for APIs based on "domain_id"

Domain support hasn't really been adopted across various OpenStack projects, yet. Ocata was the first release where we had a v3-only jenkins job set up for projects to run against (domains are a v3-only concept in keystone and don't really exist in v2.0). I think it would be great to push on some

Re: [openstack-dev] [rally][no-admin] Finally Rally can be run without admin user

On Tue, Jun 13, 2017 at 3:51 PM, Morgan Fainberg wrote: > On Tue, Jun 13, 2017 at 1:04 PM, Boris Pavlovic wrote: > > Hi stackers, > > > > Intro > > > > Initially Rally was targeted for developers which means running it from > > admin was OK. > >

Re: [openstack-dev] [all] etcd3 as base service - update

On Fri, Jun 9, 2017 at 11:17 AM, Clint Byrum <cl...@fewbar.com> wrote: > Excerpts from Lance Bragstad's message of 2017-06-08 16:10:00 -0500: > > On Thu, Jun 8, 2017 at 3:21 PM, Emilien Macchi <emil...@redhat.com> > wrote: > > > > > On Thu, Jun 8,

Re: [openstack-dev] [all] etcd3 as base service - update

On Fri, Jun 9, 2017 at 9:57 AM, Mike Bayer <mba...@redhat.com> wrote: > > > On 06/08/2017 01:34 PM, Lance Bragstad wrote: > >> After digging into etcd a bit, one place this might be help deployer >> experience would be the handling of fernet keys for token encryp

Re: [openstack-dev] [release][glance][barbican][telemetry][keystone][designate][congress][magnum][searchlight][swift][tacker] unreleased libraries

Just pushed a release for pycadf as well [1]. [1] https://review.openstack.org/#/c/472717/ On Fri, Jun 9, 2017 at 9:43 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > We have a review in flight to release python-keystoneclient [0]. Thanks > for the reminder! &

Re: [openstack-dev] [release][glance][barbican][telemetry][keystone][designate][congress][magnum][searchlight][swift][tacker] unreleased libraries

We have a review in flight to release python-keystoneclient [0]. Thanks for the reminder! [0] https://review.openstack.org/#/c/472667/ On Fri, Jun 9, 2017 at 9:39 AM, Doug Hellmann wrote: > We have several teams with library deliverables that haven't seen > any releases

[openstack-dev] [keystone] Specification Freeze

Happy Stanley-Cup-Playoff-Game-5 Day, Sending out a quick reminder that tomorrow is specification freeze. I'll be making a final push for specifications that target Pike work tomorrow. I'd also like to merge others to backlog as we see fit. By EOD tomorrow, I'll go through and put procedural

Re: [openstack-dev] [all] etcd3 as base service - update

On Thu, Jun 8, 2017 at 3:21 PM, Emilien Macchi <emil...@redhat.com> wrote: > On Thu, Jun 8, 2017 at 7:34 PM, Lance Bragstad <lbrags...@gmail.com> > wrote: > > After digging into etcd a bit, one place this might be help deployer > > experience would be the han

Re: [openstack-dev] [all] etcd3 as base service - update

After digging into etcd a bit, one place this might be help deployer experience would be the handling of fernet keys for token encryption in keystone. Currently, all keys used to encrypt and decrypt tokens are kept on disk for each keystone node in the deployment. While simple, it requires

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

. Thanks for all the feedback and patience. [0] https://review.openstack.org/#/c/464763/ On Tue, Jun 6, 2017 at 4:39 PM, Marc Heckmann <marc.heckm...@ubisoft.com> wrote: > On Tue, 2017-06-06 at 17:01 -0400, Erik McCormick wrote: > > On Tue, Jun 6, 2017 at 4:44 PM, Lance B

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

. Thanks for all the feedback and patience. [0] https://review.openstack.org/#/c/464763/ On Tue, Jun 6, 2017 at 4:39 PM, Marc Heckmann <marc.heckm...@ubisoft.com> wrote: > On Tue, 2017-06-06 at 17:01 -0400, Erik McCormick wrote: > > On Tue, Jun 6, 2017 at 4:44 PM, Lance B

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

On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann <marc.heckm...@ubisoft.com> wrote: > Hi, > > On Tue, 2017-06-06 at 10:09 -0500, Lance Bragstad wrote: > > Also, with all the people involved with this thread, I'm curious what the > best way is to get consensus. If I've tallie

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

On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann <marc.heckm...@ubisoft.com> wrote: > Hi, > > On Tue, 2017-06-06 at 10:09 -0500, Lance Bragstad wrote: > > Also, with all the people involved with this thread, I'm curious what the > best way is to get consensus. If I've tallie

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

/ On Tue, Jun 6, 2017 at 10:01 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > I replied to John, but directly. I'm sending the responses I sent to him > but with the intended audience on the thread. Sorry for not catching that > earlier. > > > On Fri, May 26, 2017 at

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

> >> On Fri, May 26, 2017 at 2:52 AM, joehuang <joehu...@huawei.com> wrote: >> >>> I think a option 2 is better. >>> >>> Best Regards >>> Chaoyi Huang (joehuang) >>> -- >>> *From:* Lance Bragstad [lb

Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

On Thu, Jun 1, 2017 at 3:46 PM, Andrey Grebennikov < agrebenni...@mirantis.com> wrote: > We had a very similar conversation multiple times with Keystone cores > (multi-site Keystone). > Geo-rep Galera was suggested first and it was immediately declined (one of > the reasons was the case of

[openstack-dev] [tc][ptls][all] Potential Queens Goal: Move policy and policy docs into code

Hi all, I've proposed a community-wide goal for Queens to move policy into code and supply documentation for each policy [0]. I've included references to existing documentation and specifications completed by various projects and attempted to lay out the benefits for both developers and

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

/build/html/specs/keystone/ongoing/global-roles.html On Wed, May 31, 2017 at 9:10 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > > > On Fri, May 26, 2017 at 10:21 AM, Sean Dague <s...@dague.net> wrote: > >> On 05/26/2017 10:44 AM, Lance Bragstad wrote: >>

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

On Fri, May 26, 2017 at 10:21 AM, Sean Dague <s...@dague.net> wrote: > On 05/26/2017 10:44 AM, Lance Bragstad wrote: > > > Interesting - I guess the way I was thinking about it was on a per-token > > basis, since today you can't have a single token represent mu

Re: [openstack-dev] [kolla][osprofiler][keystone][neutron][nova] osprofiler in paste deploy files

On Mon, May 29, 2017 at 4:08 AM, Matthieu Simonin wrote: > Hello, > > I'd like to have more insight on OSProfiler support in paste-deploy files > as it seems not similar across projects. > As a result, the way you can enable it on Kolla side differs. Here are > some

[openstack-dev] [keystone] deprecating the policy and credential APIs

At the PTG in Atlanta, we talked about deprecating the policy and credential APIs. The policy API doesn't do anything and secrets shouldn't be stored in credential API. Reasoning and outcomes can be found in the etherpad from the session [0]. There was some progress made on the policy API [1], but

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

On Fri, May 26, 2017 at 9:31 AM, Sean Dague <s...@dague.net> wrote: > On 05/26/2017 10:05 AM, Lance Bragstad wrote: > > > > > > On Fri, May 26, 2017 at 5:32 AM, Sean Dague <s...@dague.net > > <mailto:s...@dague.net>> wrote: > > > >

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

On Fri, May 26, 2017 at 5:32 AM, Sean Dague wrote: > On 05/26/2017 03:44 AM, John Garbutt wrote: > > +1 on not forcing Operators to transition to something new twice, even > > if we did go for option 3. > > > > Do we have an agreed non-distruptive upgrade path mapped out yet?

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

igration you're willing to make. This might be a loaded question and it will vary across deployments, but how long would you expect that migration to take for you're specific deployment(s)? -m > > > > > On Thu, 2017-05-25 at 10:42 +1200, Adrian Turjak wrote: > > > > On 25

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

igration you're willing to make. This might be a loaded question and it will vary across deployments, but how long would you expect that migration to take for you're specific deployment(s)? -m > > > > > On Thu, 2017-05-25 at 10:42 +1200, Adrian Turjak wrote: > > > > On 25

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

stone/blob/3d033df1c0fdc6cc9d2b02a702efca286371f2bd/etc/keystone.conf.sample#L2334-L2342 On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > Hey all, > > To date we have two proposed solutions for tackling the admin-ness issue > we have acr

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

[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

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

I'm in favor of option #1. I think it encourages our developers to become better writers with guidance from the docs team. While ensuring docs are proposed prior to merging the implementation cross-repository is totally possible, I think #1 makes that flow easier. Thanks for putting together the

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

Project: Keystone Attendees: 12 - 15 We conflicted with one of the Baremetal/VM sessions I attempted to document most of the session in my recap [0]. We started out by doing a round-the-room of introductions so that folks could put IRC nicks to faces (we also didn't have a packed room so this

Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

On Thu, May 18, 2017 at 6:43 PM, Curtis wrote: > On Thu, May 18, 2017 at 4:13 PM, Adrian Turjak > wrote: > > Hello fellow OpenStackers, > > > > For the last while I've been looking at options for multi-region > > multi-master Keystone, as well as

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On Thu, May 18, 2017 at 9:39 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > > > On Thu, May 18, 2017 at 8:45 AM, Sean Dague <s...@dague.net> wrote: > >> On 05/18/2017 09:27 AM, Doug Hellmann wrote: >> > Excerpts from Adrian Turjak's message of 2017-05-18

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On Thu, May 18, 2017 at 8:45 AM, Sean Dague wrote: > On 05/18/2017 09:27 AM, Doug Hellmann wrote: > > Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200: > > > >> Fully agree that expecting users of a particular cloud to understand how > >> the policy stuff works

[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

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On Tue, May 16, 2017 at 8:54 AM, Monty Taylor <mord...@inaugust.com> wrote: > On 05/16/2017 05:39 AM, Sean Dague wrote: > >> On 05/15/2017 10:00 PM, Adrian Turjak wrote: >> >>> >>> >>> On 16/05/17 13:29, Lance Bragstad wrote: >>> &

Re: [openstack-dev] [keystone] [Pile] Need Exemption On Submitted Spec for the Keystone

That sounds good - I'll review the spec before today's meeting [0]. Will someone be around to answer questions about the spec if there are any? [0] http://eavesdrop.openstack.org/#Keystone_Team_Meeting On Mon, May 15, 2017 at 11:24 PM, Mh Raies wrote: > Hi Lance, > > >

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak <adri...@catalyst.net.nz> wrote: > > On 16/05/17 01:09, Lance Bragstad wrote: > > > > On Sun, May 14, 2017 at 11:59 AM, Monty Taylor <mord...@inaugust.com> > wrote: > >> On 05/11/2017 02:32 PM, Lance B

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On Sun, May 14, 2017 at 11:59 AM, Monty Taylor <mord...@inaugust.com> wrote: > On 05/11/2017 02:32 PM, Lance Bragstad wrote: > >> Hey all, >> >> One of the Baremetal/VM sessions at the summit focused on what we need >> to do to make OpenStack more cons

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On Mon, May 15, 2017 at 6:20 AM, Sean Dague wrote: > On 05/15/2017 05:59 AM, Andrey Volkov wrote: > > > >> The last time this came up, some people were concerned that trusting > >> request-id on the wire was concerning to them because it's coming from > >> random users. > > > >

[openstack-dev] [all][keystone][product] api keys/application specific passwords

Hey all, One of the Baremetal/VM sessions at the summit focused on what we need to do to make OpenStack more consumable for application developers [0]. As a group we recognized the need for application specific passwords or API keys and nearly everyone (above 85% is my best guess) in the session

[openstack-dev] [keystone] session etherpads

Hey all, We have a couple sessions to start off the week and I wanted to send out the links to the etherpads [0] [1] [2]. Let me know if you have any questions. Otherwise feel free to catch up or pre-populate the etherpads with content if you have any. Thanks! [0]

Re: [openstack-dev] [all][ptl][goals] Community goals for Queen

For scheduling purposes, here is a link to the session [0]. [0] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18732/queens-goals On Sat, May 6, 2017 at 5:36 PM, Matt Riedemann wrote: > On 5/5/2017 8:23 PM, Sean Dague wrote: > >> On 05/05/2017 05:09

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

Re: [openstack-dev] [keystone][horizon] weekly meeting

nstack.org/p/ocata-keystone-horizon > > On Thu, Apr 20, 2017 at 3:46 PM, Lance Bragstad <lbrags...@gmail.com> > wrote: > >> I wonder if the meeting tooling supports a monthly cadence? >> >> On Thu, Apr 20, 2017 at 2:42 PM, Rob Cresswell < >> robert.cressw

[openstack-dev] [keystone] No policy meeting next week (2017-05-10)

Next week is the Forum, so we'll forego the the policy meeting in favor of some face-to-face discussions. Let's pick back up with policy recaps on the 17th of May. Thanks, Lance __ OpenStack Development Mailing List (not

[openstack-dev] [keystone][forum] BM/VM session conflict with project workshop

Looking through the schedule of keystone-tagged sessions, it appears we have a conflict between one of the BM/VM sessions [0] and keystone's project on-boarding session [1]. I wouldn't be opposed to shuffling, but I assume it's too late for that? If we can get a good idea of who is going to show

[openstack-dev] [keystone] Colleen Murphy for core

Hey folks, During today's keystone meeting we added another member to keystone's core team. For several releases, Colleen's had a profound impact on keystone. Her reviews are meticulous and of incredible quality. She has no hesitation to jump into keystone's most confusing realms and as a result

[openstack-dev] [keystone] No meeting next week (2017-05-09)

Just a reminder that we won't have a meeting next week since it will be the week of the Forum in Boston. Our next meeting will be on May 16th. See you then! __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [keystone] mascot v2.0

to bump up the timeline for this and add Heidi to the thread. That way she is aware of any feedback we want to give. If we don't have any feedback by tomorrow, we will default to the mascot we already have. Thanks! On Mon, Apr 24, 2017 at 9:13 AM, Lance Bragstad <lbrags...@gmail.com> wrote: &

[openstack-dev] [keystone] forum session etherpads

Hi all, I've created the etherpads for our sessions and linked them to the wiki [0]. I've bootstrapped them with basic content and they are ready to be bookmarked! If you'd like to help flesh out the agendas for any of those sessions, just ping me. Thanks! [0]

Re: [openstack-dev] [nova][oslo.utils] Bug-1680130 Check validation of UUID length

We had to do similar things in keystone in order to validate uuid-ish types (just not as fancy) [0] [1]. If we didn't have to worry about being backwards compatible with non-uuid formats, it would be awesome to have one implementation for checking that. [0]

[openstack-dev] [keystone] mascot v2.0

Based on some feedback of the original mascot, the Foundation passed along another revision that incorporates a keyhole into the turtle shell. There are two versions [0] [1]. We can choose to adopt one of the new formats, or stick with the one we already have. I have it on our agenda for

[openstack-dev] [keystone][horizon] weekly meeting

Happy Thursday folks, Rob and I have noticed that the weekly attendance for the Keystone/Horizon [0] meeting has dropped significantly in the last month or two. We contemplated changing the frequency of this meeting to be monthly instead of weekly. We still think it is important to have a sync

[openstack-dev] [keystone] pike-1 release

I've proposed keystone's pike-1 release [0]. If there is anything that we need to wait on for pike-1 that hasn't merged yet, please let me know at your earliest convenience. [0] https://review.openstack.org/#/c/456319/ __

[openstack-dev] [keystone] policy meeting 2017-4-12

Just a reminder that we will be having the policy meeting in 45 minutes in #openstack-meeting-cp [0]. It was cancelled last week due to tight schedules. See you there! [0] https://etherpad.openstack.org/p/keystone-policy-meeting

Re: [openstack-dev] [keystone] Adding foreign keys between subsystems

On Wed, Apr 12, 2017 at 9:28 AM, David Stanek wrote: > [tl;dr I want to remove the artificial restriction of not allowing FKs > between > subsystems and I want to stop FK enforcement in code.] > > The keystone code architecture is pretty simple. The data and > functionality

Re: [openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

On Wed, Apr 12, 2017 at 9:42 AM, Amrith Kumar wrote: > Hmm, all the cool kids didn’t receive the email but I did. Now I feel bad > ☹ > > > > -amrith > > > > *From:* Morgan Fainberg [mailto:morgan.fainb...@gmail.com] > *Sent:* Wednesday, April 12, 2017 9:53 AM > *To:*

[Openstack-operators] [keystone] in-code policy

Hey operators, I wanted to send out a friendly reminder that keystone's policy has been moved into code [0]. Sample policy files can be generated using oslopolicy tooling [1], and duplicate policies can be removed from policy files, making maintenance a little easier. We're still working through

Re: [openstack-dev] [nova][api] quota-class-show not sync to quota-show

On Tue, Apr 11, 2017 at 1:21 PM, Matt Riedemann wrote: > On 4/11/2017 2:52 AM, Alex Xu wrote: > >> We talked about remove the quota-class API for multiple times >> (http://lists.openstack.org/pipermail/openstack-dev/2016-July/099218.html >> ) >> >> I guess we can deprecate

Re: [Openstack-operators] FW: [quotas] Unified Limits Conceptual Spec RFC

Sending out a heads up that the initial spec [0] merged. [0] https://review.openstack.org/#/c/440815/ On Thu, Mar 30, 2017 at 1:44 PM, Tim Bell wrote: > > For those that are interested in nested quotas, there is proposal on how > to address this forming in openstack-dev (and

Re: [openstack-dev] [Openstack-operators] FW: [quotas] Unified Limits Conceptual Spec RFC

Sending out a heads up that the initial spec [0] merged. [0] https://review.openstack.org/#/c/440815/ On Thu, Mar 30, 2017 at 1:44 PM, Tim Bell wrote: > > For those that are interested in nested quotas, there is proposal on how > to address this forming in openstack-dev (and

Re: [openstack-dev] [policy][nova][keystone] policy meeting next week

they've found useful for RBAC discussions, feel free to drop them here. [0] http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf On Wed, Apr 5, 2017 at 4:45 PM, Lance Bragstad <lbrags...@gmail.com> wrote: > We ended up cancelling today's policy meeting, but policy discussions

[openstack-dev] [keystone] rejoining our IRC channel

If you chill in #openstack-keystone, we had a little mishap today that resulted in people getting accidentally kicked from the channel. Everything is back to normal and if you haven't already done so, feel free to hop back in. Thanks!

[openstack-dev] [policy][nova][keystone] policy meeting next week

We ended up cancelling today's policy meeting, but policy discussions carried on throughout the day in #openstack-keystone [0]. We have several specs up for review [1][2][3][4]. Some are nova specs and a couple are proposed to keystone. With keystone's spec proposal freeze coming up next week [5],

[openstack-dev] [keystone] broken python35 job due to webob compatibility issues

The keystone gate is currently broken [0]. This seems related to a previous change we made to be compatible with webob 1.7 [1]. Looks like we missed a couple spots in the original patch that are failing now that we're using a newer version of webob. There is a solution up for review [2] that

Re: [openstack-dev] [requirements] pycrypto is dead, long live pycryptodome... or cryptography...

/keystonemiddleware/+bug/1677308 On Wed, Mar 29, 2017 at 10:41 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > With pycrypto removed from keystoneauth [0] (thanks Brant, Monty, and > Morgan!), I did some poking at the usage in keystonemiddleware [1]. > > The usage is built into aut

Re: [openstack-dev] [requirements] pycrypto is dead, long live pycryptodome... or cryptography...

With pycrypto removed from keystoneauth [0] (thanks Brant, Monty, and Morgan!), I did some poking at the usage in keystonemiddleware [1]. The usage is built into auth_token middleware for encrypting and decrypting things stored in cache [2], but it is conditional based on configuration [3] and

[openstack-dev] [keystone] No policy meeting today

Hey folks, The schedule for today's meeting is pretty empty [0] so we will go ahead and cancel. There are several policy patches in keystone and nova that are working their way through review. Instead of meeting, a better use of that time might be reviewing what we have in the pipeline (detailed

[openstack-dev] [keystone] [all] [tc] OpenStack mission review request

The TC meeting today [0] had some discussion on an interpretation of OpenStack's mission statement [1]. The purpose of this note is two-fold. First, it would be great to get some keystone folks to review that change, especially paragraph four. Second, is an overall request for any last minute

Re: [openstack-dev] [requirements][keystone][glance] WebOb

Following up again. Today we merged the fixes for some WebOb 1.7 compatibility issues we were having [0]. Thanks to David (dstanek) and John (jdennis) for digging in and getting this squared away. [0] https://review.openstack.org/#/c/422234/ On Wed, Mar 22, 2017 at 1:37 PM, Lance Bragstad

Re: [openstack-dev] [requirements][keystone][glance] WebOb

Posting a keystone update here as well. We are iterating on it in review as well as in IRC. There are a few things we're doing within keystone that raised some questions as to how we should handle some of the new changes in WebOb. I'll post another update once we make some more progress. On Wed,

Re: [openstack-dev] [all][ptl] Action required ! - Please submit Boston Forum sessions before April 2nd

I have a couple questions in addition to Matt's. The keystone group is still trying to figure out what this means for us and we discussed it in today's meeting [0]. Based on early feedback, we're going to have less developer presence at the Forum than we did at the PTG. Are these formal sessions

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

On Thu, Mar 16, 2017 at 4:31 PM, John Dickinson <m...@not.mn> wrote: > > > On 16 Mar 2017, at 14:10, Lance Bragstad wrote: > > Hey folks, > > The reseller use case [0] has been popping up frequently in various > discussions [1], including unified limits. &g

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

ther up or down the tree? If not, would it be a nice-to-have? > > Thanks, > Kevin > > ------ > *From:* Lance Bragstad [lbrags...@gmail.com] > *Sent:* Thursday, March 16, 2017 2:10 PM > *To:* OpenStack Development Mailing List (not for usage questi

[openstack-dev] [keystone][all] Reseller - do we need it?

Hey folks, The reseller use case [0] has been popping up frequently in various discussions [1], including unified limits. For those who are unfamiliar with the reseller concept, it came out of early discussions regarding hierarchical multi-tenancy (HMT). It essentially allows a certain level of

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

gt; On Thu, Mar 16, 2017 at 12:45 PM, Lance Bragstad <lbrags...@gmail.com> > wrote: > > 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

<    1   2   3   4   5   6   >