<div dir="ltr"><div><div><div><div><div>Hi,<br><br>I've noticed that the names for authorisation in the policy.json file for an API extension generally isn't the same as any of the fields in the extension definition. For example, for the Fixed IPs extension we have:<br>
<br>authorize = extensions.extension_authorizer('compute', 'fixed_ips')<br>name = "FixedIPs"<br>alias = "os-fixed-ips"<br><br></div>for floating ips:<br><br>authorize = extensions.extension_authorizer('compute', 'floating_ips')<br>
name = "FloatingIps"<br>alias = "os-floating-ips"<br><br></div>for flavorextradata:<br><br>authorize = extensions.soft_extension_authorizer('compute', 'flavorextradata')<br>name = "FlavorExtraData"<br>
alias = "OS-FLV-EXT-DATA"<br><br></div>This causes a couple of problems. It increases the probability of an accidental name collision and with V3 making it much easier to keep API extensions out of tree this we can't rely on code reviews always picking this up and can't pick up clashes easily at runtime. Secondly to implement <a href="https://blueprints.launchpad.net/nova/+spec/nova-v3-api-filter">https://blueprints.launchpad.net/nova/+spec/nova-v3-api-filter</a> and keep the policy naming for an API extension self consistent it needs to be based on something in the extension.<br>
<br></div>What I'd like to do for only the V3 API is to change the convention so the name used for an extension's policy to be the same as the alias definition. This would make things more difficult for a Grizzly->Havana upgrade, but long term I think its worth it.<br>
<br></div>Any comments?<br><br>Regards,<br><br>Chris<br><br></div>