The problem occurs when I try to manage a service like nfsd which has a
default set of flags. Consider the following commands, which basically
performs what ansible does when the user is not supplying any extra
arguments:
---
# rcctl status nfsd
NO
# rcctl enable nfsd
On Fri, Oct 10, 2014 at 01:50:52PM +0200, Antoine Jacoutot wrote:
If I now run the tool again, still without any supplied arguments, it
will compare the empty set of user supplied flags to -tun 4 which
always differs. So ansible will now think it needs to change something
forever :).
On Fri, Oct 10, 2014 at 02:50:40PM +0200, Patrik Lundin wrote:
On Fri, Oct 10, 2014 at 01:50:52PM +0200, Antoine Jacoutot wrote:
If I now run the tool again, still without any supplied arguments, it
will compare the empty set of user supplied flags to -tun 4 which
always differs. So
On Fri, Oct 10, 2014 at 03:05:40PM +0200, Antoine Jacoutot wrote:
But you should not have to.
If you don't pass any flags to ansible, why is ansible looking at the output
of rcctl status to compare flags?
In saltstack, iirc what I implemented is that flags are only compared when
one
Ouch.
I just noticed the following problem.
There are four things a user might want:
1. Disable a service.
rcctl disable service
always does that,
and you can compare the output of
rcctl status service
to NO to decide whether running that is actually needed.
2. Enable
4. Enable the service *without* any arguments (even if it has
default arguments).
It's been discussed at lenght in Slovenia -- that's a known issue; the move of
rc.conf to a parsed config file has had similar side effects on other stuffs.
I see no way to do that with rcctl(8).
Maby the expected results of our tools are different. My goal for the
ansible module is that you either keep a specific set of flags in the
playbook which will then get set if necessary, or you remove the flags
and will instead get the system default.
Not passing any arguments does not
On Fri, Oct 10, 2014 at 03:53:15PM +0200, Antoine Jacoutot wrote:
Maby the expected results of our tools are different. My goal for the
ansible module is that you either keep a specific set of flags in the
playbook which will then get set if necessary, or you remove the flags
and will
On 2014/10/10 15:19, Patrik Lundin wrote:
Not passing any arguments does not mean do not modify any flags, it
means make sure we have the default flags. Because of this I will need
to check if the current set of flags are the default or not.
Would it make sense for rcctl status to display
On Fri, Oct 10, 2014 at 08:02:17PM +0100, Stuart Henderson wrote:
On 2014/10/10 15:19, Patrik Lundin wrote:
Not passing any arguments does not mean do not modify any flags, it
means make sure we have the default flags. Because of this I will need
to check if the current set of flags are the
Hello,
This is another question triggered by working on rcctl(8) support for
the ansible service module.
The module wants to figure out if it should reset the flags in
rc.conf.local to the default set if no arguments are supplied by the
user.
The problem with this is that there is no way to
The module wants to figure out if it should reset the flags in
rc.conf.local to the default set if no arguments are supplied by the
user.
Can you provide an example. Because if not arguments are supplied, according to
your previous mail, it should run like:
rcctl enable foobar flags
which
On Thu, Oct 09, 2014 at 10:58:34PM +0200, Antoine Jacoutot wrote:
The module wants to figure out if it should reset the flags in
rc.conf.local to the default set if no arguments are supplied by the
user.
Can you provide an example. Because if not arguments are supplied, according
to
Sorry, I should probably have been more clear on the reason I need it :).
The main issue from the ansible perspective is to know if we are _going_
to change something or not. The user may for example run ansible in
--check mode where it should only report if it is about to change
something
On Thu, Oct 09, 2014 at 11:25:58PM +0200, Antoine Jacoutot wrote:
Sorry, I should probably have been more clear on the reason I need it :).
The main issue from the ansible perspective is to know if we are _going_
to change something or not. The user may for example run ansible in
On Thu, Oct 09, 2014 at 11:51:50PM +0200, Patrik Lundin wrote:
To solve this I need the default flags to compare to the output of
'status'.
... I guess another solution could be if 'status' only showed flags that
differed from the default.
Regards,
Patrik Lundin
16 matches
Mail list logo
