<html><body><p><font size="2"><br></font><tt><font size="2">Ghanshyam Mann <gmann@ghanshyammann.com> wrote on 07/25/2018 05:44:46 AM:<br>... snip ...</font></tt><br><tt><font size="2">> 1. is it ok to show the keypair used info via API ? any original <br>> rational not to do so or it was just like that from starting. <br></font></tt><br><tt><font size="2">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</font></tt><br><tt><font size="2"><br>> 2. Because this change will show the keypair used quota information <br>> in API's existing filed 'in_use', it is API behaviour change (not <br>> interface signature change in backward incompatible way) which can <br>> cause interop issue. Should we bump microversion for this change? <br></font></tt><br><tt><font size="2">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.</font></tt><br><BR>
</body></html>