[Gluster-infra] [gluster.org_salt_states] Want to refactor jenkins.slave

[Michael Scherer]

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 ?

> 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.


> 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 ?

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 :)
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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.gluster.org/pipermail/gluster-infra/attachments/20151124/948b9d24/attachment.sig>