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

package: add :upgrade action #337

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

terceiro
Copy link
Contributor

Since there is no generic way of checking whether there is a new version
of a given package, the upgrade action just installs the package
unconditionally, assuming that the package installation command will
install a newer version if it's available (that's the case for e.g.
apt-get).

Since it's only possible to check whether there was any version change
after the action, show_differences needs to be called explicitly when
the package version changes for us to get some feedback in the logs.

Since there is no generic way of checking whether there is a new version
of a given package, the upgrade action just installs the package
unconditionally, assuming that the package installation command will
install a newer version if it's available (that's the case for e.g.
apt-get).

Since it's only possible to check whether there was any version change
_after_ the action, show_differences needs to be called explicitly when
the package version changes for us to get some feedback in the logs.
@unasuke
Copy link
Member

unasuke commented Mar 14, 2021

First, thank you for your pull request.

I'm still not sure why this is necessary.
A "configuration management tool" like Itamae needs to be idempotent, reproducible, and declarative.
In this respect, ":upgrade action" seems very procedural to me.

For example, If you need to install newer package, you can specify the "version" attribute to the package resource I think.

Could you give us a more detailed use case?

@terceiro
Copy link
Contributor Author

I maintain a platform of 30+ machines, which I'm migrating from chef to itamae. There are 3 packages that are developed for that platform, of which we always want the latest version. Today, those packages are uploaded to repositories that are configured in the machines, and in chef, the install action does the upgrade, and testing the migration I noticed that itamae skips the installation completely if any version of the package is already installed.

@terceiro
Copy link
Contributor Author

Also, if I add new machines to the platform, using install the new ones will get the new version of those packages, while the older ones would be stuck with the previous version.

@terceiro
Copy link
Contributor Author

On the other hand, I understand your reluctance since my implementation violates a few principles of the itamae design, such as knowing what would happen without doing anything (e.g. --dry-run)

@unasuke
Copy link
Member

unasuke commented Mar 15, 2021

I understood. In that case, it's useful. And hard to write a spec. (I can't find a way to mock the behavior of the package manager.)
Could you give us more time to review it?

I want your opinion @sue445 . I basically agree with this.

@sue445
Copy link
Member

sue445 commented Mar 16, 2021

I basically agree with this.

me too.

@terceiro Please add test code for this new feature.

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

Successfully merging this pull request may close these issues.

3 participants