On 04/06/2014 03:22 PM, Vipul Sabhaya wrote: > > > > On Sun, Apr 6, 2014 at 9:36 AM, Russell Bryant <rbry...@redhat.com > <mailto:rbry...@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.hop...@hp.com <mailto:justin.hop...@hp.com> > > <mailto:justin.hop...@hp.com <mailto:justin.hop...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev