Alon Bar-Lev has posted comments on this change.

Change subject: storage: set block schedule elevator using udev
......................................................................


Patch Set 1:

Hi,

If someone wanted to override the setting for specific disk, he would have 
written udev rule and not change kernel command-line.

And even if this was the case, we can name our rule to be loaded as earliest to 
allow existing rule override.

If someone changed the kernel command-line manually he violated our support 
profile, as we assume deadline, and assume vdsm is a SLAVE hypervisor 
bootstrapped using supported method.

But if that is *REALLY* what bothering you (someone manually set the kernel 
command-line with unsupported setting), then I can read the /proc/cmdline in 
the udev script and simply do nothing if a setting in the kernel command-line 
exists. Maybe we should also support people who compile their own rhel kernel 
with different default?

BTW: Current bootstrap implementation will override this manual setting anyway 
during bootstrap, so we do not support manual changes. But let's ignore reality 
for now.

I think it is a mistake to go in this route, as we were the one who messed with 
kernel command-line in the first place. This was invalid decision that was 
taken at that time. Had we done this today we would have used udev to achieve 
the same. Because we had done this in kernel command-line we forced the user to 
[maybe] customize it at same place instead of flexible udev rule. Leaving this 
in kernel command-line because of previous poor decision is not a great 
argument if we want to clean up this bootstrap corner.

We can have a text within release notes to alert these advanced users to move 
their customization to udev, so the 3 (max) people who are effected will know 
what to do.

As I wrote previously, the question is which component is the owner of setting 
the iosched, vdsm or bootstrap. If this is rejected from vdsm and go into 
bootstrap domain, it will be implemented as udev rule too, I believe this 
belongs to vdsm.

Alon

--
To view, visit http://gerrit.ovirt.org/8700
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0a8de1c861bf4570509599b6f47235ed38cc424d
Gerrit-PatchSet: 1
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Alon Bar-Lev <[email protected]>
Gerrit-Reviewer: Adam Litke <[email protected]>
Gerrit-Reviewer: Alon Bar-Lev <[email protected]>
Gerrit-Reviewer: Ayal Baron <[email protected]>
Gerrit-Reviewer: Barak Azulay <[email protected]>
Gerrit-Reviewer: Dan Kenigsberg <[email protected]>
Gerrit-Reviewer: Douglas Schilling Landgraf <[email protected]>
Gerrit-Reviewer: Eduardo <[email protected]>
Gerrit-Reviewer: Fabian Deutsch <[email protected]>
Gerrit-Reviewer: Federico Simoncelli <[email protected]>
Gerrit-Reviewer: Itamar Heim <[email protected]>
Gerrit-Reviewer: Mark Wu <[email protected]>
Gerrit-Reviewer: Saggi Mizrahi <[email protected]>
_______________________________________________
vdsm-patches mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/vdsm-patches

Reply via email to