Open Stack

2018-07-26 1:43 GMT+08:00 Chris Friesen <chris.friesen at windriver.com>:

> On 07/25/2018 10:29 AM, William M Edmonds wrote:
>
>>
>> Ghanshyam Mann <gmann at 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-request at lists.openstack.org?subject:unsubscribe
> 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/20180726/c5792a67/attachment.html>