the instance lock is a mechanism that prevent non-admin user to operate on the instance (resize, etc, looks to me snapshot is not currently included) the permission is a wider concept that major in API layer to allow or prevent user in using the API , guess instance lock might be enough for prevent instance actions .
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: "Hopper, Justin" <justin.hop...@hp.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>,
Date: 04/08/2014 02:05 PM
Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature
Phil,
I am reviewing the existing “check_instance_lock” implementation to see
how it might be leveraged. Off the cuff, it looks pretty much what we
need. I need to look into the permissions to better understand how one
can “lock” and instance.
Thanks for the guidance.
Justin Hopper
Software Engineer - DBaaS
irc: juice | gpg: EA238CF3 | twt: @justinhopper
On 4/7/14, 10:01, "Day, Phil" <philip....@hp.com> wrote:
>I can see the case for Trove being to create an instance within a
>customer's tenant (if nothing else it would make adding it onto their
>Neutron network a lot easier), but I'm wondering why it really needs to
>be hidden from them ?
>
>If the instances have a name that makes it pretty obvious that Trove
>created them, and the user presumably knows that did this from Trove, why
>hide them ? I'd of thought that would lead to a whole bunch of
>confusion and support calls when they try to work out why they are out
>of quota and can only see subset of the instances being counted by the
>system.
>
>If the need is to stop the users doing something with those instances
>then maybe we need an extension to the lock mechanism such that a lock
>can be made by a specific user (so the trove user in the same tenant
>could lock the instance so that a non-trove user in that tenant couldn’t
>unlock ). We already have this to an extent, in that an instance locked
>by an admin can' t be unlocked by the owner, so I don’t think it would be
>too hard to build on that. Feels like that would be a lot more
>transparent than trying to obfuscate the instances themselves.
>
>> -----Original Message-----
>> From: Hopper, Justin
>> Sent: 06 April 2014 01:37
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature
>>
>> Russell,
>>
>> Thanks for the quick reply. If I understand what you are suggesting it
>>is that
>> there would be one Trove-Service Tenant/User that owns all instances
>>from
>> the perspective of Nova. This was one option proposed during our
>> discussions. However, what we thought would be best is to continue to
>>use
>> the user credentials so that Nova has the correct association. We
>>wanted a
>> more substantial and deliberate relationship between Nova and a
>> dependent service. In this relationship, Nova would acknowledge which
>> instances are being managed by which Services and while ownership was
>>still
>> to that of the User, management/manipulation of said Instance would be
>> solely done by the Service.
>>
>> At this point the guard that Nova needs to provide around the instance
>>does
>> not need to be complex. It would even suffice to keep those instances
>> hidden from such operations as ³nova list² when invoked by directly by
>>the
>> user.
>>
>> Thanks,
>>
>> Justin Hopper
>> Software Engineer - DBaaS
>> irc: juice | gpg: EA238CF3 | twt: @justinhopper
>>
>>
>>
>>
>> On 4/5/14, 14:20, "Russell Bryant" <rbry...@redhat.com> wrote:
>>
>> >On 04/04/2014 08:12 PM, Hopper, Justin wrote:
>> >> Greetings,
>> >>
>> >> I am trying to address an issue from certain perspectives and I think
>> >> some support from Nova may be needed.
>> >>
>> >> _Problem_
>> >> Services like Trove use run in Nova Compute Instances. These
>> >> Services try to provide an integrated and stable platform for which
>> >> the ³service² can run in a predictable manner. Such elements include
>> >> configuration of the service, networking, installed packages, etc.
>> >> In today¹s world, when Trove spins up an Instance to deploy a
>> >> database on, it creates that Instance with the Users Credentials.
>> >> Thus, to Nova, the User has full access to that Instance through
>> >> Nova¹s API. This access can be used in ways which unintentionally
>> compromise the service.
>> >>
>> >> _Solution_
>> >> A proposal is being formed that would put such Instances in a
>> >> read-only or invisible mode from the perspective of Nova. That is,
>> >> the Instance can only be managed from the Service from which it was
>> >> created. At this point, we do not need any granular controls. A
>> >> simple lock-down of the Nova API for these Instances would suffice.
>> >> However, Trove would still need to interact with this Instance via
>>Nova
>> API.
>> >>
>> >> The basic requirements for Nova would beŠ
>> >>
>> >> A way to identify a request originating from a Service vs coming
>> >> directly from an end-user
>> >> A way to Identify which instances are being managed by a Service
>> >> A way to prevent some or all access to the Instance unless the
>> >> Service ID in the request matches that attached to the Instance
>> >>
>> >> Any feedback on this would be appreciated.
>> >
>> >The use case makes sense to me. I'm thinking we should expect an
>> >identity to be created in Keystone for trove and have trove use that
>> >for managing all of its instances.
>> >
>> >If that is sufficient, trove would need some changes to use its service
>> >credentials instead of the user credentials. I don't think any changes
>> >are needed in Nova.
>> >
>> >Is there anything missing to support your use case using that approach?
>> >
>> >--
>> >Russell Bryant
>> >
>> >_______________________________________________
>> >OpenStack-dev mailing list
>> >OpenStack-dev@lists.openstack.org
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[attachment "smime.p7s" deleted by Chen CH Ji/China/IBM]
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<<inline: graycol.gif>>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
