On Fri, Jun 14, 2013 at 9:45 AM, David Chadwick wrote:
>
> 2. Step 1b. How does the delegate know which role to request? This is
> unintuitive. A delegator (rather than delegate) knows the role he wants to
> delegate. One would normally expect the delegator to request Keystone to
> delegate this ro
On Wed, Aug 28, 2013 at 7:22 PM, Yongsheng Gong wrote:
> For admin, we must use admin token. In general, the token from API
> context is not of role admin.
>
So... because the authenticated user making the API request *may not* have
"admin" access, you're dropping that authorization in favor of
On Tue, Sep 3, 2013 at 5:52 PM, Steven Hardy wrote:
> Hi,
>
> I have a question for the keystone folks re the expected behavior when
> deleting a trust.
>
> Is it expected that you can only ever delete a trust as the user who
> created it, and that you can *not* delete the trust when impersonatin
On Wed, Sep 4, 2013 at 5:45 AM, Steven Hardy wrote:
> On Wed, Sep 04, 2013 at 09:49:48AM +0100, Steven Hardy wrote:
> > This final step is the problematic step - atm (unless I'm making a
> mistake,
> > which as previously proven is entirely possible! ;) it seems that it's
> > impossible for anyon
On Wed, Sep 4, 2013 at 9:14 AM, Salvatore Orlando wrote:
> whenever I run devstack keystone falies to start because dogpile.cache is
> not installed; this is easily solved by installing it, but I wonder if it
> should be in requirements.txt
> Also, since the cache appears to be disabled by default
On Wed, Sep 4, 2013 at 9:58 AM, David Stanek wrote:
>
>
> On Wed, Sep 4, 2013 at 10:23 AM, Dolph Mathews wrote:
>
>>
>> On Wed, Sep 4, 2013 at 9:14 AM, Salvatore Orlando wrote:
>>
>>> whenever I run devstack keystone falies to start because dogpile.cac
you *should* have it installed, even though it won't be used :-/
https://github.com/openstack/keystone/blob/6979ae010d1fa20caeda13c8f88cdf6dbfa259c6/requirements.txt#L22
> Salvatore
>
>
> On 4 September 2013 15:23, Dolph Mathews wrote:
>
>>
>> On Wed
On Wed, Sep 4, 2013 at 10:56 AM, Monty Taylor wrote:
> Hey all!
>
> https://review.openstack.org/#/c/42178/2 has landed in nova, which means
> that nova now requires tox 1.6 or higher (for those folks using tox).
> We'll be wanting to port the same change to all of the projects, so if
> you use t
On Tue, Sep 10, 2013 at 11:01 AM, Thierry Carrez wrote:
> Alex Gaynor wrote:
> > Many of you have probably seen me send review requests in the last few
> weeks
> > about adding PyPy support to various OpenStack projects. A few people
> were
> > confused by these, so I wanted to fill everyone in on
On Mon, Sep 9, 2013 at 4:28 PM, Alex Gaynor wrote:
> Hi all,
>
> Many of you have probably seen me send review requests in the last few
> weeks
> about adding PyPy support to various OpenStack projects. A few people were
> confused by these, so I wanted to fill everyone in on what I'm up to :)
>
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 i
On Tue, Oct 20, 2015 at 11:43 AM, Dolph Mathews
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 solutions that have work
On Tue, Oct 20, 2015 at 12:09 PM, Sean Dague 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
> > solutions in the
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 repository to point to when docume
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*".
> You do not need to speci
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:
> > > > Can people help me work t
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 extending token expirati
+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 horizon-stable-maint, he is
> alread
On Tue, Nov 17, 2015 at 2:56 PM, Lindsay Pallickal
wrote:
>
>
> On Tue, Nov 17, 2015 at 5:31 AM, Dolph Mathews
> wrote:
>
>>
>>
>> On Tuesday, November 17, 2015, Lindsay Pallickal
>> wrote:
>>
>>>
>>> It looks like expiration is d
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. Minim
On Thu, Dec 3, 2015 at 10:33 AM, Ihar Hrachyshka
wrote:
> Akihiro Motoki wrote:
>
> Hi,
>>
>> python-neutronclient still has XML support of Neutron API.
>> I would like to discuss when we drop XML support in neutronclient.
>>
>> Neutron API XML suppoort was marked as deprecated in Icehouse and J
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
> > constrained by Apac
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 a
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
wrote:
> This is implemented as a "self-service user password change" on the v2
> pu
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
* d
On Wed, Dec 9, 2015 at 2:25 AM, Thomas Goirand 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 possible to ask,
> > vi
east 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 >
> Reply-To: "OpenStack Development Mailing List (not for usa
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
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 password into the databse
>
> Should only happen
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 appreciated.
>>
>> -- Forwarded message ---
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 doesn’t help - since
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) authe
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:
http://dolphm.com/open
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: bto...@us.ibm.com
>
> Assist
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, or which alrea
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
> direction. From a securi
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 e-mails (only
> >> periodic-stable do), so
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 July 11-15
> R-11 July 18-22
>
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 you for
> answering!
>
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 patience) but we are getting closer. The goal
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
> access.(*)
>
> There
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 /opt/stack/logs/key.l
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]# keystone --debug role-list*
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 authentication req
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.
https://github.com/openstack/keystone/blob/3c4fe622ac5da00b04ccc8bc4e207a2e9ab0f863
ut 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 Mat
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 n
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:
http://docs.openstack.org/developer/ke
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,
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.
D
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?
>
No, the API-facing concept
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 the
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.
>
> The name is very po
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/
> https://review.openstack.org/#/c/197601/
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 put their company
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 | +
+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 S3Token APIs, I want to propose
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
> 4. keystone gets secret
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 cl
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, Kirill
On Wed, Jul 15, 2015 at 4:51 PM, Matt Fischer 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 token validation wit
On Thu, Jul 16, 2015 at 10:29 AM, Davanum Srinivas
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 your
desired rot
xt step.
>
> Thanks.
>
>
> On Wed, Jul 15, 2015 at 4:00 PM, Dolph Mathews
> wrote:
>
>>
>>
>> On Wed, Jul 15, 2015 at 4:51 PM, Matt Fischer
>> wrote:
>>
>>> I'm having some issues with keystone revocation events. The bottom line
>>>
>>>
>>>
>>>
>>>
>>> Sent via mobile
>>>
>>> On Jul 22, 2015, at 11:51, Matt Fischer wrote:
>>>
>>> Dolph,
>>>
>>> Per our IRC discussion, I was unable to see any performance
>>&g
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 node
On Mon, Jul 27, 2015 at 1:31 PM, Clint Byrum 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 discuss
On Mon, Jul 27, 2015 at 2:03 PM, Clint Byrum 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 wrote:
> >
> > > Excerpts from Alexander Makarov's message of 2015-07-27 10:01:34 -0700:
> > > > Greetings!
> > > >
> > > > I
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
wrote:
>
>
> On Mon, Jul 27, 2015 at 2:03 PM, Clint Byrum wrote:
>
>> Excerpts fr
On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick
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 policy that doe
es in the horizon 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 Chadwic
y, August 6, 2015 5:52:40 AM
> > 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 mak
On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad wrote:
>
>
> On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews
> wrote:
>
>>
>> On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox
>> wrote:
>>
>>>
>>>
>>> - Original Message -
On Thu, Aug 6, 2015 at 6:09 PM, Dolph Mathews
wrote:
>
> On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad
> wrote:
>
>>
>>
>> On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews
>> wrote:
>>
>>>
>>> On Wed, Aug 5, 2015 at 6:54 PM, Jamie
https://review.openstack.org/#/c/212515/
On Thu, Aug 13, 2015 at 6:57 AM, Alexandre Levine 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
> keystone v3 by the following
On Thu, Aug 20, 2015 at 7:40 AM, Hans Feldt 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 glance-api) to use the l
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
/ dis
-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, supported the concept of
> inheri
+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 k
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 (
> https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1
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 game as much
> as possible.
>
>
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:
https://github.com/openstack/ironic/blob
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, excl
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 should simply encourage
>> > people to not wait un
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 sample configuration for Ap
Keystone is certainly CPU bound while doing crypto operations
(authentication, token creation, token validation, etc), so we're
experimenting with pypy now, but don't have any strong interest in the gate
jobs running *currently*. We might want to add one for keystone at some
point, though.
On Wed,
I assume that by "v3 policy file" you're specifically referring to:
https://github.com/openstack/keystone/blob/f6c01dd1673b290578e9fff063e27104412ffeda/etc/policy.v3cloudsample.json
Which essentially illustrates enforcement of a much more powerful
authorization model than most deployers are fami
On Wed, Jun 3, 2015 at 5:58 PM, John Wood wrote:
> Hello folks,
>
> There has been discussion about adding user group support to the
> per-secret access control list (ACL) feature in Barbican. Hence secrets
> could be marked as accessible by a group on the ACL rather than an
> individual user a
Sent:* Wednesday, June 03, 2015 7:23:22 PM
>> * To:* OpenStack Development Mailing List (not for usage questions)
>> * Subject:* Re: [openstack-dev] [keystone][barbican] Regarding exposing
>> X-Group- in token validation
>>
>> In general I am of the opinion with the
s passed to services, just X-Group-Ids. I'm
guessing this won't provide the user experience that Barbican is looking
for?
I'm leaning towards solution (A), but curious if that'll work for Barbican
and/or if anyone has an idea that I'm overlooking.
On Thu, Jun 4, 2015 at 8:18
On Wed, Jun 3, 2015 at 11:25 PM, Adam Young 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 really what we sh
On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick
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 end
> product that I or
s 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 [dolph.math...@gmail.com]
> *Sent:* Thursday
o 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).
>
>
> He
On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox
wrote:
>
>
> - Original Message -
> > From: "David Chadwick"
> > 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 b
x in token validation
>
> The one proviso is that in single LDAP situations, the cloud provider
> can 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
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\
dict(enumerate(xrange(100))).ite
On Thu, Jun 11, 2015 at 12:34 AM, Robert Collins
wrote:
> On 11 June 2015 at 17:16, Robert Collins
> 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 again
> - sorry. I'm going to step away fr
88564/
On Wed, Jun 10, 2015 at 10:47 AM, Dolph Mathews
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
On Mon, Jun 15, 2015 at 12:07 PM, Jay Pipes 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 Metal" -- in th
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 o
301 - 400 of 440 matches
Mail list logo
