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

[Kaushal M]

On Tue, Nov 24, 2015 at 4:42 AM, Michael Scherer <mscherer at redhat.com> 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
> Gluster-infra at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-infra