Re: [openstack-dev] [keystone] [keystoneauth] Debug data isn't sanitized - bug 1638978

Another option, pass log=False which we currently do for all the auth requests. This will prevent debug printing the body at all, so con, by default you can't see that message, but it's there because I never wanted to mess around with masking individual service's secrets like this. On 29 Sep.

[openstack-dev] [keystone][zuul] A Sad Farewell

summit and will catch up with some of you there, and hopefully see some of you at linux.conf.au. To everyone else, thank you and I hope we'll meet again. Jamie Lennox, Stacker. __ OpenStack Development Mailing List

Re: [openstack-dev] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

On 16 June 2017 at 00:44, Mikhail Fedosin wrote: > Thanks György! > > On Thu, Jun 15, 2017 at 1:55 PM, Gyorgy Szombathelyi doclerholding.com> wrote: > >> Hi Mikhail, >> >> (I'm not from the Keystone team, but did some patches for using >>

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

On 27 February 2017 at 08:56, Sean Dague wrote: > We recently implemented a Nova feature around validating that project_id > for quotas we real in keystone. After that merged, trippleo builds > started to fail because their undercloud did not specify the 'identity' > service as

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

Congrats Boris, Great to have new people on board. Well earned. On 1 November 2016 at 15:53, Brad Topol wrote: > Congratulations Boris!!! Very well deserved!!! > > --Brad > > > Brad Topol, Ph.D. > IBM Distinguished Engineer > OpenStack > (919) 543-0646 > Internet:

Re: [openstack-dev] [osc] bug/design flaw: Clients not cached per region

On 18 October 2016 at 12:09, Dean Troyer wrote: > On Mon, Oct 17, 2016 at 5:29 PM, Adrian Turjak > wrote: > > What I'm wondering is can the current client cache be changed to be keyed > > off the client_manager.region_name? That way the change is only

Re: [openstack-dev] [keystone] keystoneclient.client.v3.Client: extract identity endpoint

On 13 October 2016 at 23:19, Johannes Grassler wrote: > Hello, > > I've got an existing keystoneclient.client.v3.Client object with an > authenticated session. Now I'd like to get the identity URL this > object uses for requesting things from Keystone. I want to use that > URL

Re: [openstack-dev] requests-mock

On 11 October 2016 at 16:23, Clay Gerrard wrote: > Greetings! > > Anyone have any experience to share positive or negative using > requests-mock? I see it's been used to replace another dependency that had > some problems in many of the OpenStack python client libraries:

Re: [openstack-dev] [cue][qa] Status of OpenStack CI jobs

Cue failing on oslo.context was noticed by the oslo gate jobs a while ago. These patches [1][2][3] were put up to cue to fix the issue and cleanup the context usage on 2016/07/22 and have not seen a review. [1] https://review.openstack.org/#/c/345693 [2] https://review.openstack.org/#/c/345694

Re: [openstack-dev] [keystone][oslo][release][requirements][FFE] global-requirements update to positional to 1.1.1

On 8 September 2016 at 11:29, Tony Breeds wrote: > On Wed, Sep 07, 2016 at 08:10:45AM -0500, Matthew Thode wrote: > > https://review.openstack.org/366631 > > > > The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the > > current minimum requirement)

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

Congratulations Ron. Welcome aboard. On 3 September 2016 at 04:13, Brad Topol wrote: > Shh! Let them get the leg irons welded shut on him first :-). Pay no > attention Ron... Congratulations! > > > Brad Topol, Ph.D. > IBM Distinguished Engineer > OpenStack > (919)

Re: [openstack-dev] [oslo][nova][requirements] Getting oslo.context 2.6.0 into the gate

On 27 July 2016 at 19:10, Tony Breeds wrote: > On Mon, Jul 18, 2016 at 04:09:54PM +0200, Markus Zoeller wrote: > > Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed > > change [2] is not yet in place, which broke "gate-nova-python27-db"[3]. > > Logstash

Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

On 20 July 2016 at 00:06, Joshua Harlow wrote: > Hayes, Graham wrote: > >> On 18/07/16 22:27, Ronald Bradford wrote: >> >>> Hi All, >>> >>> For Oslo libraries we ensure that API's are backward compatible for 1+ >>> releases. >>> When an Oslo API adds a new class attribute

