Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with de-registered Debian Cassandra package versions #421

Open
zmarois opened this issue Mar 1, 2018 · 2 comments
Open

Dealing with de-registered Debian Cassandra package versions #421

zmarois opened this issue Mar 1, 2018 · 2 comments
Labels
enhancement New feature or request needs-feedback Further information is requested

Comments

@zmarois
Copy link
Contributor

zmarois commented Mar 1, 2018

With Cassandra's move back to semantic versioning, they have begun introducing patch versions. However, the Apache Debian repo only maintains the latest patch version for each minor version in their packages list.

I asked about this on the Users mailing list, to which the response was "This is a feature. Users really should be installing the latest release version.". I had made my case for why I'd want a specific version to their IRC channel also. So this is not a bug we can expect to be fixed, but an issue to work around if we want to install a specific version.

While this is not a direct problem caused by this puppet module, it is a concern for users of it if we utilize package_ensure for a specific version.

I'd like to understand if the maintainers of this project have an opinion on dealing with this. I see the following options:

  • Build a different mechanism to install a specific Cassandra version
  • Build any safeguards to at least inform users (API documentation, making package_ensure invalid to set to a specific version > 3.11 on debian systems) that specific versions are only supported if it happens to be the latest version
  • Just let the apt error about missing specific version bubble to the user when Apache releases a new patch (current implementation)

I'm uncomfortable installing the latest version always, as I'd like to keep my cluster all running the same version, and if I need to replace an unhealthy node, I don't want to have to upgrade the rest of my cluster first. So I'm probably going to build some mechanism to support that in my system.

@dallinb
Copy link
Contributor

dallinb commented Mar 1, 2018

I agree that install latest is probably the last option anyone should adopt from a configuration management point of view. Could you expand upon your first suggested option?

@zmarois
Copy link
Contributor Author

zmarois commented Mar 1, 2018

Either hack together some way of constructing a local repo that points to the .deb file in the archive (note that they do all still exist, they just aren't in the Package list), or, when a specific version is specified >= 3.11, use dpkg. Perhaps not allow a specific version >= 3.11 and require a full url to the package.

@juniorsysadmin juniorsysadmin added enhancement New feature or request needs-feedback Further information is requested labels Mar 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs-feedback Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants