OK, so I'm cranking on All of the Kerberso stuff: plus S4U2Proxy work
etcexcept that I have never worked with DJango directly before. I
want to get a sanity check on my approach:
Instead of authenticating to Keystone, Horizon will use mod_auth_krb5
and REMOTE_USER to authenticate the
guessing that I would really need to write
django-openstack-kerberos-backend to merge the logic from
RemoteUserBackend with django_openstack_auth; I think I want the logic
of django_openstack_auth.backend.KeystoneBackend.authenticate
All the best,
-Gabriel
*From:*Adam Young [mailto:ayo
On 05/28/2014 11:59 AM, David Chadwick wrote:
Hi Everyone
at the Atlanta meeting the following slides were presented during the
federation session
http://www.slideshare.net/davidwchadwick/keystone-apach-authn
It was acknowledged that the current design is sub-optimal, but was a
best first
.
Thanks,
Tizy
On Tue, May 20, 2014 at 8:27 AM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 05/16/2014 05:08 AM, Tizy Ninan wrote:
Hi,
We have an openstack Havana deployment on CentOS 6.4 and
nova-network network service installed using Mirantis Fuel v4.0
On 05/28/2014 07:43 PM, Ben Nemec wrote:
This is a development list, please ask usage questions on the users
list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Thanks.
Ordinarily I would ordinarily agree, but this is getting into stuff that
devs need to discuss.
-Ben
On
The Keystone team is going to be making sure the code that needs to be
in by J2 is in. That means the API changes.
I'll be there.
On 05/23/2014 03:09 AM, Clark, Robert Graham wrote:
I’d like to attend all the Barbican stuff and I’m sure there’ll be some
interesting Keystone things too.
I've been looking in to enabling Kerberos for Horizon. Since Horizon
passes the Users credentials on to Keystone to get a token, Kerberos
requires an additional delegation mechanism. This leads to some
questions about how to handle delegation in the case of Federated Identity.
In
On 05/22/2014 07:03 PM, Maru Newby wrote:
On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com wrote:
Maru's concerns are that:
1. It is large
2. It is complex
As per the discussion in the irc meeting today, I hope it is clear now that
eventual size and complexity are not real
On 05/20/2014 09:39 PM, Bohai (ricky) wrote:
Thanks for your explanation.
I think the implement in nova maybe is a good reference.
I have filed it to a blueprint.
https://blueprints.launchpad.net/cinder/+spec/united-policy-in-cinder
Would like to load policy from the policy store in
On 05/21/2014 11:09 AM, Chuck Thier wrote:
There is a review for swift [1] that is requesting to set the max
header size to 16k to be able to support v3 keystone tokens. That
might be fine if you measure you request rate in requests per minute,
but this is continuing to add significant
On 05/21/2014 02:00 PM, Kurt Griffiths wrote:
adding another ~10kB to each request, just to save a once-a-day call to
Keystone (ie uuid tokens) seems to be a really high price to pay for not
much benefit.
I have the same concern with respect to Marconi. I feel like KPI tokens
are fine for
On 05/21/2014 03:36 PM, Kurt Griffiths wrote:
Good to know, thanks for clarifying. One thing I'm still fuzzy on,
however, is why we want to deprecate use of UUID tokens in the first
place? I'm just trying to understand the history here...
Because they are wasteful, and because they are the
On 05/21/2014 08:23 PM, John Dickinson wrote:
On May 21, 2014, at 4:26 PM, Adam Young ayo...@redhat.com wrote:
On 05/21/2014 03:36 PM, Kurt Griffiths wrote:
Good to know, thanks for clarifying. One thing I'm still fuzzy on, however, is
why we want to deprecate use of UUID tokens in the first
On 05/12/2014 10:25 PM, Dmitri Zimine wrote:
The problem: Keystone authentication on MAC works from command line,
but fails when run from PyCharm. And I want to run PyCharm to debug!
The root cause: Keystone uses openssl cms which is only available in
new openssl. I installed openssl via
On 05/16/2014 05:08 AM, Tizy Ninan wrote:
Hi,
We have an openstack Havana deployment on CentOS 6.4 and nova-network
network service installed using Mirantis Fuel v4.0.
We are trying to integrate the openstack setup with the Microsoft
Active Directory(LDAP server). I only have a read access
While we are waiting to see if the Nova specs process works out, I have
started a personal copy of the repo and tailored it to Keystone:
https://github.com/admiyo/keystone-specs/
I've made use of it for a Blueprint
https://blueprints.launchpad.net/keystone/+spec/crls
Which is only partially
On 05/08/2014 07:55 PM, Tiwari, Arvind wrote:
Hi All,
Below is my proposal to address VPC use case using hierarchical
administrative boundary. This topic is scheduled in Hierarchical
Multitenancy
http://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U2wYXXKLR_9
session
On 05/06/2014 09:01 PM, Roman Sokolkov wrote:
Tizy,
Selinux is disabled on all nodes under Fuel.
https://github.com/stackforge/fuel-library/blob/stable/4.0/deployment/puppet/cobbler/templates/kickstart/centos.ks.erb#L32
You could check it by getenforce command. It should report
On 05/02/2014 03:06 PM, Rob Crittenden wrote:
TL;DR
Work is happening on a unified client library. This provides the
opportunity to rework the way SSL options are handled. Can we discuss
this in one of the sessions at the Atlanta Summit in a few weeks?
Good survey, thanks.
On 04/30/2014 10:06 AM, Robert Li (baoli) wrote:
Hi John,
With the summit around the corner, please advise how we should run
this session: http://summit.openstack.org/cfp/details/248
We are currently working on this nova spec,
https://review.openstack.org/#/c/86606/. I guess its content
On 04/28/2014 02:07 PM, Pitucha, Stanislaw Izaak wrote:
Hi all,
I've seen some blueprints/wikis from people interested in certificate
signing via barbican orders, so hopefully you'll have some feedback.
I submitted a proposal for certificate/signing order API at
On 04/17/2014 07:17 AM, Roman Bodnarchuk wrote:
Hello,
Right now I am trying to set-up a self-signup for users of our
OpenStack cloud. One of the essential points of this signup is
verification of user's email address - until a user proves that this
address belongs to him/her, he/she should
On 04/18/2014 11:21 AM, Stephen Balukoff wrote:
Howdy, folks!
Could someone explain to me the SSL usage scenario where it makes
sense to re-encrypt traffic traffic destined for members of a back-end
pool? SSL termination on the load balancer makes sense to me, but I'm
having trouble
As we get closer to the summit, I'd like to make sure we have resolution
on one of the most critical issues in Keystone. How to deal with users
coming out of multiple data sources.
The issue is that a userid out of one domain must fill two requirements:
1. one userid cannot conflict with a
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 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 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/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/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/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/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
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 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
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/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/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/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
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?
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
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
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
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
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 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
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
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:
/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
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
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
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.
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/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.
...@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
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
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
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/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/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/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/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/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/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/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 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 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 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/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/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:
401 - 500 of 560 matches
Mail list logo