Re: [openstack-dev] [Openstack] Naming polls - and some issues

Partially because its name is Circular Quay, so it would be like calling the S release Street for Street. Having said that there are not that many of them and Sydney people know what you mean when you are going to the Quay. On 14 July 2016 at 21:35, Neil Jerram wrote: > Not

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

On 4 July 2016 at 19:58, Julien Danjou wrote: > On Mon, Jul 04 2016, Denis Makogon wrote: > > > What would be the best place to submit spec? > > The cross project spec repo? > > https://git.openstack.org/cgit/openstack/openstack-specs/ > > -- > Julien Danjou > /* Free

Re: [openstack-dev] [keystone][openid][mistral] Enabling OpenID Connect authentication w/o federation

On 23 June 2016 at 21:30, Renat Akhmerov wrote: > Hi, > > I’m looking for some hints on how to enable authentication via OpenID > Connect protocol, particularly in Mistral. Actually, specific protocol is > not so important. I’m mostly interested in conceptional vision

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

> service : for service users only, not real > humans > {service_type}_admin : identity_admin, compute_admin, > network_admin etc. > {service_type}_{api_resource}_manager: identity_user_manager, >

Re: [openstack-dev] Troubleshooting and ask.openstack.org

On 29 June 2016 at 09:49, Steve Martinelli wrote: > I think we want something a bit more organized. > > Morgan tossed the idea of a keystone-docs repo, which could have: > > - The FAQ Adam is asking about > - Install guides (moved over from openstack-manuals) > - A spot

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

On 21 June 2016 at 11:41, Edward Leafe wrote: > On Jun 18, 2016, at 9:03 AM, Clint Byrum wrote: > > > Whatever API version is used behind the compute API is none of the user's > > business. > > Actually, yeah, it is. > > If I write an app or a tool that expects

Re: [openstack-dev] [keystone][security] Service User Permissions

On 20 June 2016 at 12:33, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > On Sun, Jun 19, 2016 at 6:51 PM, Adam Young <ayo...@redhat.com> wrote: > >> On 06/16/2016 02:19 AM, Jamie Lennox wrote: >> >> Thanks everyone for your input. >&

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

Quick question: why do we need the service type or name in there? You really should know what API you're talking to already and it's just something that makes it more difficult to handle all the different APIs in a common way. On Jun 18, 2016 8:25 PM, "Steve Martinelli"

Re: [openstack-dev] [keystone][security] Service User Permissions

Thanks everyone for your input. I generally agree that there is something that doesn't quite feel right about purely trusting this information to be passed from service to service, this is why i was keen for outside input and I have been rethinking the approach. To this end i've proposed

Re: [openstack-dev] Fwd: keystone federation user story

On 25 May 2016 at 03:55, Alexander Makarov wrote: > Colleagues, > > here is an actual use case for shadow users assignments, let's discuss > possible solutions: all suggestions are appreciated. > > -- Forwarded message -- > From: Andrey Grebennikov

Re: [openstack-dev] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps

On 13 May 2016 at 04:15, Sean Dague wrote: > On 05/12/2016 01:47 PM, Morgan Fainberg wrote: > > This also comes back to the conversation at the summit. We need to > > propose the timeline to turn over for V3 (regardless of > > voting/non-voting today) so that it is possible to

Re: [openstack-dev] [Keystone][Nova] Any Code Examples of Other Services Using Keystone Policy?

I don't see that we need a new role for this because it would need to be added to all the admin users. I was thinking just admin or target.project_id==token.project_id. Hopefully in future this would get better because we can get nova to send the service token as well and enforce that it came from

Re: [openstack-dev] [keystone] Keystone commands

On 20 April 2016 at 14:02, Dolph Mathews wrote: > On Tue, Apr 19, 2016 at 10:40 PM, Kenny Ji-work > wrote: > >> Hi all, >> >> I have installed openstack mitaka, when I execute any keystone's commands >> with the result displayed below: >> But I

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 20 April 2016 at 04:17, Monty Taylor wrote: > On 04/19/2016 10:16 AM, Daniel P. Berrange wrote: > >> On Tue, Apr 19, 2016 at 09:57:56AM -0500, Dean Troyer wrote: >> >>> On Tue, Apr 19, 2016 at 9:06 AM, Adam Young wrote: >>> >>> I wonder how much of

