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 AM, Dolph Mathews dolph.math...@gmail.com
wrote:
To clarify: we already have to include the groups
.
--Morgan
Sent via mobile
On Jun 3, 2015, at 18:44, Dolph Mathews *dolph.math...@gmail.com*
dolph.math...@gmail.com wrote:
On Wed, Jun 3, 2015 at 5:58 PM, John Wood *john.w...@rackspace.com*
john.w...@rackspace.com wrote:
Hello folks,
There has been discussion about adding user group support
On Wed, Jun 3, 2015 at 5:58 PM, John Wood john.w...@rackspace.com 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
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
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
Developers can handle ASCII. Developers can't handle steel blue versus
cornflower blue.
But seriously, graphics collaboratively authored by developers should,
ideally, be editable via a text file. Otherwise they won't be maintained.
On Tue, May 12, 2015 at 8:31 PM, Devananda van der Veen
On Monday, May 4, 2015, Flavio Percoco fla...@redhat.com wrote:
On 02/05/15 12:02 -0700, Morgan Fainberg wrote:
On May 2, 2015, at 10:28, Monty Taylor mord...@inaugust.com wrote:
On 05/01/2015 09:16 PM, Jamie Lennox wrote:
Hi all,
At around the time Barbican was applying for
On Thursday, May 7, 2015, Adam Young ayo...@redhat.com wrote:
On 05/06/2015 06:54 PM, Hu, David J (Converged Cloud) wrote:
david8hu One of the first thing we have to do is get all of our glossary
straight J I am starting to hear about “capability”. Are we talking
about “rule” in oslo
On Mon, Apr 27, 2015 at 6:46 AM, Ajaya Agrawal ajku@gmail.com wrote:
On Mon, Apr 27, 2015 at 6:05 AM, Jamie Lennox jamielen...@redhat.com
wrote:
Not to speak for Brant, but i think the confusion here is why you are
doing this. From my perspective you should never be in a position where
On Sunday, April 26, 2015, Jamie Lennox jamielen...@redhat.com wrote:
- Original Message -
From: German Eichberger german.eichber...@hp.com javascript:;
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org javascript:;
Sent:
In case anyone is interested in reading the specific issues:
- image-update command returns name 'sys' is not defined error
https://bugs.launchpad.net/python-glanceclient/+bug/1432249
- Since 0.16.1 client breaks nova when using https
wrote:
On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
dolph.math...@gmail.com
wrote:
On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic
bo...@pavlovic.me wrote:
Jay,
Not far, IMHO. 100ms difference in startup time isn't something we
should spend much time
Nothing stands out as obviously-wrong in your configuration, so I'd suggest
starting with the following to debug:
Enable debug mode in keystone.conf and watch the log files in both keystone
and barbican (those produced by auth_token) and attempt your request
against barbican again.
Next, ensure
On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic bo...@pavlovic.me wrote:
Jay,
Not far, IMHO. 100ms difference in startup time isn't something we should
spend much time optimizing. There's bigger fish to fry.
I agree that priority of this task shouldn't be critical or even high, and
that
What you're proposing quickly becomes an authorization question. What
capabilities can this service provide? is a far less useful question than
what capabilities is the user authorized to consume? More generally, why
would you advertise any capability that the user is going to receive a
4xx/5xx
On Tuesday, March 17, 2015, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Encryption per se does not decrease token size, the best it can do is
keep the token size the same size.
Correct.
So using Fernet tokens will not on
its own alter the token size. Reducing the size must come from
On Mon, Mar 16, 2015 at 10:10 AM, Adam Young ayo...@redhat.com wrote:
Oslo policy has been released as a stand alone library. This is great, in
that the rules engine is relatively non-applicaition specific, and I assume
that all of the policy based project are planning to migrate over to
On Fri, Mar 13, 2015 at 10:06 AM, Doug Hellmann d...@doughellmann.com
wrote:
On Fri, Mar 13, 2015, at 06:57 AM, Thierry Carrez wrote:
Clint Byrum wrote:
I spend a not-insignificant amount of time deciding which threads to
read and which to fully ignore each day, so extra threads mean
Here's a minimal example I wrote (based on master)
https://github.com/dolph/keystone-deploy/tree/master/playbooks/roles/http
And one intended for production:
https://github.com/stackforge/os-ansible-deployment/tree/master/playbooks/roles/os_keystone/tasks#
You can also checkout DevStack.
Great to hear that this has been addressed, as this impacted a few tests in
keystone.
(but why was the fix not released as 1.7.1?)
On Tue, Mar 10, 2015 at 4:10 PM, Robert Collins robe...@robertcollins.net
wrote:
There was a broken wheel built when testtools 1.7.0 was released. The
wheel was
On Fri, Feb 27, 2015 at 8:39 AM, Dmitry Tantsur dtant...@redhat.com wrote:
Hi all!
This (presumably) pretty basic question tortures me for several months
already, so I kindly seek for help here.
I'm working on a Flask-based service [1] and I'd like to use Keystone
tokens for
On Wed, Feb 25, 2015 at 4:12 AM, Victor Stinner vstin...@redhat.com wrote:
Hi,
I also just put up another proposal to consider:
https://review.openstack.org/#/c/156711/
Sew over eventlet + patching with threads
My asyncio spec is unclear about WSGI, I just wrote
The spec doesn't
On Wed, Feb 25, 2015 at 10:47 AM, Doug Hellmann d...@doughellmann.com
wrote:
On Wed, Feb 25, 2015, at 09:33 AM, Eugeniya Kudryashova wrote:
Hi, stackers!
As was suggested in topic [1], using an HTTP header was a good solution
for
communicating common/standardized OpenStack API error
On Wed, Feb 25, 2015 at 5:42 PM, Zane Bitter zbit...@redhat.com wrote:
On 25/02/15 15:37, Joe Gordon wrote:
On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell tim.b...@cern.ch
mailto:tim.b...@cern.ch wrote:
A few inline comments and a general point
How do we handle scenarios like
On Wed, Feb 25, 2015 at 3:02 PM, Matt Joyce m...@nycresistor.com wrote:
Wondering if heat should be performing this orchestration.
I wouldn't expect heat to have access to everything that needs to be
cleaned up.
Would provide for a more pluggable front end to the action set.
-matt
On
On Fri, Feb 6, 2015 at 12:47 PM, Adam Young ayo...@redhat.com wrote:
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,
Big +1 from me if we can land something solid.
On Fri, Feb 13, 2015 at 3:12 PM, Yee, Guang guang@hp.com wrote:
++
As for the unbound groups concern, our initial internal Federation POCs
worked well with a single group so far. The proposed hierarchical role
groups, or perhaps even
+1
On Tue, Feb 10, 2015 at 11:51 AM, Morgan Fainberg morgan.fainb...@gmail.com
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
+1
On Sun, Jan 18, 2015 at 1:11 PM, Morgan Fainberg morgan.fainb...@gmail.com
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
On Wed, Jan 7, 2015 at 10:32 AM, Lance Bragstad lbrags...@gmail.com wrote:
https://review.openstack.org/#/c/113586/ is owned by dstanek but I
understand he is out this week at a conference?
Correct.
It might be worth dropping in #openstack-keystone and seeing if dstanek
would be alright
Both of these build failures should be fixed by:
https://review.openstack.org/#/c/144182/
(Thanks, Alan!)
On Tue, Jan 6, 2015 at 12:28 AM, A mailing list for the OpenStack Stable
Branch test reports. openstack-stable-ma...@lists.openstack.org wrote:
Build failed.
-
The default behavior, rebasing automatically, is the sane default to avoid
having developers run into unexpected merge conflicts on new patch
submissions.
But if git-review can check to see if a review already exists in gerrit
*before* doing the local rebase, I'd be in favor of it skipping the
On Tue, Dec 23, 2014 at 1:33 PM, David Chadwick d.w.chadw...@kent.ac.uk
wrote:
Hi Adam
On 23/12/2014 17:34, Adam Young wrote:
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
I've envisioned basically the same feature before, but I don't find the
comments to be particularly useful without the complete context.
What I really want from gerrit is a 3-way diff, wherein the first column is
always the original state of the repo, the second column is a
user-selectable
On Wed, Nov 26, 2014 at 1:15 PM, Steve Gordon sgor...@redhat.com wrote:
- Original Message -
From: Deepak Shetty dpkshe...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Hi stackers,
I was having this thought
I'm very much interested in this new Keystyone thing. Is the name still
open to debeate?
On Wed, Nov 12, 2014 at 9:26 AM, Brad Topol bto...@us.ibm.com wrote:
I have filled out the form and very much look forward to attending!!!
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919)
As someone who has spent quite a bit of time triaging bugs, I'd be hugely
in favor of this. I'd probably be willing to pitch in on additional
projects, as well.
Is there already tooling for this built around Launchpad, or do we have to
roll our own?
With storyboard.openstack.org looming on the
On Sunday, November 2, 2014, John Dennis jden...@redhat.com wrote:
It was hoped we could simply borrow the Keystone mapping
implementation but it was found to be too limiting and not sufficiently
expressive. We could not find another alternative so we designed a new
mapper which is described
On Thursday, October 30, 2014, Ondrej Wisniewski
ondrej.wisniew...@dektech.com.au wrote:
Hi Stefano and Dolph,
since me and my team joined the OpenStack developer community just
recently, I really appreciate your comments and suggestions. After all, we
are here to learn. The current
On Wed, Oct 29, 2014 at 4:20 AM, Ondrej Wisniewski
ondrej.wisniew...@dektech.com.au wrote:
Hi Ricardo,
thanks a lot for your help and detailed instructions. It will surely come
in handy when I will need to do something like that. I am looking also into
this possibility.
But the actual
Great question!
For some backstory, the community interest in supporting XML has always
been lackluster, so the XML translation middleware has been on a slow road
of decline. It's a burden for everyone to maintain, and only works for
certain API calls. For the bulk of Keystone's documented APIs,
On Mon, Oct 20, 2014 at 7:04 AM, Jamie Lennox jamielen...@redhat.com
wrote:
- Original Message -
From: Dolph Mathews dolph.math...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Tuesday, October 7, 2014 6:56:15
I ran this tool on Keystone and liked the results - the two methods that
ranked D should certainly be refactored. It also matched a few methods in
openstack/common.
But flake8 supports complexity checking already, using mccabe. Just enable
complexity checking with:
$ flake8 --max-complexity 20
The :5000 port of Keystone is designed to be exposed publicly via HTTPS. In
the /v2.0/ API, there's only a handful of calls exposed on that port. In
/v3/ the entire API is exposed, but wrapped by RBAC. If you're using
HTTPS, it should be safe to expose the public interfaces of all
the services to
+1 for readable, well-documented code /bikeshed
On Mon, Oct 13, 2014 at 8:28 PM, Angus Lees g...@inodes.org wrote:
(Context: https://review.openstack.org/#/c/117418/)
I'm looking for some rough consensus on what naming conventions we want for
unused variables in Neutron, and across the
On Tuesday, October 7, 2014, Adam Young ayo...@redhat.com wrote:
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
On Mon, Sep 29, 2014 at 6:01 AM, Sean Dague s...@dague.net wrote:
On 09/29/2014 05:06 AM, Thierry Carrez wrote:
Sean Dague wrote:
Setuptools 6.0 was released Friday night. (Side note: as a service to
others releasing major software bumps on critical python software on a
Friday night
On Wed, Sep 24, 2014 at 9:48 AM, Day, Phil philip@hp.com wrote:
I think we should aim to /always/ have 3 notifications using a pattern
of
try:
...notify start...
...do the work...
...notify end...
except:
...notify abort...
On Thu, Sep 25, 2014 at 3:21 PM, Ved Lad ved...@gmail.com wrote:
The Openstack installation (Havana) at our company has a large number of
service endpoints in the catalog. As a consequence, when using PKI tokens,
my HTTP request header gets too big to handle for services like neutron. Im
I'd be interested in participating in this as well.
I wrote Keystone's v3 Identity API Document Overview and Conventions [1]
with an eye toward hopefully establishing *some* consistency across
multiple projects (or at least having a starting ground with which to
discuss and iterate on).
[1]
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 Juno. There
was a perceived increase in stability
that route. I'd wholly recommend against it though, because I don't see a
strong use case to use names instead of IDs here (correct me if I'm wrong).
On Sep 21, 2014 12:18 PM, Dolph Mathews dolph.math...@gmail.com wrote:
Querying keystone for tenant names is certainly fair game.
Keystone should
Querying keystone for tenant names is certainly fair game.
Keystone should be considered the only source of truth for tenant names
though, as they are mutable and not globally unique on their own, so other
services should not stash any names from keystone into long term
persistence (users,
On Sep 12, 2014 10:05 AM, Russell Bryant rbry...@redhat.com wrote:
On 09/12/2014 07:37 AM, Thierry Carrez wrote:
If you think this is wrong and think the design summit suggestion
website is a better way to do it, let me know why! If some programs
really can't stand the 'etherpad/IRC'
On Wed, Sep 3, 2014 at 8:25 AM, Sean Dague s...@dague.net wrote:
On 09/03/2014 09:03 AM, Daniel P. Berrange wrote:
On Wed, Sep 03, 2014 at 08:37:17AM -0400, Sean Dague wrote:
I'm not sure why people keep showing up with sort requirements patches
like -
On Wed, Sep 3, 2014 at 11:23 AM, Doug Hellmann d...@doughellmann.com
wrote:
On Sep 3, 2014, at 12:20 PM, Dolph Mathews dolph.math...@gmail.com
wrote:
On Wed, Sep 3, 2014 at 8:25 AM, Sean Dague s...@dague.net wrote:
On 09/03/2014 09:03 AM, Daniel P. Berrange wrote:
On Wed, Sep 03, 2014
On Tue, Aug 26, 2014 at 6:44 AM, Sean Dague s...@dague.net wrote:
On 08/26/2014 05:38 AM, Thierry Carrez wrote:
Hi keystone/infra,
One key upcoming Juno feature (Keystone to keystone federation) is
currently blocked on adding pysaml2 to requirements:
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 this.
i.e. The project is better off without it.
A bit off topic, but I've never liked this message that
On Thu, Aug 21, 2014 at 11:53 AM, Daniel P. Berrange berra...@redhat.com
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
Regarding the connection to release notes, it'd be useful to link from
official release note bullet points back to the corresponding spec on
specs.openstack.org to provide additional detail.
On Fri, Aug 15, 2014 at 2:58 PM, Anne Gentle a...@openstack.org wrote:
On Fri, Aug 15, 2014 at 2:47
On Tue, Aug 12, 2014 at 10:30 AM, Yee, Guang guang@hp.com wrote:
Hi Kristy,
Have you try the [] or @ rule as mentioned here?
That still requires valid authentication though, just not any specific
authorization. I don't think we have a way to express truly public
resources in oslo.policy.
On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery mest...@mestery.com wrote:
On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez
On Tue, Aug 12, 2014 at 1:08 PM, Doug Hellmann d...@doughellmann.com
wrote:
On Aug 12, 2014, at 1:44 PM, Dolph Mathews dolph.math...@gmail.com
wrote:
On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon joe.gord...@gmail.com
wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery mest
if you already have all the dependencies
available:
$ sh tools/config/generate_sample.sh
-- Forwarded message --
From: jazeltq jaze...@163.com
Date: Mon, Aug 11, 2014 at 5:06 AM
Subject: how to generate keystone.conf.sample in havana release?
To: Dolph Mathews dolph.math
in auth_token for fetching catalogs when a service
expects one, but auth_token finds it to be missing from PKI tokens.
On Thu, Jul 31, 2014 at 6:59 AM, Russell Bryant rbry...@redhat.com wrote:
On 07/30/2014 10:57 AM, Dolph Mathews wrote:
We recently merged an implementation for GET /v3/catalog which
We recently merged an implementation for GET /v3/catalog which finally
enables POST /v3/auth/tokens?nocatalog to be a reasonable default behavior,
at the cost of an extra HTTP call from remote service back to keystone
where necessary.
Spec:
Hello everyone,
This is me waving my arms around trying to gather feedback on a change in
scope that seems agreeable to a smaller audience. Most recently, we've
discussed this in both the Keystone [1] and Oslo [2] weekly meetings.
tl;dr it seems to make sense to move the PyCADF library from the
On Wed, Jul 23, 2014 at 1:03 AM, Fei Long Wang feil...@catalyst.net.nz
wrote:
Greetings,
I'm trying to figure out if Keystone can support more granular role
management or if there is any plan to do that in the future. Currently,
AWS can support adding a role and assigning the capability from
On Thu, Jul 17, 2014 at 7:56 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Jul 16, 2014 at 5:07 PM, Morgan Fainberg
morgan.fainb...@gmail.com wrote:
Reposted now will a lot less bad quote issues. Thanks for being patient
with the re-send!
On Thu, Jul 17, 2014 at 5:43 AM, McCabe, Donagh donagh.mcc...@hp.com
wrote:
Hi,
I’m working on the Swift implications of using composite authorization [1]
[2].
My question for Keystone developers is : what project-id do we expect the
service token to be scoped to - the service's
so we know for the next round what is needed when.
Jay
On Sun, 2014-07-13 at 16:31 -0600, John Griffith wrote:
On Sun, Jul 13, 2014 at 8:01 AM, Dolph Mathews
dolph.math...@gmail.com javascript:; wrote:
On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant
jsbry
with bugs. I would expect that a
patch to fix a bug would have to have a corresponding bug report. Just
accepting patches with no known justification seems like the wrong way to
go.
--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786
*From:* Dolph
On Mon, Jul 7, 2014 at 3:05 PM, Adam Young ayo...@redhat.com wrote:
On 07/07/2014 11:11 AM, Dolph Mathews wrote:
On Fri, Jul 4, 2014 at 5:13 PM, Adam Young ayo...@redhat.com wrote:
Unscoped tokens are really a proxy for the Horizon session, so lets treat
them that way.
1. When a user
On Fri, Jul 4, 2014 at 5:13 PM, Adam Young 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 get back a list of
their projects:
some thing along the lines of:
domains [{
On Mon, Jul 7, 2014 at 8:34 AM, Brant Knudson b...@acm.org wrote:
Henry -
On Mon, Jul 7, 2014 at 7:17 AM, Henry Nash hen...@linux.vnet.ibm.com
wrote:
Hi
Our debug log file size is getting pretty hugea typical py26 jenkins
run produces a whisker under 50Mb of log - which is
On Fri, Jul 4, 2014 at 12:31 AM, Steve Martinelli steve...@ca.ibm.com
wrote:
To add to the growing pains of keystone-specs, one thing I've noticed is,
there is inconsistency in the 'REST API Impact' section.
To be clear here, I don't mean we shouldn't include what new APIs will be
created, I
...@ca.ibm.com
8200 Warden Ave
Markham, ON L6G 1C7
Canada
From:Dolph Mathews dolph.math...@gmail.com
To:OpenStack Development Mailing List (not for usage
questions) openstack-dev@lists.openstack.org,
Date:07/07/2014 01:39 PM
Subject:Re: [openstack-dev] [keystone
Devananda van der Veen devananda@gmail.com
:
On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews dolph.math...@gmail.com
wrote:
The argument has been made in the past that small features will require
correspondingly small specs. If there's a counter-argument to this
example
(a small feature
The argument has been made in the past that small features will require
correspondingly small specs. If there's a counter-argument to this example
(a small feature requiring a relatively large amount of spec effort), I'd
love to have links to both the spec and the resulting implementation so we
On Tue, Jul 1, 2014 at 11:20 AM, Coles, Alistair alistair.co...@hp.com
wrote:
We have a change [1] under review in Swift to make access control lists
compatible with migration to keystone v3 domains. The change makes two
assumptions that I’d like to double-check with keystone folks:
1.
This is a known limitation of the token backend and the token revocation
list: we don't index tokens in the backend by roles (and we don't want to
iterate the token table to find matching tokens).
However, if we land support for token revocation events [1] in the
auth_token [2] middleware, we'll
*From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
*Sent:* Friday, June 20, 2014 8:41 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [keystone]endpoint table is missing
reference to region table
The region table is relatively new
On Thu, Jun 19, 2014 at 7:55 PM, Stephen Balukoff sbaluk...@bluebox.net
wrote:
Thanks for the link, Anita!
These are definitely good guidelines, but there are a couple problems with
doing the election exactly as described in the document: It looks like to
generate the list of voters, it
The region table is relatively new, and no one has stepped up to link the
two together. A couple considerations:
A) a data migration will need to be performed to sync up the regions in the
endpoint table with regions in the region table (populate those foreign
keys, creating corresponding regions
On Mon, Jun 2, 2014 at 7:21 PM, Christopher Yeoh cbky...@gmail.com wrote:
Hi,
There's been a few patches like this floating around recently which fix
the incorrect use of 413 as the http error code when a request fails
because of the requestor is out of quota.
On Thu, May 29, 2014 at 12:59 PM, Tim Bell tim.b...@cern.ch wrote:
A further vote to maintain compatibility . One of the key parts to a good
federation design is to be using it in the field and encountering real life
problems.
Production sites expect stability of interfaces and
On Tue, May 27, 2014 at 6:30 AM, Marco Fargetta
marco.farge...@ct.infn.itwrote:
Hi All,
• Federated Keystone and Horizon
□ Completely open-ended, there isn't much an expectation that we
deliver
this in Juno, but it's something we should start thinking about.
□
On Tue, May 27, 2014 at 8:12 AM, Marco Fargetta
marco.farge...@ct.infn.itwrote:
On Tue, May 27, 2014 at 07:39:01AM -0500, Dolph Mathews wrote:
On Tue, May 27, 2014 at 6:30 AM, Marco Fargetta
marco.farge...@ct.infn.itwrote:
Hi All,
• Federated Keystone and Horizon
On Wed, May 21, 2014 at 10:41 AM, John Dickinson m...@not.mn wrote:
Can you explain how PKI info is compressible? I thought it was encrypted,
which should mean you can't compress it right?
They're not encrypted - just signed and then base64 encoded. The JSON (and
especially service catalog)
On Wed, May 21, 2014 at 2:36 PM, Kurt Griffiths
kurt.griffi...@rackspace.com 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...
I don't think
AWS).
This is a fantastic argument in favor of UUID today. PKI will likely never
be fixed-length, but hopefully we can continue making them smaller such
that this argument might carry substantially less weight someday.
--John
On May 21, 2014, at 9:09 AM, Dolph Mathews dolph.math
On Sat, May 17, 2014 at 9:46 PM, Adam Young ayo...@redhat.com wrote:
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
On Tue, Apr 29, 2014 at 1:25 AM, Robert Collins
robe...@robertcollins.netwrote:
On 29 April 2014 12:27, Dolph Mathews dolph.math...@gmail.com wrote:
Sure: domain names are unambiguous but user mutable, whereas Heat's
approach
to using admin tenant name is at risk to both mutability
On Tue, May 6, 2014 at 3:17 AM, Roman Bodnarchuk
roman.bodnarc...@indigitus.ch wrote:
Thanks for reply. I think I got the justifications for such an approach.
BTW, is there a resource, which can be used to track support of Keystone
v3 (and domain-based policies) among OS services? Are
On Thu, May 1, 2014 at 8:50 AM, Fuente, Pablo A pablo.a.fue...@intel.comwrote:
Hi,
We recently implemented our V2 REST API, and at this moment we are
trying to get working our python client against this new version. For
this reason, we start a discussion about how the client will
On Mon, Apr 28, 2014 at 12:51 PM, Clint Byrum cl...@fewbar.com wrote:
So in the process of making Heat deploy itself, I've run into a bit of a
deadlock.
https://bugs.launchpad.net/tripleo/+bug/1287453
https://bugs.launchpad.net/heat/+bug/1313003
Currently, we deploy OpenStack like this:
On Mon, Apr 28, 2014 at 2:48 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Dolph Mathews's message of 2014-04-28 12:28:41 -0700:
On Mon, Apr 28, 2014 at 12:51 PM, Clint Byrum cl...@fewbar.com wrote:
So in the process of making Heat deploy itself, I've run into a bit of
a
On Sun, Apr 27, 2014 at 12:19 PM, Andreas Jaeger a...@suse.com wrote:
The documentation team noticed that we have links in the version
responses of several APIs that contain URLs that do not exist at all.
For example, cinder includes a link to
python-keystoneclient 0.8.0 has been released and is now available on pypi
[1].
Given the recency of the 0.7 series, this a relatively small release.
However, 0.8.0 notably fixes a race condition in
keystoneclient.middleware.auth_token for PKI deployments [2], which is
closely related to an issue
On Fri, Apr 11, 2014 at 1:57 PM, Adam Lawson alaw...@aqorn.com wrote:
Hi Michael,
KS Federation was originally planned for Icehouse RC2 but was later
postponed until the Juno release with priority since there was a
disagreement re approach. Or something along those lines. But it won't be
101 - 200 of 388 matches
Mail list logo
