Ansible work and organization

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rUake15nkmeqAJaPQq15DNkrU3qSBauM5 Content-Type: multipart/mixed; boundary="Bc659WIoxXX4Lhv6F7nK4c8PBqsasJf6j" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck@redhat.com> To: oVirt Infra <infra@ovirt.org> Cc: Michael Scherer <misc@redhat.com>, Karsten Wade <kwade@redhat.com> Message-ID: <81a28335-daf0-6bec-f7ae-92490f605606@redhat.com> Subject: Ansible work and organization --Bc659WIoxXX4Lhv6F7nK4c8PBqsasJf6j Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. 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. 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=C2=B8 but we alr= eady have one which is used by the MM3 work. 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. 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 coordinati= on. 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. - 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. - how some resources (Ansible roles=E2=80=A6) 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=C2=B8 but this is open to discussion (as stated on my previous mess= ages) As we say here: yoroshiku onegai shimasu. \_o< --Bc659WIoxXX4Lhv6F7nK4c8PBqsasJf6j-- --rUake15nkmeqAJaPQq15DNkrU3qSBauM5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXw8HRAAoJEFXp+fesHEQ/C5QP/27m98NAIpmdAi/tuJOruiOb y96pBd8KajR2ZUDtEqumZsNZaloVNHVBTDjPC4Cz6QHdiq4ECWUoe5L67fuscVow CNH8GNa6XwJyDnbas+57S0WSXHTkuZe3Tbib43kiYvI/VRrgJ9V9GdMe3KOwC2Pj 1LXnpCl3zSt3ktw99ErCj2c5nxzAl0AElPWzh0Ph6Mi7UfbhAAL05MpY3vK8Kwcq I/IKDytMLSJi8aeUqGGRZ7kj0G5Kvn2pvZ3ogA8dOgPopNMW4BysEuOoYcjzQZfB 8LujlKU8pVjb87gnQpJZcDiRPXkZVOwTplTvBhgr+RIaRTZ++NbDOvrM0kDIpnjp QEkD7x0Z8HkJ0vzX1j/sduiGPJ3xDK28mH/AtlmU4JIl2otYOgMoFPpgL+J3W+6C REcH9AFyEg0sCdaoGfKgOCXTQAYxNOgtiNw98QROE/LiVSkNv8ZUiupr0fM0Izfw HkCF+o5dES80Xl914gjSKXYnvv5EF1u76gMzBKvL/PcmCB4BbR6oo1ErOx1ZS3xX /+pJDSUIWiUxW6DBKNIGGfMNvEQYL8nI5mMBjXA8W7jA/3JWe+Gwnmd6/rkGNcA6 Bfq96ECwRrEcKhksYEam+FHeaVwdD8IcEfE3NF/liYi4Y3VGDHeUHmKFCYvoGWU8 bUveh9mS1l848tksFYWu =35u9 -----END PGP SIGNATURE----- --rUake15nkmeqAJaPQq15DNkrU3qSBauM5--

On 29 August 2016 at 08:02, Marc Dequènes (Duck) <duck@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@redhat.com RHEV-CI Team
participants (2)
-
Barak Korren
-
Marc Dequènes (Duck)