Ansible work and organization

[Barak Korren]

On 29 August 2016 at 08:02, Marc Dequènes (Duck) <duck at redhat.com> wrote:
> Hello folks,
>
> Since I started working on MM3 migration using Ansible, I received
> absolutely no feedback on the Ansible side of my work (and I asked
> several time, specifically on this aspect). At first I was new in the
> project, this was an attempt, I did not have much access, so it was
> created as an external git repository. Now very quickly an
> 'infra-ansible' repo was created and is already filling with review
> requests, but it seems to me we missed a few steps to coordinate.

You shouldn't take review requests to be finished work, they are just
that, requests for review, they in no way represent any final
decisions. They are meant to create exactly the kind of discussion you
want to make, but with working code to talk about.

Since I'm new to Ansible, I needed to produce some working code to be
able to provide any meaningful comments on the code you already wrote.

> I'm not very familiar with the Gerrit workflow, but I'm learning, that's
> why I asked how I could integrate my work into the new repo but got no
> reply. It seemed to me my work could be a proper startup point, but now
> I'm faced with splitting and reintegrating my work with what is already
> coming in. It feels really useless a work, frustrating, and I also see
> no reason to loose all the history.

The way to integrate your work is to submit it as a series of patches
to the new repo, you can either base them on the patches I already
wrote or just on top of the initial empty commit. As we discuss and
merge patches, we will go through the process of coming up with an
agreed upon structure and process.

(As an unrelated note, I find the 'git-review' plugin to be a very
useful tool for managing series of dependant patches)

> Also I talked (ML, JIRA) about the roles we (in OSAS) were working on in
> order to share the load of the maintenance across several projects. Our
> experience is we often need almost the same classic features, so no
> reason to recreate the wheel and maintain different versions. We cannot
> trust any role on the Internet, but we can trust people in Red Hat or
> well known contributors. Nobody seemed to have an objection on this;
> nobody adked any question either. Nevertheless now the incoming reviews
> shows all of this is ignored and we're doing exactly it: a new
> postgresql role just popped-up in one review for example¸ but we already
> have one which is used by the MM3 work.

It seems that the requirements.yaml file and the ansible-galaxy
command provide for adequate means to integrate 3rd party roles such
as ones written by OSAS as long as they are hosted on some public Git
repe or (preferably) Ansible Galaxy.

When writing the patches I submitted, I did my best to use roles that
seemed both popular on Ansible Galaxy and well maintained on GitHub, I
was not aware of the existing work by OSAS, I must have missed some of
your comments.

The postgres role in particular, was written only because I could find
no suitable and well functioning candidate in Ansible Galaxy (Most
roles there seem to be targeted at Ubuntu/Debian anyway). It is very
minimal and sketchy, I will gladly replace it.

The purpose of the review process, and the point of adding you as a
reviewer was exactly to let you comment and point towards such
resources.

> I really tried to not be pushy, to ask for your opinions and reviews,
> but not much happened. I thought people were busy and it would come in
> time. Now I really don't know how I can catch up.

Don't worry, as I said before, these are only WIP requests for review.
Indented exactly to create the kind of discussion you seem to want to
make.

Please submit your code as well so we can continue the discussion in Gerrit.

> So, we need to discuss:
>   - how OSAS is going to work with the infra team:
>     I'm new, so it's ok to feel a bit off, but I'd like better coordination.
>     I should not have to do extra work for integrating what I did on
> MM3, so clearly it's a failure I would like to avoid in the future.

It seems to me the best methodology would be for OSAS to maintain
upstream roles that are then consumed via ansible-galaxy and
requirements.yaml in the oVirt-specific infra-ansible repo.

Like I said, I'm new to Ansible, so I'm open to other suggestions.

>   - how the config management will be organized/managed:
>     there's many ways to organize, to call the roles, to test the rules.
>     I've based my work on Misc's good work and added a few things myself.
>     I've also started working on testing using Vagrant: it works but has
> limitations. There's other attempts on the Internet but they also have
> drawbacks, maybe others we did not find yet. So there's room for
> discussion too, and integration with your CI. The current setup is in my
> repo.

I tried to follow guidelines here:
http://docs.ansible.com/ansible/playbooks_best_practices.html

Other suggestions are welcome.

WRT Vagrant - I know this is a popular tool to use for Ansible role
testing, but I'd prefer that if and when we add a CI flow to our
Ansible repo, it would be based on our existing CI standards and Lago.

So far I did spend any effort in this direction though, because I had
the luxury of an unused "production" VM to play with...

>   - how some resources (Ansible roles…) are to be shared or not:
>     the OSAS team is very small, shares its time and energy among
> several projects, you have several people with a good Puppet background
> but less so on Ansible, so I would advise sharing workload. The OSAS
> team can act as a neutral third party and insure all needed features are
> taken into account, reviews are done in a timely manner, for example. It
> was just a logical move from us to allow us spending less time on these
> tasks¸ but this is open to discussion (as stated on my previous messages)

I think I already answered this above, if OSAS would provide usable
stand-alone roles, we will be happy to consume them and contribute as
needed. We've used this kind of process with Puppet modules in the
past, and I'm also trying to follow it with the 3rd-party modules I
already use.

> As we say here: yoroshiku onegai shimasu.

(Trying to practice my very broken Japanese :)

Shinpaishinaide kudasai.
Watashi o yurushitekudasai


-- 
Barak Korren
bkorren at redhat.com
RHEV-CI Team