[openstack-dev] Unsubscribe

> On 5 Jun 2018, at 14:56, Eric Fried wrote: > > To summarize: cyborg could model things nested-wise, but there would be > no way to schedule them yet. > > Couple of clarifications inline. > > On 06/05/2018 08:29 AM, Jay Pipes wrote: >> On 06/05/2018 08:50 AM, Stephen Finucane wrote: >>> I th

[openstack-dev] [keystone] Signing off

Hi   It is with a somewhat heavy heart that I have decided that it is time to hang up my keystone core status. Having been involved since the closing stages of Folsom, I've had a good run! When I look at how far keystone has come since the v2 days, it is remarkable - and we should all feel a sense

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

Congratulations, Colleen - well deserved. Henry > On 2 May 2017, at 19:15, Lance Bragstad wrote: > > 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 meticulou

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

isting openstack > deployment. Domain per reseller (reseller as domain admin) and sub-domain per > reseller customer (as sub-domain admin) I'm interested in! > > > > On 17 Mar. 2017 10:27 pm, Henry Nash wrote: > OK, so I worked on the original spec for this in

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

OK, so I worked on the original spec for this in Keystone, based around real world requirements we (IBM) saw. For the record, here’s the particular goal we wanted to achieve: 1) A cloud owner (i.e. the enterprise owns and maintains the core of the cloud), wants to attract more traffic by using

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

Thanks, Guang, for your valuable contributions. Henry > On 2 Feb 2017, at 05:13, Steve Martinelli wrote: > > Due to inactivity and a change in his day job, Guang was informed that he > would be removed from keystone-core, a change he understands and supports. > > I'd like to publicly thank Gua

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

Echoing the comments of others. - thanks for all your hard work and expertise. Henry > On 23 Nov 2016, at 15:05, Lance Bragstad wrote: > > 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

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

Steve, It’s been a pleasure working with you as PTL - an excellent tenure. Enjoy taking some time back! Henry > On 21 Nov 2016, at 19:38, Steve Martinelli wrote: > > one of these days i'll learn how to spell :) > > On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli

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

have code that can work on different DB versions (either explicitly or via versioned objects), or you hide the schema changes by “data synchronisation via Triggers”, which is where this whole thread came from. Henry > On 14 Sep 2016, at 23:08, Jay Pipes wrote: > > On 09/01/2016 05:29

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

Welcome, Ron! Henry > On 1 Sep 2016, at 15:44, 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 feature work > for shadowing LDAP and federated users, as well as enhancing

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

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

Re: [openstack-dev] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

Hi Matt, So the keystone changes were intentional. From Mitaka onwards, a domain is represented as a project which is “acting as a domain” (it has an attribute “is_domain” set to true). The situation you describe, where what were top level projects now have the project acting as the default dom

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

at 16:22, Morgan Fainberg wrote: > > On Jun 14, 2016 00:46, "Henry Nash" <mailto:henryna...@mac.com>> wrote: > > >> On 14 Jun 2016, at 07:34, Morgan Fainberg > <mailto:morgan.fainb...@gmail.com>> wrote: >> >> >> >> On Mon, J

Re: [openstack-dev] Version header for OpenStack microversion support

ev.html> > Keystone can follow the cross project spec and use the service type (Identity > instead of Keystone). > > On Jun 17, 2016 12:44 PM, "Ed Leafe" mailto:e...@leafe.com>> > wrote: > On Jun 17, 2016, at 11:29 AM, Henry Nash <mailto:henryna...@mac.

[openstack-dev] Version header for OpenStack microversion support

