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 <[email protected]> Gerrit-Reviewer: Alon Bar-Lev <[email protected]> Gerrit-Reviewer: Barak Azulay <[email protected]> Gerrit-Reviewer: Dan Kenigsberg <[email protected]> Gerrit-Reviewer: Douglas Schilling Landgraf <[email protected]> Gerrit-Reviewer: Federico Simoncelli <[email protected]> _______________________________________________ vdsm-patches mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/vdsm-patches
