[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

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

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

our existing 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 <henryna...@mac.com> wrote: > OK, so I worked on the

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

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

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

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

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

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

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

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

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

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

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

ocs.openstack.org/developer/manila/devref/api_microversion_dev.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" <e...@leafe.com <mailto:e...@leafe.com>> >

[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 <morgan.fainb...@gmail.com> wrote: > > > > On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash <henryna...@mac.com > <mailto:henryna...@mac.com>> wrote: > So, I think it depends what level of compatibility we are aimin

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

> On 10 Jun 2016, at 18:48, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > > On Fri, Jun 10, 2016 at 6:37 AM, Henry Nash <henryna...@mac.com > <mailto:henryna...@mac.com>> wrote: > On further reflection, it seems to me that we can never simp

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 <henryna...@mac.com> wrote: > > OK, so thanks for the feedback - underst

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

e Bragstad" <lbrags...@gmail.com >> <mailto:lbrags...@gmail.com> >> <mailto:lbrags...@gmail.com <mailto:lbrags...@gmail.com>>> wrote: >>> >>> >>> >>> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash <henry

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

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

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

> On 3 Jun 2016, at 16:38, Lance Bragstad <lbrags...@gmail.com> wrote: > > > > On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <henryna...@mac.com > <mailto:henryna...@mac.com>> wrote: > >> On 3 Jun 2016, at 01:22, Adam Young <ayo...@redhat.com &g

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

> On 3 Jun 2016, at 01:22, Adam Young <ayo...@redhat.com> 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 o

[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

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

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 <henryna...@mac.com> wrote: > > Hi > > This depends on the policy rule for the get_user call - which is defined by &

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

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

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

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

..@intel.com>> wrote: > On 01/30/2016 07:02 PM, Henry Nash wrote: > > 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 b

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

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

[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

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][cross-project] Standardized role names and policy

> On 30 Jan 2016, at 21:55, Adam Young <ayo...@redhat.com > <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 o

[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

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

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 <henry.n...@icloud.com> wrote: > > Good, wide ranging discussion. > > From my point of view, this isn’t about trusting cores, rather (

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

[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

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,

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

[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

[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

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

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

[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

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

Jun 2015, at 18:19, Dolph Mathews dolph.math...@gmail.com wrote: On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash henry.n...@uk.ibm.com 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

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

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

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 Keystone, though, not something other projects need to worry about. I'm hoping Henry Nash can chime in and correct me! Thanks, John From

[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

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

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

[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

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,

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

+1 On 10 Feb 2015, at 18:04, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: +1 On Tue, Feb 10, 2015 at 11:51 AM, Morgan Fainberg morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote: Hi everyone! I wanted to propose Marek Denis (marekd on

[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

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

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

I'll be there! Henry On 12 Nov 2014, at 02:29, Adam Young ayo...@redhat.com 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

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 guang@hp.com wrote: ++ Amen, brother! From: Lance Bragstad

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 bruno.bompas...@cern.ch wrote: Hi folks! I would like to know what is the

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

[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

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

of the 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 mar...@redhat.com wrote: On Tue, 2014-07-15 at 08:54 +0100, Henry Nash wrote

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 joe.gord...@gmail.com wrote: On Tue, Jul 15, 2014 at 5:00 AM, Henry Nash hen

[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

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 mark.washenber...@markwash.net wrote: On Wed, Feb 26, 2014 at 5:25 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Tue, Feb 25, 2014 at 2:38 PM, Jay

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] [all][keystone] Increase of USER_ID length maximum from 64 to 255

On 27 Feb 2014, at 17:52, Jay Pipes jaypi...@gmail.com wrote: On Thu, 2014-02-27 at 16:13 +, 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 the user or group ID. So

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

Re: [openstack-dev] Multidomain User Ids

On 4 Dec 2013, at 13:28, Dolph Mathews dolph.math...@gmail.com wrote: On Sun, Nov 24, 2013 at 9:39 PM, Adam Young ayo...@redhat.com 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.

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

[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

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

Re: [openstack-dev] [keystone] Pagination

, August 12, 2013 5:27 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone] Pagination On 08/12/2013 05:34 PM, Henry Nash wrote: Hi I'm working on extending the pagination into the backends. Right now, we handle the pagination in the v3 controller class

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

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

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 both

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

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!

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

/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I489e8e50035f88eca4235908ae8b1a532645daab Gerrit-PatchSet: 12 Gerrit-Project: openstack/keystone Gerrit-Branch: master Gerrit-Owner: henry-nash hen...@linux.vnet.ibm.com Gerrit-Reviewer: Brant Knudson bknud...@us.ibm.com Gerrit

[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

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 do we know wether to lie

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

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

in 66DEADBEEF would get a 403 only for an object that existed but that they had no permission to read, and 404 for a resource that doesn't exist. regards David On 23/07/2013 16:40, Henry Nash wrote: Hi As part of bp https://blueprints.launchpad.net/keystone

[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

Re: [openstack-dev] [keystone] Inherited domain roles: Options for Havana and beyond

we should go with option a (role-assignment as a first class citizen) which seems correct to me, looking in to time constraint, option 'b' is OK as an EXTENSION but SHOULD NOT BE implemented as part of core API. Thoughts??? Arvind -Original Message- From: Henry Nash