Re: [openstack-dev] [oslo] oslo.context and name fields

from_environ was mine, it's reasonably new and at the time i was blocked upon getting a release before pushing it out to services. Since then i've been distracted with other things. The intent at the time was exactly this to standardize the values on the context object, though in my case i was

Re: [openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests

On 2 April 2016 at 09:21, Rodrigo Duarte wrote: > > > On Thu, Mar 31, 2016 at 1:11 PM, Matthew Treinish > wrote: > >> On Thu, Mar 31, 2016 at 11:38:55AM -0400, Minying Lu wrote: >> > Hi all, >> > >> > I'm working on resource federation at the

Re: [openstack-dev] [keystone] [horizon] [qa] keystone versionless endpoints and v3

/287532/ [2] https://review.openstack.org/#/c/285879/ On 9 March 2016 at 10:21, Matt Fischer <m...@mattfischer.com> wrote: > On Tue, Feb 23, 2016 at 8:49 PM, Jamie Lennox <jamielen...@gmail.com> > wrote: > >> >> >> On 18 February 2016 at 10:50, Matt Fischer &l

Re: [openstack-dev] [openstack][keystone] What is the difference between auth_url and auth_uri?

This is an unfortunate naming scheme that is a long story. Simple version is: auth_url is what the auth plugin is using, so where the process will authenticate to before it authenticates tokens, probably an internal url. auth_uri is what ends up in the WWW-Authenticate: keystone-uri= header and

Re: [openstack-dev] [nova] python-novaclient region setting

On 23 February 2016 at 01:02, Monty Taylor wrote: > On 02/21/2016 11:40 PM, Andrey Kurilin wrote: > >> Hi! >> `novaclient.client.Client` entry-point supports almost the same >> arguments as `novaclient.v2.client.Client`. The difference is only in >> api_version, so you can

Re: [openstack-dev] [keystone] [horizon] [qa] keystone versionless endpoints and v3

On 18 February 2016 at 10:50, Matt Fischer wrote: > I've been having some issues with keystone v3 and versionless endpoints > and I'd like to know what's expected to work exactly in Liberty and beyond. > I thought with v3 we used versionless endpoints but it seems to cause

Re: [openstack-dev] [keystone] Addressing issue of keysone token expiry during long running operations

Hey Paul, At the Tokyo summit we discussed a general way to make it so that user tokens were only expiration tested once. When the token hits nova for example we can say it was validated, then when nova talks to glance it sends both the user token (or enough data to represent the user token) and

Re: [openstack-dev] [ironic][neutron][keystone] how to reauth the token

On 17 December 2015 at 02:59, Pavlo Shchelokovskyy < pshchelokovs...@mirantis.com> wrote: > Hi all, > > I'd like to start discussion on how Ironic is using Neutron when Keystone > is involved. > > Recently the patch [0] was merged in Ironic to fix a bug when the token > with which to create the

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

On 8 December 2015 at 07:53, Thomas Goirand wrote: > On 12/01/2015 07:57 AM, Steve Martinelli wrote: > > Trying to summarize here... > > > > - There isn't much interest in keeping eventlet around. > > - Folks are OK with running keystone in a WSGI server, but feel they are > >

Re: [openstack-dev] [keystone] Case for renewability of tokens, increasing expiration time

I realize this has been mostly closed up, but just a few additions. On 19 November 2015 at 08:06, Dolph Mathews wrote: > On Tue, Nov 17, 2015 at 2:56 PM, Lindsay Pallickal > wrote: > >> >> >> On Tue, Nov 17, 2015 at 5:31 AM, Dolph Mathews

Re: [openstack-dev] [All] Use of self signed certs in endpoints

On 14 November 2015 at 19:09, Xav Paice wrote: > Hi, > > I'm sure I'm not the only one that likes to use SSL everywhere possible, > and doesn't like to pay for 'real' ssl certs for dev environments. > Figuring out how to get requests to allow connection to the self signed >

Re: [openstack-dev] Help with getting keystone to migrate to Debian testing: fixing repoze.what and friends

On 12 November 2015 at 15:09, Clint Byrum wrote: > Excerpts from Clint Byrum's message of 2015-11-11 10:57:26 -0800: > > Excerpts from Morgan Fainberg's message of 2015-11-10 20:17:12 -0800: > > > On Nov 10, 2015 16:48, "Clint Byrum" wrote: > > > > > > > >

Re: [openstack-dev] [keystone] [puppet] [neutron] Deprecating nova_admin_ options in puppet-neutron

On re-reading the original email i've been thinking of auth_token middleware rather than nova_admin_* options (i haven't done much neutron config). I think everything still applies though and hopefully this can be a mechanism that's reused across modules. On 15 October 2015 at 10:37, Jamie Lennox

