Re: [openstack-dev] [Keystone][Token expiration]

d apply the header of "X-Service-Token" and change > of "allow_expired" in keystone.conf. > > Br, > > Tuan/Nokia > > On Mon, Apr 3, 2017 at 2:36 PM, Dolph Mathews <dolph.math...@gmail.com> > wrote: > > > does it mean that the token now will l

Re: [openstack-dev] [Keystone][Token expiration]

> does it mean that the token now will live forever No; it behaves as described in the document you linked. If you have any specific security concerns, please raise them appropriately (such as a security bug, if necessary). On Mon, Apr 3, 2017 at 5:27 AM lương hữu tuấn

Re: [openstack-dev] [keystone]PKI token VS Fernet token

means > that > > # keystone will maintain one staged key, one primary key, and one secondary > > # key. Increasing this value means that additional secondary keys will be > kept > > # in the rotation. (integer value) > > # max_active_keys = 3 > Dolph Mathews

Re: [openstack-dev] [keystone]PKI token VS Fernet token

Thank you for the data and your test scripts! As Lance and Stanek already alluded, Fernet performance is very sensitive to keystone's configuration. Can your share your keystone.conf as well? I'll also be in Atlanta and would love to talk Fernet performance, even if we don't have a formal time

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

What made most services jump +20% between mitaka and newton? Maybe there is a common cause that we can tackle. I'd also be in favor of reducing the number of workers in the gate, assuming that doesn't also substantially increase the runtime of gate jobs. Does that environment variable

Re: [openstack-dev] [keystone] Do we really need two listening ports ?

On Wed, Feb 1, 2017 at 6:59 AM Thomas Goirand wrote: > On 02/01/2017 10:54 AM, Attila Fazekas wrote: > > Hi all, > > > > Typically we have two keystone service listening on two separate ports > > 35357 and 5000. > > > > Historically one of the port had limited functionality, but

Re: [openstack-dev] [all] Creating a new IRC meeting room ?

On Sun, Dec 4, 2016 at 8:49 PM Tony Breeds wrote: > On Fri, Dec 02, 2016 at 11:35:05AM +0100, Thierry Carrez wrote: > > Hi everyone, > > > > There has been a bit of tension lately around creating IRC meetings. > > I've been busy[1] cleaning up unused slots and

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

Thank you for your selfless community service, Steve! It takes a LOT of commitment to be a successful PTL, and I think you delivered in spades. We owe you a lot of gratitude. -Dolph On Mon, Nov 21, 2016 at 11:54 AM Steve Martinelli wrote: > Keystoners, > > I do not

Re: [openstack-dev] [Keystone] Project name DB length

On Wed, Sep 28, 2016 at 10:55 PM Adrian Turjak wrote: > I think with PKI tokens we had worse to worry about! > > At any rate, would be great to know, and if there isn't a strong reason > against it we can make project name 255 for some more flexibility. > It's nice for

Re: [openstack-dev] [all][i18n] do we need translation mark for strings in tests?

On Sat, Oct 1, 2016 at 5:24 PM Ihar Hrachyshka wrote: > Akihiro Motoki wrote: > > > Hi, > > > > I noticed strings in tests (unit tests or others) have translation marks > > (_, _LE and so on). > > Do we need translation marks for them? > > > > I don't

Re: [openstack-dev] [osc][keystone] User Project List

t that `openstack show user` (without a user ID or name as an argument) should return "me" (the authenticated user), as I think that'd be a better user experience. > On 22/09/2016 12:58 AM, Dolph Mathews <dolph.math...@gmail.com> wrote: > > > > > > > > On Wed, Se

Re: [openstack-dev] [osc][keystone] User Project List

On Wed, Sep 21, 2016 at 12:31 AM Adrian Turjak wrote: > The default keystone policy up until Newton doesn't let a user get their > own user > This seems to be the crutch of your issue - can you provide an example of this specific failure and the corresponding policy? As

Re: [openstack-dev] [ptl] code churn and questionable changes

This is a topic that appears periodically; I think it's important that we consider the patches objectively, just like any other patch. If these patches result in substantial and unproductive load on infra that can be deemed abusive, then that's another matter. And as a general rule, there is

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

On Fri, Jun 10, 2016 at 12:20 PM Clint Byrum wrote: > Excerpts from Henry Nash's message of 2016-06-10 14:37:37 +0100: > > On further reflection, it seems to me that we can never simply enable > either of these approaches in a single release. Even a v4.0 version of the > API

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

On Wed, May 25, 2016 at 2:57 AM Jamie Lennox wrote: > 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

Re: [openstack-dev] [keystone] orchestration and db_sync

On Tue, May 31, 2016 at 8:41 AM David Stanek wrote: > On Fri, May 27, 2016 at 12:08 PM, Ryan Hallisey > wrote: > > Theses changes do not all happen at the same times for an OpenStack > installation. > > > - Create the service's users and add a

Re: [openstack-dev] [all] Deprecated options in sample configs?

I think the metadata_manager is one of many terrible examples of deprecated configuration options. The documentation surrounding a deprecation should *always* tell you why something is being deprecated, and what you should be using instead to achieve the same, or better, result moving forward. But

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On Thu, May 12, 2016 at 8:10 AM Edmund Rhudy (BLOOMBERG/ 120 PARK) < erh...@bloomberg.net> wrote: > +1 on desiring OAuth-style tokens in Keystone. > OAuth 1.0a has been supported by keystone since the havana release, you just have to turn it on and use it:

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

My understanding from the summit session was that we should have a specific role defined in keystone's policy.json here: https://github.com/openstack/keystone/blob/a16287af5b7761c8453b2a8e278d78652497377c/etc/policy.json#L37 Which grants access to nothing in keystone beyond that check. So, the

Re: [openstack-dev] Keystone Authorization Failed: Forbidden (HTTP 403)

t you don't have authorization to make the request (listing users, for example). You'd be able to login to horizon and spin up a VM, or do the same from the CLI, but not make the requests you're using to exercise the cloud admin role. > On Wed, Apr 27, 2016 at 4:55 PM, Dolph Mathews <dolph.

Re: [openstack-dev] Keystone Authorization Failed: Forbidden (HTTP 403)

Depending on which release of keystone you're running, try enabling either insecure_debug (more recent releases) or debug (older releases) to true in keystone.conf to get more detailed error messages from keystone.

Re: [openstack-dev] Devstack liberty with keystone v3

On Tuesday, April 26, 2016, kiran vemuri UH wrote: > Hello Sean, > > I tried doing what you suggested and what ZhiQiang Fan suggested as > well. > > But both of them give me similar error when I try to fetch keystone > catalog. > > DEBUG:keystoneclient.auth.identity.v2:Making

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

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 execute `openstack role list`, the result is succeed. > > *[root@devstack scripts]#

Re: [openstack-dev] [keystone] Problem with WSGI on keystone

On Tue, Apr 19, 2016 at 11:57 AM, Rosensweig, Elisha (Nokia - IL) < elisha.rosensw...@nokia.com> wrote: > Hi All, > > Recently, I've been having trouble running stack.sh from scratch. With the > default configuration I've been using for a while, I get the following > error in

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert wrote: > Hi, > > we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2 > Federation system by Keystone where we're a Service Provider (SP). > > The problem in this situation is getting a token for direct API >

Re: [openstack-dev] [Keystone] State of Fernet Token deployment

On Mon, Apr 18, 2016 at 5:14 PM, Adam Young wrote: > On 04/18/2016 10:29 AM, Brant Knudson wrote: > > > > On Fri, Apr 15, 2016 at 9:04 PM, Adam Young wrote: > >> We all want Fernet to be a reality. We ain't there yet (Except for mfish >> who has no

Re: [openstack-dev] [all] - About Openstack upgrade

On Thu, Apr 14, 2016 at 8:40 PM, Kenny Ji-work wrote: > Hi all, > > We have deployed openstack liberty in our online environment by using > devstack. We wanner upgrade our openstack to the newest version - mitaka, > so is there some tools or facilities to complete it? Thank

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

On Wed, Apr 13, 2016 at 9:07 PM, Morgan Fainberg wrote: > It is that time again, the time to plan the Keystone midcycle! Looking at > the schedule [1] for Newton, the weeks that make the most sense look to be > (not in preferential order): > > R-14 June 27-01 > R-12

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

