Open Stack

On 04/06/2014 09:02 AM, Christopher Yeoh wrote:
> On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin <justin.hopper at hp.com
> <mailto:justin.hopper at hp.com>> wrote:
> 
>     Russell,
> 
>     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.
> 
> 
> Are you looking for something to prevent accidental manipulation of an
> instance created by Trove or intentional changes as well? Whilst doing
> some filtering in nova list is simple on the surface, we don't try to
> keep server uuids secret in the API, so its likely that sort of
> information will leak through other parts of the API say through volume
> or networking interfaces. Having to enforce another level of permissions
> throughout the API would be a considerable change. Also it would
> introduce inconsistencies into the information returned by Nova - eg
> does quota/usage information returned to the user include the server
> that Trove created or is that meant to be adjusted as well?
> 
> If you need a high level of support from the Nova API to hide servers,
> then if its possible, as Russell suggests to get what you want by
> building on top of the Nova API using additional identities then I think
> that would be the way to go. If you're just looking for a simple way to
> offer to Trove clients a filtered list of servers, then perhaps Trove
> could offer a server list call which is a proxy to Nova and filters out
> the servers which are Trove specific since Trove knows which ones it
> created.

Yeah, I would *really* prefer to go the route of having trove own all
instances from the perspective of Nova.  Trove is what is really
managing these instances, and it already has to keep track of what
instances are associated with which user.

It sounds like what you really want is for Trove to own the instances,
so I think we need to get down to very specifically won't work with that
approach.

For example, is it a billing thing?  As it stands, all notifications for
trove managed instances will have the user's info in them.  Do you not
want to lose that?  If that's the problem, that seems solvable with a
much simpler approach.

-- 
Russell Bryant