Open Stack

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.day at 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" <rbryant at 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 at lists.openstack.org
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5441 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140408/06eb689d/attachment.bin>