On Wed, Apr 13, 2016 at 2:37 PM, Emilien Macchi wrote: > On Wed, Apr 13, 2016 at 12:13 PM, Matthew Treinish > wrote: > > On Wed, Apr 13, 2016 at 10:59:10AM -0400, Emilien Macchi wrote: > >> Hi, > >> > >> Current OpenStack Infra Periodic jobs do not send

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad wrote: > Keystone's credential API pre-dates barbican. We started talking about > having the credential API back to barbican after it was a thing. I'm not > sure if any work has been done to move the credential API in this >

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

On Friday, April 8, 2016, John Dickinson wrote: > > > On 8 Apr 2016, at 13:35, Jeremy Stanley wrote: > > > On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote: > >> There are many ways to game a simple +1 counter, such as +1'ing changes > >> that already have at least 1x +2,

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

We're _all_ winners. On Friday, April 8, 2016, Brad Topol wrote: > If Termie comes out of retirement to respond to a thread are there really > any winners??? :-) > > --Brad > > > Brad Topol, Ph.D. > IBM Distinguished Engineer > OpenStack > (919) 543-0646 > Internet:

Re: [openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

You can use the public URL as a fallback to the internal URL; however, the admin URL is assumed to be the only privileged API endpoint. The details are buried in API documentation (and perhaps history), but I tried to summarize the intended design here as I understand it:

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

For some historical perspective, that's basically how v2 was designed. The "public" service (port 5000) did nothing but the auth flow. The "admin" service (port 35357) was identity management. Unfortunately, there are (perhaps uncommon) authentication flows where, for example, you need to 1)

Re: [openstack-dev] [keystone][nova] Many same "region_name" configuration really meaingful for Multi-region customers?

Unless someone on the operations side wants to speak up and defend cross-region nova-cinder or nova-neutron interactions as being a legitimate use case, I'd be in favor of a single region identifier. However, both of these configuration blocks should ultimately be used to configure keystoneauth,

Re: [openstack-dev] [all] Please do *not* use git (and specifically "git log") when generating the docs

On Saturday, February 20, 2016, Thomas Goirand <z...@debian.org> wrote: > On 02/19/2016 05:39 AM, Dolph Mathews wrote: > > > > On Thu, Feb 18, 2016 at 11:17 AM, Thomas Goirand <z...@debian.org > <javascript:;> > > <mailto:z...@debian.org <javascript

Re: [openstack-dev] [all] Please do *not* use git (and specifically "git log") when generating the docs

On Thu, Feb 18, 2016 at 11:17 AM, Thomas Goirand wrote: > Hi, > > I've seen Reno doing it, then some more. It's time that I raise the > issue globally in this list before the epidemic spreads to the whole of > OpenStack ! :) > > The last occurence I have found is in oslo.config

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

+1 this is a totally logical move, especially given that the current implementation back to the /v3/credentials API anyway. On Friday, February 5, 2016, Morgan Fainberg wrote: > Looking over the state [and relatively untested nature] of the Keystone > EC2 API and

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov wrote: > swift3(s3) works like ec2-api. > > 1. swift3/ec2-api recieves AWS request > 2. it parses signature and access_key (and other headers) > 3. it sends these values (and token that calculated from request) to > keystone >

Re: [openstack-dev] Keystone token-get failing during devstack juno-eol installation

What is in the Apache / keystone log? On Fri, Jan 22, 2016 at 1:56 AM, Jonnalagadda, Venkata < venkata.jonnalaga...@intl.att.com> wrote: > Hi, > > > > I tried to install devstack (juno-eol) on Ubuntu 12.04 and seeing > “keystone token get failing..” as below – > > > > 2016-01-22 11:06:33.470 | +

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

This is a topic for legal-discuss, not -dev. http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss On Friday, January 15, 2016, Thomas Goirand wrote: > This isn't the first time I'm calling for it. Let's hope this time, I'll > be heard. > > Randomly, contributors

Re: [openstack-dev] [oslo][nova][all] timeutils deprecation removals will break Nova