Re: [openstack-dev] [keystone] [puppet] [neutron] Deprecating nova_admin_ options in puppet-neutron

TL;DR: you can fairly easily convert existing puppet params into auth plugin format for now, but we're going to need the hash based config soon. I think as a first step it is a good idea to replace the deprecated options and use the password, v2password or v3password plugins* because you will

Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services

So this is a long thread and i may have missed something in it, however this exact topic came up as a blocker on a devstack patch to get TLS testing in the gate with HAproxy. The long term solution we had come up with (but granted not proposed anywhere public) is that we should transition

Re: [openstack-dev] [magnum] keystone pluggable model

- Original Message - > From: "Murali Allada" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Thursday, 10 September, 2015 6:41:40 AM > Subject: [openstack-dev] [magnum] keystone pluggable

Re: [openstack-dev] [keystone]how to get service_catalog

) directly. Jamie [1] https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/session.py#L845 > On Mon, Sep 7, 2015 at 12:54 PM, Jamie Lennox < jamielen...@redhat.com > > wrote: > > - Original Message - > > > > From:

Re: [openstack-dev] [keystone]how to get service_catalog

- Original Message - > From: "王华" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Monday, 7 September, 2015 12:00:43 PM > Subject: [openstack-dev] [keystone]how to get service_catalog > > Hi

Re: [openstack-dev] [Keystone][Glance] keystonemiddleware & multiple keystone endpoints

ailure: Unable > to establish connection to http://172.17.0.95:35357/auth/tokens. Retrying in > 1.0s. > 2015-09-06 07:50:55.576 194 INFO keystoneclient.session [-] Failure: Unable > to establish connection to http://172.17.0.95:35357/auth/tokens. Retrying in > 2.0s. > 2015-

Re: [openstack-dev] [DevStack][Keystone][Ironic][Swit][Barbican] FYI: Defaulting to Keystone v3 API

cting it to merge). However to get this back in I think the easiest thing to do is just set OS_AUTH_VERSION in devstack with a comment about "needed for swift". I think we should consider OS_IDENTITY_API_VERSION an OSC flag rather that something we want all the CLIs to copy (as API_VERSI

Re: [openstack-dev] [DevStack][Keystone][Ironic][Swit][Barbican] FYI: Defaulting to Keystone v3 API

Note that this fixing this does not mean ironic has to support keystone v3 (but please fix that too). It just means that somewhere in ironic's gate it is doing like an "openstack user create" or a role assignment directly with the OSC tool assuming v2 rather than using the helpers that devstack

Re: [openstack-dev] [Keystone][Glance] keystonemiddleware multiple keystone endpoints

- Original Message - From: Hans Feldt hans.fe...@ericsson.com To: openstack-dev@lists.openstack.org Sent: Thursday, August 20, 2015 10:40:28 PM Subject: [openstack-dev] [Keystone][Glance] keystonemiddleware multiple keystone endpoints How do you configure/use

[openstack-dev] [qa][devstack][keystone] Updating devstack to Identity V3

Hi all, I've been pushing for a while now to convert devstack to completely use the identity v3 API as we try to deprecate the v2.0 API. Currently all the functions in functions-common consume the v3 API via setting --os -identity-api-version 3 for each command to override the v2 default.

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

- Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Thursday, 13 August, 2015 3:06:46 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 11/08/2015 01:46, Jamie Lennox wrote: - Original

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

if in future we find we need to add something more complex like tagging it's another option we can consider then. On 06/08/2015 00:54, Jamie Lennox wrote: - Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

- Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 10/08/2015 01:53, Jamie Lennox wrote: - Original

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

- Original Message - From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login

Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares

- Original Message - From: Mehdi Abaakouk sil...@sileht.net To: openstack-dev@lists.openstack.org Sent: Friday, August 7, 2015 1:57:54 AM Subject: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares Hi, I want to share with you some problems I have recently

Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares

- Original Message - From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, August 10, 2015 12:36:14 PM Subject: Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

that the user picked an IDP in horizon and i don't want to do discovery again. regards David On 07/08/2015 01:29, Jamie Lennox wrote: *From: *Dolph Mathews dolph.math...@gmail.com *To: *OpenStack

Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients

- Original Message - From: michael mccune m...@redhat.com To: openstack-dev@lists.openstack.org Sent: Friday, August 7, 2015 1:21:53 AM Subject: Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients On 08/05/2015 10:27 PM, Jamie Lennox wrote

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

- Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 6:25:29 PM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login On 06/08/2015 00:54, Jamie Lennox wrote: - Original

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

6, 2015 at 11:25 AM, Lance Bragstad lbrags...@gmail.com wrote: On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From

Re: [openstack-dev] [keystone] policy issues when generating trusts with different clients

Hey Mike, I think it could be one of the hacks that are in place to try and keep compatibility with the old and new way of using the client is returning the wrong thing. Compare the output of trustor.user_id and trustor_auth.get_user_id(sess). For me trustor.user_id is None which will make

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

- Original Message - From: David Lyle dkly...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon

Re: [openstack-dev] [puppet][keystone] To always use or not use domain name?

- Original Message - From: Adam Young ayo...@redhat.com To: openstack-dev@lists.openstack.org Sent: Thursday, August 6, 2015 1:03:55 AM Subject: Re: [openstack-dev] [puppet][keystone] To always use or not use domain name? On 08/05/2015 08:16 AM, Gilles Dubreuil wrote: While

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

- Original Message - From: Steve Martinelli steve...@ca.ibm.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, August 5, 2015 3:59:34 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login

Re: [openstack-dev] [sahara] keystone session upgrade

On 18 Jul 2015 6:29 am, michael mccune m...@redhat.com wrote: On 07/16/2015 04:31 PM, michael mccune wrote: i will also likely be rewriting the spec to encompass these changes if i can get them working locally. just wanted to follow up before i rewrite the spec. i think the most

[openstack-dev] [glance] V3 authentication to swift

Glancers, A while ago I wrote an email outlining a couple of ways we could support keystone v3 authentication when using swift as a backend for glance_store. In the long term it would be best to transition swiftclient to use sessions as this would allow us to do more extensive (kerberos, ssl

Re: [openstack-dev] [glance] V3 Authentication for swift store

- Original Message - From: stuart mclaren stuart.mcla...@hp.com To: openstack-dev@lists.openstack.org Sent: Thursday, 18 June, 2015 7:06:12 PM Subject: Re: [openstack-dev] [glance] V3 Authentication for swift store Hi Jamie, Glance has another way of specifying the swift

Re: [openstack-dev] V3 Authentication for swift store

-Original Message- From: Jamie Lennox [mailto:jamielen...@redhat.com] Sent: 18 June 2015 07:02 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [glance] V3 Authentication for swift store Hey everyone, TL;DR: glance_store requires a way

[openstack-dev] [glance] V3 Authentication for swift store

Hey everyone, TL;DR: glance_store requires a way to do v3 authentication to the swift backend. The keystone team is making a push to properly deprecate the v2 authentication APIs this cycle. As part of that we have a series of devstack reviews that moves devstack over to only using v3 APIs[1]

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

- Original Message - From: David Chadwick d.w.chadw...@kent.ac.uk To: openstack-dev@lists.openstack.org Sent: Saturday, 6 June, 2015 6:01:10 PM Subject: Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name On 06/06/2015 00:24, Adam Young

Re: [openstack-dev] [Keystone] Domain and Project naming

- Original Message - From: Adam Young ayo...@redhat.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Thursday, 4 June, 2015 2:25:52 PM Subject: [openstack-dev] [Keystone] Domain and Project naming With Hierarchical Multitenantcy, we have the issue

Re: [openstack-dev] [keystone][clients] - Should we implement project to endpoint group?

- Original Message - From: Enrique Garcia garcianava...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, May 11, 2015 2:19:43 AM Subject: Re: [openstack-dev] [keystone][clients] - Should we implement

Re: [openstack-dev] [heat][python-heatclient] Does python-heatclient works with keystone sessions?

will be hidden because it's part of the token exchange. On Fri, May 8, 2015 at 4:22 PM Jay Reslock jresl...@gmail.com wrote: Hi Jamie, How do I see the service catalog that I am getting back? On Fri, May 8, 2015 at 3:25 AM Jamie Lennox jamielen...@redhat.com wrote: - Original

Re: [openstack-dev] [heat][python-heatclient] Does python-heatclient works with keystone sessions?

- Original Message - From: Jay Reslock jresl...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Friday, May 8, 2015 7:42:50 AM Subject: Re: [openstack-dev] [heat][python-heatclient] Does python-heatclient works

[openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate

Hi all, At around the time Barbican was applying for incubation there was a discussion about supported WSGI frameworks. From memory the decision at the time was that Pecan was to be the only supported framework and that for incubation Barbican had to convert to Pecan (from Falcon). Keystone is

Re: [openstack-dev] ERROR: openstackclient.shell Exception raised: python-keystoneclient 1.4.0

Rick, This is a problem of dependency resolution rather than an issue of keystoneclient specifically. You can see that glanceclient has a cap on keystoneclient that the installed version doesn't meet. Dependency resolution has always been a problem but is raising its head again recently. If

Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

- Original Message - From: German Eichberger german.eichber...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Saturday, 25 April, 2015 8:55:23 AM Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate

Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc)

, and could easily be tweaked to use a token plugin (when it's ready). I think the same can be said for our k2k issue, but I'm not sure. Thanks, Steve Martinelli OpenStack Keystone Core Jamie Lennox jamielen...@redhat.com wrote on 03/15/2015 10:52:31 PM: From: Jamie Lennox jamielen

Re: [openstack-dev] [keystone][congress][group-policy] Fetching policy from a remote source

- Original Message - From: Adam Young ayo...@redhat.com To: openstack-dev@lists.openstack.org Sent: Tuesday, March 17, 2015 8:59:17 AM Subject: Re: [openstack-dev] [keystone][congress][group-policy] Fetching policy from a remote source On 03/16/2015 03:24 PM, Doug Hellmann

[openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc)

Hi All, Please note when reading this that I have no real knowledge of django so it is very possible I'm overlooking something obvious. ### Issue Django OpenStack Auth (DOA) has always been tightly coupled to the notion of a username and password. As keystone progresses and new authentication

Re: [openstack-dev] [Keystone] [devstack] About _member_ role

On 02/17/15 21:01, Jamie Lennox wrote: - Original Message - From: Pasquale Porreca pasquale.porr...@dektech.com.au To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, 17 February, 2015 9:07:14 PM Subject: [openstack

Re: [openstack-dev] Kerberos in OpenStack

I replied to almost exactly this email off-list and so thought i would copy my reply to -dev. - Original Message - From: Jamie Lennox jamielen...@redhat.com To: Sanket Lawangare sanket.lawang...@gmail.com Sent: Wednesday, February 25, 2015 6:39:14 AM Subject: Re: Kerberos

Re: [openstack-dev] [Keystone] [devstack] About _member_ role

- Original Message - From: Pasquale Porreca pasquale.porr...@dektech.com.au To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, 17 February, 2015 9:07:14 PM Subject: [openstack-dev] [Keystone] [devstack] About _member_

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

- Original Message - From: Alexander Makarov amaka...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, 17 February, 2015 4:00:05 AM Subject: Re: [openstack-dev] [keystone] [trusts] [all] How trusts should

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

+1 - Original Message - From: Guang Yee guang@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, 11 February, 2015 10:45:07 AM Subject: Re: [openstack-dev] [Keystone] Proposing Marek Denis for the Keystone

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 - Original Message - From: Morgan Fainberg morgan.fainb...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, 19 January, 2015 5:11:02 AM Subject: [openstack-dev] [Keystone] Nominating Brad Topol for

Re: [openstack-dev] [all] Lets not assume everyone is using the global `CONF` object (zaqar broken by latest keystoneclient release 1.0)

- Original Message - From: Doug Hellmann d...@doughellmann.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Saturday, 20 December, 2014 12:07:59 AM Subject: Re: [openstack-dev] [all] Lets not assume everyone is using the

Re: [openstack-dev] [python-cinderclient] Return request ID to caller

- Original Message - From: Abhijeet Malawade abhijeet.malaw...@nttdata.com To: openstack-dev@lists.openstack.org Sent: Friday, 12 December, 2014 3:54:04 PM Subject: [openstack-dev] [python-cinderclient] Return request ID to caller HI, I want your thoughts on blueprint

[openstack-dev] [keystone][oslo] Handling contexts and policy enforcement in services

TL;DR: I think we can handle most of oslo.context with some additions to auth_token middleware and simplify policy enforcement (from a service perspective) at the same time. There is currently a push to release oslo.context as a library, for reference:

[openstack-dev] [oslo][kite] oslo.messaging changes for message security

Hi all, To implement kite we need the ability to sign and encrypt the message and the message data. This needs to happen at a very low level in the oslo.messaging stack. The existing message security review (https://review.openstack.org/#/c/109806/) isn't going to be sufficient. It allows us to

Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery

and Discovery On Mon, Oct 20, 2014 at 7:04 AM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday

Re: [openstack-dev] [Keystone] Question regarding Service Catalog and Identity entries...

- Original Message - From: Ben Meyer ben.me...@rackspace.com To: openstack-dev@lists.openstack.org Sent: Monday, October 20, 2014 3:53:39 PM Subject: Re: [openstack-dev] [Keystone] Question regarding Service Catalog andIdentity entries... On 10/20/2014 08:12 AM, Jamie

Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery

- Original Message - From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, October 7, 2014 6:56:15 PM Subject: Re: [openstack-dev] Horizon and Keystone: API Versions and

Re: [openstack-dev] [Keystone] Question regarding Service Catalog and Identity entries...

- Original Message - From: Ben Meyer ben.me...@rackspace.com To: openstack-dev@lists.openstack.org Cc: Jamie Painter jamie.pain...@rackspace.com Sent: Tuesday, October 7, 2014 4:31:16 PM Subject: [openstack-dev] [Keystone] Question regarding Service Catalog and Identity

Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites

- Original Message - From: Nathan Kinder nkin...@redhat.com To: openstack-dev@lists.openstack.org Sent: Tuesday, October 14, 2014 2:25:35 AM Subject: Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites On 10/13/2014 01:17 PM, Morgan

Re: [openstack-dev] [all] [clients] [keystone] lack of retrying tokens leads to overall OpenStack fragility

, Jamie Lennox wrote: - Original Message - From: Steven Hardy sha...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, September 11, 2014 1:55:49 AM Subject: Re: [openstack-dev] [all] [clients] [keystone

Re: [openstack-dev] [all] [clients] [keystone] lack of retrying tokens leads to overall OpenStack fragility

tokens leads to overall OpenStack fragility On Wed, Sep 10, 2014 at 08:46:45PM -0400, Jamie Lennox wrote: - Original Message - From: Steven Hardy sha...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday

Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency

- Original Message - From: Travis S Tripp travis.tr...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Friday, 12 September, 2014 10:30:53 AM Subject: [openstack-dev] masking X-Auth-Token in debug output - proposed

Re: [openstack-dev] [all] [clients] [keystone] lack of retrying tokens leads to overall OpenStack fragility

- Original Message - From: Steven Hardy sha...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, September 11, 2014 1:55:49 AM Subject: Re: [openstack-dev] [all] [clients] [keystone] lack of retrying

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

On Thu, 2014-09-04 at 17:37 -0400, Adam Young wrote: While the Keystone team has made pretty good strides toward Federation for getting a Keystone token, we do not yet have a complete story for Horizon. The same is true about Kerberos. I've been working on this, and I want to inform the

  1   2   >