Open life5ign opened 1 year ago
Files identified in the description:
If these files are incorrect, please update the component name
section of the description or use the !component
bot command.
cc @mulby click here for bot help
Hi @life5ign thanks for your ticket (again). A couple of comments:
auto
?Hello @russoz , thanks for the reply; the way I see it: if I'm selecting path for the command, it implies that it's manual, so it's contradictory for it to remain in auto mode, subject to change by the system; if I declare I want a state, ansible should ensure that the the system can't just change it to something else.
from man update-alternatives
:
Each link group is, at any given time, in one of two modes: automatic or manual. When a group is in automatic mode, the alternatives system will automatically decide, as packages are installed and removed, whether and how to update the links. In manual mode, the alternatives system will retain the choice of the administrator and avoid changing the links (except when something is broken).
Link groups are in automatic mode when they are first introduced to the system. If the system administrator makes changes to the system's automatic settings,
this will be noticed the next time update-alternatives is run on the changed link's group, and the group will automatically be switched to manual mode.
This is why I consider it a bug that when I, as the admin, am specifying a certain file (the program) to be referred to by a name, ansible doesn't make this happen fully, in that it lets that name remain open to be changed to point to a different file, upon an upgrade, e.g. If I were setting this on the CLI, namely pointing a name to a given file, it would be set in manual mode; it would not be automatic at that point.
Hello @russoz , thanks for the reply; the way I see it: if I'm selecting path for the command, it implies that it's manual, so it's contradictory for it to remain in auto mode, subject to change by the system; if I declare I want a state, ansible should ensure that the the system can't just change it to something else.
Exactly my point: that is your understanding. I am not a regular user of alternatives
(neither command nor module), so I cannot vouch for that, so whilst I appreciate the rationale you presented, I cannot help wonder that there might be other users out there who do not expect ansible to be forever responsible for the link group once it touches it.
The fact that the module author(s) thought of the auto/manual setting and did not decide to turn the link groups automatically into manual tells me that there was a different set of expectations to them.
from
man update-alternatives
:Each link group is, at any given time, in one of two modes: automatic or manual. When a group is in automatic mode, the alternatives system will automatically decide, as packages are installed and removed, whether and how to update the links. In manual mode, the alternatives system will retain the choice of the administrator and avoid changing the links (except when something is broken). Link groups are in automatic mode when they are first introduced to the system. If the system administrator makes changes to the system's automatic settings,
I might be splitting hairs here, but assuming the wording is accurate and that the devil is int he details, I need to ask: by linking a group to one specific target (that might or might not be the same already in place), does that change "the system's automatic settings"? The sentence from the manual does not (update: I missed the negation the first time around) seem to necessarily indicate that updating the links should turn the group manual.
this will be noticed the next time update-alternatives is run on the changed link's group, and the group will automatically be switched to manual mode.
This is why I consider it a bug that when I, as the admin, am specifying a certain file (the program) to be referred to by a name, ansible doesn't make this happen fully, in that it lets that name remain open to be changed to point to a different file, upon an upgrade, e.g. If I were setting this on the CLI, namely pointing a name to a given file, it would be set in manual mode; it would not be automatic at that point.
We have two different states related to a link group: the target of the link(s) and the mode. Maybe what the module is missing is a parameter mode
to allow admins to determine that behaviour.
@russoz ok, thank you for explaining that my thoughts and beliefs are mine, that wasn't clear before. But we are on github, and I'm just an ansible user who is trying to be helpful to the community by copying this (call it whatever you want, I actually don't really care what it's called) over from a stale thread that I encountered. I don't have the time to go much into this, but it seems that you might?
I read the first and last sentences of your post, and I do think mode
is necessary.
Not sure when I would be able to work on that, but this ticket clearly needs to be in the backlog.
Have you tried state=selected
? state=present
means "I don't care whether it's auto or not", while state=selected
means "I want to have it selected, but not as auto".
Hmm, I see you mentioned state: selected
in the issue description. So your report has nothing to do with the issue in https://github.com/ansible/ansible/issues/66598 except a similar description, since the module in ansible/ansible never supported state=selected
but only state=present
(and the issue was asking to change the behavior of what state=present
is).
In any case, if state=selected
results in auto, then this is very likely a bug in the module.
I'm turning off email notifications for this thread due to the extra attitude and rudeness brought to the table by the last two users who responded. Hopefully the ansible team can make up for this with more friendly people somehow. So no, I won't be seeing any replies below.
I'm sorry that you perceive our comments as rude. We try to triage issues to figure out what are actually bugs, what are wishes/feature requests, and what are user support questions. As the discussion in this issue shows this isn't usually so clear.
Apologies for giving you that impression, it was never the intention. That being said, as Felix has put it, we usually try to focus on the technical issue.
As to the issue at hand, I am glad we agreed on a way to move forward, despite your reservations with the language. And I meant what I wrote that this must be in the collection's backlog. Personally, I have been working on different modules lately and I cannot spare more bandwidth to add another one t this time, but hopefully will be able to do so in a not so distant future.
The param state
was first introduced in 4.8.0
. The reference I can find is #4576
Actually, that state
param PR came from a reported issue https://github.com/ansible-collections/community.general/issues/4543 which seemed to point, in a first quick glance, to the problems caused by setting the alternatives mode to manual. But I definitely need to read it more carefully and run a couple of tests before drawing any conclusions.
Heey, I'm running into the same problem as described above. The default for all alternatives seems to be automatic mode so there is currently no way using Ansible to set a specific version as active. Much appreciation here if you could consider to fix the bug / build the feature.
In any case, if
state=selected
results in auto, then this is very likely a bug in the module.
The problem is that state=selected
will be true if the alternative has already selected automatically. In that case no change is made and "auto" is still in force.
If, later in my play, another package which provides the same alternative (with a higher priority) is installed it will then become selected (still on auto).
Running the same play a second time results in community.general.alternatives
changing the alternative, and at that point it will be set to "manual".
This breaks idempotency. Either a user will rely on the priority
and state=present
, or they will expect a specific alternative to be selected
. The module needs to check not just the value of the link, but also make sure it is set to manual in the latter case to know if an update is required.
Summary
This issue never got ported over, as far as I can tell; I can confirm that the alternatives module still doesn't set the mode to "manual, at least not when the alternative was already set to the correct path"
Please see original issue, as well as my new writeup, in which I confirm the issue is still present.
https://github.com/ansible/ansible/issues/66598
Issue Type
Bug Report
Component Name
alternatives
Ansible Version
Community.general Version
and, I'm using the updated version 7.1.0, which I just updated
Configuration
OS / Environment
Ubuntu 22.04 LTS
Steps to Reproduce
Expected Results
I expect the mode to be "manual" on the server
Actual Results
but it is still "auto":
Code of Conduct