decided to GO-TO a trip around the world...who can
we pull in to make this flow in with the rest of Horizon?
regards
David
On 18/02/2015 16:06, Dolph Mathews wrote:
On Fri, Feb 6, 2015 at 12:47 PM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 02/04/2015 03:54 PM, Thai
On 02/16/2015 02:21 PM, Samuel Merritt wrote:
On 2/14/15 9:49 PM, Adam Young wrote:
On 02/13/2015 04:19 PM, Morgan Fainberg wrote:
On February 13, 2015 at 11:51:10 AM, Lance Bragstad
(lbrags...@gmail.com mailto:lbrags...@gmail.com) wrote:
Hello all,
I'm proposing the Authenticated
On 02/13/2015 04:19 PM, Morgan Fainberg wrote:
On February 13, 2015 at 11:51:10 AM, Lance Bragstad
(lbrags...@gmail.com mailto:lbrags...@gmail.com) wrote:
Hello all,
I'm proposing the Authenticated Encryption (AE) Token specification
[1] as an SPFE. AE tokens increases scalability of
.
On Wed, Feb 11, 2015 at 9:10 PM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote:
No, I just checked it. Nova receives trust token and raise this
error.
In my script, I see:
http://paste.openstack.org/show/171452
On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:
Hi !
I investigated trust's use cases and encountered the problem: When I
use auth_token obtained from keystoneclient using trust, I get *403*
Forbidden error: *You are not authorized to perform the requested action.*
Steps to reproduce:
-
as, not the project in question. If these two values
don't match, then, yes, the rule would fail.
|
On Wed, Feb 11, 2015 at 7:55 PM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:
Hi !
I investigated trust's use
On 02/10/2015 12:51 PM, Morgan Fainberg wrote:
Hi everyone!
I wanted to propose Marek Denis (marekd on IRC) as a new member of the
Keystone Core team. Marek has been instrumental in the implementation
of Federated Identity. His work on Keystone and first hand knowledge
of the issues with
On 02/04/2015 03:54 PM, Thai Q Tran wrote:
Hi all,
I have been helping with the websso effort and wanted to get some
feedback.
Basically, users are presented with a login screen where they can
select: credentials, default protocol, or discovery service.
If user selects credentials, it works
On 02/05/2015 04:20 AM, Anton Zemlyanov wrote:
Hi,
I guess Credentials is login and password. I have no idea what is
Default Protocol or Discovery Service.
The proposed UI is rather embarrassing.
No it is not. It is a rapid prototyping technique to get things to fail
fast, and to get
Drop. It is wasting cycles, and not something we should use in
production. Migrations specific to SQLPlus are the most time consuming
work-arounds we have. SQLPlus does not suit our development approach.
On 02/03/2015 01:32 PM, Georgy Okrokvertskhov wrote:
I think we should switch to
On 01/30/2015 07:23 AM, Sandy Walsh wrote:
From: Johannes Erdfelt [johan...@erdfelt.com]
Sent: Thursday, January 29, 2015 9:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] SQL Schema Downgrades
On 01/29/2015 03:11 PM, Mike Bayer wrote:
Morgan Fainberg morgan.fainb...@gmail.com wrote:
Are downward migrations really a good idea for us to support? Is this downward
migration path a sane expectation? In the real world, would any one really
trust the data after migrating downwards?
On 01/30/2015 02:19 AM, Thomas Spatzier wrote:
From: Zane Bitter zbit...@redhat.com
To: openstack Development Mailing List
openstack-dev@lists.openstack.org
Date: 29/01/2015 17:47
Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in
Heat
I got a question today about
Short term answers:
The amount of infrastructure we would have to build to replicate CRON is
not worth it.
Figuring out a CRON strategy for nontrivial deployment is part of a
larger data management scheme.
Long term answers:
Tokens should not be persisted. We have been working toward
On 01/27/2015 05:19 PM, Jim Meyer wrote:
+1 all the way down.
More fun double-plus-good.
—j
On Jan 27, 2015, at 1:50 PM, Monty Taylor mord...@inaugust.com wrote:
I do not like how we are selecting names for our releases right now.
The current process is autocratic and opaque and not fun -
On 01/18/2015 02:11 PM, Morgan Fainberg wrote:
Hello all,
I would like to nominate Brad Topol for Keystone Spec core (core
reviewer for Keystone specifications and API-Specification only:
https://git.openstack.org/cgit/openstack/keystone-specs ). Brad has
been a consistent voice advocating
On 01/16/2015 12:37 AM, Abhishek Talwar/HYD/TCS wrote:
Hi,
I have been trying to debug the test cases in OpenStack, but I am not
getting successful with it. So if someone can help me with that. The
last response from the dev-list was to use $ ./run_tests.sh -d [test
module path] but this
On 01/06/2015 09:28 PM, Steve Martinelli wrote:
Howdy,
https://etherpad.openstack.org/p/kilo-keystone-midcycle
https://etherpad.openstack.org/p/kilo-nova-midcycleis the etherpad
for the Keystone midcycle meetup. Similar to the Nova team, we should
start
collecting topics to cover, and sort
On 12/30/2014 11:47 AM, Jeremy Stanley wrote:
On 2014-12-30 10:32:22 -0600 (-0600), Dolph Mathews wrote:
The default behavior, rebasing automatically, is the sane default
to avoid having developers run into unexpected merge conflicts on
new patch submissions.
Please show me an example of this
On 12/23/2014 11:34 AM, David Chadwick wrote:
Hi guys
we now have the ABFAB federation protocol working with Keystone, using a
modified mod_auth_kerb plugin for Apache (available from the project
Moonshot web site). However, we did not change Keystone configuration
from its original SAML
On 12/09/2014 10:57 AM, Brad Topol wrote:
+1! Makes sense.
--Brad
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From: Morgan Fainberg morgan.fainb...@gmail.com
To: Adam Young ayo
On 12/09/2014 12:18 PM, Morgan Fainberg wrote:
I would like to propose that we keep the policy library under the oslo
program. As with other graduated projects we will maintain a core team
(that while including the oslo-core team) will be comprised of the
expected individuals from the Identity
Isn't this what the API repos are for? Should EG the Keystone schemes
be served from
https://github.com/openstack/identity-api/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 12/04/2014 01:44 PM, Stefano Maffulli wrote:
On 12/04/2014 09:24 AM, Anita Kuno wrote:
I think we move into very dangerous territory if we are equating a core
review Gerrit permission (it is just a Gerrit permission, if it is
perceived as anything other than that that is a perception we have
On 12/03/2014 06:24 PM, Sukhdev Kapur wrote:
Congratulations Henry and Kevin. It has always been pleasure working
with you guys.
If I may express my opinion, Bob's contribution to ML2 has been quite
substantial. The kind of stability ML2 has achieved makes a statement
of his dedication
On 12/02/2014 12:39 AM, Richard Jones wrote:
On Mon Dec 01 2014 at 4:18:42 PM Thai Q Tran tqt...@us.ibm.com
mailto:tqt...@us.ibm.com wrote:
I agree that keeping the API layer thin would be ideal. I should
add that having discrete API calls would allow dynamic population
of table.
On 12/01/2014 09:09 AM, Doug Hellmann wrote:
On Nov 30, 2014, at 8:51 PM, Jamie Lennox jamielen...@redhat.com wrote:
TL;DR: I think we can handle most of oslo.context with some additions to
auth_token middleware and simplify policy enforcement (from a service
perspective) at the same time.
On 11/26/2014 09:52 AM, David Chadwick wrote:
I tend to agree with Morgan. There are resources and there are users.
And there is something in the middle that says which users can access
which resources. It might be an ACL, a RBAC role, or a set of ABAC
attributes, or something else (such as a
On 11/23/2014 06:13 PM, Robert Collins wrote:
On WSGI - if we're in an asyncio world, I don't think WSGI has any
relevance today - it has no async programming model. While is has
incremental apis and supports generators, thats not close enough to
the same thing: so we're going to have to port
We started an etherpad to gather requirements etc:
https://etherpad.openstack.org/p/mapping-engine-enhancements
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
There is a lot of discussion about policy. I've attempted to pull the
majority of the work into a single document that explains the process in
a step-by-step manner:
http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
Its really long, so I won't bother reposting the whole article
On 11/14/2014 09:05 AM, Thomas Goirand wrote:
That's a reasonable amount of work. Multiply this by 2 for the xstatic
packages (if we keep using that), that's about 14 new packages.
By the way, can't we use libjs-sockjs instead of ng-websocket?
Last, I'm ok if we add all these, but please,
On 11/12/2014 02:06 PM, Doug Hellmann wrote:
During our “Graduation Schedule” summit session we worked through the list of
modules remaining the in the incubator. Our notes are in the etherpad [1], but as
part of the Write it Down” theme for Oslo this cycle I am also posting a
summary of the
On 11/12/2014 06:21 AM, Darren Kenny wrote:
Chris Dent wrote:
On Tue, 11 Nov 2014, Adam Young wrote:
My suggestion, from a while ago, was to have a naming scheme that
deconflicts putting all of the services onto a single server, on
port 443.
+1
The current state of affairs is indeed weird
On 11/12/2014 03:03 AM, Matthias Runge wrote:
On 12/11/14 08:40, Richard Jones wrote:
I believe the nodeenv method of installing node solves this, as it's
entirely local to the development environment.
See below, this touches package build as well.
I will have to go through all
Recent recurrence of the Why ios everything on its own port question
triggered my desire to take this pattern and put it to rest.
My suggestion, from a while ago, was to have a naming scheme that
deconflicts putting all of the services onto a single server, on port 443.
I've removed a lot of
On 11/11/2014 05:47 PM, Ian Cordasco wrote:
On 11/11/14, 16:35, Adam Young ayo...@redhat.com wrote:
Recent recurrence of the Why ios everything on its own port question
triggered my desire to take this pattern and put it to rest.
My suggestion, from a while ago, was to have a naming scheme
On 11/11/2014 06:31 PM, Dave Walker wrote:
On 11 November 2014 22:35, Adam Young ayo...@redhat.com wrote:
Recent recurrence of the Why ios everything on its own port question
triggered my desire to take this pattern and put it to rest.
My suggestion, from a while ago, was to have a naming
On 11/11/2014 08:18 PM, Morgan Fainberg wrote:
I am trying to pin down a location for our mid-cycle meetup, I need to
get an idea of who will be joining us at the Keystone meetup. I’ve
included a couple questions relating to Barbican in the case we can
double-up and have a day of overlap like
On 11/01/2014 06:51 PM, Alan Pevec wrote:
%install
export OSLO_PACKAGE_VERSION=%{version}
%{__python} setup.py install -O1 --skip-build --root %{buildroot}
Then everything should be ok and PBR will become your friend.
Still not my friend because I don't want a _build_ tool as runtime
On 11/02/2014 07:23 AM, Mark Atwood wrote:
I will also try to get more keybase.io invites, for those who want them.
keybase.io is a web service that provides an independently provable
binding between your social media and github identities, and your gpg
key.
I have been granted *many* invites
On 11/10/2014 07:35 PM, Thomas Goirand wrote:
On 10/28/2014 02:53 AM, Marty Falatic (mfalatic) wrote:
I'm relatively new to the keysigning *event* concept - can
someone give a little more detail on this and where it
comes into play? Does anyone else use a service (e.g.,
keybase.io) for this
On 11/01/2014 11:29 AM, Kashyap Chamarthy wrote:
On Sat, Nov 01, 2014 at 09:13:21PM +0800, Thomas Goirand wrote:
Hi,
I was wondering if some distribution OpenStack package maintainers
would be interested to have some cross-distribution discussion on
Friday, during the contributors sessions.
In certmonger 0.75.13 you can use local-getcert and it will have a
signing cert (selfsigned CA cert). This allows us to replace the
keystone-manage ssl_swetup and pki_setup with certmonger calls.
This should be the plan moving forward, with Certmonger/Barbican
integration a short term
On 10/09/2014 03:36 PM, Duncan Thomas wrote:
On 9 October 2014 07:49, henry hly henry4...@gmail.com wrote:
Hi Joshua,
...in fact hierarchical scale
depends on square of single child scale. If a single child can deal
with 00's to 000's, cascading on it would then deal with 00,000's.
That is
On 10/16/2014 03:18 PM, Dave Walker wrote:
On 16 October 2014 20:07, David Stanek dsta...@dstanek.com wrote:
SNIP
I may be missing something, but can you use the external auth method with
the LDAP backend?
No, as the purpose of the LDAP backend is to validate user/pass
combination are valid.
On 10/16/2014 02:58 PM, David Chadwick wrote:
Dave
when federation is used, the user's group is stored in a mapping rule.
So we do have a mechanism for storing group memberships without using
LDAP or creating an entry for the user in the SQL backend. (The only
time this is kinda not true is if
On 10/15/2014 11:49 AM, Kevin L. Mitchell wrote:
Now that we have an API working group forming, I'd like to kick off some
discussion over one point I'd really like to see our APIs using (and
I'll probably drop it in to the repo once that gets fully set up): the
difference between synchronous and
to User delegations appropriate for long
running tasks. So, yeah, should work for these use cases.
(Pulled up what I could find on trusts. Need to chew on this a bit,
as it is not immediately clear if this fits.)
On Wed, Oct 1, 2014 at 6:53 AM, Adam Young ayo...@redhat.com
mailto:ayo
There are two distinct permissions to be managed:
1. What can the user do.
2. What actions can this token be used to do.
2. is a subset of 1.
Just because I, Adam Young, have the ability to destroy the golden image
I have up on glance does not mean that I want to delegate that ability
On 10/09/2014 09:31 AM, John Dennis wrote:
On 10/08/2014 04:58 PM, Adam Young wrote:
When gyee posted his X509 server-side auth plugin patch, the feedback
we gave was that it should be using the mapping code from Federation to
transform the environment variables set by the web server
When gyee posted his X509 server-side auth plugin patch, the feedback
we gave was that it should be using the mapping code from Federation to
transform the environment variables set by the web server to the
Keystone userid, username, domain name, and so forth.
The PKI token format currently
Horizon has a config options which says which version of the Keystone
API it should work against: V2 or V3. I am not certain that there is
still any reason for Horizon to go against V2. However, If we defer the
decision to Keystone, we come up against the problem of discovery.
On the
On 10/06/2014 05:28 PM, Anita Kuno wrote:
On 10/06/2014 04:11 PM, Adam Young wrote:
On 10/06/2014 03:25 PM, Patricia Ellis wrote:
Hi Adam,
Thanks for taking the time to reply.
I'm more of a web development type than security. I have some maths
background so perhaps something with data
On 10/07/2014 02:10 PM, Jay Faulkner wrote:
On Oct 7, 2014, at 10:38 AM, Adam Young ayo...@redhat.com wrote:
We should come up with a published list of intern and senior projects
proposals
I know there is a low-hanging-fruit tag in the bug tracker, and this summer
when we had two interns
:38 PM, Adam Young wrote:
On 10/06/2014 05:28 PM, Anita Kuno wrote:
On 10/06/2014 04:11 PM, Adam Young wrote:
I am looking to get someone to work on a Javascript based web client
to
replace Horizon.
Can I just say that I think using new people looking to have work
experience with OpenStack
On 10/06/2014 01:14 PM, Patricia Ellis wrote:
My name is Patricia Ellis, I am a fourth year software development
student at Cork Institute of Technology. I am looking for ideas for my
final year project. I have six weeks to get my proposal together and
then 13 weeks to implement it. I am
considering here:
https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+owner:%22ayoung+%253Cayoung%2540redhat.com%253E%22,n,z
On 6 October 2014 18:37, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 10/06/2014 01:14 PM, Patricia Ellis wrote:
My
On 10/01/2014 04:14 AM, Steven Hardy wrote:
On Tue, Sep 30, 2014 at 10:44:51AM -0400, Adam Young wrote:
What is keeping us from dropping the (scoped) token duration to 5 minutes?
If we could keep their lifetime as short as network skew lets us, we would
be able to:
Get rid of revocation
What is keeping us from dropping the (scoped) token duration to 5 minutes?
If we could keep their lifetime as short as network skew lets us, we
would be able to:
Get rid of revocation checking.
Get rid of persisted tokens.
OK, so that assumes we can move back to PKI tokens, but we're
On 09/30/2014 12:21 PM, Sean Dague wrote:
On 09/30/2014 11:58 AM, Jay Pipes wrote:
On 09/30/2014 11:37 AM, Adam Young wrote:
On 09/30/2014 11:06 AM, Louis Taylor wrote:
On Tue, Sep 30, 2014 at 10:44:51AM -0400, Adam Young wrote:
What are the uses that require long lived tokens?
Glance has
On 09/30/2014 12:10 PM, John Griffith wrote:
On Tue, Sep 30, 2014 at 7:35 AM, John Garbutt j...@johngarbutt.com
mailto:j...@johngarbutt.com wrote:
On 30 September 2014 14:04, joehuang joehu...@huawei.com
mailto:joehu...@huawei.com wrote:
Hello, Dear TC and all,
Large
On 09/30/2014 12:21 PM, Sean Dague wrote:
On 09/30/2014 11:58 AM, Jay Pipes wrote:
On 09/30/2014 11:37 AM, Adam Young wrote:
On 09/30/2014 11:06 AM, Louis Taylor wrote:
On Tue, Sep 30, 2014 at 10:44:51AM -0400, Adam Young wrote:
What are the uses that require long lived tokens?
Glance has
This is comparable to the HEAT use case that Keystone Trusts were
originally designed to solve.
If the glance client knows the roles required to perform those
operations, it could create the trust up front, with the Glance
Service user as the trustee; the trustee execute the trust when it
On 09/29/2014 12:12 PM, Jay Pipes wrote:
Hey Stackers,
So, I had a thought this morning (uh-oh, I know...).
What if we wrote a token driver in Keystone that uses Swift for
backend storage?
I have long been an advocate of the memcache token driver versus the
SQL driver for performance
On 09/25/2014 10:38 PM, Robert Collins wrote:
On 26 September 2014 14:18, Adam Young ayo...@redhat.com wrote:
There are a few Keystone features that are coming together for Kilo.
...
For endpoint binding, an endpoint will have to know its own id. So the
endpoint_id will be recorded
There are a few Keystone features that are coming together for Kilo.
Endpoint binding of tokens is one, and I think can be handled completely
in keystonemiddelware.auth_token. Another, though, is based on a few
requests we've had to be able to have policy performed against a
specific object
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 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/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/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/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/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
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
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
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
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/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/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
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 07/11/2014 11:55 AM, Flavio Percoco wrote:
On 07/11/2014 05:43 PM, Morgan Fainberg wrote:
The Keystone team is happy to announce that as of yesterday (July 10th 2014),
with the merge of https://review.openstack.org/#/c/100747/ Keystone is now
gating on Apache + mod_wsgi based deployment.
On 07/14/2014 11:47 AM, Steven Hardy wrote:
Hi all,
I'm probably missing something, but can anyone please tell me when devstack
will be moving to keystone v3, and in particular when API auth_token will
be configured such that auth_version is v3.0 by default?
Some months ago, I posted this
Summary of the discussion in #openstack-keystone.
Policy in OpenStack is the mechanism by which Role-Based-Access-Control
is implemented. Policy is distributed in rules files which are processed
at the time of a user request. Audit has come to mean the automated
emission and collection of
On 07/07/2014 05:39 AM, Marco Fargetta wrote:
On Fri, Jul 04, 2014 at 06:13:30PM -0400, Adam Young wrote:
Unscoped tokens are really a proxy for the Horizon session, so lets
treat them that way.
1. When a user authenticates unscoped, they should get back a list
of their projects:
some thing
On 07/07/2014 10:33 AM, Marco Fargetta wrote:
3. Unscoped tokens should be very short lived: 10 minutes.
Unscoped tokens should be infinitely extensible: If I hand an
unscoped token to keystone, I get one good for another 10 minutes.
Using this time limit horizon should extend all the
On 07/07/2014 11:11 AM, Dolph Mathews wrote:
On Fri, Jul 4, 2014 at 5:13 PM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
Unscoped tokens are really a proxy for the Horizon session, so
lets treat them that way.
1. When a user authenticates unscoped, they should
On 07/07/2014 01:16 PM, Victor Lowther wrote:
As one of the original authors of dracut, I would love to see it being
used to build initramfs images for TripleO. dracut is flexible, works
across a wide variety of distros, and removes the need to have
special-purpose toolchains and packages for
Probably should not have posted this over a weekend, especially a Long
weekend.
On 07/04/2014 06:13 PM, Adam Young wrote:
Unscoped tokens are really a proxy for the Horizon session, so lets
treat them that way.
1. When a user authenticates unscoped, they should get back a list
Unscoped tokens are really a proxy for the Horizon session, so lets
treat them that way.
1. When a user authenticates unscoped, they should get back a list of
their projects:
some thing along the lines of:
domains [{ name = d1,
projects [ p1, p2, p3]},
{
On 07/03/2014 04:48 PM, David Kranz wrote:
While moving success response code checking in tempest to the client,
I noticed that exactly one of the calls to list users for a tenant
checked for 200 or 203. Looking at
http://docs.openstack.org/api/openstack-identity-service/2.0/content/,
it
On 06/05/2014 05:25 PM, Tahmina Ahmed wrote:
Dear all,
I am trying to use neo4j graph database instead of mysql for my
keystone would you please help with any documentation or ideas how I
need to write the driver.
No clue about Graph Databases myself. You should pick one backend,
301 - 400 of 560 matches
Mail list logo
