[openstack-dev] [Nova] Can novaclient help us maintain Grizzly compatibility?

Jay Pipes jaypipes at gmail.com
Mon Jun 10 11:50:26 UTC 2013


On 06/10/2013 02:35 AM, Kieran Spear wrote:
> Hi all,
>
> There's code working its way through OpenStack to enable editing a security group's name and description [1]. Looking at the Horizon patch got me thinking about how we can avoid exposing the new UI to Grizzly nova users where it's not supported. There doesn't seem to be a good way to do this currently, short of hard-coding switches in the Horizon settings file.
>
> Nova v2 has an /extensions endpoint that gives out an "updated" timestamp for each extension. It seems like novaclient has the information it needs to provide downstream users like Horizon with API availability information that would facilitate the kind of N-1 release compatibility that Horizon aims for, but it doesn't expose or wrap it.
>
> One solution is to add a method to the base manager that can be used to ask whether an action is supported, e.g.:
>
> is_supported = client.security_groups.supports('update')

++

> The actual version to check for would be defined in the SecurityGroupManager in that case, so client users wouldn't need to care about it, and Novaclient reviewers can easily cross-check that version with what's added to Nova.
>
> What do people think? Is this worth pursuing? From poking around novaclient it looks like this would be trivial to implement, which makes me wonder if there's a good reason why it isn't there already.

I think it's a great idea.

-jay




More information about the OpenStack-dev mailing list