Open Stack

On Sun, Apr 6, 2014 at 9:36 AM, Russell Bryant <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>> 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.


> 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.

Since we'd prefer to keep these checks at the Infrastructure layer intact
for Users that interact with the Trove API, I think the issue goes beyond
just filtering them out from the API.

One idea that we've floated around is possibly introducing a 'shadow'
tenant, that allows Services like Trove to create Nova / Cinder / Neutron
resources on behalf of the actual tenant.  The resources owned by this
shadow tenant would only be visible / manipulated by a higher-level
Service.  This could require some Service token to be provided along with
the original tenant token.

Example: POST /v2/{shadow_tenant_id}/servers


> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140406/931e7d98/attachment.html>