We are putting a lot of effort into the Specs process. It seems like a
pity to let them go to waste after the features they describe are
implemented. Ideally, they should be part of the official
documentation. Many are too detailed to be a release note.
Should they be part of the patch,
On 08/21/2014 12:34 PM, Dolph Mathews wrote:
On Thu, Aug 21, 2014 at 11:21 AM, Daniel P. Berrange
berra...@redhat.com mailto:berra...@redhat.com wrote:
On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote:
I would prefer that you didn't merge this.
i.e. The
On 08/21/2014 12:53 PM, Daniel P. Berrange wrote:
On Thu, Aug 21, 2014 at 11:34:48AM -0500, Dolph Mathews wrote:
On Thu, Aug 21, 2014 at 11:21 AM, Daniel P. Berrange berra...@redhat.com
wrote:
On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote:
I would prefer that you didn't merge
On 08/22/2014 09:02 PM, Anne Gentle wrote:
/flame-on
Let's call spades, spades here. Czar is not only overkill, but
the wrong metaphor.
/flame-off
I'm with Rocky on the anti-czar-as-a-word camp. We all like clever
names to shed the corporate stigma but this word ain't it.
On 08/23/2014 02:01 AM, Clint Byrum wrote:
I don't know how Zaqar does its magic, but I'd love to see simple signed
URLs rather than users/passwords. This would work for Heat as well. That
way we only have to pass in a single predictably formatted string.
Excerpts from Zane Bitter's message of
On 08/25/2014 10:49 AM, Zane Bitter wrote:
On 24/08/14 23:17, Adam Young wrote:
On 08/23/2014 02:01 AM, Clint Byrum wrote:
I don't know how Zaqar does its magic, but I'd love to see simple
signed
URLs rather than users/passwords. This would work for Heat as well.
That
way we only have
On 08/26/2014 06:12 AM, Henry Nash wrote:
Hi
It was fully merged for Juno-2 - so if you are having problems, feel
free to share the settings in you main config and keystone.heat.config
files
Henry
On 26 Aug 2014, at 10:26, Bruno Luis Dos Santos Bompastor
bruno.bompas...@cern.ch
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 people that are interested in the approach, as
well as
a couple years ago, but I
can't say it is so compelling that we should do it now.
Step 3 is a different story and it needs more evaluation of the
possible scenarios opened.
Cheers,
Marco
On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote:
While the Keystone team has made pretty good
to the outside world. But in general, the
services themselves should be hardened enough to be exposed directly to
the public internet. That is the design of OpenStack.
Cheers,
Marco
On Fri, Sep 05, 2014 at 10:14:00AM -0400, Adam Young wrote:
On 09/05/2014 04:49 AM, Marco Fargetta wrote:
Hi
On 09/11/2014 03:15 AM, Richard Jones wrote:
[This is Horizon-related but affects every service in OpenStack, hence no
filter in the subject]
I would like for OpenStack to support browser-based Javascript API
clients.
Currently this is not possible because of cross-origin resource
blocking in
On 09/15/2014 08:28 PM, Nathan Kinder wrote:
On 09/12/2014 12:46 AM, Angus Lees wrote:
On Thu, 11 Sep 2014 03:21:52 PM Steven Hardy wrote:
On Wed, Sep 10, 2014 at 08:46:45PM -0400, Jamie Lennox wrote:
For service to service communication there are two types.
1) using the user's token like
Phase one for dealing with Federation can be done with CORS support
solely for Keystone/Horizon integration:
1. Horizon Login page creates Javascript to do AJAX call to Keystone
2. Keystone generates a token
3. Javascript reads token out of response and sends it to Horizon.
This should
cross-project track session for the
Summit.
Securing a browser-centric world is a tricky realm... let's make sure we get it
right. :-)
Agreed. I think this is one topic that will benefit from serious
upfront effort.
- Gabriel
-Original Message-
From: Adam Young [mailto:ayo
make
sure we get it right. :-)
- Gabriel
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com
mailto:ayo...@redhat.com]
Sent: Tuesday, September 16, 2014 3:40 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Keystone
On 09/17/2014 10:07 AM, David Chadwick wrote:
On 17/09/2014 14:55, Marek Denis wrote:
On 17.09.2014 15:45, Steve Martinelli wrote:
++ to your suggestion David, I think making the list of trusted IdPs
publicly available makes sense.
I think this might be useful in an academic/science world
solution as it requires
modifying the core Keystone code.
We need a fix to address this issue. My suggestion would be to make the API for
retrieving the list of trusted IDPs publicly accessible, so that no credentials
are
needed for this.
regards
David
On 16/09/2014 23:39, Adam Young wrote
. Javascript picks up the Federated unscoped token from the response
at the end of step 4 and use that to get a scoped token.
6. Javascript submites the scoped token to Horizon and user is logged in.
Whew.
On 17/09/2014 15:17, Adam Young wrote:
On 09/17/2014 10:07 AM, David Chadwick wrote
On 09/17/2014 11:56 AM, Matthieu Huin wrote:
Hi,
- Original Message -
From: Adam Young ayo...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Wednesday, September 17, 2014 5:00:16 PM
Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
On 09/17/2014 10:35 AM
On 09/18/2014 05:14 PM, Doug Hellmann wrote:
On Sep 18, 2014, at 4:34 PM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
On 18/09/2014 21:04, Doug Hellmann wrote:
On Sep 18, 2014, at 12:36 PM, David Chadwick
d.w.chadw...@kent.ac.uk wrote:
Our recent work on federation suggests we need an
On 09/19/2014 01:43 PM, Doug Hellmann wrote:
On Sep 19, 2014, at 6:56 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
On 18/09/2014 22:14, Doug Hellmann wrote:
On Sep 18, 2014, at 4:34 PM, David Chadwick d.w.chadw...@kent.ac.uk
wrote:
On 18/09/2014 21:04, Doug Hellmann wrote:
On Sep
On 09/22/2014 10:47 AM, Dolph Mathews wrote:
Dearest stackers and [key]stoners,
With the PTL candidacies officially open for Kilo, I'm going to take
the opportunity to announce that I won't be running again for the
position.
I thoroughly enjoyed my time as PTL during Havana, Icehouse and
On 12/09/2013 11:07 AM, Sean Dague wrote:
On 12/09/2013 10:12 AM, Brant Knudson wrote:
Monty -
Thanks for doing the work already to get the infrastructure set up.
Looks like I've got the easy part here. I posted an initial patch that
has one test from keystone in
:15 AM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind
we are making good progress, but what I dont like about your
On 12/09/2013 03:04 PM, David Chadwick wrote:
On 09/12/2013 19:37, Adam Young wrote:
On 12/06/2013 04:44 AM, David Chadwick wrote:
Another alternative is to change role name into role display name,
indicating that the string is only to be used in GUIs, is not guaranteed
to be unique, is set
On 12/09/2013 05:34 PM, Steven Hardy wrote:
Hi all,
I have some queries about what the future of the ec2tokens API is for
keystone, context as we're looking to move Heat from a horrible mixture of
v2/v3 keystone to just v3, currently I'm not sure we can:
- The v3/credentials API allows
While Python 3 has enumerated types, Python 2 does not, and the standard
package to provide id, Flufl.enum, is not yet part of our code base. Is
there any strong objection to including Flufl.enum?
http://pythonhosted.org/flufl.enum/
It makes for some very elegant code, especially for
/enum/__init__.py, line
352, in __getitem__
return cls._member_map_[name]
KeyError: 1
This seems to say that you cannot access an IntEnum as an integer, which
just seems broken.
Alex
On Mon, Dec 9, 2013 at 7:37 PM, Adam Young ayo...@redhat.com wrote:
While Python 3 has enumerated
...@kent.ac.uk]
Sent: Tuesday, December 10, 2013 1:30 AM
To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
How about the following which
, 2013 at 8:23 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
On 12/10/2013 09:55 AM, Adam Young wrote:
On 12/10/2013 05:24 AM, Flavio Percoco wrote:
On 09/12/13 19:45 -0800, Alex Gaynor wrote:
Would it make sense to use the `enum34` package
- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December 10, 2013
1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing
List (not for usage questions) Cc: Henry Nash;
dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev]
[keystone] Service scoped
https://blueprints.launchpad.net/keystone/+spec/update-policy-to-cloud
On 12/11/2013 11:18 AM, Lyle, David wrote:
+1 on moving the domain admin role rules to the default policy.json
-David Lyle
From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Wednesday, December 11, 2013 9:04 AM
To:
On 12/11/2013 10:11 PM, Paul Belanger wrote:
On 13-12-11 11:18 AM, Lyle, David wrote:
+1 on moving the domain admin role rules to the default policy.json
-David Lyle
From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Wednesday, December 11, 2013 9:04 AM
To: OpenStack Development
On 12/04/2013 08:58 AM, Jarret Raim wrote:
While I am all for adding a new program, I think we should only add one
if we
rule out all existing programs as a home. With that in mind why not add
this
to the keystone program? Perhaps that may require a tweak to keystones
mission
statement, but
On 12/16/2013 02:57 PM, Gabriel Hurley wrote:
I've run into a use case that doesn't currently seem to have a great solution:
Let's say my users want to use a top-of-stack OpenStack project such as Heat,
Trove, etc. that I don't currently support in my deployment. There's absolutely no reason
On 12/04/2013 12:35 PM, Henry Nash wrote:
On 4 Dec 2013, at 13:28, Dolph Mathews dolph.math...@gmail.com
mailto:dolph.math...@gmail.com wrote:
On Sun, Nov 24, 2013 at 9:39 PM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
The #1 pain point I hear from people
Dirk,
If it were as easy as just replaceing hteh hash algorithm, we would
have done it a year + ago. I'm guessing you figured that by now.
Here is the deal: We need to be able to make things work side by side.
Not sure how to do that, but I think the right solution is to make
keystone
On 01/06/2014 01:10 PM, Jeremy Stanley wrote:
On 2014-01-06 10:19:39 -0500 (-0500), Adam Young wrote:
If it were as easy as just replaceing hteh hash algorithm, we
would have done it a year + ago. I'm guessing you figured that by
now.
[...]
With the lack of In-Reply-To header and not finding
We are working on cleaning up the Keystone code with an eye to Oslo and
reuse:
https://review.openstack.org/#/c/56333/
On 01/08/2014 02:47 PM, Georgy Okrokvertskhov wrote:
Hi,
Keep policy control in one place is a good idea. We can use standard
policy approach and keep access control
So finally tried running a devstack instance on Fedora 20: rootwrap
failed on the cinder stage of the install. So I scaled back to a
Keystone only install.
[fedora@ayoung-f20 devstack]$ cat localrc
FORCE=yes
ENABLED_SERVICES=key,mysql,qpid
This failed starting the Keystone server with two
to land -
https://review.openstack.org/#/c/63647/
Because of the rhel6 support in devstack, every new version of fc needs
manual support, because there are tons of packages needed in fc* that
don't exist in rhel.
-Sean
On 01/09/2014 02:15 PM, Adam Young wrote:
So finally tried running
On 01/09/2014 04:58 PM, Sean Dague wrote:
On 01/09/2014 04:12 PM, Dean Troyer wrote:
On Thu, Jan 9, 2014 at 2:16 PM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
That didn't seem to make a difference, still no cache. The RPMS are
not getting installed, even if I
That worked. I incorporated the
FORCE_PREREQ=1
change and all good.
On 01/10/2014 04:54 AM, Flavio Percoco wrote:
On 09/01/14 23:27 -0500, Adam Young wrote:
On 01/09/2014 04:58 PM, Sean Dague wrote:
On 01/09/2014 04:12 PM, Dean Troyer wrote:
On Thu, Jan 9, 2014 at 2:16 PM, Adam
Use two separate domains for them. Make the userids be uuid@domainid
to be able distinguish one from the other.
On 01/27/2014 04:27 PM, Simon Perfer wrote:
I'm looking to create a simple Identity driver that will look at
usernames. A small number of specific users should be authenticated by
On 01/27/2014 12:26 PM, Marek Denis wrote:
Dear all,
We have Identity Provider and mapping CRUD operations already merged,
so it's a good point to prepare Keystone and Apache to handle SAML (as
a starter) requests/responses.
For the next OpenStack release it'd be the Apache that handles SAML
On 01/23/2014 06:21 AM, Steven Hardy wrote:
Hi all,
I've recently been working on migrating the heat internal interfaces to use
the keystone v3 API exclusively[1].
This work has mostly been going well, but I've hit a couple of issues which
I wanted to discuss, so we agree the most appropriate
On 01/28/2014 09:55 PM, ?? ??? wrote:
Hi all,
I want to participate in Barbican project. I'm interested in this bp
https://blueprints.launchpad.net/barbican/+spec/support-rsa-key-store-generation
Who can answer some questions about it?
On 02/04/2014 11:09 AM, Dean Troyer wrote:
On Tue, Feb 4, 2014 at 9:00 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
Can you be more specific about what goes wrong here? I'm not entirely
sure I understand why an old client of arbitrary age needs to be
supported with
On 02/06/2014 05:18 AM, Florent Flament wrote:
Vish:
+1 for hierchical IDs (e.g:
b04f9ea01a9944ac903526885a2666de.c45674c5c2c6463dad3c0cb9d7b8a6d8)
Please keep names and identifiers separate. Identifiers should *NOT* be
hierarchical. Names can be.
Think of the operating system
On 02/01/2014 12:24 PM, Saju M wrote:
Hi folks,
Could you please spend 5 minutes on the blueprint
https://blueprints.launchpad.net/horizon/+spec/user-registration and
add your suggestions in the white board.
Thanks,
___
OpenStack-dev mailing
On 02/24/2014 08:41 AM, Dina Belova wrote:
Cristian, hello
I believe that should not be done in such direct way, really.
Why not using project.extra field in DB to store this info? Is that
not appropriate for your ideas or there will be problems with there
implementing using extras?
It
On 02/26/2014 08:25 AM, Dolph Mathews wrote:
On Tue, Feb 25, 2014 at 2:38 PM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
On Tue, 2014-02-25 at 11:47 -0800, Morgan Fainberg wrote:
For purposes of supporting multiple backends for Identity (multiple
LDAP, mix of
small part of
the patch. I personally favor 2b), since it is simple, has less
moving parts and does not change any external facing requirements for
storage of user and group IDs (above and beyond what is true today).
Henry
On 27 Feb 2014, at 03:46, Adam Young ayo...@redhat.com wrote:
On 02/26/2014
On 03/03/2014 02:32 PM, Jay Pipes wrote:
On Mon, 2014-03-03 at 11:09 -0800, Vishvananda Ishaya wrote:
On Mar 3, 2014, at 6:48 AM, Jay Pipes jaypi...@gmail.com wrote:
On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainberg wrote:
Having done some work with MySQL (specifically around similar data
On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:
For what it's worth in Sahara (former Savanna) we inject the second
key by userdata. I.e. we add
echo ${public_key} ${user_home}/.ssh/authorized_keys
to the other stuff we do in userdata.
Dmitry
2014-03-10 17:10 GMT+04:00 Jiří Stránský
On 03/11/2014 11:42 AM, Sudipta Biswas3 wrote:
Hi all,
I'm hitting a scenario where, a user runs an action against an object
in neutron for which they don't have the authority to perform the
action(perhaps their role allows read of the object, but not update).
The following returned to back
On 03/11/2014 01:20 PM, Clint Byrum wrote:
Excerpts from Adam Young's message of 2014-03-11 07:50:58 -0700:
On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:
For what it's worth in Sahara (former Savanna) we inject the second
key by userdata. I.e. we add
echo ${public_key}
On 03/21/2014 12:33 AM, W Chan wrote:
Can the long running task be handled by putting the target task in the
workflow in a persisted state until either an event triggers it or
timeout occurs? An event (human approval or trigger from an external
system) sent to the transport will rejuvenate
On 03/28/2014 12:15 PM, Hachem Chraiti wrote:
Hi,
Can i have some UML Diagrams for the Ceilometer Project??
Or even diagrams for Keystone too
Sincerly ,
Chraiti Hachem
software engineer
___
OpenStack-dev mailing list
On 03/28/2014 03:01 AM, Tom Fifield wrote:
Thanks to those projects that responded. I've proposed sessions in
swift, ceilometer, tripleO and horizon.
Keystone would also be interested in user feedback, of course.
On 17/03/14 07:54, Tom Fifield wrote:
All,
Many times we've heard a desire
On 04/01/2014 07:36 AM, Yaguang Tang wrote:
Thanks Jamie,
then the following question is do we intend to move other services
client library V3 identity support to python-openstackclient?
AFAIK it's poorly supported for Nova Cinder Neutron client library,
and I am working on add v3 support for
On 10/09/2013 08:43 PM, Fox, Kevin M wrote:
Thanks for the docs. It looks like I got through all of that already, its the
authentication module part that is throwing me.
I managed to manually get a token by putting mod_krb5 on Location
/keystone/main/v2.0/tokens and using curl against it,
On 10/16/2013 12:23 PM, Dolph Mathews wrote:
I'll be finalizing the design summit schedule [1] for keystone
following the weekly meeting [2] on Tuesday, October 22nd 18:00 UTC.
Please have your proposals submitted before then.
So far I think everyone has done a GREAT job self-organizing the
On 10/18/2013 12:04 PM, Brant Knudson wrote:
To provide a bit more background... Keystone has a bunch of
keystoneclient tests for the v2 API. These tests actually git clone
a version of keystoneclient (master, essex-3, and 0.1.1)[0], to use
for testing. Maybe at some point the tests were just
On 10/18/2013 01:54 PM, Sean Dague wrote:
On 10/18/2013 11:59 AM, Dolph Mathews wrote:
On Fri, Oct 18, 2013 at 10:34 AM, Steven Hardy sha...@redhat.com
mailto:sha...@redhat.com wrote:
Hi all,
Starting a thread to discuss $subject, as requested in:
On 10/18/2013 07:21 PM, Sean Dague wrote:
On 10/18/2013 05:09 PM, Dolph Mathews wrote:
On Fri, Oct 18, 2013 at 3:19 PM, David Stanek dsta...@dstanek.com
mailto:dsta...@dstanek.com wrote:
On Fri, Oct 18, 2013 at 1:48 PM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
On 10/23/2013 09:14 AM, Chmouel Boudjnah wrote:
Hello,
If i understand correctly (and I may be wrong) we are moving away from
user_crud to use /credentials for updating password including ec2. The
credentials facility was implemented in this blueprint :
On 10/23/2013 11:35 AM, Dolph Mathews wrote:
On Wed, Oct 23, 2013 at 8:14 AM, Chmouel Boudjnah
chmo...@enovance.com mailto:chmo...@enovance.com wrote:
Hello,
If i understand correctly (and I may be wrong) we are moving away
from user_crud to use /credentials for updating
On 10/29/2013 12:18 PM, Tim Bell wrote:
We also need some standardisation on the command line options for the client
portion (such as --os-auth-method, --os-x509-cert etc.) . Unfortunately, this
is not yet in Oslo so there would be multiple packages to be enhanced.
There is a OS client talk on
On 10/30/2013 05:38 AM, Álvaro López García wrote:
On Tue 29 Oct 2013 (17:04), Adam Young wrote:
On 10/29/2013 12:18 PM, Tim Bell wrote:
We also need some standardisation on the command line options for the client
portion (such as --os-auth-method, --os-x509-cert etc.) . Unfortunately
On 10/29/2013 06:29 AM, Thierry Carrez wrote:
Dina Belova wrote:
There is no such mixed calendar. It was made, as far as I remember,
because design and summit talks are very different and should be separated.
But still, it is not really comfortable.
Yes, it's a bit of a trade-off...
In the
On 10/31/2013 03:40 PM, Steven Hardy wrote:
Hi all,
So firstly, if you're an XML guru, I apologize, the questions below are
probably really basic, I always prefer JSON or YAML, because every time I
deal with XML, I get a week-long-headache ;)
So I'm writing Tempest API tests for the keystone
On 10/31/2013 03:24 PM, Jeremy Stanley wrote:
On 2013-10-31 13:30:32 + (+), Mark McLoughlin wrote:
[...]
In cases like that, I'd be of a mind to go +2 Awesome! Thanks for
catching this! It would be great to have a unit test for this, but
it's clear the current code is broken so I'm fine
On 10/31/2013 07:58 PM, Adam Young wrote:
On 10/31/2013 03:40 PM, Steven Hardy wrote:
Hi all,
So firstly, if you're an XML guru, I apologize, the questions below are
probably really basic, I always prefer JSON or YAML, because every
time I
deal with XML, I get a week-long-headache ;)
So I'm
On 11/01/2013 04:58 AM, Steven Hardy wrote:
On Thu, Oct 31, 2013 at 09:40:46PM -0400, Adam Young wrote:
snip
I think it is safe to say that the trusts API is broken in XML. I
added the following test:
diff --git a/keystone/tests/test_v3_auth.py b/keystone/tests/test_v3_auth.py
index c0e191b
On 11/11/2013 03:00 PM, Morgan Fainberg wrote:
David,
My concern with this approach is that keystone currently doesn't have
the mechanisms to handle a polling job (no such thing as periodic
tasks like in nova) and we go to some fairly extreme effort to not use
eventlet anywhere. We also
On 11/06/2013 07:20 PM, Miller, Mark M (EB SW Cloud - RD - Corvallis)
wrote:
Hello,
I am trying to front all of the Grizzly OpenStack services with Apache2 in
order to enable SSL. I've got Horizon and Keystone working but am struggling
with Nova. The only documentation I have been able to
On 11/14/2013 10:52 AM, Álvaro López García wrote:
Hi all,
During the review of [1] I had a look at the tests that are related
with external authentication (i.e. the usage of REMOTE_USER) in
Keystone and I realised that there is a bunch of them that are setting
external as one of the
On 11/14/2013 10:03 AM, Steven Hardy wrote:
On Wed, Nov 13, 2013 at 10:04:04AM -0600, Dolph Mathews wrote:
I guarantee there's a few things I'm forgetting, but this is my collection
of things we discussed at the summit and determined to be good things to
pursue during the icehouse timeframe.
On 11/14/2013 03:42 AM, Jesse Pretorius wrote:
On 13 November 2013 23:39, Miller, Mark M (EB SW Cloud - RD -
Corvallis) mark.m.mil...@hp.com mailto:mark.m.mil...@hp.com wrote:
I finally found a set of web pages that has a working set of
configuration files for the major OpenStack
On 11/10/2013 07:26 PM, Paul Belanger wrote:
Greeting,
In a previous thread I talked about building an application atop of
horizon and keystone. So far things are working out pretty well. One
thing I have been trying to figure out is how to move forward with
user registration for the horizon
On 11/14/2013 11:39 AM, Tim Hinrichs wrote:
I completely agree that making Congress successful will rely crucially on
addressing performance and scalability issues. Some thoughts...
1. We're definitely intending to cache data locally to avoid repeated API
calls. In fact, a prototype cache
On 11/14/2013 07:37 PM, Avi L wrote:
I have installed openstack-keystone-2013.2-0.11.b3.el6.noarch rpm and
I added a active directory user test123 with role admin and tenant
admin successfully.
However when I run keystone user-list if gives me the following error:
Authorization Failed: An
On 11/15/2013 11:15 AM, Ben Nemec wrote:
This list is for development discussion only. Since this sounds like
a question specific to RHEL, might I suggest you ask it on
http://openstack.redhat.com/forum/ ?
Nah, this is legit.
Thanks.
-Ben
On 2013-11-15 10:13, Abhishek Lahiri wrote:
On 11/18/2013 07:01 PM, Tiwari, Arvind wrote:
Hi,
Based on our discussion in design summit , I have redone the
service_id binding with roles BP
https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition.
I have added a new BP (link below) along with detailed use
On 11/19/2013 08:21 AM, Dolph Mathews wrote:
Related BP:
Create a unified request identifier
https://blueprints.launchpad.net/nova/+spec/cross-service-request-id
And we have discussed workplans as well, which would be data to be
carried along with the request id
On 11/21/2013 01:55 AM, Russell Bryant wrote:
Greetings,
I'd like to check in on the status of this API addition:
https://review.openstack.org/#/c/40692/
The last comment is:
propose against stackforge as discussed at summit?
Yes, it was discussed in a small group, and not
On 11/21/2013 03:08 PM, Jarret Raim wrote:
The Barbican team has been taking a look at the KDS feature and the
proposed patch and I think this may be better placed in Barbican rather
than Keystone. The patch, from what I can tell, seems to require that a
service account create use a key under
On 11/22/2013 01:49 PM, Mark McLoughlin wrote:
On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote:
Russell Bryant wrote:
[...]
I'm not thrilled about the prospect of this going into a new project for
multiple reasons.
- Given the priority and how long this has been dragging out, having
The #1 pain point I hear from people in the field is that they need to
consume read only LDAP but have service users in something Keystone
specific. We are close to having this, but we have not closed the
loop. This was something that was Henry's to drive home to completion.
Do we have a
...@openstack.org]
Sent: Monday, November 25, 2013 4:17 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution
Server, Trusted Messaging
Adam Young wrote:
Keep KDS configuration separate from the Keystone configuration: the
fact
On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
Hi Adam,
Based on our discussion over IRC, I have updated the below etherpad with
proposal for nested role definition
Updated. I made my changes Green. It isn't easy being green.
In order to provide Devstack a better certificate management example, we
want to make devstack capable of calling Certmaster.
This package is in Debian, but not in Ubuntu.
For example
http://packages.debian.org/experimental/certmaster
How does one go about installing a package like this for
On 11/29/2013 10:06 AM, Mark McLoughlin wrote:
Hey
Anyone got an update on this?
The keystone blueprint for KDS was marked approved on Tuesday:
https://blueprints.launchpad.net/keystone/+spec/key-distribution-server
and a new keystone review was added on Sunday, but it must be a draft
On 11/27/2013 12:45 AM, Takahiro Shida wrote:
Hi all,
I'm also interested in this issue.
Create a unified request identifier
https://blueprints.launchpad.net/nova/+spec/cross-service-request-id
I checked this BP and the following review.
https://review.openstack.org/#/c/29480/
There are
On 12/02/2013 08:20 PM, Chuck Short wrote:
On Mon, Dec 2, 2013 at 6:21 PM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
On 12/02/2013 06:15 PM, Adam Young wrote:
In order to provide Devstack a better certificate management
example, we
want to make devstack
I've been thinking about your comment that nested roles are confusing
What if we backed off and said the following:
Some role-definitions are owned by services. If a Role definition is
owned by a service, in role assignment lists in tokens, those roles we
be prefixd by the service name. /
On 11/26/2013 12:07 PM, Maru Newby wrote:
Keystone is almost finished replacing the term 'tenant' with 'project' (see
recent thread
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09709.html)
and we might want to think about how and when Neutron makes a similar
transition.
that the
default domain can show up as an empty string. Thus, project scoped
roles from the default domain would be:
\glance\admin
and from a non default domain
domX\glance\admin
regards
David
On 04/12/2013 01:51, Adam Young wrote:
I've been thinking about your comment that nested
role for the y project in domain x
//x/admin means admin for service x from the default domain
etc.
will that work?
Very clean. Yes. That will work.
regards
David
On 04/12/2013 15:04, Adam Young wrote:
On 12/04/2013 04:08 AM, David Chadwick wrote:
I am happy with this as far as it goes. I
1 - 100 of 560 matches
Mail list logo
