Hi,
I'm jumping in this thread to understand whether there's a chance KeyStone can
implement some use cases around the concept of object ownership.
I apologise if this email turns out to be a bunch of nonsense; unfortunately I
don't have a strong AAA background :).
As pointed out several times
Ziad,
1. You mention that Nova has a shim for lazy syncing of accounts with
Keystone. What about Swift? Or the account_autocreate (in proxy-server.conf)
the only option to achieve this?
2. As to the Rackspace dashboard, what API does it use for provisioning? Is it
a Rackspace-only API or so
I know there is a middleware piece:
https://github.com/rackspace/keystone/blob/master/keystone/middleware/swift_auth.py
I'll defer to the swift folks on the other parts…
From: "Khandeshi, Divyesh"
mailto:divyesh.khande...@hp.com>>
Date: Mon, 18 Jul 2011 15:47:31 +0100
To: Ziad Sawalha
mailto:z
Hi Divyesh – additional info I just got:
"run with account_autocreate = True. As long as account ids == tenant names,
you should be fine. For example, if you request /v1.0/AUTH_foobar and you have
the foobar tenant then it will try to authorize against the foobar tenant."
Z
From: "Khandeshi,
The original purpose behind sharing the HostID with a customer was to allow
a customer to identify situations where they had two VMs placed on the same
host. This knowledge is extremely critical if a customer is trying to setup
two VMs in an HA configuration. Because this use case does not requir
Below:
On Jul 18, 2011, at 3:28 AM, Salvatore Orlando wrote:
> Hi,
>
> I’m jumping in this thread to understand whether there’s a chance KeyStone
> can implement some use cases around the concept of object ownership.
> I apologise if this email turns out to be a bunch of nonsense; unfortunatel
Hi Vish,
Please see my comments inline.
From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
Sent: 18 July 2011 17:36
To: Salvatore Orlando
Cc: Ziad Sawalha; openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
Below:
On Jul 18, 2011, at 3:28 AM, S
Jay and Monty, could you give the list an update on the status and timeline
of the GitHub migration?
The last informal estimate I had heard was that July 15th was the planned
date. What are the current issues?
--andy
___
Mailing list: https://launchpad.
Hi Ziad,
Thanks for your responses.
So Swift will authenticate against Keystone directly with the method you
describe below? But is there an actual sync mechanism to sync keystone(tenant)
-> swift(account)? account_autocreate provides the lazy option.
Sorry for repeating this (and may be Swift
John,
Thanks for the information.
When you mention PUT/DELETE accounts - where is this API documented? Or could
you provide more details for the supported methods?
Thanks
Divyesh
-Original Message-
From: John Dickinson [mailto:john.dickin...@rackspace.com]
Sent: Monday, July 18, 201
To provision an account in a swift cluster without using the autocreate option,
you must run a proxy server with the allow_account_management option set to
True. Your auth system then needs to PUT/DELETE accounts to that proxy server
as necessary. There are security implications here (which is w
John,
Sorry, hit the send button too fast..
What are the security implications?
Thanks
Divyesh
-Original Message-
From: openstack-bounces+divyesh.khandeshi=hp@lists.launchpad.net
[mailto:openstack-bounces+divyesh.khandeshi=hp@lists.launchpad.net] On
Behalf Of Khandeshi, Divye
The security implications are tied to what credentials as user gets from the
auth server you are using. The possibility is that a user could delete their
own account (or even another user's account) or create new accounts. Disabling
allow_account_management eliminates these issues by disabling t
On 07/18/2011 02:59 PM, Andy Smith wrote:
Jay and Monty, could you give the list an update on the status and
timeline of the GitHub migration?
Things are going quite swimingly. Proof of concept went well and we've
been working on starting to roll some things out.
We've moved the CI repos (gi
On Jul 18, 2011, at 10:24 AM, Salvatore Orlando wrote:
> Hi Vish,
>
> Please see my comments inline.
>
> From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
> Sent: 18 July 2011 17:36
> To: Salvatore Orlando
> Cc: Ziad Sawalha; openstack@lists.launchpad.net
> Subject: Re: [Openstack] Ope
There are two concepts that I would like Nova Volumes to support:
1. Allow different storage classes within a storage driver. For
example, in our case we will have some nodes with high iops
capabilities and other nodes for cheaper/larger volumes.
2. Allow for different storage backends to be
Hi Chuck,
This idea is very good aligned with some functionality we intend to
propose as part of our Virtual Storage Array feature.
I suppose in general the goal here is to be able to create a volume from
storage of specified class. For me it means that:
1. User should be able to select storage
17 matches
Mail list logo
