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