On Sunday, December 20, 2015, Davanum Srinivas wrote: > Nova folks, > > We have this review in oslo.utils: > https://review.openstack.org/#/c/252898/ > > There were failed effort in the past to cleanup in Nova: > https://review.openstack.org/#/c/164753/ >

Re: [openstack-dev] [oslo][keystone] Move oslo.policy from oslo to keystone

On Wed, Dec 16, 2015 at 1:33 PM, Davanum Srinivas wrote: > Brant, > > I am ok either way, guess the alternative was to add keystone-core > directly to the oslo.policy core group (can't check right now). > That's certainly reasonable, and kind of what we did with pycadf. > >

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

On Wed, Dec 16, 2015 at 9:59 AM, 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

[openstack-dev] [keystone] Will domain be removed in Keystone Mitaka?

On Tue, Dec 15, 2015 at 10:08 PM, darren wang wrote: > Hi Dolph, > > > > We are doing something on “domain” now, but I saw bp-reseller which will > integrate domain with project and remove domain finally, I’m pretty > concerned that will domain be removed in Mitaka? >

Re: [openstack-dev] [keystone] Is "domain" a mapping to real-world cloud tenant?

Unfortunately, "tenancy" has multiple definitions in our world so let me try to clarify further! Do you have a link to that paper? Tenants (v2) and projects (v3) have a history as serving to isolate the resources (VMs, networks, etc) of multiple tenants. They literally provide for multitenancy.

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

The port is an arbitray choice for developers running on standalone services over HTTP. Just don't choose something in the linux ephemeral port range :) In production, assume all services can be deployed on 443. As for service *type*, it should not include project names, code names, API versions,

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

On Wed, Dec 9, 2015 at 2:25 AM, Thomas Goirand <z...@debian.org> wrote: > On 12/08/2015 04:09 AM, Dolph Mathews wrote: > > In Debian, many services/daemons are run, then their API is used by > the > > package. In the case of Keystone, for example, it is poss

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

Benchmarks always appreciated! But, these types of benchmarks are *entirely* useless unless you can provide the exact configuration you used for each scenario so that others can scrutinize the test method and reproduce your results. So, off the top of my head, I'm looking for: * keystone.conf *

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

least some idea of what lies in > between (networking, etc) —briefly outlined > * whatever else I'm forgetting —feel free to add in the comments > > > > Regards, > Ali > > From: Dolph Mathews <dolph.math...@gmail.com > <javascript:_e(%7B%7D,'cvml','dolph.m

Re: [openstack-dev] [keystone][doc][tempest] What title should be for OS-KSCRUD extension

I just noticed you suggested " "; if that's the prevailing form, then I'd suggest "Change password (self-service)". On Tue, Dec 8, 2015 at 9:31 PM, Dolph Mathews <dolph.math...@gmail.com> wrote: > This is implemented as a "self-service user password change

Re: [openstack-dev] [keystone][doc][tempest] What title should be for OS-KSCRUD extension

This is implemented as a "self-service user password change" on the v2 public API. The user is required to have a token for the password they are changing, and is required to know the original password before a new one can be set. There is a similar "administrative password reset" call on the v2

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

On Monday, December 7, 2015, 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][all] Move from active distrusting model to trusting model

Scenarios I've been personally involved with where the "distrustful" model either did help or would have helped: - Employee is reprimanded by management for not positively reviewing & approving a coworkers patch. - A team of employees is pressured to land a feature with as fast as possible.

Re: [openstack-dev] [keystone][stable] nominating lin hua cheng for keystone-stable-maint

+1 On Tue, Nov 17, 2015 at 5:24 PM, Steve Martinelli wrote: > I'd like to nominate Lin Hua Cheng for keystone-stable-maint. He has been > doing reviews on keystone's liberty and kilo stable branches since mitaka > development has opened, and being a member of

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

On Tue, Nov 17, 2015 at 2:56 PM, Lindsay Pallickal <pallic...@gmail.com> wrote: > > > On Tue, Nov 17, 2015 at 5:31 AM, Dolph Mathews <dolph.math...@gmail.com> > wrote: > >> >> >> On Tuesday, November 17, 2015, Lindsay Pallickal <pallic...@gmail.co

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

On Tuesday, November 17, 2015, Lindsay Pallickal wrote: > I was having an issue extending the expiration on unscoped and > tenant/project scoped tokens retrieved with an existing token. I now > realize this is a feature, not a bug, but I've got some points to argue > that

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann wrote: > Excerpts from Clint Byrum's message of 2015-11-05 10:09:49 -0800: > > Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800: > > > Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500: > > > >

Re: [openstack-dev] openstack-barbican-authenticate-keystone-barbican-command

On Wed, Oct 21, 2015 at 6:26 AM, Dave McCowan (dmccowan) wrote: > Hi Arif-- > Are you using Keystone for authentication? > If so, you need to get an authentication token from Keystone and add > it as a header to your curl command: -H "X-Auth-Token:*$TOKEN*". >

Re: [openstack-dev] [all][heat] Which repo to use in docs -- git.openstack.org or github.com?

On Tue, Oct 20, 2015 at 12:20 PM, Christopher Aedo wrote: > On Tue, Oct 20, 2015 at 3:43 AM, Andreas Jaeger wrote: > > On 2015-10-20 12:17, Qiming Teng wrote: > >> > >> Hi, > >> > >> Just encountered this again in code review [1]. The question is about > >> the

Re: [openstack-dev] [infra][all] Reviews with a prio label?

This is actually something I've thought a lot about (focusing the community's review efforts), and have experimented with various solutions in the keystone community. I've built external solutions that have worked fairly well, but my current preference is to take advantage of what's already built

Re: [openstack-dev] [infra][all] Reviews with a prio label?

On Tue, Oct 20, 2015 at 11:43 AM, Dolph Mathews <dolph.math...@gmail.com> wrote: > This is actually something I've thought a lot about (focusing the > community's review efforts), and have experimented with various solutions > in the keystone community. I've built external solu

Re: [openstack-dev] [infra][all] Reviews with a prio label?

On Tue, Oct 20, 2015 at 12:09 PM, Sean Dague <s...@dague.net> wrote: > On 10/20/2015 12:43 PM, Dolph Mathews wrote: > > This is actually something I've thought a lot about (focusing the > > community's review efforts), and have experimented with various > > solution

Re: [openstack-dev] Apache2 vs uWSGI vs ...

On Fri, Sep 18, 2015 at 11:09 AM, Vladimir Kuklin wrote: > I just suggested to untie keystone from wsgi and implement uwsgi support. > And then let the user decide what he or she wants. > Keystone is not tied to Apache or mod_wsgi, if that's what you mean. We provide a

Re: [openstack-dev] [all][elections] PTL nomination period is now over

On Thu, Sep 17, 2015 at 3:15 PM, John Griffith wrote: > > > On Thu, Sep 17, 2015 at 2:00 PM, Doug Hellmann > wrote: > >> Excerpts from Morgan Fainberg's message of 2015-09-17 12:51:33 -0700: >> >> > I think this is all superfluous however and we

Re: [openstack-dev] [all][TC] 'team:danger-not-diverse tag' and my concerns

Perhaps gamify the tagging process? By inverting the tagging convention from something negative to something positive like "sponsored-by-company-x", you're offering bragging rights to companies that are the sole sponsors of projects. "Here's a list of projects that Company X directly supports,

Re: [openstack-dev] [devstack][keystone][ironic] Use only Keystone v3 API in DevStack

On Fri, Sep 11, 2015 at 2:55 PM, Yee, Guang wrote: > Can you please elaborate on "granularity of policy support within > Ironic."? Is there a blueprint/etherpad we can take a look? > See the lack of granularity expressed by Ironic's current policy file:

Re: [openstack-dev] [keystone] creating new users with invalid mail addresses possible

On Fri, Sep 11, 2015 at 9:29 AM, Morgan Fainberg wrote: > We don't utilize email address for anything. It is not meant to be a > top-level column. We've had a lot of discussions on this. The main result > is we decided that Keystone should be getting out of the PII

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

