Federico Simoncelli has posted comments on this change.
Change subject: setup: move the certificate generation
......................................................................
Patch Set 2:
vdsm components: vdsm-reg, bootstrap, vdsm init.d have special
treatment for ovirt-node.
Correct, and only few special cases require to persist files (which anyway must be
addressed in a transparent way providing hooks).
An example from vdsm init.d:
ovirt_store_config "$lconf" "$qconf" "$ldconf"
"$llogr"
That is just an example of how doing it in the init file is wrong. First of all
there's no need to do this at runtime because in this case the files are the same on
all the ovirt nodes (in a perfect world the ovirt-node should be able to do this at
iso-generation time). As exception we recently introduced a workaround for a libvirt issue
temporarily adding the generation of an host_uuid (now saved to $lconf) which in the
future will be generated by libvirt bz864564 (WRT to ovirt-node is just a file to persist
that now happens to be $lconf, in the future not anymore).
Second, as you see the init file is not standard as it should and a vast majority of it is
already planned to be moved to external tools (where ovirt-node could hook additional
logic for persisting, but only if strictly required).
Why do you think the certificates and keys are so special to have
them persist in different place?
They aren't special, they just try to not repeat the errors of the past. The question
is why is vdsm so special to you that can't be treated as other services as for
example openssh.
It is obvious that when a code needs to be run on ovirt-node you
handle the implications without another bug opened for this task.
The "component" field in bugzilla should reflect the real component (I can't
commit a patch to the ovirt-node with a vdsm bz).
As a final note you should remember that:
1. persisting the key/ca/certificate is *not* mandatory because if you want to use the
host locally you are allowed to do so (even without persisting). If you personally as
sysadmin want to commit to a key/ca then persist it.
2. if you really want to persist key/ca/certificate (but as I said in 1 is not required)
you can do it in the ovirt-node as you already do it for all the other standard services
3. as you may know ovirt-node is going to support other applications (as for example
gluster), are you going to argue with all project to add a persist call when they make a
change to their files?
This is my take on the problem and the patch that solves bz860067 (vdsm should generate
keys and certificate when init.d script is started and not when installed), there's no
reason to spend more time on this.
--
To view, visit
http://gerrit.ovirt.org/8368
To unsubscribe, visit
http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I40fa3d9a6a54e312e399af3f87ac67e843078360
Gerrit-PatchSet: 2
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Federico Simoncelli <fsimonce(a)redhat.com>
Gerrit-Reviewer: Alon Bar-Lev <alonbl(a)redhat.com>
Gerrit-Reviewer: Barak Azulay <bazulay(a)redhat.com>
Gerrit-Reviewer: Dan Kenigsberg <danken(a)redhat.com>
Gerrit-Reviewer: Douglas Schilling Landgraf <dougsland(a)redhat.com>
Gerrit-Reviewer: Federico Simoncelli <fsimonce(a)redhat.com>