On Thu, 2014-09-04 at 17:37 -0400, Adam Young wrote:
> 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 th
- Original Message -
> From: "Steven Hardy"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Thursday, September 11, 2014 1:55:49 AM
> Subject: Re: [openstack-dev] [all] [clients] [keystone] lack of retrying
> tokens leads to overall OpenStack fragility
>
- Original Message -
> From: "Sean Dague"
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, 11 September, 2014 9:44:43 PM
> Subject: Re: [openstack-dev] [all] [clients] [keystone] lack of retrying
> tokens leads to overall OpenStack fragility
>
>
s leads to overall OpenStack fragility
>
> On Wed, Sep 10, 2014 at 08:46:45PM -0400, Jamie Lennox wrote:
> >
> > - Original Message -
> > > From: "Steven Hardy"
> > > To: "OpenStack Development Mailing List (not for usage questions)"
- Original Message -
> From: "Travis S Tripp"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Friday, 12 September, 2014 10:30:53 AM
> Subject: [openstack-dev] masking X-Auth-Token in debug output - proposed
> consistency
>
>
>
> Hi All,
>
>
>
> I’
On Wed, 2013-11-20 at 15:17 -0800, Clint Byrum wrote:
> Excerpts from Mark Washenberger's message of 2013-11-20 10:14:42 -0800:
> > Hi folks,
> >
> > The project python-glanceclient is getting close to needing a major release
> > in order to finally remove some long-deprecated features, and to mak
On Wed, 2013-11-20 at 13:26 +0200, David Hadas wrote:
> Hi all,
>
> We created a wiki page discussing the addition of software side encryption
> to Swift:
> "The general scheme is to create a swift proxy middleware that will encrypt
> and sign the object data during PUT and check the signature + d
change out urllib for requests or some
> other transport to make HTTP requests to we don't need to refactor
> every one of the mock/mox subouts to match the exact set of parameters
> to be passed. Httpretty makes managing this significantly easier
> (hence was the reasoning to mo
So i've a feeling that this was proposed and dismissed once before. I
don't remember why.
So my concern with barbican is that i'm under the impression that
barbican was going to be an 'overcloud' service. That's a really bad way
of putting it, but it is service and user facing and discovered via t
On Fri, 2013-11-22 at 20:07 -0600, Matt Riedemann wrote:
>
> On Friday, November 22, 2013 5:52:17 PM, Russell Bryant wrote:
> > On 11/22/2013 06:01 PM, Christopher Yeoh wrote:
> >>
> >> On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann
> >> mailto:mrie...@linux.vnet.ibm.com>> wrote:
> >>
> >> .
;href":
"http:\/\/docs.openstack.org\/api\/openstack-identity-service\/2.0\/identity-dev-guide-2.0.pdf",
"type": "application\/pdf",
"rel": "describedby"
}
]
}
]
}
}
- Original Message ---
Adrian,
The main blocker for the time being with keystoneclient and py3 is our
use of a library called HTTPretty in our testing - on which there is a
very recent thread. There is upstream work to make this py3 compatible
but i'm not sure how quickly it's moving.
Any code in keystoneclient itsel
our developers
> might take an interest in helping with the upstream work. At the very least,
> it might be nice to have some understanding of how much work there is to be
> done in HTTPretty.
>
> Cheers,
>
> Adrian
>
> On Dec 4, 2013, at 3:29 PM, Jamie
On Wed, 2013-12-04 at 20:48 -0500, David Stanek wrote:
> On Wed, Dec 4, 2013 at 6:44 PM, Adrian Otto
> wrote:
> Jamie,
>
> Thanks for the guidance here. I am checking to see if any of
> our developers might take an interest in helping with the
> upstream w
gt;
>
> Original message ----
> From: Morgan Fainberg
> Date:12/04/2013 6:17 PM (GMT-08:00)
> To: Jamie Lennox ,"OpenStack Development Mailing List (not for usage
> questions)"
> Subject: Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last
>
Using the default policies it will simply check for the admin role and not care
about the domain that admin is limited to. This is partially a left over from
the V2 api when there wasn't domains to worry about.
A better example of policies are in the file etc/policy.v3cloudsample.json. In
there
I attempted this in keystone as part of a very simple extension [1]. I
understand that it is a much simpler case but nesting the Pecan within the
existing routing infrastructure, rather than have a single Pecan app was fairly
simple (though there are some limiting situations).
Any reason you de
Is there any way to have WSME pass through arbitrary attributes to the created
object? There is nothing that i can see in the documentation or code that would
seem to support this.
In keystone we have the situation where arbitrary data was able to be attached
to our resources. For example ther
On Thu, 2014-01-09 at 11:16 +0100, Julien Danjou wrote:
> On Thu, Jan 09 2014, Jamie Lennox wrote:
>
> > Is there any way to have WSME pass through arbitrary attributes to the
> > created object? There is nothing that i can see in the documentation or code
> > that wo
On Fri, 2014-01-10 at 10:23 -0500, Doug Hellmann wrote:
>
>
>
>
> On Thu, Jan 9, 2014 at 12:02 AM, Jamie Lennox
> wrote:
> Is there any way to have WSME pass through arbitrary
> attributes to the created object? There is nothing that i can
>
On Mon, 2014-01-13 at 10:05 -0500, Doug Hellmann wrote:
>
>
>
>
> On Sun, Jan 12, 2014 at 6:33 PM, Jamie Lennox
> wrote:
> On Fri, 2014-01-10 at 10:23 -0500, Doug Hellmann wrote:
> >
> >
> >
> >
>
*snip*
>
>
> Distinction between client layers won't get lost and would only be
> improved. My basic idea is the following:
>
> 1) Transport layer would handle all transport related stuff - HTTP,
> JSON encoding, auth, caching, etc.
>
> 2) Model layer (Resource classes, BaseManager, etc.) will
I can't see any reason that all of these situations can't be met.
We can finally take the openstack pypi namespace, move keystoneclient ->
openstack.keystone and similar for the other projects. Have them all based upon
openstack.base and probably an openstack.transport for transport.
For the a
ok with the CLI, creating a single repository with a
> team responsible for managing consistency in the UI.
>
>
> Doug
This *is* the approach Dean took with the CLI. Have a package that
provides the CLI but then have the actual work handed off to the
individual clients (with quite a l
don't do this here - the thread is way too deep already.
If we get into discussing individual points let's do one question per thread
and prefix the emails with [client] or something to tie it all together
- Original Message -
> From: "Alexei Kornienko"
> To: "OpenStack Development Mai
- Original Message -
> From: "Steven Hardy"
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, 23 January, 2014 9:21:47 PM
> Subject: [openstack-dev] [keystone][heat] Migration to keystone v3 API
> questions
>
> Hi all,
>
> I've recently been working on migrating the hea
- Original Message -
> From: "Florent Flament"
> To: openstack-dev@lists.openstack.org
> Sent: Friday, 24 January, 2014 8:07:28 AM
> Subject: Re: [openstack-dev] [Keystone] bp proposal: quotas on users and
> projects per domain
>
> I understand that not everyone may be interested in su
- Original Message -
> From: "Dean Troyer"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Tuesday, February 4, 2014 9:31:57 AM
> Subject: Re: [openstack-dev] Ugly Hack to deal with multiple versions
>
> On Mon, Feb 3, 2014 at 1:50 PM, Adam Young < ayo..
- Original Message -
> From: "Adam Young"
> To: openstack-dev@lists.openstack.org
> Sent: Wednesday, February 5, 2014 2:29:18 AM
> Subject: Re: [openstack-dev] Ugly Hack to deal with multiple versions
> On 02/04/2014 11:09 AM, Dean Troyer wrote:
> > On Tue, Feb 4, 2014 at 9:00 AM, Sean
- Original Message -
> From: "Noorul Islam K M"
> To: "Dolph Mathews"
> Cc: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Friday, 7 February, 2014 2:00:34 PM
> Subject: Re: [openstack-dev] [keystone] Integrating with 3rd party DB
>
> Dolph Mathews writes:
- Original Message -
> From: "Noorul Islam K M"
> To: "Jamie Lennox"
> Cc: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Friday, 7 February, 2014 7:13:20 PM
> Subject: Re: [openstack-dev] [keystone] Integra
Hi all,
I am one of i think a number of efforts trying to make clients be interoperable
between different versions of an API.
What i would like to talk about specifically here are the inconsistencies in
the version listing of the different servers when you query the root GET '/'
and GET '/vX'
On Thu, 2014-02-13 at 19:35 -0700, Christopher Yeoh wrote:
> On Thu, 13 Feb 2014 21:10:01 -0500
> Sean Dague wrote:
> > On 02/13/2014 08:28 PM, Christopher Yeoh wrote:
> > > On Thu, 13 Feb 2014 15:54:23 -0500
> > > Sean Dague wrote:
>
> > >
> > > So one question I have around a global version i
it this
> is from, but I've been using it as a sanity check for the discovery
> bits in OSC.
Yes, i've seen that one. It's more client side how we should work with
it though. If we can standardize the server side response then the
client side becomes much more reusable.
>
On Thu, 2014-02-13 at 08:37 -0500, Sean Dague wrote:
> On 02/13/2014 07:50 AM, Jamie Lennox wrote:
> > Hi all,
> >
> > I am one of i think a number of efforts trying to make clients be
> > interoperable between different versions of an API.
> >
> > What
On Mon, 2014-02-17 at 16:09 +1000, Jamie Lennox wrote:
> On Thu, 2014-02-13 at 08:37 -0500, Sean Dague wrote:
> > On 02/13/2014 07:50 AM, Jamie Lennox wrote:
> > > Hi all,
> > >
> > > I am one of i think a number of efforts trying to make clients be
> >
I promised Jesse after the openstack-sdk meeting that I would do a write
up of the direction of keystoneclient's auth plugins and Sessions. Have
a look here:
http://www.jamielennox.net/blog/2014/02/24/client-session-objects/
I know that this is different to the way Dean was looking at using them
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.
There is currently a push to release oslo.context as a
library, for reference:
https://github.com/openstack/oslo.context/blo
- Original Message -
> From: "Abhijeet Malawade"
> To: openstack-dev@lists.openstack.org
> Sent: Friday, 12 December, 2014 3:54:04 PM
> Subject: [openstack-dev] [python-cinderclient] Return request ID to caller
>
>
>
> HI,
>
>
>
> I want your thoughts on blueprint 'Log Request ID M
- Original Message -
> From: "Doug Hellmann"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Saturday, 20 December, 2014 12:07:59 AM
> Subject: Re: [openstack-dev] [all] Lets not assume everyone is using the
> global `CONF` object (zaqar broken by l
+1
- Original Message -
> From: "Morgan Fainberg"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Monday, 19 January, 2015 5:11:02 AM
> Subject: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec
> core
>
> Hello all,
>
> I would like
On Thu, 2014-04-17 at 19:58 +0300, Roman Bodnarchuk wrote:
> Hello,
>
> I am trying to make sure that a user can't do anything useful with an
> unscoped token, and got to the following code in
> keystoneclient.middleware.auth_token:
>
> if _token_is_v2(token_info) and not auth_ref.proj
All,
TL;DR: novaclient should be able to use the common transport/auth layers of
keystoneclient. If it does there are going to be functions like
client.authenticate() that won't operate the same way when a session object is
passed. For most users who just use the CRUD operations there will be
Joe Gordon wrote:
> >
> >
> >
> > On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox > <mailto:jamielen...@redhat.com>> wrote:
> >
> > All,
> >
> > TL;DR: novaclient should be able to use the common transport/auth
> > layers
ovaclient
>
>
>
>
> On Wed, May 7, 2014 at 7:54 PM, Jamie Lennox < jamielen...@redhat.com >
> wrote:
>
>
>
>
>
> - Original Message -
> > From: "Monty Taylor" < mord...@inaugust.com >
> > To: openstack-dev
These are the ARBAC documents that came up in our meeting with Shawn
McKinney at Summit:
1. OpenStack RBAC proposal slide deck
http://people.redhat.com/jlennox/OpenStackRbacProposal2014.pdf
2. ANSI RBAC (INCITS 359-2004) Specification document:
http://profsandhu.com/journals/tissec/ANSI+INCITS+
Among the problems cause by the inconsistencies in the clients is that
all the options that are required to create a client need to go into the
config file of the service. This is a pain to configure from the server
side and can result in missing options as servers fail to keep up.
With the sessio
On Thu, 2014-06-12 at 09:13 +1200, Steve Baker wrote:
> On 12/06/14 08:18, Mark McLoughlin wrote:
> > On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote:
> >> On 11/06/14 15:07, Jamie Lennox wrote:
> >>> Among the problems cause by the inconsistencies in the clients
On Wed, 2014-06-11 at 04:43 +, Angus Salkeld wrote:
> On 11/06/14 13:10, Jamie Lennox wrote:
> > Among the problems cause by the inconsistencies in the clients is that
> > all the options that are required to create a client need to go into the
> > config file of the servi
On Wed, 2014-06-11 at 19:52 -0400, Sean Dague wrote:
> On 06/11/2014 07:47 PM, Jamie Lennox wrote:
> > On Thu, 2014-06-12 at 09:13 +1200, Steve Baker wrote:
> >> On 12/06/14 08:18, Mark McLoughlin wrote:
> >>> On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote:
&
how HKDF is used if you're interested).
>
> There are areas for integration between Kite and Barbican. The most obvious
> would be to utilize Baribican to store the long-term keys used to
> authenticate the communicating party.
>
> Thanks,
> -NGK
>
> >
> > Tho
On Thu, 2014-06-12 at 16:29 -0700, Valerie Anne Fenwick wrote:
> Hi FOlks
>
> I haven't seen anymore on this. Is this happening? If so, are there more
> details? (location, agenda, etc). Thanks!
Details: http://dolphm.com/openstack-keystone-hackathon-for-juno/
I think the agenda will be pushi
- Original Message -
> From: "Jamie Lennox"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Friday, June 13, 2014 12:28:25 PM
> Subject: Re: [openstack-dev] [Openstack-security] [Barbican][OSSG][Keystone]
> Mid-Cycl
On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote:
> Hi all,
>
>
> I am sorry if this has been discussed before, the question is will we
> support keystone v3 operation
> in python-keystoneclient? I know most of the v3 functionality have
> been implemented in python-openstackclient, but from
braries is NOT to provide a cli. The cli is just an application that makes
use of the library.
So yes, i think it has generally been accepted that the clients will move (at
there own pace) to using openstackclient for there CLI, but openstackclient
will still rely on the various libraries
- Original Message -
> From: "Paul Michali (pcm)"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Cc: jamielen...@gmail.com
> Sent: Wednesday, April 9, 2014 12:09:58 AM
> Subject: [openstack-dev] [infra]Requesting consideration of httmock package
> for test-re
package for test-requirements in Juno
>
> On Apr 8, 2014, at 3:04 PM, Jamie Lennox < jamielen...@redhat.com > wrote:
>
>
>
>
>
>
> - Original Message -
>
>
> From: "Paul Michali (pcm)" < p...@cisco.com >
> To: "Op
On Fri, 2014-04-11 at 13:29 +, Paul Michali (pcm) wrote:
> See inline @PCM…
>
>
> On Apr 9, 2014, at 5:56 PM, Jamie Lennox
> wrote:
>
>
> >
> >
> > - Original Message -
> > > From: "Paul Michali (pcm)"
> > &g
- Original Message -
> From: "Dolph Mathews"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Tuesday, October 7, 2014 6:56:15 PM
> Subject: Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery
>
>
>
> On Tuesday, October 7, 2014, Adam Y
- Original Message -
> From: "Ben Meyer"
> To: openstack-dev@lists.openstack.org
> Cc: "Jamie Painter"
> Sent: Tuesday, October 7, 2014 4:31:16 PM
> Subject: [openstack-dev] [Keystone] Question regarding Service Catalog and
> Identity entries...
>
> I am trying to use the Python Ke
- Original Message -
> From: "Nathan Kinder"
> To: openstack-dev@lists.openstack.org
> Sent: Tuesday, October 14, 2014 2:25:35 AM
> Subject: Re: [openstack-dev] [all][policy][keystone] Better Policy Model and
> Representing Capabilites
>
>
>
> On 10/13/2014 01:17 PM, Morgan Fainberg
>
> 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 usag
- Original Message -
> From: "Ben Meyer"
> To: openstack-dev@lists.openstack.org
> Sent: Monday, October 20, 2014 3:53:39 PM
> Subject: Re: [openstack-dev] [Keystone] Question regarding Service Catalog
> andIdentity entries...
>
> On 10/20/20
Hi all,
To implement kite we need the ability to sign and encrypt the message and the
message data. This needs to happen at a very low level in the oslo.messaging
stack. The existing message security review
(https://review.openstack.org/#/c/109806/) isn't going to be sufficient. It
allows us to si
On Wed, 2014-06-25 at 22:42 -0500, Dean Troyer wrote:
> On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen
> wrote:
> I'm looking at creating a new python-client
> and I was wondering if there was any on going effort to share
> code between the clients or not? I've looked at the
On Thu, 2014-07-24 at 22:44 +, Pendergrass, Eric wrote:
> In an effort to test ceilometer roles I removed the admin role from
> the admin tenant and user. Now I can’t add it back since I don’t have
> a user/tenant combo with the admin role:
>
>
>
> keystone user-role-add --role e4252b63c30
With the aim of replacing httplib and cert validation with requests[1]
I've put forward the following review to use the requests library for
auth_token middleware.
https://review.openstack.org/#/c/34161/
This adds 2 new config options.
- The ability to provide CAs to validate https connections a
(Resend this as i realize it didn't get to the list)
I just want to clarify where some of this discussion came from. I
actually think that oslo does a great job at keeping so many project up
to date with common code without the restrictions that going to a
library straight away. The problem is I
All,
So I wrote out an article the other day on the background to the keystoneclient
changes that I've been trying to get through.
Please take a look:
http://www.jamielennox.net/blog/2013/09/27/apiclient-communications/
I'm hoping that it gives a better understanding of the concepts and the
On Mon, 2013-10-14 at 18:36 -0700, Bhuvan Arumugam wrote:
> Just making sure i'm not the only one facing this problem.
> https://bugs.launchpad.net/nova/+bug/1239894
Yep, we thought this may raise some issues but insecure by default was
just not acceptable.
> keystoneclient v0.4.0 was released l
Yes keystone can run under SSL using the eventlet server. Look for the ssl
section in keystone.conf
https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L296
You'll want to set enabled, certfile and keyfile, from memory ca_certs is to do
with client side certs.
Jamie
-
le system that was in novaclient [1], but it should
> be moved to keystone client. There was some movement to port this to [2]
> but the change was abandoned in favour of a more complex solutions: one
> that never came in (oslo [3]) and another from Jamie Lennox in [4] that
> is still a WI
On Wed, 2013-11-06 at 06:16 +0800, Clint Byrum wrote:
> Excerpts from Steven Hardy's message of 2013-11-03 00:06:39 +0800:
> > Hi all,
> >
> > Looking to start a wider discussion, prompted by:
> > https://review.openstack.org/#/c/54651/
> > https://blueprints.launchpad.net/heat/+spec/management-ap
On Tue, 2013-06-25 at 09:30 -0600, Pete Zaitcev wrote:
> On Tue, 25 Jun 2013 08:50:49 +0100
> Michael Kerrin wrote:
>
> > we raised a bug https://bugs.launchpad.net/devstack/+bug/1193112 where the
>
> > $ /opt/stack/swift/bin/swift-proxy-server /etc/swift/proxy-server.conf -v
> > Traceback (mo
On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote:
> On 27 June 2013 04:55, Adam Young wrote:
> > Right now Keystone provides so called bearer tokens: This means that whoever
> > has a token can do whatever the token entitles him to do. If I
> > manage to get somebody's token I can do whatev
On Thu, 2013-06-27 at 11:39 -0400, Jay Pipes wrote:
> On 06/26/2013 12:55 PM, Adam Young wrote:
> > Glance:
> > - Uses httplib for communication
> > - Uses keystoneclient within cli
> > - Checks that socket is patched before importing eventlet for httplib.
>
> For the record, Glance uses httplib,
On Thu, 2013-06-27 at 16:35 +0200, Thierry Carrez wrote:
> Adam Young wrote:
> > Right now Keystone provides so called bearer tokens: This means that
> > whoever has a token can do whatever the token entitles him to do. If I
> > manage to get somebody's token I can do whatever this person is able
On Mon, 2013-07-01 at 14:09 -0700, Nachi Ueno wrote:
> Hi folks
>
> I'm interested in it too.
> I'm working on VPN support for Neutron.
> Public key authentication is one of feature milestone in the IPsec
> implementation.
> But I believe key-pair management api and the implementation will be
> qu
On Tue, 2013-07-02 at 02:03 +, Everett Toews wrote:
> This topic came up at the last summit in Portland at [1] and [2].
>
>
> Yehia and another colleague of his from HP had a design that was
> discussed and it seemed like they were going to start work on it.
> Another developer from CERN expr
On Mon, 2013-07-08 at 21:55 -0400, Adam Young wrote:
>
> Tokens are, for the most part, immutable. Once they are written, they
> don't change except if they get revoked. This is a fairly rare
> occurance, but it does happen.
>
> Deleting tokens based on age should be fairly straight forward, an
On Thu, 2013-05-02 at 00:46 +, Gabriel Hurley wrote:
> Based on input from several of the PTLs (and others), I'd like to propose the
> following outline for how version discovery should be handled across
> heterogeneous clouds:
>
> https://etherpad.openstack.org/api-version-discovery-proposa
- Original Message -
> From: "Dolph Mathews"
> To: "OpenStack Development Mailing List"
> Sent: Saturday, 27 July, 2013 4:56:10 AM
> Subject: Re: [openstack-dev] Proposal for API version discovery
>
>
> On Wed, Jul 24, 2013 at 12:41 AM,
- Original Message -
> From: "Doug Hellmann"
> To: "OpenStack Development Mailing List"
> Sent: Saturday, 27 July, 2013 4:15:53 AM
> Subject: Re: [openstack-dev] [Keystone] Alembic support
>
>
>
>
> On Fri, Jul 26, 2013 at 2:04 PM, Adam Young < ayo...@redhat.com > wrote:
>
>
>
Hi all,
Partially in response to the trusts API review in keystoneclient
(https://review.openstack.org/#/c/39899/ ) and my work on keystone API
version discoverability (spell-check disagrees but I'm going to assume
that's a word - https://review.openstack.org/#/c/38414/ ) I was thinking
about how
+1
On Tue, 2013-08-06 at 14:20 -0500, Dolph Mathews wrote:
> Through feedback on code reviews and blueprints, Morgan clearly has
> the best interests of the project itself in mind. I'd love for his
> votes to carry a bit more weight!
>
>
> https://review.openstack.org/#/dashboard/2903
>
>
>
On Tue, 2013-08-06 at 11:17 -0400, Adam Young wrote:
> On 08/06/2013 10:54 AM, Dolph Mathews wrote:
>
> >
> > On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams
> > wrote:
> >
> > On Aug 6, 2013, at 8:36 AM, Adam Young wrote:
> >
&
Regarding my blueprint
https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-auth-token
and Guang's bug
https://bugs.launchpad.net/python-keystoneclient/+bug/1207922
(auth_token middleware always use v2.0 to request admin token), i'm
trying to make a v3 client capable of valid
I'm not sure where it would make sense within the API to return the name
of the page/per_page variables to the client that doesn't involve having
already issued the call (ie returning the names within the links box
means you've already issued the query). If we standardize on the
page/per_page combi
On 12 November 2015 at 15:09, Clint Byrum wrote:
> Excerpts from Clint Byrum's message of 2015-11-11 10:57:26 -0800:
> > Excerpts from Morgan Fainberg's message of 2015-11-10 20:17:12 -0800:
> > > On Nov 10, 2015 16:48, "Clint Byrum" wrote:
> > > >
> > > > Excerpts from Morgan Fainberg's message
On 14 November 2015 at 19:09, Xav Paice wrote:
> Hi,
>
> I'm sure I'm not the only one that likes to use SSL everywhere possible,
> and doesn't like to pay for 'real' ssl certs for dev environments.
> Figuring out how to get requests to allow connection to the self signed
> cert would have paid f
I realize this has been mostly closed up, but just a few additions.
On 19 November 2015 at 08:06, Dolph Mathews wrote:
> On Tue, Nov 17, 2015 at 2:56 PM, Lindsay Pallickal
> wrote:
>
>>
>>
>> On Tue, Nov 17, 2015 at 5:31 AM, Dolph Mathews
>> wrote:
>>
>>>
>>>
>>> On Tuesday, November 17, 2015
On 8 December 2015 at 07:53, Thomas Goirand wrote:
> On 12/01/2015 07:57 AM, Steve Martinelli wrote:
> > Trying to summarize here...
> >
> > - There isn't much interest in keeping eventlet around.
> > - Folks are OK with running keystone in a WSGI server, but feel they are
> > constrained by Apac
On 13 May 2016 at 04:15, Sean Dague wrote:
> On 05/12/2016 01:47 PM, Morgan Fainberg wrote:
> > This also comes back to the conversation at the summit. We need to
> > propose the timeline to turn over for V3 (regardless of
> > voting/non-voting today) so that it is possible to set the timeline t
On 25 May 2016 at 03:55, Alexander Makarov wrote:
> Colleagues,
>
> here is an actual use case for shadow users assignments, let's discuss
> possible solutions: all suggestions are appreciated.
>
> -- Forwarded message --
> From: Andrey Grebennikov
> Date: Tue, May 24, 2016 at 9:
Hi All,
I'd like to bring to the attention of the wider security groups and
OpenStack users the Service Users Permissions [1] spec currently proposed
against keystonemiddleware.
To summarize quickly OpenStack has long had the problem of token expiry
happening in the middle of a long running opera
Thanks everyone for your input.
I generally agree that there is something that doesn't quite feel right
about purely trusting this information to be passed from service to
service, this is why i was keen for outside input and I have been
rethinking the approach.
To this end i've proposed reservat
Quick question: why do we need the service type or name in there? You
really should know what API you're talking to already and it's just
something that makes it more difficult to handle all the different APIs in
a common way.
On Jun 18, 2016 8:25 PM, "Steve Martinelli" wrote:
> Looks like Manila
On 20 June 2016 at 12:33, Morgan Fainberg wrote:
>
>
> On Sun, Jun 19, 2016 at 6:51 PM, Adam Young wrote:
>
>> On 06/16/2016 02:19 AM, Jamie Lennox wrote:
>>
>> Thanks everyone for your input.
>>
>> I generally agree that there is something that doesn&#
On 21 June 2016 at 11:41, Edward Leafe wrote:
> On Jun 18, 2016, at 9:03 AM, Clint Byrum wrote:
>
> > Whatever API version is used behind the compute API is none of the user's
> > business.
>
> Actually, yeah, it is.
>
> If I write an app or a tool that expects to send information in a certain
>
On 29 June 2016 at 09:49, Steve Martinelli wrote:
> I think we want something a bit more organized.
>
> Morgan tossed the idea of a keystone-docs repo, which could have:
>
> - The FAQ Adam is asking about
> - Install guides (moved over from openstack-manuals)
> - A spot for all those neat and uno
1 - 100 of 175 matches
Mail list logo