Thank you for all your work, Morgan! Good luck with the opportunity to write some code again :) On Thu, Sep 10, 2015 at 4:40 PM, Morgan Fainberg wrote: > As I outlined (briefly) in my recent announcement of changes ( >

Re: [openstack-dev] [all] Something about being a PTL

+1 Fantastically well said. I'd encourage all current and potential PTLs to take these words to heart. > I believe it's safe enough to say that you'll have to spend 60% to 70% of your time upstream, assuming the porject is a busy one. The busier the project, the closer to 100% this becomes. For

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

-1 Unless there's something more to this, I don't think it's worth any sort of risk to stability just to shuffle API implementations around that can't wait for mikata. On Fri, Sep 4, 2015 at 12:28 PM, Henry Nash wrote: > Keystone has, for a number of releases,

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

Does anyone have an example of an API outside of OpenStack that would return 400 in this situation (arbitrary query string parameters)? Based on my past experience, I'd expect them to be ignored, but I can't think of a reason why a 400 would be a bad idea (but I suspect there's some prior art /

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

On Thu, Aug 20, 2015 at 7:40 AM, Hans Feldt hans.fe...@ericsson.com wrote: How do you configure/use keystonemiddleware for a specific identity endpoint among several? In an OPNFV multi region prototype I have keystone endpoints per region. I would like keystonemiddleware (in context of

Re: [openstack-dev] [keystone] keystone v3 problem in Kilo

https://review.openstack.org/#/c/212515/ On Thu, Aug 13, 2015 at 6:57 AM, Alexandre Levine alexandrelev...@gmail.com wrote: Hi everybody, There is a problem using keystone v3 in Kilo by external EC2 API service. The problem doesn't exist for keystone v2 and it is fixed in master for

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

On Thu, Aug 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: David Lyle dkly

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

On Thu, Aug 6, 2015 at 6:09 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Thu, Aug 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

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

Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login Forcing Horizon to duplicate Keystone settings just makes everything much harder to configure and much more fragile. Exposing whitelisted, or all, IdPs makes much more sense. On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews

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

On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 04/08/2015 18:59, Steve Martinelli wrote: Right, but that API is/should be protected. If we want to list IdPs *before* authenticating a user, we either need: 1) a new API for listing public IdPs or 2) a new

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

settings (idp+protocol) But, it's already in keystone. Thanks, Steve Martinelli OpenStack Keystone Core [image: Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadwic]Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed

Re: [openstack-dev] [keystone] token revocation woes

discussion, I was unable to see any performance improvement here although not calling DELETE so often will reduce the number of deadlocks when we're under heavy load especially given the globally replicated DB we use. On Tue, Jul 21, 2015 at 5:26 PM, Dolph Mathews dolph.math...@gmail.com wrote

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

Although using a node's *local* filesystem requires external configuration management to manage the distribution of rotated keys, it's always available, easy to secure, and can be updated atomically per node. Note that Fernet's rotation strategy uses a staged key that can be distributed to all

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

On Mon, Jul 27, 2015 at 1:31 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Alexander Makarov's message of 2015-07-27 10:01:34 -0700: Greetings! I'd like to discuss pro's and contra's of having Fernet encryption keys stored in a database backend. The idea itself emerged during

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

Matt Fischer also discusses key rotation here: http://www.mattfischer.com/blog/?p=648 And here: http://www.mattfischer.com/blog/?p=665 On Mon, Jul 27, 2015 at 2:30 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Mon, Jul 27, 2015 at 2:03 PM, Clint Byrum cl...@fewbar.com wrote

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

On Mon, Jul 27, 2015 at 2:03 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Dolph Mathews's message of 2015-07-27 11:48:12 -0700: On Mon, Jul 27, 2015 at 1:31 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Alexander Makarov's message of 2015-07-27 10:01:34 -0700:

Re: [openstack-dev] [keystone] token revocation woes

, 2015 at 4:00 PM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Jul 15, 2015 at 4:51 PM, Matt Fischer m...@mattfischer.com wrote: I'm having some issues with keystone revocation events. The bottom line is that due to the way keystone handles the clean-up of these events[1], having

Re: [openstack-dev] [Fuel] Add support for Keystone's Fernet encryption keys management: initialization, rotation

On Thu, Jul 16, 2015 at 10:29 AM, Davanum Srinivas dava...@gmail.com wrote: Adam, For 1, do we let user configure max_active_keys? what's the default? The default in keystone is 3, simply to support having one key in each of the three phases of rotation. You can increase it from there per

Re: [openstack-dev] [keystone] token revocation woes

On Wed, Jul 15, 2015 at 4:51 PM, Matt Fischer m...@mattfischer.com wrote: I'm having some issues with keystone revocation events. The bottom line is that due to the way keystone handles the clean-up of these events[1], having more than a few leads to: - bad performance, up to 2x slower

Re: [openstack-dev] [Keystone] Symbol not found: _BIO_new_CMS

Also for the sake of future googlers: we gave up on supporting keystone development in OS X a release or two ago due to the increasing number of workarounds like this that we had to track (a few of which impacted the code base itself, and were thus dropped). On Tue, Jul 14, 2015 at 3:42 PM,

Re: [openstack-dev] [murano] [congress] Congress needs to fetch environments from all tenants.

How about using domain-based role assignments in keystone and requiring domain-level authorization in policy, and then only returning data about the collection of tenants that belong to the authorized domain? That way you don't have an API that violates multi-tenant isolation, consumable only by

Re: [openstack-dev] [Keystone][OSC] Keystone v3 user create --project $projid does not add user to project?

This was entirely intentional, in order to replace the implicit role assignment behavior in v2 with an explicit behavior in v3. The default_project_id attribute (***emphasis*** mine): References the user's default project against which to authorize, if the API user does not explicitly specify

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On Mon, Jun 15, 2015 at 12:07 PM, Jay Pipes jaypi...@gmail.com wrote: It has come to my attention in [1] that the microversion spec for Nova [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead of the name of the API -- i.e. OpenStack Compute and OpenStack Bare

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

/ On Wed, Jun 10, 2015 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com wrote: We're aiming for a Spec Proposal Freeze deadline for Liberty of June 23rd, but are requiring that specs are approved by our spec reviewers by that date. The spec [1] is currently pretty straightforward and provides us

Re: [openstack-dev] [all][python3] use of six.iteritems()

On Thu, Jun 11, 2015 at 12:34 AM, Robert Collins robe...@robertcollins.net wrote: On 11 June 2015 at 17:16, Robert Collins robe...@robertcollins.net wrote: This test conflates setup and execution. Better like my example, ... Just had it pointed out to me that I've let my inner asshole out

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

chose (for backward compatibility reasons) to allow the underlying LDAP user/group ID….so we might want to advise this to be disabled (there’s a config switch to use the Public ID mapping for even this case). Henry On 5 Jun 2015, at 18:19, Dolph Mathews dolph.math...@gmail.com wrote: On Fri

Re: [openstack-dev] [all][python3] use of six.iteritems()

tl;dr *.iteritems() is faster and more memory efficient than .items() in python2* Using xrange() in python2 instead of range() because it's more memory efficient and consistent between python 2 and 3... # xrange() + .items() python -m timeit -n 20 for\ i\ in\

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

On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox jamielen...@redhat.com wrote: - 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

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

the group with the name they want and come take your credentials. What may be safe is for the barbican ACL to contain the group_id if they are uniqueue across all domains, or take a domain_id group_name pair for the acl. Thanks, Kevin -- *From:* Dolph Mathews

Re: [openstack-dev] [Glance][Keystone] Glance and trusts

On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: I did suggest another solution to Adam whilst we were in Vancouver, and this mirrors what happens in the real world today when I order something from a supplier and a whole supply chain is involved in creating the

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

to the underlying local ID in the particular LDAP backend. Oh, awesome! I didn't realize we did that for groups as well. So then, we're safe exposing X-Group-Ids to services via keystonemiddleware.auth_token but still not X-Group-Names (in any trivial form). Henry From: Dolph Mathews dolph.math

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

On Wed, Jun 3, 2015 at 11:25 PM, Adam Young ayo...@redhat.com wrote: With Hierarchical Multitenantcy, we have the issue that a project is currentl restricted in its naming further than it should be. The domain entity enforces that all project namess under the domain domain be unique, but

  1   2   3   4   >