On 07/25/2018 10:29 AM, William M Edmonds wrote:
Ghanshyam Mann <gm...@ghanshyammann.com> wrote on 07/25/2018 05:44:46 AM:
... snip ...
> 1. is it ok to show the keypair used info via API ? any original
> rational not to do so or it was just like that from starting.
keypairs aren't tied to a tenant/project, so how could nova track/report a quota
for them on a given tenant/project? Which is how the API is constructed... note
the "tenant_id" in GET /os-quota-sets/{tenant_id}/detail
> 2. Because this change will show the keypair used quota information
> in API's existing filed 'in_use', it is API behaviour change (not
> interface signature change in backward incompatible way) which can
> cause interop issue. Should we bump microversion for this change?
If we find a meaningful way to return in_use data for keypairs, then yes, I
would expect a microversion bump so that callers can distinguish between a)
talking to an older installation where in_use is always 0 vs. b) talking to a
newer installation where in_use is 0 because there are really none in use. Or if
we remove keypairs from the response, which at a glance seems to make more
sense, that should also have a microversion bump so that someone who expects the
old response format will still get it.
Keypairs are weird in that they're owned by users, not projects. This is
arguably wrong, since it can cause problems if a user boots an instance with
their keypair and then gets removed from a project.
Nova microversion 2.54 added support for modifying the keypair associated with
an instance when doing a rebuild. Before that there was no clean way to do it.
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
