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?

[major]

After a freenode discussion, I got a link to this bug:

• https://bugs.launchpad.net/python-openstackclient/+bug/1319381

Keyring support probably needs to come out unless there is a viable alternative. :(

[dtroyer]

@rudymccomb OSC uses os-client-config which provides ~/.config/openstack/clouds.yaml support for managing multiple cloud configurations. This is being added to some of the project CLIs also (I am unsure of status WRT nova offhand). This reduces env switching to setting --os-cloud (or OS_CLOUD) properly.

[major]

How about this going forward (perhaps for supernova 3.0?):

1. Use the os-client-config module to use the ~/.config/openstack/clouds.yaml as the configuration backend
   • This would allow users to configure openstackclient properly (which is handy)
   • Then supernova could get its config from there
   • Lots more testing exists in os-client-config than in supernova ;)
2. Remove keyring support
   • It sounds like the python keyring module needs work
   • For automated scripts, users should be vaulting their credentials anyway
3. Update documentation to reflect the new changes

Comments? Concerns?

[igueths]

I would vote for option two here; I have been a Supernova user whenever I have had to do things with Nova, which admittedly has not been that frequently however that is starting to change.

[ahill00]

@major - the plan in your comment[1] sounds reasonable.

[1] https://github.com/major/supernova/issues/108#issuecomment-206439619

[msabramo]

But does openstackclient support all the features that supernova supports?

I've just recently started playing with using openstackclient instead of novaclient and the clouds.yaml stuff from os_client_config is nifty, but does openstack client let you target multiple clouds with one command, like supernova does? Maybe I missed it, but I didn't see that feature.

Maybe some of the features of supernova (with targeting multiple environments at once, groups, and dynamic config coming to mind) could be contributed to openstackclient before supernova is deprecated?

[aoyawale]

not sure if I'm late to the party but, I vote for the second option. I just discovered supernova and it has made my life easier. We are still using an older openstack version so using supernova has given me less gray hairs.