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 <fsimonce(a)redhat.com>
Gerrit-Reviewer: Alon Bar-Lev <alonbl(a)redhat.com>
Gerrit-Reviewer: Ayal Baron <abaron(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>