Should supernova be abandoned?

[major]

There are some issues at play that make supernova difficult to maintain:

• The python keyring module has made some large changes recently that make it difficult to use
• The openstackclient module is getting more and more features, many of which overlap with supernova
• supernova was only meant to be a hack until multi-region or multi-cloud configurations existed for OpenStack tools (which openstackclient is now doing in a much more elegant way)

I'm asking the supernova users to weigh in on:

1. Abandoning supernova (and putting it into maintenance mode)
2. Keep the project going, but adopt the openstackclient configuration file (abandoning ~/.supernova configuration files)

There may be other options that I haven't thought about, either. Feel free to add any suggestions you can think of here!

[samjsharpe]

If OSC includes roughly the same features as supernova then I vote for deprecation (1).

A nice way of doing it is by creating a branch of this repo that only contains a README.md saying the project is in maintenance mode and then setting that branch to be the default for this github project so people can immediately see that's what's happened but the code on master is still available.

Bonus points if that README.md also lists how to port any config in supernova to OSC and examples of equivalent commands.

[yodermk]

I've not used openstackclient but it looks good so (1) is fine with me.

[ahill00]

I'm a heavy supernova user. I'd like to see option 2 with a new major version number.

[Trozz]

I have been a heavy supernova user for quite some time, but with the features of OSC I would vote for deprecation (1).

*Edit typo

[major]

@Trozz Thanks -- I assume you meant OSC (openstackclient)? :)

[jimrollenhagen]

I'd vote for (1.5): keep supernova around until the nova CLI is officially deprecated, then do (1).

(I think that's the long-term plan, anyway, not sure if there's a timeline yet. Bugging #openstack-nova now :P)

[major]

@andyhky Would you want supernova to work the same way but just use the clouds.yml as a backend?

[major]

Thanks, @jimrollenhagen!

[rillip3]

I had not use openstack client previously, but getting Supernova to work now (mostly due to Nova dependencies) is kind of a PITA. I installed it to try it out right now, and I can definitely say I'd prefer to use something like Supernova to manage all these danged environment variables, particularly since to use a token I have to provide the service that the token is for (for some reason... I'm also sad it only takes token or password, not API key. Seems like a fundamental oversight in how APIs are used). I'd vote 2

[major]

@rillip3 Are you saying that openstackclient, other openstack tools, or supernova is difficult to install? I'd like to understand your use case and concerns a bit more.

[jimrollenhagen]

Turns out nova folks don't really have a plan to deprecate the CLI, and certainly not any time soon, so ignore me :)

[rudymccomb]

I agree with @Trozz I would rather option 2 than abandon it altogether. I am starting to use openstackclient but I have not seen a feature yet that allows it to manage multiple environments the way supernova does. That being said @rillip3 has a point getting it working is a pita. Too bad Supernova cant merge with openstackclient.

[major]

Thanks for the comments, @rudymccomb. What would you want to see from openstackclient that exists in supernova?