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-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-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-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-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:*

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

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

<    1   2   3   4   5   >