8000 Should supernova be abandoned? · Issue #108 · major/supernova · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Mar 13, 2022. It is now read-only.

Should supernova be abandoned? #108

Open
major opened this issue Apr 6, 2016 · 20 comments
Open

Should supernova be abandoned? #108

major opened this issue Apr 6, 2016 · 20 comments
Assignees
Labels

Comments

@major
Copy link
Owner
major commented Apr 6, 2016

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!

@major major self-assigned this Apr 6, 2016
@major major added the question label Apr 6, 2016
@samjsharpe
Copy link

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
Copy link
yodermk commented Apr 6, 2016

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

@ahill00
Copy link
Contributor
ahill00 commented Apr 6, 2016

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

@Trozz
Copy link
Trozz commented Apr 6, 2016

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
Copy link
Owner Author
major commented Apr 6, 2016

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

@jimrollenhagen
Copy link

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
Copy link
Owner Author
major commented Apr 6, 2016

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

@major
Copy link
Owner Author
major commented Apr 6, 2016

Thanks, @jimrollenhagen!

@rillip3
Copy link
rillip3 commented Apr 6, 2016

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
Copy link
Owner Author
major commented Apr 6, 2016

@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
Copy link

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

@rudymccomb
Copy link

I agree with @Trozz I would rather option 2 than abandon it altogether. I am starting to use openst 8000 ackclient 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
Copy link
Owner Author
major commented Apr 6, 2016

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

@major
Copy link
Owner Author
major commented Apr 6, 2016

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

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

@dtroyer
Copy link
dtroyer commented Apr 6, 2016

@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
Copy link
Owner Author
major commented Apr 6, 2016

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?

8000

@igueths
Copy link
igueths commented Apr 6, 2016

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
Copy link
Contributor
ahill00 commented Apr 6, 2016

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

[1] #108 (comment)

@msabramo
Copy link
Contributor
msabramo commented Jul 8, 2016

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
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

0