Hi, Thanks for your feedbacks here is a summary of what has been done, and what remains to be done:
In SF, patches to manage replication.config in the config repository - http://softwarefactory-project.io/r/#/c/3689/ (Make sure the config auto generated change is merged before tests) - Work and Need review - http://softwarefactory-project.io/r/#/c/3540/22 (Manage Gerrit replication.config in the configuration repo) - Work and Need review In managesf and sfmanager: - http://softwarefactory-project.io/r/#/c/3541/ (Remove replication and sshconfig REST endpoint) - Need more work - http://softwarefactory-project.io/r/#/c/3618/ (Remove commands related to replication and sshconfig config) - Need more work Once the patches above will be merged, the config repository will contains an additional file gerrit/replication.config. config-check will do a basic syntax validation and config-update simply copy the file to /home/gerrit/site_path/etc/replication.config. The upgrade process is supposed to copy the replication.config file from the FS if the config repo does not have a gerrit/replication.config file. Next steps is to well document it according to our discussion (especially for the Github part). To summarize the normal (expected) workflow for the replication process will be : SF will authenticate with the Gerrit key on the remotes defined in the replication.config. And only a modification to replication.config in the config repository is sufficient to configure the replication of a project (expect the first time when the destination host key needs to be added to the known_hosts and the target repo exists for github replication). Note that the default replication.config http://softwarefactory-project.io/r/#/c/3540/23/config/config-repo/gerrit/replication.config has the statement autoReload to true. Also most of the configurable options of the replication plugin will be exposed to the SF users. There is a bunch of available options actually (http://softwarefactory-project.io/r/plugins/replication/Documentation/config.html). The non standard one and the not recommended but still usable is when something specific needs to be configured via .ssh/config like the use of an alternate private key to authenticate (like for using the deploy keys feature of Github). For this one we should add a tool that: - take: the hostname alias, the real hostname, the private key path as arguments - copy the key at the right place / set perms - Place/ or replace the following statement in .ssh/config Host "Alias" Hostname realhostname PreferredAuthentications publickey IdentityFile /home/gerrit/.ssh/keyname - The tool warns for a Gerrit restart (but let the admin do that manually) - Nothing more / nothing less I'm wondering also if a tool to ease known_host management should be written (useful in both scenarios) like read replication.config and (.ssh/config) find destinations, fetch host key of destination, then add missing ones to known_hosts. And finally warn for a Gerrit restart if new host keys has been added to known_hosts. Christian, I was more in favor with python scripts in /usr/local/bin instead of Ansible playbooks. And also I'm not sure those scripts are really needed ATM if we manage to change replication strategy from the "deploy key" to Specific user with the Gerrit key once this replication refactoring lands. And just a side note I saw that the replication plugin can be configured with a remote.NAME.adminUrl that may be used to call a specific URL to create missing repository ... we should investigate if storing a script on SF (that read a Github API key from sfcreds.yaml) and create the repo on Github by itself should be feasible :) Let me know if that plan sounds good for you ? Cheers, Fabien _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
