# Role interface design questions **URL:** \ **Category:** Ansible Developer\ **Created:** [July 19, 2018, 6:30pm UTC](https://forum.ansible.com/t/role-interface-design-questions/28099 "2018-07-19T18:30:20Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Pavel\_Cahyna](https://avatars.discourse-cdn.com/v4/letter/p/f1d935/32.png) [@Pavel\_Cahyna](https://forum.ansible.com/u/Pavel_Cahyna)\ **Post date:** [July 19, 2018, 6:30pm UTC](https://forum.ansible.com/t/role-interface-design-questions/28099/1 "2018-07-19T18:30:20Z")
Hello, we would like to make some improvements of the roles contained in the linux-syste-roles project ([https://github.com/linux-system-roles](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](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/](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](https://bugzilla.redhat.com/show_bug.cgi?id=1597545) Advice from more experienced role developers would be welcome. Best regards, Pavel ---
**Author:** ![Terry\_Bowling](https://avatars.discourse-cdn.com/v4/letter/t/48db29/32.png) [@Terry\_Bowling](https://forum.ansible.com/u/Terry_Bowling)\ **Post date:** [July 19, 2018, 7:22pm UTC](https://forum.ansible.com/t/role-interface-design-questions/28099/2 "2018-07-19T19:22:20Z")
+ansible-project list for more eyes ---
**Author:** ![mhalano](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mhalano/32/1815_2.png) [@mhalano](https://forum.ansible.com/u/mhalano)\ **Post date:** [July 20, 2018, 6:49pm UTC](https://forum.ansible.com/t/role-interface-design-questions/28099/3 "2018-07-20T18:49:36Z")
“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). ---
**Author:** ![Pavel\_Cahyna](https://avatars.discourse-cdn.com/v4/letter/p/f1d935/32.png) [@Pavel\_Cahyna](https://forum.ansible.com/u/Pavel_Cahyna)\ **Post date:** [July 20, 2018, 10:50pm UTC](https://forum.ansible.com/t/role-interface-design-questions/28099/4 "2018-07-20T22:50:38Z")
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. ---
**Author:** ![nirik](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nirik/32/686_2.png) [@nirik](https://forum.ansible.com/u/nirik)\ **Post date:** [July 25, 2018, 11:10pm UTC](https://forum.ansible.com/t/role-interface-design-questions/28099/5 "2018-07-25T23:10:54Z")
> Hello, > > we would like to make some improvements of the roles contained in the > linux-syste-roles project ([https://github.com/linux-system-roles](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](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. 🙂 > - Respecting previous configuration. The selinux role >   ([https://github.com/linux-system-roles/selinux/](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](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