Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix Linode plan selection #47810
What does this PR do?
Fixes Linode plan selection in the Linode Salt Cloud module.
What issues does this PR fix or reference?
Linode plan labels used to look like this:
Additionally, 1GB Linodes are labeled
This has broken, presumably, all existing Linode cloud profiles.
Only accepting plan labels in the form of
Accepting labels in either form (
Commits signed with GPG?
@rallytime I'm not necessarily opposed to doing so.
My thought was that, given how many cloud profiles this likely will have broken, it would be better to create backwards compatibility than to require every single user of the Linode module to modify all of their Linode cloud profiles (an easy enough sed for a few profiles, but if I have 300 cloud profiles
I can see your argument too, though. If you have a preference for that approach, and letting the user sort things out, I'm happy to adjust.
@rmcintosh Yeah, I can definitely see how that would be helpful for people. I also am thinking about maintaining this moving forward and what that should look like. I updated the docs for the Linode driver in #47781, but I can see how editing many cloud profiles would be a chore.
Maybe a good compromise would be to keep this helpful change, but also warn the user that they're using an old size?
@saltstack/team-cloud Anyone else have a preference here?
There are not any active plans to move from v3 to v4 that I know of. If you're willing to update the driver, that would be great!
A change like that should definitely go into develop and be run through the cloud tests. As long as v4 can effectively support the same functionality that is currently here, then that should be good. The API connection doesn't have any package dependencies, so that makes upgrading support easier.
Are the connection/authentication parameters the same? (I have not looked.) If they are, that would be most excellent so we wouldn't need to worry about supporting both the v3 and v4 versions at once.
v4 uses the "Authorization: Bearer $token" scheme vs. v3 which only accepts
Alone, that isn't too troublesome to work around but at least presently, the two token types are not inter-compatible - so one cannot use a v3 token in the v4 API (or vice versa). So, your concern about maintaining both is well-founded. Offhand, I don't have a great solution to the problem... but I'll ponder that
Just one nitpick change, everything else looks good to me.
I have a couple of requests - mostly very picky ones.
Thanks again for this fix. :)
One thing we have done in the past was create a new file/driver for new API versions. We had to do that with the DigitalOcean driver a couple of years ago when they changed their API versions significantly.
I see that Linode has marked the v3 API as deprecated, so it's a good idea to build out a v4 version now. Is that something you'd like to work on @rmcintosh? If not, we can start working on it.
Once the v4 version is complete, we can put the old driver on a deprecation path to be eventually replaced completely by v4. Do you know how long Linode is planning on supporting v3?
The same idea of maintaining functionality would apply (at least as best as possible) to the new driver. Then the v4 version will already be in place/tested before v3 support is removed on Linode's end.
@rallytime Thanks! I think I got to each of those - but please let me know if I overlooked anything
I'd be happy to start working on it! And I think creating a new driver for the v4 version would be wise - I had pondered whether that would be a possible solution but wasn't sure if you all were amenable to that. Good to know
There's no set date, presently. We anticipate that it will be quite some time before we're able to decommission it completely (1 year or longer, at least, in all likelihood).
This sounds reasonable to me