Hi Justin, Glad you like the idea of using lock ;-)
I still think you need some more granularity that user or admin - currently for Trove to lock the users VMs as admin it would need an account that has admin rights across the board in Nova, and I don't think folks would want to delegate that much power to Trove. Also the folks who genuinely need to enforce an admin level lock on a VM (normally if there is some security issue with the VM) wouldn’t want Trove to be able to unlock it. So I think we're on the right lines, but needs more thinking about how to get a bit more granularity - I'm thinking of some other variant of lock that fits somewhere between the current user and admin locks, and is controlled via policy by a specific role, so you have something like: User without AppLock role - can apply/remove user lock to instance. Cannot perform operations is any lock is set on the instance User with AppLock role - can apply/remove application lock to instance. Cannot perform operations on the instance if the admin lock is set User with Admin role - can apply/remove admin lock. Can perform any operations on the instance Phil > -----Original Message----- > From: Hopper, Justin > Sent: 07 April 2014 19:01 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature > > Phil, > > I think you “lock” concept is more along the lines of what we are looking for. > Hiding them is not a requirement. Preventing the user from using Nova > directly on those Instances is. So locking it with an “Admin” user so that > they > could not snapshot, resize it directly in Nova would be great. When they use > the Trove API, Trove, as Admin, could “unlock” those Instances, make the > modification and then “lock” them after it is complete. > > Thanks, > > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
