On 12/02/16 15:09, Michael Scherer wrote: >> - Michael Schearer > > That's Scherer, not Schearer.
sorry :( > Since we did use the existing history to verify commits for the previous > server compromise, I would stress the importance of keeping the history > here, for security measures. That's kinda not negotiable. What would be the way to verify this is possible in a migration ? >> CentOS infra is deployed, in production now. We can start bringing jobs >> over right away, to suite your requirements / release timelines. > > So we could start right away with a new builder. > > Could you provision a centos 7 slave, using our slat setup as basis, to > see how it go ? > https://github.com/gluster/gluster.org_salt_states/tree/master/jenkins I would prefer to see a wider conversation and a project to project engagement to see how best the overall services would run before we start knocking into the tasks. I know a couple of people have had a look at the ci.c.o setup etc, so there should be some level of expectation there already. > For now, centos 7 is what is missing, and as I am busy with the > migration to RH DC, I will not be able to give much help directly for > now. By and large, the aim is to try and remove pain points from the gluster side - that was fairly strongly communicated as running and keeping these services up. If thats not the intention, or if the scope has changed since the conversation last week, happy to rescope. ofcourse, none of this has any impact on the build, test, release, lifecycle process for Gluster as a part of the StorageSIG in CentOS. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ Gluster-infra mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-infra
