That's not entirely the case - the API structure has changed rather
significantly (mostly made more consistent and unified), so API calls to V2 may
or may not match entirely with API calls to V3. We did go to the trouble of
writing a very thorough spec, and then checking and updating it as we di
There was a fellow "Panok", I think, that asked me about it in the dev lounge,
sounded like he was perhaps interested in driving that forward. I also sat in
on Mark McLoughlin's talk about normalizing our the RPC API code that's used
across several of the projects, and caught a bit from others t
2013.1 is the release, grizzly-1 is a release candidate
-joe
On Mar 26, 2013, at 8:12 PM, Liu Wenmao wrote:
> I notice that openstack components have two different develop code names, for
> example, openstack grizzly has 2013.1 and grizzly, so what is the difference
> between the two?
>
> T
It doesn't - the AMQP is needed for the Nova/Glance/Cinder/Ceilometer
integration and that internal RPC mechanism that they use.
-joe
On Feb 19, 2013, at 4:53 PM, Everett Toews wrote:
> Hi All,
>
> When I was doing a Swift/Keystone only install with DevStack I used the
> following in my local
Hey Ali,
We don't have an XSD for the V3 API sets - we've been holding off finalizing
that up as we are making small implementation changes as we're getting it into
practice and learning what ideas worked, and which didn't. Jorge (Rackspace)
has something and offered to do more, but hasn't subm
I haven't heard any demand for it -
- joe
On Dec 3, 2012, at 11:13 AM, Adam Young wrote:
> Right now, only the Identity submodule has an LDAP backend. This is user,
> tenants, and roles. Is there any requirement for the Catalog to have an LDAP
> back end? Endpoints and Services do not nece
houldn't have such arbitrary restrictions in
> the API contract though. It needs to be extensible and flexible to allow for
> the all sorts of use cases that are likely to occur.
>
> Thanks,
> joe
>
> -Original Message-
> From: heckj [mailto:he...@mac.
---Original Message-
> From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net
> [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On
> Behalf Of heckj
> Sent: Tuesday, November 13, 2012 1:34 PM
> To: OpenStack Development Mailing List
> C
On Nov 13, 2012, at 11:01 AM, Jorge Williams
wrote:
> On Nov 13, 2012, at 11:35 AM, heckj wrote:
>> So maintaining a token scoped to just the user, and a mechanism to scope it
>> to a tenant sound like all goodness. We can absolutely keep the API such
>> that
tenants.
>>>>>
>>>>> -jOrGe W.
>>>>>
>>>>> On Oct 22, 2012, at 9:57 PM, Adam Young wrote:
>>>>>
>>>>>> Are you guys +1 ing the original Idea, my suggestion to make it
>>>>>> optional, the fact tha
Ahmed,
We'd welcome an update to the script - some have talked about variations they
have that use YAML, etc. As long as it's simple, and can be used from devstack
to do a holistic test and verification, we'll happily take patches to the
script in Keystone. Please suggest them using the gerrit/
Keystone doesn't (yet) support CORS - there's an open blueprint for it, but no
work has been applied there as yet
-joe
On Oct 30, 2012, at 10:57 AM, Renier Morales wrote:
> On Oct 30, 2012, at 1:08 PM, David Kranz wrote:
>
>> On 10/30/2012 12:43 PM, Renier Morales wrote:
>>> Hello,
>>>
>>> I
[--password ] [--tenant_name ]
> [--auth_url ] [--region_name ]
> ...
> keystone: error: too few arguments
> root@bodega:~#
>
>
> --Ahmed.
>
> From: heckj
> Date: Friday, October 26, 2012 2:23 PM
> To: Ahmed Al-Mehdi
> Cc: &q
Ahmed,
Are you trying to find out the version of Keystone installed, or of the CLI
client? (they're different and somewhat unrelated)
-joe
On Oct 26, 2012, at 2:20 PM, Ahmed Al-Mehdi wrote:
> Hello,
>
> The option "--version" (or any variation of it) does not seem to work for
> keystone, eve
Bringing conversation for domains in Keystone to the broader mailing lists.
On Oct 26, 2012, at 5:18 AM, Dolph Mathews wrote:
> I think this discussion would be great for both mailing lists.
>
> -Dolph
>
>
> On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash wrote:
> Hi
>
> v3api doc, or elsewher
Hey Ken,
Anyone can propose a backport at any time - I pestered Mark and he was kind
enough to refer me to:
* http://wiki.openstack.org/StableBranch#Proposing_Fixes
and notes from the summit session around just this
* https://etherpad.openstack.org/process-stable-branch
I took a few minutes
Hi Pradeep,
I'm not sure what the context is for these values, so it's a little hard to
assert a clear answer.
For most openstack projects, (all but keystone), there's generally a single API
endpoints, and the keystone service catalog is configured on deployment to
point to those. The service
John brought the concern over auth_token middleware up to me directly -
I don't know of anyone that's driven the keystone middleware to these rates and
determined where the bottlenecks are other than folks deploying swift and
driving high performance numbers.
The concern that John detailed to
I sent this to the openstack-dev list, and thought I'd double post this onto
the openstack list at Launchpad for additional feedback.
-joe
Begin forwarded message:
> From: heckj
> Subject: [openstack-dev] [keystone] Tokens representing authorization to
> projects/tenants in t
not equivalent
> to manual steps mentioned in "Deploy and Install OpenStack - Red Hat Ubuntu".
> I will look into the script.
>
> Regards,
> Ahmed.
>
> From: Dolph Mathews [dolph.math...@gmail.com]
> Sent: Tuesday, October 02, 2012 2:19 PM
>
> To:
client"
> Unable to authorize user
>
> Regards,
> Ahmed.
>
>
> From: openstack-bounces+ahmed=coraid@lists.launchpad.net
> [openstack-bounces+ahmed=coraid@lists.launchpad.net] On Behalf Of Ahmed
> Al-Mehdi [ah...@cor
> 100 2310 116 100 115 12927 12816 --:--:-- --:--:-- --:--:-- 14500
> {
> "error": {
> "code": 401,
> "message": "The request you have made requires authentication.",
> "title": "Not
Ahmed -
The header that's supposed to have the token within it is labelled
"X-Auth-Token', not "X_Auth_Token". Unless you're really comfortable with the
protocol, I'd recommend using the keystone CLI from the python-keystoneclient
to do your verifying, using it's debugging (which is to show y
Hey Asher,
That's a bug in keystoneclient - the method for doing the role listing is
making a bad assumption that you're authenticating with a username and
password, not handing in a token, and is getting wrapped around the axle trying
to figure out what tenant you are. If you create an admin a
24 matches
Mail list logo
