On Tue, Nov 24, 2015 at 4:42 AM, Michael Scherer <[email protected]> wrote: > Le lundi 23 novembre 2015 à 16:39 +0530, Kaushal M a écrit : >> Hi all >> >> Now that we have public access to the gluster-infra salt states [1], (thank >> you Misc) I'd like to start contributing to it. I'd like to begin by >> refactoring the `jenkins.slave`[2] state. >> >> My aim with the refactoring is to pull out the general test environment >> configuration, from the gluster infra specific configuration. The reason to >> do this is mainly two fold, >> 1. To make it easier for developers to contribute changes to the GlusterFS >> testing environment. >> 2. To make it easier to deploy local testing environments. > > local testing, like vagrant based for example ?
Yes. It doesn't matter if it's vagrant or standalone VMs, or even possibly the developers system. It should be possible to easily prepare a system to successfully run these tests. > >> I need some questions on which I'd like feedback. >> 1. How do I contribute changes back? As I understand the github repos of >> the salt-states and salt-pillar are just mirrors. > > For now, I think patch by mail would be ok, that's the stuff that > requires the less setup. > > Ideally, I would maybe start to use gerrit, since that's what is used by > the rest of the project, but I do not have strong opinion on what to do > for review. > > Where I am a bit less happy is what happen after the review. IE, should > we pull from github and trigger a run, or use cron, or write a webhook > somewhere, etc, etc. > Okay. I'll send this a mail once I've got something useful. > >> 2. I'd like to have this test environment state separate from gluster.org >> infra states, ie., outside the current salt-states tree, in a separate >> repo, or within the glusterfs repo. This would help developers contribute >> to it, without hurting the infra states. Would this be okay? If yes, which >> repo should this be put into. > > So, I am not against splitting stuff more on salt, the only reason I > didn't is because I am not sure how it work in practice (salt docs are a > bit messy, and so I need to look a bit more on examples to grasp the > details). > > But rather than splitting, what about cleaning our environment (like, > getting ride of /d/ directory and various symlink around) to have almost > nothing gluster-infra specific ? These are things I'd like to do as a part of this refactoring effort. But to clean and improve, I first need to do this split. > > Another issue I see, we have salt config to disable ipv6 > ( > https://github.com/gluster/gluster.org_salt_states/blob/master/jenkins/disable_ipv6.sls > ) and the 2nd admin card from rackspace VM ( . > > Where would this kind of tweaks go for the goal of letting people run > test locally ? > > On one hand, they are gluster infra specific (an not even distro > agnostic yet), so should be out. > > On the other hand, if ipv6 make tests fail, then it should be disabled > if we want people to use the test suite. > > Of course, the best solution is to make ipv6 working with gluster :) We are planning to have IPv6 ready for GlusterFS-3.8. So maybe we can get rid of this customization. > The same go for the 2nd card, but I also think that's not easy or it > would have been done. > > -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > > _______________________________________________ > Gluster-infra mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-infra _______________________________________________ Gluster-infra mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-infra
