
On Sat, 1 Sep 2018 at 02:53, Brett Cannon <brett@python.org> wrote:
On Fri, 31 Aug 2018 at 09:36 Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
I also wonder though, instead of hosting it ourselves, can't we just keep daily backups of the signed CLA? It's basically a list of GitHub usernames?
Perhaps that would be an easier task than hosting and maintaining it.
I think the key question is what sort of resiliency would we have in making this potential change? If we can backup the data regularly so that if we have to quickly turn around and either stand up our own instance of cla-assistant or tweak our CLA bot then I would assume this would take care of the biggest concerns people have. Basically we need to have a plan in place if the hosted cla-assistant disappeared today without notice.
Given the infrastructure that the PSF has already set up to handle the modern incarnation of PyPI, I suspect adding our own instance of cla-assistant to that (and hence being able to easily integrate it with the PSF's existing monitoring and management tools, like DataDog) will actually be easier than devising and managing a custom cla-assistant-specific disaster recovery plan. 'tis the beauty and wonder of combining traditional three-tier open source web applications with an automated app management platform like Kubernetes :) Cheers, Nick. P.S. See https://p.datadoghq.com/sb/7dc8b3250-85dcf667bd for the current PyPI/PSF metrics dashboard. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia