<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Microsoft JhengHei";
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Its more than just non-admin, it also allows a user to lock an instance so that they don’t accidentally perform some operation on a VM.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">At one point it was (by default) an admin only operation on the OSAPI, but its always been open to all users in EC2. Recently it was changed so that admin
and non-admin locks are considered as separate things.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Chen CH Ji [mailto:jichenjc@cn.ibm.com]
<br>
<b>Sent:</b> 08 April 2014 07:13<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Nova][Trove] Managed Instances Feature<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><span style="font-size:10.0pt;font-family:"Arial","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)</span><br>
<span style="font-size:10.0pt;font-family:"Arial","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 .</span><br>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Best Regards! <br>
<br>
Kevin (Chen) Ji </span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">纪</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">
</span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">晨</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif""><br>
<br>
Engineer, zVM Development, CSTL<br>
Notes: Chen CH Ji/China/IBM@IBMCN Internet: <a href="mailto:jichenjc@cn.ibm.com">
jichenjc@cn.ibm.com</a><br>
Phone: +86-10-82454158<br>
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC
</span><br>
<br>
<img border="0" width="16" height="16" id="_x0000_i1025" src="cid:image001.gif@01CF531C.C1607EB0" alt="Inactive hide details for "Hopper, Justin" ---04/08/2014 02:05:02 PM---Phil, I am reviewing the existing “check_instance_lock"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#424282">"Hopper,
Justin" ---04/08/2014 02:05:02 PM---Phil, I am reviewing the existing “check_instance_lock” implementation to see</span><br>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">From:
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">"Hopper, Justin" <<a href="mailto:justin.hopper@hp.com">justin.hopper@hp.com</a>></span><br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">To: </span>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif"">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,
</span><br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Date:
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">04/08/2014 02:05 PM</span><br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Subject:
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">Re: [openstack-dev] [Nova][Trove] Managed Instances Feature</span><o:p></o:p></p>
<div class="MsoNormal">
<hr size="2" width="100%" noshade="" style="color:#8091A5" align="left">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<tt><span style="font-size:10.0pt">Phil,</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<tt>I am reviewing the existing “check_instance_lock” implementation to see</tt><br>
<tt>how it might be leveraged. Off the cuff, it looks pretty much what we</tt><br>
<tt>need. I need to look into the permissions to better understand how one</tt><br>
<tt>can “lock” and instance.</tt><br>
<br>
<tt>Thanks for the guidance.</tt><br>
<br>
<br>
<tt>Justin Hopper</tt><br>
<tt>Software Engineer - DBaaS</tt><br>
<tt>irc: juice | gpg: EA238CF3 | twt: @justinhopper</tt><br>
<br>
<br>
<br>
<br>
<tt>On 4/7/14, 10:01, "Day, Phil" <<a href="mailto:philip.day@hp.com">philip.day@hp.com</a>> wrote:</tt><br>
<br>
<tt>>I can see the case for Trove being to create an instance within a</tt><br>
<tt>>customer's tenant (if nothing else it would make adding it onto their</tt><br>
<tt>>Neutron network a lot easier), but I'm wondering why it really needs to</tt><br>
<tt>>be hidden from them ?</tt><br>
<tt>></tt><br>
<tt>>If the instances have a name that makes it pretty obvious that Trove</tt><br>
<tt>>created them, and the user presumably knows that did this from Trove, why</tt><br>
<tt>>hide them ? I'd of thought that would lead to a whole bunch of</tt><br>
<tt>>confusion and support calls when they try to work out why they are out</tt><br>
<tt>>of quota and can only see subset of the instances being counted by the</tt><br>
<tt>>system.</tt><br>
<tt>></tt><br>
<tt>>If the need is to stop the users doing something with those instances</tt><br>
<tt>>then maybe we need an extension to the lock mechanism such that a lock</tt><br>
<tt>>can be made by a specific user (so the trove user in the same tenant</tt><br>
<tt>>could lock the instance so that a non-trove user in that tenant couldn’t</tt><br>
<tt>>unlock ). We already have this to an extent, in that an instance locked</tt><br>
<tt>>by an admin can' t be unlocked by the owner, so I don’t think it would be</tt><br>
<tt>>too hard to build on that. Feels like that would be a lot more</tt><br>
<tt>>transparent than trying to obfuscate the instances themselves.</tt><br>
<tt>></tt><br>
<tt>>> -----Original Message-----</tt><br>
<tt>>> From: Hopper, Justin</tt><br>
<tt>>> Sent: 06 April 2014 01:37</tt><br>
<tt>>> To: OpenStack Development Mailing List (not for usage questions)</tt><br>
<tt>>> Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature</tt><br>
<tt>>> </tt><br>
<tt>>> Russell,</tt><br>
<tt>>> </tt><br>
<tt>>> Thanks for the quick reply. If I understand what you are suggesting it</tt><br>
<tt>>>is that</tt><br>
<tt>>> there would be one Trove-Service Tenant/User that owns all instances</tt><br>
<tt>>>from</tt><br>
<tt>>> the perspective of Nova. This was one option proposed during our</tt><br>
<tt>>> discussions. However, what we thought would be best is to continue to</tt><br>
<tt>>>use</tt><br>
<tt>>> the user credentials so that Nova has the correct association. We</tt><br>
<tt>>>wanted a</tt><br>
<tt>>> more substantial and deliberate relationship between Nova and a</tt><br>
<tt>>> dependent service. In this relationship, Nova would acknowledge which</tt><br>
<tt>>> instances are being managed by which Services and while ownership was</tt><br>
<tt>>>still</tt><br>
<tt>>> to that of the User, management/manipulation of said Instance would be</tt><br>
<tt>>> solely done by the Service.</tt><br>
<tt>>> </tt><br>
<tt>>> At this point the guard that Nova needs to provide around the instance</tt><br>
<tt>>>does</tt><br>
<tt>>> not need to be complex. It would even suffice to keep those instances</tt><br>
<tt>>> hidden from such operations as ³nova list² when invoked by directly by</tt><br>
<tt>>>the</tt><br>
<tt>>> user.</tt><br>
<tt>>> </tt><br>
<tt>>> Thanks,</tt><br>
<tt>>> </tt><br>
<tt>>> Justin Hopper</tt><br>
<tt>>> Software Engineer - DBaaS</tt><br>
<tt>>> irc: juice | gpg: EA238CF3 | twt: @justinhopper</tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> On 4/5/14, 14:20, "Russell Bryant" <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:</tt><br>
<tt>>> </tt><br>
<tt>>> >On 04/04/2014 08:12 PM, Hopper, Justin wrote:</tt><br>
<tt>>> >> Greetings,</tt><br>
<tt>>> >></tt><br>
<tt>>> >> I am trying to address an issue from certain perspectives and I think</tt><br>
<tt>>> >> some support from Nova may be needed.</tt><br>
<tt>>> >></tt><br>
<tt>>> >> _Problem_</tt><br>
<tt>>> >> Services like Trove use run in Nova Compute Instances. These</tt><br>
<tt>>> >> Services try to provide an integrated and stable platform for which</tt><br>
<tt>>> >> the ³service² can run in a predictable manner. Such elements include</tt><br>
<tt>>> >> configuration of the service, networking, installed packages, etc.</tt><br>
<tt>>> >> In today¹s world, when Trove spins up an Instance to deploy a</tt><br>
<tt>>> >> database on, it creates that Instance with the Users Credentials.</tt><br>
<tt>>> >> Thus, to Nova, the User has full access to that Instance through</tt><br>
<tt>>> >> Nova¹s API. This access can be used in ways which unintentionally</tt><br>
<tt>>> compromise the service.</tt><br>
<tt>>> >></tt><br>
<tt>>> >> _Solution_</tt><br>
<tt>>> >> A proposal is being formed that would put such Instances in a</tt><br>
<tt>>> >> read-only or invisible mode from the perspective of Nova. That is,</tt><br>
<tt>>> >> the Instance can only be managed from the Service from which it was</tt><br>
<tt>>> >> created. At this point, we do not need any granular controls. A</tt><br>
<tt>>> >> simple lock-down of the Nova API for these Instances would suffice.</tt><br>
<tt>>> >> However, Trove would still need to interact with this Instance via</tt><br>
<tt>>>Nova</tt><br>
<tt>>> API.</tt><br>
<tt>>> >></tt><br>
<tt>>> >> The basic requirements for Nova would beŠ</tt><br>
<tt>>> >></tt><br>
<tt>>> >> A way to identify a request originating from a Service vs coming</tt><br>
<tt>>> >> directly from an end-user</tt><br>
<tt>>> >> A way to Identify which instances are being managed by a Service</tt><br>
<tt>>> >> A way to prevent some or all access to the Instance unless the</tt><br>
<tt>>> >> Service ID in the request matches that attached to the Instance</tt><br>
<tt>>> >></tt><br>
<tt>>> >> Any feedback on this would be appreciated.</tt><br>
<tt>>> ></tt><br>
<tt>>> >The use case makes sense to me. I'm thinking we should expect an</tt><br>
<tt>>> >identity to be created in Keystone for trove and have trove use that</tt><br>
<tt>>> >for managing all of its instances.</tt><br>
<tt>>> ></tt><br>
<tt>>> >If that is sufficient, trove would need some changes to use its service</tt><br>
<tt>>> >credentials instead of the user credentials. I don't think any changes</tt><br>
<tt>>> >are needed in Nova.</tt><br>
<tt>>> ></tt><br>
<tt>>> >Is there anything missing to support your use case using that approach?</tt><br>
<tt>>> ></tt><br>
<tt>>> >--</tt><br>
<tt>>> >Russell Bryant</tt><br>
<tt>>> ></tt><br>
<tt>>> >_______________________________________________</tt><br>
<tt>>> >OpenStack-dev mailing list</tt><br>
<tt>>> ><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></tt><br>
<tt>>> ><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><br>
<tt>></tt><br>
<tt>>_______________________________________________</tt><br>
<tt>>OpenStack-dev mailing list</tt><br>
<tt>><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></tt><br>
<tt>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><br>
<tt>[attachment "smime.p7s" deleted by Chen CH Ji/China/IBM] _______________________________________________</tt><br>
<tt>OpenStack-dev mailing list</tt><br>
<tt><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></tt><br>
<tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt></span><o:p></o:p></p>
</div>
</div>
</body>
</html>