Le mercredi 09 mars 2016 à 12:44 +0530, Kaushal M a écrit : > This happened because of the changes we did with ssh-keys used for > replication. I'd forgotten that this had been done, and was expecting > pushes to happen automatically. > > Earlier, a single users key was used (key of one of the admins of the > gluster organization, Avati initially) to push changes from gerrit to > github. > This enabled all repositories in gerrit to be automatically be pushed > into to its replica in github (<project-name> in gerrit would be > automatically pushed to github/<project-name>). > This key got changed/deleted which caused replication to fail a while back. > > To avoid tying pushes to a single user like this, a separate key was > setup for each github repo, and gerrit was setup to use the respective > keys to push to each repo. > This requires manual replication configuration. This change was > implemented only for the glusterfs and glusterfs-specs repos. > All other repos require manual configuration.
Yep. I did sent the process on the list, but didn't automate as i was not expecting more repo to be added. > We'll try to comeup with a better way to do this replication. If we > can't, we'll need to manually set up the keys and encryption for each > repo. Yeah, so the ideal situation is that we have some automation. However, doing that for gluster seems a bit more complicated (there is API, but then you have to deal with oauth, did I already said how much SaaS service make our life harder today ? ). We did discuss on irc about it, and so there is basically 2 solutions: - go back to a gluster bot account, but that requires a way to secure the password properly (especially since no one will be checking the audit log for it). We could use 2FA for that account using a remote command line script on a secure server, but we still need a way to store the password in a secure way. And of course, like all password management, it requires that we decide who has access, etc, etc. - make something that automate part of it, and let the part about adding credentials to github to a admin. That's the part I plan to do later, since that could be just some ansible playbook - make something more like self service. Have people declare "I want to sync that repo to that repo I am admin of", and have it done automatically on their behalf. It would requires a lot more coding around github api, but would be the cleanest. Another issue that arise with the current scheme is that push are made under my name as I am the one that added the keys. That was somewhat unexpected, and I do not see a easy way out of it. (unfortunately, it doesn't appear in my stats, so I can't have a endless commit streak..) I am not sure if that's a problem in practice or not, since that's not impacting the git repo, just the activity stream. (again, we can't fix it to be correct, because we are depending on a proprietary SaaS offering, but I already complained about it today) Oh, and I did add the replication for the 2 repos for now. -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gluster-infra mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-infra