Hi We are currently in the process of implementing microversion support in keystone - and are obviously trying to follow the cross-projec spec for this (http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html

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

> On 14 Jun 2016, at 07:34, Morgan Fainberg wrote: > > > > On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash <mailto:henryna...@mac.com>> wrote: > So, I think it depends what level of compatibility we are aiming at. Let me > articulate them, and we can agree which we

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

ines ‘name’ to always be a full path. Henry > On 10 Jun 2016, at 18:48, Morgan Fainberg wrote: > > > > On Fri, Jun 10, 2016 at 6:37 AM, Henry Nash <mailto:henryna...@mac.com>> wrote: > On further reflection, it seems to me that we can never simply enable either &

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

solution (and there is no particular advantage with the hierarchical naming approach) - and (until the end of the deprecation) there is no break to the existing API. Henry > On 7 Jun 2016, at 09:47, Henry Nash wrote: > > OK, so thanks for the feedback - understand the message. > > Ho

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

; > <mailto:lbrags...@gmail.com> >> <mailto:lbrags...@gmail.com <mailto:lbrags...@gmail.com>>> wrote: >>> >>> >>> >>> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash >> <mailto:henryna...@mac.com> >> <mailto:henryna...@mac.

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

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

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

> On 3 Jun 2016, at 16:38, Lance Bragstad wrote: > > > > On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <mailto:henryna...@mac.com>> wrote: > >> On 3 Jun 2016, at 01:22, Adam Young > <mailto:ayo...@redhat.com>> wrote: >> >> On 06/02/201

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

> 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 names in Newton. The goal of this is to better support

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

Hi As you know, I have been working on specs that change the way we handle the uniqueness of project names in Newton. The goal of this is to better support project hierarchies, which as they stand today are restrictive in that all project names within a domain must be unique, irrespective of wh

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

Congratulations - thanks for your continued commitment to OpenStack and keystone. Henry > On 25 May 2016, at 23:58, Rodrigo Duarte wrote: > > Thank you all, it's a privilege to be part of a team from where I've learned > so much. =) > >> On Wed, May 25, 2016 at 1:05 PM, Brad Topol wrote: >

Re: [openstack-dev] [keystone][api][v3]

Oops "uncooked"! I meant unscoped! (thank you Apple's auto-correct spell checker!) Sent from my iPad > On 11 May 2016, at 10:25, Henry Nash wrote: > > Hi > > This depends on the policy rule for the get_user call - which is defined by > your policy.json file

Re: [openstack-dev] [keystone][api][v3]

Hi This depends on the policy rule for the get_user call - which is defined by your policy.json file for your keystone. In the default one supplied you need admin to do this, unlike change password where the owner (I.e. A user with an uncooked token) can execute. You could change my the rule f

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

Hi Morgan, Great to be planning this ahead of time!!! For me either of the July dates are fine - I would have a problem with the June date. Henry > On 14 Apr 2016, at 14:57, Dolph Mathews wrote: > > On Wed, Apr 13, 2016 at 9:07 PM, Morgan Fainberg > wrote: >

Re: [openstack-dev] [all] A proposal to separate the design summit

> On 22 Feb 2016, at 17:45, Thierry Carrez wrote: > > Amrith Kumar wrote: >> [...] >> As a result of this proposal, there will still be four events each year, two >> "OpenStack Summit" events and two "MidCycle" events. > > Actually, the OpenStack summit becomes the midcycle event. The new sepa

Re: [openstack-dev] [keystone][cinder] Projects acting as a domain at the top of the project hierarchy

Currently it is the cinder tempest tests that are failing. Thanks Henry > On 2 Feb 2016, at 13:30, Raildo Mascena wrote: > > See responses inline. > > On Mon, Feb 1, 2016 at 6:25 PM Michał Dulko <mailto:michal.du...@intel.com>> wrote: > On 01/30/2016 07:02 PM, He

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On 14 Feb 2016, at 09:53, Henry Nash wrote: > On 13 Feb 2016, at 03:06, Adam Young <mailto:ayo...@redhat.com>> wrote: > > On 02/12/2016 06:17 AM, Eoghan Glynn wrote: >> >>> Hello all, >>> >>> tl;dr >>> = >>>

[openstack-dev] [keystone] Domain Specific Roles vs Local Groups

Hi During the recent keystone midcycle, it was suggested than an alternative domain specific roles (see spec: https://github.com/openstack/keystone-specs/blob/master/specs/mitaka/domain-specific-roles.rst

[openstack-dev] [keystone][nova][cinder][horizon] Projects acting as a domain at the top of the project hierarchy

Hi One of the things the keystone team was planning to merge ahead of milestone-3 of Mitaka, was “projects acting as a domain”. Up until now, domains in keystone have been stored totally separately from projects, even though all projects must be owned by a domain (even tenants created via the k

Re: [openstack-dev] [keystone][cross-project] Standardized role names and policy

> On 30 Jan 2016, at 21:55, Adam Young <mailto:ayo...@redhat.com>> wrote: > > On 01/30/2016 04:14 PM, Henry Nash wrote: >> Hi Adam, >> >> Fully support this kind of approach. >> >> I am still concerned over the scope check, since we do have exa

Re: [openstack-dev] [keystone][cross-project] Standardized role names and policy

Hi Adam, Fully support this kind of approach. I am still concerned over the scope check, since we do have examples of when there is more than one (target) scope check, e.g.: an API that might operate on an object that maybe global, domain or project specific - in which case you need to “match

Re: [openstack-dev] [Keystone][Tempest] OS-INHERIT APIs were skipped by Jenkins because "os_inherit" in keystone.conf was disable.

Hi Maho, So in the keystone unit tests, we flip the os_inherit flag back and forth during tests to make sure it is honored correctly. For the tempest case, I don’t think you need to do that level of testing. Setting the os_inherit flag to true will have no effect if you have not created any ro

Re: [openstack-dev] [keystone] Diagnostic APIs for Keystone

Some good ideas here, Adam. I would think that some of the real “diagnostic APIs” might only be available via keystone-manage, rather than an exposed API. Henry > On 24 Nov 2015, at 03:07, Adam Young wrote: > > Figuring out what is or is not going to work when a user tries to perform an > ope

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

-company approval helps us overall, and so I’m comfortable and support with the existing approach. Henry > On 24 Nov 2015, at 09:06, Henry Nash wrote: > > Good, wide ranging discussion. > > From my point of view, this isn’t about trusting cores, rather (as was > pointed out b

[openstack-dev] [keystone] HMT/Reseller - The Proposed Plan

Hi During our IRC meeting this week, we decided we needed a recap of this plan, so here goes: Phase 0 (already merged in Liberty): We already support a hierarchy of projects (using the parent_id attribute of the project entity). All the projects in a tree must be in the same domain. Role assi

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

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

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

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

[openstack-dev] [keystone] Update on Reseller

Hi At the design summit we have had a number of discussions on how to complete the reseller functionality (original spec: https://review.openstack.org/#/c/139824 ). We all agreed that we should split the implementation into: 1) Refactor the way domains

Re: [openstack-dev] [keystone] PTL non-candidacy

Gotta add my thanks as well…as I’m sure Dolph will attest, it’s a tough job - and we’ve been lucky to have people who have been prepared to put in the really significant effort that is required to make both the role and the project successful! To infinity and beyond…. Henry > On 11 Sep 2015,

[openstack-dev] FFE Request for moving inherited assignment to core in Keystone

Keystone has, for a number of releases, supported the concept of inherited role assignments via the OS-INHERIT extension. At the Keystone mid-cycle we agreed moving this to core this was a good target for Liberty, but this was held by needing the data driver testing to be in place (https://re

Re: [openstack-dev] FFE Request for completion of data driven assignment testing in Keystone

Great, thanks. Henry > On 4 Sep 2015, at 09:17, Thierry Carrez wrote: > > Morgan Fainberg wrote: >> >>>I would like to request an FFE for the remaining two patches that >>>are already in review >>>(https://review.openstack.org/#/c/153897/ and >>> https://review.openstack.org/#/c/15

[openstack-dev] FFE Request for list role assignment in tree blueprint in Keystone

The approved Keystone blueprint (https://review.openstack.org/#/c/187045/ ) was held up during the Liberty cycles by needing the data driver testing to be in place (https://review.openstack.org/#/c/190996/ ).

[openstack-dev] FFE Request for completion of data driven assignment testing in Keystone

The approved Keystone Blueprint (https://review.openstack.org/#/c/190996/ ) for enhancing our testing of the assignment backend was split into 7 patches. 5 of these landed before the liberty-3 freeze, but two had not yet been approved. I would like to r

[openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

Hi With keystone, we recently came across an issue in terms of the assumptions that the openstack client is making about the entities it can show - namely that is assumes all entries have a ‘name’ attribute (which is how the "openstack show" command works). Turns out, that not all keystone enti

Re: [openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities

So I was one of the keystone folks who looked at pagination (hell, I even had an implementation - and the framework for it still exists in keystone). However, I think it is true to say that there were as many people (external to keystone) who thought pagination was a bad idea, as thought it was

Re: [openstack-dev] Hyper-V 2008 R2 support

Hi So adding a deprecation warning but saying the “the code is there but not tested” in Liberty isn’t really doing it right. The deprecation warning should come in a release where the code is still tested and working (so there is no danger in breaking customers), but they are warned that they

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

Matt, Your hybrid driver seems to be doing something different than what Julian was asking - namely providing some “automatic role assignments” for users stored in LDAP (unless I am not understanding your patch)? I guess you could argue that’s a restricted version of being able to create group

[openstack-dev] [keystone] Request for spec freeze execption

Hi Role assignment inheritance has been an extension in Keystone for a number of cycle. With the introduction of project hierarchies (which also support assignment inheritance), we’d like to move inheritance into core. At the same time as the move to core, we’d like to modify the way inheritan

Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies

So although I am in favor of approving some of this, it isn’t quite clear what portions of “Dynamic Policy” is being asked for an exception? We need to be clear exactly what bps we are taking about here, since there is a lot under that umbrella. Henry > On 13 Jul 2015, at 19:20, Yee, Guang

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

On 5 Jun 2015, at 18:19, Dolph Mathews wrote: > > > On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash <mailto:henry.n...@uk.ibm.com>> wrote: > So I think that GroupID's are actually unique and safesince in the multi > LDAP case we provide an indirection already in Ke

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

I am sure I have missed something along the way, but can someone explain to me why we need this at all. Project names are unique within a domain, with the exception of the project that is acting as its domain (i.e. they can only every be two names clashing in a hierarchy at the domain level and

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

er IDs it > wants, and those might conflict with those of other domains. We have a > workaround for a similar issue with user IDs, but it hasn't been applied to > groups, leaving them quite broken in this scenario. I'd consider this to be > an issue we need to solve in Ke

[openstack-dev] [keystone] On dynamic policy, role hierarchies/groups/sets etc.

We’ve been discussing changes to these areas for a while - and although I think there is general agreement among the keystone cores that we need to change *something*, we’ve been struggling to get agreement on exactly how.. So to try and ground the discussion that will (I am sure) occur in Vanc

Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

Fully support this. I, for one, volunteer to take on a lot of the work needed to clean up any our tests/environment to allow this to a happen. Hardly a month goes by without a fix having to be re-applied to our sql code to get round some problem that didn’t show up in original testing because S

Re: [openstack-dev] [Keystone] Requesting FFE for last few remaining patches for domain configuration SQL support

Rich,Yes, I am adding this ability to the keystone client library and then to osc.HenryOn 17 Mar 2015, at 20:17, Rich Megginson <rmegg...@redhat.com> wrote: On 03/17/2015 01:26 PM, Henry Nash wrote:

[openstack-dev] [Keystone] Requesting FFE for last few remaining patches for domain configuration SQL support

Hi Prior to Kilo, Keystone supported the ability for its Identity backends to be specified on a domain-by-domain basis - primarily so that different domains could be backed by different LDAP servers. In this previous support, you defined the domain-specific configuration options in a separate c

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

So I’m Ok with an exception for this, but still have reservations of the this AE technique (at least the one that is currently proposed). I assume this will be marked as experimental - since we have not formally agreed that this is a standard we want to lock into core? Henry > On 14 Feb 2015, a

Re: [openstack-dev] [Keystone] Proposing Marek Denis for the Keystone Core Team

+1 > On 10 Feb 2015, at 18:04, Dolph Mathews > wrote: > > +1 > > On Tue, Feb 10, 2015 at 11:51 AM, Morgan Fainberg > wrote: > Hi everyone! > > I wanted to propose Marek Denis (marekd on IRC) as a new member of the > Keystone C

[openstack-dev] [Keystone] Splitting up the assignment component

Hi As most of you know, we have approved a spec (https://review.openstack.org/#/c/129397/) to split the assignments component up into two pieces, and the code (divided up into a series of patches) is currently in review (https://review.openstack.org/#/c/130954/). While most aspects of the spli

Re: [openstack-dev] Dynamic Policy

Hi Adam, So a comprehensive write-up...although I'm not sure we have made the case for why we need a complete rewrite of how policy is managed. We seemed to have lept into a solution without looking at other possible solutions to the problems we are trying to solve. Here's a start at an alter

Re: [openstack-dev] [Keystyone] Mid-Cycle Meetup Planning

I'll be there! Henry On 12 Nov 2014, at 02:29, Adam Young wrote: > On 11/11/2014 08:18 PM, Morgan Fainberg wrote: >> I am trying to pin down a location for our mid-cycle meetup, I need to get >> an idea of who will be joining us at the Keystone meetup. I’ve included a >> couple questions relat

Re: [openstack-dev] [keystone] Stepping down as PTL

Agree with all the comments made - Dolph, you really did a great job as PTL - keeping the balanced view is a crucial part of the role. Keystone is the better for it. Henry On 23 Sep 2014, at 17:08, Yee, Guang wrote: > ++ Amen, brother! > > From: Lance Bragstad [mailto:lbrags...@gmail.com]

Re: [openstack-dev] [Keystone] Domain-specific Drivers

Hi It was fully merged for Juno-2 - so if you are having problems, feel free to share the settings in you main config and keystone.heat.config files Henry On 26 Aug 2014, at 10:26, Bruno Luis Dos Santos Bompastor wrote: > Hi folks! > > I would like to know what is the status on the “Domain-s

Re: [openstack-dev] [Keystone] Keystone multi-domain ldap + sql in Icehouse

Hi So the bad news is that you are correct, multi-domain LDAP is not ready in IceHouse (It is marked as experimental.and it has serious flaws). The good news is that this is fixed for Juno - and this support has already been merged - and will be in the Juno milestone 2 release. Here's the

Re: [openstack-dev] REST API access to configuration options

Joe, I'd imagine an API like this would be pretty useful for some of these config tools - so I'd imagine they might well be consumers of this API. Henry On 15 Jul 2014, at 13:10, Joe Gordon wrote: > > > > On Tue, Jul 15, 2014 at 5:00 AM, Henry Nash wrote: > M

Re: [openstack-dev] REST API access to configuration options

serversand this actually becomes more important as people distribute config files around to the various servers (since more chance of something getting out of sync). Henry On 15 Jul 2014, at 10:08, Mark McLoughlin wrote: > On Tue, 2014-07-15 at 08:54 +0100, Henry Nash wrote: >> HI

[openstack-dev] REST API access to configuration options

HI As the number of configuration options increases and OpenStack installations become more complex, the chances of incorrect configuration increases. There is no better way of enabling cloud providers to be able to check the configuration state of an OpenStack service than providing a direct R

[openstack-dev] [keystone] Size of Log files

Hi Our debug log file size is getting pretty hugea typical py26 jenkins run produces a whisker under 50Mb of log - which is problematic for at least the reason that our current jenkins setup consider the test run a failure if the log file is > 50 Mb. (see http://logs.openstack.org/14/7421

Re: [openstack-dev] [all][keystone] Increase of USER_ID length maximum from 64 to 255

Hi Mark, So we would not modify any existing IDs, so no migration required. Henry On 28 Feb 2014, at 17:38, Mark Washenberger wrote: > > > > On Wed, Feb 26, 2014 at 5:25 AM, Dolph Mathews > wrote: > > On Tue, Feb 25, 2014 at 2:38 PM, Jay Pipes wrote: > On Tue, 2014-02-25 at 11:47 -0800,

Re: [openstack-dev] [all][keystone] Increase of USER_ID length maximum from 64 to 255

On 27 Feb 2014, at 17:52, Jay Pipes wrote: > On Thu, 2014-02-27 at 16:13 +0000, Henry Nash wrote: >> So a couple of things about this: >> >> >> 1) Today (and also true for Grizzly and Havana), the user can chose >> what LDAP attribute should be returned as t

Re: [openstack-dev] [all][keystone] Increase of USER_ID length maximum from 64 to 255

So a couple of things about this: 1) Today (and also true for Grizzly and Havana), the user can chose what LDAP attribute should be returned as the user or group ID. So it is NOT a safe assumption today (ignoring any support for domain-specific LDAP support) that the format of a user or group

Re: [openstack-dev] Hierarchicical Multitenancy Discussion

Vish, Excellent idea to discuss this more widely. To your point about domains not being well understood and that most policy files being just "admin or not", the exception here is, of course, keystone itself - where we can use domains to support enable various levels of cloud/domain & project

[openstack-dev] [keystone] Filtering and limiting ready for final reviews

Hi Both Filtering and List Limiting are ready for final review (both were pretty heavily reviewed on the run up to Havana, if you remember, but we decided to pull them): https://review.openstack.org/#/c/43257/ https://review.openstack.org/#/c/44836/ The only debate on list limiting is whether

Re: [openstack-dev] [keystone] domain admin role query

Hi So the idea wasn't the you create a domain with the id of 'domain_admin_id', rather that you create the domain that you plan to use for your admin domain, and then paste its (auto-generated) domain_id into the policy file. Henry On 12 Dec 2013, at 03:11, Paul Belanger wrote: > On 13-12-11

Re: [openstack-dev] Multidomain User Ids

On 4 Dec 2013, at 13:28, Dolph Mathews wrote: > > On Sun, Nov 24, 2013 at 9:39 PM, Adam Young wrote: > The #1 pain point I hear from people in the field is that they need to > consume read only LDAP but have service users in something Keystone > specific. We are close to having this, but w

Re: [openstack-dev] [keystone] design summit outcomes

Hi David, I think that's the wrong table (remembering our conversation!)the role assignment table(s) in keystone today is part of what you would call a mapper table, they don't define the attributes. What I think we agreed was rather than taking one giant lead to the all-encompassing mappe

Re: [openstack-dev] [Nova][Keystone][glance] Keystone V3 Domains and Nova

I think an obvious first step of domain support outside keystone is for images. Today, I believe, an image can be global or project based. There is definitely a use case for a third state of being domain based - and hence available to all projects in that domain, but not to those in other doma

[openstack-dev] [keystone] Case sensitivity & backend databases

Hi Do we specify somewhere whether text field matching in the API is case sensitive or in-sensitive? I'm thinking about filters, as well as user and domain names in authentication. I think our current implementation will always be case sensitive for filters (since we do that in python and do

[openstack-dev] [keystone][horizon]Backend filtering in Keystone

Hi Gabriel, Following up on our discussions on filtering and pagination, here's where we stand: 1) We have a patch ready to go into H that implements a framework that lets the keystone backend drivers implement filters (e.g. would be included in the SQL SELECT rather than being a post-prcessed

Re: [openstack-dev] [keystone] Pagination

So I have started an etherpad to summarize the views expressed over this email chain: https://etherpad.openstack.org/pagination Feel free to add to (and correct) this. Henry On 14 Aug 2013, at 17:25, Mac Innes, Kiall wrote: > So, Are we saying that UIs built on OpenStack APIs shouldn't be able

Re: [openstack-dev] Difference between RBAC polices thats stored in policy.json and policies that can be created using openstack/identity/v3/policies

Hi Sudheesh, Using v3/policies is just a way of allowing other keystone projects (nova, glance) etc. a place to centrally store/access their policy files. Keystone does not interpret any of the data you store here - it is simply acting as a central repository (where you can store a big blob of

Re: [openstack-dev] [keystone] Pagination

Jay, Thanks for all the various links - most useful. To map this into keystone context, if we were to follow this logic we would: 1) Support 'limit' and 'marker' (as opposed to 'page', 'page_szie', or anything else). These would be standard, independent of what backing store keystone was usin

Re: [openstack-dev] [keystone] Pagination

On 13 Aug 2013, at 16:03, Dolph Mathews wrote: > > On Tue, Aug 13, 2013 at 3:10 AM, Henry Nash wrote: > Hi > > So few comebacks to the various comments: > > 1) While I understand the idea that a client would follow the next/prev links > returned in collections

Re: [openstack-dev] [keystone] Pagination

iltering. > > We have a bug for the second part. I'll open one for the limit. > >> >> Mark >> >> From: Adam Young [mailto:ayo...@redhat.com] >> Sent: Monday, August 12, 2013 5:27 PM >> To: openstack-dev@lists.openstack.org >> Subject: Re

[openstack-dev] [keystone] Pagination

Hi I'm working on extending the pagination into the backends. Right now, we handle the pagination in the v3 controller classand in fact it is disabled right now and we return the whole list irrespective of whether page/per-page is set in the query string, e.g.: def paginate(cls, conte

Re: [openstack-dev] Problem using Keystone split backend

Yep, agreed, certainly my codeif you can provide as much info in the bug as possible, and I'll get straight on it. Henry On 9 Aug 2013, at 00:14, Adam Young wrote: > On 08/08/2013 03:58 PM, Gaspareto, Otavio wrote: >> >> Hi all, >> >> I’m using the Keystone split backend code (H2) with b

Re: [openstack-dev] [Keystone] Validating UUID tokens with V3 API

Hi Jamie, So potentially part of this solution may be one of the blueprints and implementation I am currently working on to allow policy rules to specify fields in the target entity that an API is accessing, see: https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target https://revie

Re: [openstack-dev] Change in openstack/keystone[master]: Implement domain specific Identity backends

4 files changed, 1,028 insertions(+), 372 deletions(-) > > > git pull ssh://review.openstack.org:29418/openstack/keystone > refs/changes/30/39530/12 > -- > To view, visit https://review.openstack.org/39530 > To unsubscribe, visit https://review.openstack.org/settings > > Gerrit-Message

Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core

+1 from me, Morgan would be a great addition. Henry On 6 Aug 2013, at 20:20, Dolph Mathews wrote: > Through feedback on code reviews and blueprints, Morgan clearly has the best > interests of the project itself in mind. I'd love for his votes to carry a > bit more weight! > > https://review.

[openstack-dev] Separate Migration Repos

Hi Adam, Wanted to just give you more detail on the issue I keep pressing on for your change (https://review.openstack.org/#/c/36731/). For extensions which create their own "private" tables, I totally get it. I'd like, however, to understand what happens for a more complex extension. Let's

Re: [openstack-dev] [keystone] Extending policy checking to include target entities

Sorce wrote: > On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote: >> ...the problem is that if the object does not exists we might not be able >> tell whether the use is authorized or not (since authorization might depend >> on attributes of the object itself)so how d

Re: [openstack-dev] [keystone] Extending policy checking to include target entities

> On 23/07/2013 19:02, Henry Nash wrote: >> One thing we could do is: >> >> - Return Forbidden or NotFound if we can determine the correct answer >> - When we can't (i.e. the object doesn't exist), then return NotFound >> unless a new config value 'p

Re: [openstack-dev] [keystone] Extending policy checking to include target entities

urces under domain/66DEADBEEF would show up > as 403s regardless of existantce or not if the user had no roles in the > domain 66DEADBEEF. A user that would be allowed access to resources in > 66DEADBEEF would get a 403 only for an object that existed but that they &

[openstack-dev] [keystone] Extending policy checking to include target entities

Hi As part of bp https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target I have uploaded some example WIP code showing a proposed approach for just a few API calls (one easy, one more complex). I'd appreciate early feedback on this before I take it any further. https://review.op

[openstack-dev] [keystone] New blueprint and implementation to standardize getting role assignments at authentication time

Hi In thinking about how to implement the OS-INHERIT extension as well as planning for simplification in iceHouse of all our backend grants tables, I realized we needed to rationalise the various different methodologies for getting the list of roles in the token/auth controllers (v2 local is di

Re: [openstack-dev] [keystone] More on inherited domain roles

ather an implementation detail worth > considering now. > > This would be consistent with the token revocation approach, where we make > the effort to revoke all tokens at the time of the event. > > > > On 06/13/2013 09:49 AM, Henry Nash wrote: >> Thanks

Re: [openstack-dev] [keystone] Inherited domain roles

; be, but you have the entire virtual space covered. > > Thinking to the future, an alternative model is to have global hierarchical > role names (domain.role, domain.project.role) and to assign the role *.*.role > to someone now. > > regards > > David > > On 19/06/2

  1   2   >