2018-07-26 1:43 GMT+08:00 Chris Friesen <chris.frie...@windriver.com>:
> 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.
I don't understand this, we didn't count the keypair usage with the
instance together, we just count the keypair usage for specific user.
>
>
> 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
>
__________________________________________________________________________
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
