Bug 1508614

Created attachment 1346694 [details]
Playbook used to recreate

In the role, whenever you specify a slave or a VLAN, the master/parent profile must also be present. That is, you cannot just define a profile for a bond-slave, without also specifying a profile for the bond-master (same for VLAN and its parent).


The role allows for convenience to combine 'state=present' and 'state=up' in one. You can shorten:

  - name: "Wired Profile"
    state: "present"
    type: "ethernet"
    ...
  - name: "Wired Profile"
    state: "up"

to:

  - name: "Wired Profile"
    state: "up"
    type: "ethernet"
    ...

but this is really just a shortcut for covenience.


'state=up' and 'state=down' with initscripts are anyway problematic. The role does not know in which state the system is, when it issues `ifup`. And initscripts don't know it either. They just execute a series of commands, which may or may not work (e.g. it may not properly stop a previously running dhclient instance).
Especially with initscripts, the role leaves the burden of getting it right to the user who implements the playbook.

It's not clear to me what to do about this.


the workaround is also the solution: with initscripts, the user must get the order of 'state=up' and 'state=down' right.
Maybe, 'state=up' and 'state=down' doesn't really make sense with initscripts at all, and you would rather call service `service network restart`?
Maybe the role could get a new setting to call `service network restart`. It would safe the user from 
  - service:
      name: network
      state: restarted
      args: eth0



Matt, what do you think?

I have been using the workaround you listed at the end in the demo playbook (although with a completely poorly written task now that I look at it).

> Especially with initscripts, the role leaves the burden of getting it right to > the user who implements the playbook.

To me, this what we need to solve.  If these are meant to act the same across different versions, then the user shouldn't have to worry about understanding the differences.

> Maybe, 'state=up' and 'state=down' doesn't really make sense with initscripts > at all, and you would rather call service `service network restart`?
> Maybe the role could get a new setting to call `service network restart`.

If I'm reading right, you're suggesting to change the 'up' and 'down' behavior for these interfaces and put the service restart with the "right" interface name in the role?  

So if state is 'up' and handler is 'initscripts', the real state is 'present' and we always restart the interface for an 'up' state?  If you think that could work dynamically that seems reasonable.  It also matches the "sysadmin" behavior for initscripts: edit a bunch of files, restart the interface with the service.  

An alternate thought:

Since VLANs, bridges, bonds, and teams (anything than normal eth really) all have needs for similar changes, maybe there's a need to change the way args work in the types?  So, instead of defining members separately, there could be a 'members' var?  I'm thinking of a sequence of mappings if we need complex settings on a member, like:

members:
  - eth0
  - eth1

or a mapping if needed

members:
  - {interface_name: eth0, mac: "aa:bb:cc:dd:ee:ff"}
  - {interface_name: eth1, mac: "a1:b1:c1:d1:e1:f1"}

Nested interfaces (a bond attached to a bridge) could be complicated I think.

Do either of these options seem realistic?

(In reply to Thomas Haller from comment #3)
> In the role, whenever you specify a slave or a VLAN, the master/parent
> profile must also be present. That is, you cannot just define a profile for
> a bond-slave, without also specifying a profile for the bond-master (same
> for VLAN and its parent).
> 
> ...  snip
> 
> 
> 'state=up' and 'state=down' with initscripts are anyway problematic. The
> role does not know in which state the system is, when it issues `ifup`. And
> initscripts don't know it either. They just execute a series of commands,
> which may or may not work (e.g. it may not properly stop a previously
> running dhclient instance).
> Especially with initscripts, the role leaves the burden of getting it right
> to the user who implements the playbook.
> 
> It's not clear to me what to do about this.

Is this not the power of Ansible Facts, to know the state of things and enable idempotency?  We have a wealth of knowledge about the network and interfaces easily accessible via the facts variables available during the role execution.  Here's how you can see what is available to you.

  ansible <HOST> -m setup -a 'gather_subset=network'
  ansible <HOST> -m setup -a 'gather_subset=network filter=ansible_interfaces' 

Considering this, is it possible to have a resolution to this BZ in the near future?  It breaks our RHEL 6 compatibility story for a very common networking configuration scenario.

Mass-moving bugs RHEL <= 7.6.0 to 7.7.0.
As we are past RFE deadline for 7.7.0 and we should have no new features on 7.8.0, please evaluate if it's still wanted on RHEL7 and contact PM for exception. You may also move it to RHEL8 if that's wanted. Thanks!

Matt, if possible, please take a look at the upstream system role pull request: https://github.com/linux-system-roles/network/pull/250 - it should address the problem with creating the playbook that you specified.

Till, I don't have access the environment any more and won't be able to test the scenario I initially reported.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.