Open Stack

On 06/21/2012 12:44 PM, Thomas, Duncan wrote:
> John Griffith on 20 June 2012 18:26 wrote:
> 
> 
>> On Wed, Jun 20, 2012 at 10:53 AM, Nick Barcet
>> <nick.barcet at canonical.com> wrote:
>>> What we want is to retrieve the maximum amount of data, so we can
>> meter
>>> things, to bill them in the end. For now and for Cinder, this would
>>> first include (per user/tenant):
>>> - the amount of reserved volume space
>>> - the amount of used volume space
>>> - the number of volumes
>>> but we'll need probably more in a near future.
> 
> 
>> We should chat about how things are shaping up so far and how you're
>> implementing things on the other sides (consistency where
>> practical/possible).  Also, it sort of depends on the architecture and
>> use model details of Ceilometer, which I hate to admit but I'm not
>> really up to speed on.
>>
>> My first reaction/thought is the best most appropriate place to tie in
>> is via the python-cinderclient.  There would be a number of ways to
>> obtain some of this info, whether deriving it or maybe some extensions
>> to obtain things directly.
> 
> One thing to watch for here is access control... Don't want one tenant 
> able to find out about another's usage. Probably not important on a private
> cloud deployment, but certainly important in the public cloud space. Having
> a separate endpoint to do this kind of admin stuff over also means you can
> have much tighter IP level access controls...

It would seem to me that the easiest way would be for calls that are
emitted from the same host as cinder manager on the local interface to
be handled as "admin" calls. We could then place Ceilometer's cinder
agent on the same host, which would not be allowed to any user, thus not
creating a breach of security.

Thoughts?

Nick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120625/36f72ed4/attachment.sig>