[Bug 1672650] Comment bridged from LTC Bugzilla

[bugproxy]

------- Comment From Peter.Oberparleiter at de.ibm.com 2017-03-27 04:19 EDT-------
(In reply to comment #8)
> I do not see bridge_role file available until after the three devices in a
> group are online.
> As in the file is not in sysfs when the qeth devices are offline (and have
> not yet been ever onlined yet aka absolutely fresh boot)
>
> Why should I be specifying the layer2 attribute, if it is the default? That
> violates the DRY principle.
>
> Or specifically, shouldn't specifying bridge_role=primary; trigger
> generation of the layer2=1 attribute in the generated udev rules file?!

The qeth device driver registers the layer2-specific attributes either
when the layer2 attribute is set, or when the device is set online and
the driver determines that layer2=1 is the correct setting. This
explains the original error reported in this bug report: the udev rule
tried to write to the bridge_role attribute even though it did not yet
exist, resulting in a "permission denied" error (because the directory
is not writable).

This is the result of a somewhat incomplete design assumption - for z/VM
guests, chzdev determines the layer2 setting based on Hypervisor
information, so the sorting implemented by chzdev (bridge_role after
layer2) works. It does not work however, when the value of the
layer2-setting is left to the device driver, as in the LPAR case.

We cannot simply change the ordering of all layer2-specific attributes
to "after online", because some of these (e.g. sniffer, hsuid) can only
be set after layer2 was set and before online is set.

I think the idea you proposes in your latest comment sounds like a good approach: if a user specifies a layer2-specific attribute, and layer2 is not set, that is:
- not auto-detected by chzdev as under z/VM
- not set persistently by a previous invocation
- not set by this invocation,
then chzdev could generate layer=1 implicitly, and issue an informational message to indicate the same.

Additionally, if a layer2-specific attribute is set and the
layer2-attribute is set to 0 (set persistently before, or specified
during this invocation), chzdev should abort with an error.

We'll evaluate how this is best implemented in chzdev. In the mean-time,
specifying layer=1 can be used as a work-around in such cases.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to s390-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1672650

Title:
  chzdev ccwgroup qeth properties incorrect ordering with respect to
  online

Status in Ubuntu on IBM z Systems:
  New
Status in s390-tools package in Ubuntu:
  Incomplete
Status in s390-tools source package in Xenial:
  New
Status in s390-tools source package in Yakkety:
  New

Bug description:
  For Canonical Openstack we are currently preseeding LPARs with
  bridge_role=primary setting.

  This is achieved by setting the property with chzdeve e.g.:

  $ chzdev --no-root-update -pVe c003 bridge_role=primary

  On boot this sometimes results in generated udev rules failing to apply the bridge_role property:
  systemd-udevd[2634]: error opening ATTR{/sys/devices/qeth/0.0.c003/bridge_role} for writing: Permission denied

  The reason being, is that bridge_role attribute is attempted to
  written, before it exists, as the devices have not been onlined yet
  into a ccwgroup.

  Updating zdev/src/qeth.c to use ordering after online and check for online only appears to resolve above race condition, for the property in question
  	.order_cmp = ccw_online_only_order_cmp,
  	.check = ccw_online_only_check,

  However looking at that file, it would appear to me that most qeth
  properties should be ordered after online, as during boot they do not
  exist until after the qeth is onlined.

  Please reverse proxy this bug report to IBM s390-tools engineering.

  Regards,

  Dimitri.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1672650/+subscriptions