Open Stack

On 04/06/2014 03:22 PM, Vipul Sabhaya wrote:
> 
> 
> 
> On Sun, Apr 6, 2014 at 9:36 AM, Russell Bryant <rbryant at redhat.com
> <mailto:rbryant at redhat.com>> wrote:
> 
>     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>
>     > <mailto: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.
> 
> Although this approach would work, there are some manageability issues
> with it.  When trove is managing 100’s of nova instances, then things
> tend to break down when looking directly at the Trove tenant through the
> Nova API and trying to piece together the associations, what resource
> failed to provision, etc.

This isn't specific enough to understand what the problem is.

>     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.
> 
> 
> We have for the most part solved the billing issue since Trove does
> maintain the association, and able to send events on-behalf of the
> correct user.  We would lose out on the additional layer of checks that
> Nova provides, such as Rate Limiting per project, Quotas enforced at the
> Nova layer.  The trove tenant would essentially need full access without
> any such limits.

Don't you get rate limiting and quotas through the trove API, instead?

-- 
Russell Bryant