Ayal Baron has posted comments on this change. Change subject: setup: move the certificate generation ......................................................................
Patch Set 2: Patch Set 2: >> 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. > We are not asking sysadmin to persist anything, we are doing this for > sysadmin in call use cases. I would not like to introduce new sysadmin > requirement only because we moved the place we generate keys. > Why do you ignore the remote usecase? >> 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 > standard services are what ovirt-node manages, vdsm is not standard service. > vdsm should take care of his own persistence as done so far. >> 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? > yes I do. seriously? there are over 100 packages that ovirt-node pulls. Do you really think that the maintainer of each and every one of these (and any other ovirt-node chooses to pull in) should be aware of the quirks ovirt-node has and make sure to 'persist' correctly? do you really think the package owners would even care? Imo ovirt-node as a distribution should take care of it's eccentricities and not impose these on the different packages (as it's doomed to fail anyway and I also think is wrong). The plugins into ovirt-node will also not be handled by the package owners. e.g. if someone chooses to add a nagios agent, the persist will be handled not by the agent, but by an external 'installation' script that customizes the use of the agent to the ovirt-node use case. This would be written e.g. by a user interested in having this plugin. So by design you're imposing on the users the knowledge that ovirt-node is different and requires extra handling when configuring. How is this different for vdsm? We could however provide a script that takes care of these things separately for interested parties, just to make things simpler or simply document what needs to be done (seeing as it's simply running 'persist' in a loop on a set of files and there may be users who would want part of the files persisted and other parts not (e.g. in this case, generating the keys externally and importing, but the rest persisting according to the recommendations) -- 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: 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: Federico Simoncelli <[email protected]> _______________________________________________ vdsm-patches mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/vdsm-patches
