Role interface design questions

Archives Ansible Developer
1

Hello,

we would like to make some improvements of the roles contained in the
linux-syste-roles project (https://github.com/linux-system-roles) and
we would like feedback on the design / user interface choices.
The issues we are not sure about are:

- state attribute. The network role
  (https://github.com/linux-system-roles/network), which manages network
  connections e.g. of NetworkManager, uses a state attribute for every
  connection. We found that the current four states (present, absent, up,
  down) partially overlap and are quite ill-defined. We want to split them
  into two state variables, one for the presence of the profile
  configuration, the other for the runtime state. They would be called

  persistent_state: present/absent
  state: up/down

  This would satisfy our needs but we are thinking that having two state
  attributes of an object might be quite unexpected. Is there some prior
  art for this or a better way to handle it?

- Respecting previous configuration. The selinux role
  (https://github.com/linux-system-roles/selinux/), if selinux_mode is
  not given, would leave the selinux mode at the previous value. This is
  the safe option (changing selinux mode has te potential of braking a
  machine or make it insecure), but makes the result dependent on the
  previous configuration. Does it make sense? Also, we have been
  discussing whether local modifications to the selinux booleans, file
  contexts etc. should be dropped before the role sets the desired value.
  The reasoning for not dropping them is that then the role can not be
  used twice to configure different (non-overlapping) selinux values,
  because the second run would clobber the first. Also, clobbering the
  previous state could be quite unexpected and potentially dangerous. But
  not doing it has the possible disadvantage of not defining the state
  completely.

  Relevant discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1597545

Advice from more experienced role developers would be welcome.

Best regards, Pavel

2

+ansible-project list for more eyes

3

“up” and “down” presume “present” state. “absent” state doesn’t have this options. It’s quite like a state of a package (like “latest” state presumes “present” state) or a cloud machine (“running” presumes “present” state, also “stopped” state).

4

It is not exactly the case in our situation and that's why we want to
split it into two attributes because it is confusing. "up" and
"down" do not presume "present" because "up" and "down" are the runtime
states of a connection, while "present" and "absent" determine the
presence of the saved (on disk) profile
(/etc/sysconfig/network-scripts/ifcfg* file or a NetworkManager
equivalent). And it is completely valid to have a connection which is
"up" and its saved state is removed, i.e. "absent". So they are really
orthogonal and all combinations are valid.

P.

5

Hello,

we would like to make some improvements of the roles contained in the
linux-syste-roles project (https://github.com/linux-system-roles) and
we would like feedback on the design / user interface choices.

Greetings. I've just been looking at your network role to replace the
cobbled together ansible networking handling we use in Fedora
Infrastructure, so I have some thoughts below...

The issues we are not sure about are:

- state attribute. The network role
  (https://github.com/linux-system-roles/network), which manages network
  connections e.g. of NetworkManager, uses a state attribute for every
  connection. We found that the current four states (present, absent, up,
  down) partially overlap and are quite ill-defined. We want to split them
  into two state variables, one for the presence of the profile
  configuration, the other for the runtime state. They would be called

  persistent_state: present/absent
  state: up/down

  This would satisfy our needs but we are thinking that having two state
  attributes of an object might be quite unexpected. Is there some prior
  art for this or a better way to handle it?

I can see splitting them up, that definitely makes sense.

Most roles don't have such a complex state to keep track of, at most I
see things applying changes and then restarting/persisting them at the
end by running the handler(s). In this case the odd state out seems to
me to be the 'runtime' one. I can see uses for it, but I bet it's a lot
less common than persistent. Perhaps it would make sense to make
persistent a bool (defaulting to true) and then if someone wanted to
manipulate a runtime only config they could set 'persistent: false' or
the like.

I'll probibly have more thoughts after I play with the roles some, this
is just a quick glance. :slight_smile:

- Respecting previous configuration. The selinux role
  (https://github.com/linux-system-roles/selinux/), if selinux_mode is
  not given, would leave the selinux mode at the previous value. This is
  the safe option (changing selinux mode has te potential of braking a
  machine or make it insecure), but makes the result dependent on the
  previous configuration. Does it make sense?

I'd find it more expected to error out if you don't set a value here.
If you went to the trouble of including this role you must have a
desired state, so I would just not default it at all.

Also, we have been

  discussing whether local modifications to the selinux booleans, file
  contexts etc. should be dropped before the role sets the desired value.
  The reasoning for not dropping them is that then the role can not be
  used twice to configure different (non-overlapping) selinux values,
  because the second run would clobber the first. Also, clobbering the
  previous state could be quite unexpected and potentially dangerous. But
  not doing it has the possible disadvantage of not defining the state
  completely.

  Relevant discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1597545

Yeah, I would definitely not expect it to clear the configuration unless
I specifically called for it to do so (perhaps this could be an option
defaulting to leaving things alone). If you call something twice and
overwrite changes from the first run thats a mistake in your playbooks
that you should correct (and should be visible by running a --check
--diff run).

Advice from more experienced role developers would be welcome.

Best regards, Pavel

kevin