Move to https://github.com/ansible-collections/community.zabbix/issues

[ericsysmin]

Is your feature request related to a problem? Please describe.
Should we decide to move these roles to the collection within the Ansible project?

Describe the solution you'd like
I'd like to see a consolidated option where we can all a single collection for both modules, and roles to handle Zabbix

Additional context
Add any other context or screenshots about the feature request here.

[dj-wasabi]

Hi @ericsysmin

I'm all for it, but I have no idea yet how to proceed with it.

[D3DeFi]

Hi guys, I was searching for this based on @ericsysmin issue.

First of all, I am still a bit confused myself about the whole collection movement as there haven't been any "official" instructions since this post from March. Ansible 2.10 should use some kind of hook to pull all of the collections (that contain modules previously included with Ansible) when being installed.

Me with @sky-joker have decided to move zabbix modules from community.general to community.zabbix in order to have some possibilities into the future, like CI not too tightly restricted by upstream and so on. Unfortunately, we are not very active lately due to a limited time available for such activity (at least on my side, but I pressume sky-joker has the same problem).

As I see it, we now have mostly a free ruling about the collection, except a few details that should get specified by Ansible (like semantic versioning, releasing on galaxy, etc..). Collections do encourage developers to collect content with the same matter of subject into a single place, so merging your modules with community.zabbix collection would make a sense. This is however accompanied by bundling them all together (single repo for everything).

Have you thought about something like this since we last touched the subject in this PR?

[dj-wasabi]

Hi @ericsysmin & @D3DeFi

I think it is in the best interest for the Zabbix community that is using Ansible, that everything Zabbix related will be available in 1 place. So, if you @D3DeFi and @sky-joker are the collection maintainers and you agree with it as well, then we should move forward and move the roles to the collection. I'm not sure how to proceed with this one? @ericsysmin has created an example repo like this one https://github.com/ericsysmin/ansible-collection-zabbix/tree/master/roles that might work... or we just move everything..

[ericsysmin]

I agree with this here. It would make the most sense, and allow better visibility and allow a single place for everything. @dj-wasabi @D3DeFi If you would like we can do a quick zoom, and build a PR copy all the roles into this repo and go from there? If we really do just move them here, there is no reason to use git submodules like I did in my example.

[gundalow]

Hi,
You can put the roles in community.zabbix
As you say, that will help people find them, and help build up the community and users.

[gundalow]

Friends don't let friends use git submodules.

[D3DeFi]

We had a few interactions previously regarding zabbix modules/roles, so this plan is probably a good idea.

Take these as just an ideas. I see something like this happening:

• each role will be placed to community.zabbix/roles/,
• roles READMEs either go to community.zabbix/docs/ or are linked to from community.zabbix/docs/README.md:

#Roles documentation
* [ansible-zabbix-agent](https://repo/blob/master/roles/zabbix-agent/README.md)
* etc...

• @dj-wasabi will join us as a maintainer for the whole community repo. @ericsysmin, not sure if you are maintaining alongside @dj-wasabi or not, but you are welcome as well if you are interested,
• we can incorporate CODEOWNERS to correctly notify you guys about roles, and notifications about plugins go to us. Something can be included that will label PRs/issues as well (maybe this is possible via github actions?),
• release cycle will be mainly driven by roles, as they are more actively developed as of rn. Plugins will just ride along for now,
• @dj-wasabi, either open a separate PR for each role separately or one big PR for everything. Unfortunately, you will loose commit/PR/issue histories as we did when we moved to a collection,
• changes to plugins will be tested for both plugins and roles. Changes to roles don't need to run integration tests for plugins. Maybe we will be able to instruct Github Actions to do this for us,
• touching integration testing - we are using Github Actions as other collection repos. We would need to analyze/decide if it is a good idea to use both them and Travis or rather a single solution,
• other things I have forgotten..

@ericsysmin, I have no trouble joining zoom call for this, but you can probably expect more questions from me than answers as I am sysadmin rather than developer

[D3DeFi]

@sky-joker what is your take on @dj-wasabi joining us in the community.zabbix collection with his roles?

[sky-joker]

I think this role move to Zabbix collection is a good idea.
As @D3DeFi writes, we need to come up with a migration plan.
If we're going to manage our tasks, I think it's better to use a project.

[sky-joker]

I have done to create a migration project :)

https://github.com/ansible-collections/community.zabbix/projects/3

[sky-joker]

I've created a discussion issue for Zabbix roles migration.

ansible-collections/community.zabbix#16

[ericsysmin]

@sky-joker @D3DeFi @dj-wasabi we need to decide when we want to copy the modules in, and we can each do a PR for each one. The migration is fairly straight forward on moving roles to Collections. @sivel has even written some tools to help. https://gist.github.com/sivel/bca2fe56680c76f0eea647f5477dd46b, it was written for Python 3.8 so ensure you have that version of python.

[gundalow]

In ansible-collections/community.zabbix#17 (comment) @ericsysmin asked:

My only question with this is how to migrate any existing issues from the original repository.

There are two ways manually, or via GitHub issue transfer

Manually

1. Create a new issue
2. cc relevant people
3. Close the old issue with a link to the new one

GitHub Issue transfer

1. move dj-wasabi/ansible-zabbix-agent/ to ansible-collection/ansible-zabbix-agent
2. Move issues from ansible-collection/ansible-zabbix-agent to ansible-collections/community.zabbix (via GitHub functionality)
3. Move ansible-collections/community.zabbix back to dj-wasabi/ansible-zabbix-agent/

Unfortunately doing this will break any links people have to the old issues.

Given there are at most 13 issues to be moved, I think we are OK to move the issues manually.

[sky-joker]

Thank you @ericsysmin for the PR :)

@D3DeFi

Since the master branch will be heavily modified, I think the destination of the Pull Request needs to be a separate development branch instead of the master branch.
I think it's better to merge the roles into the development branch and then merge them into the master.
I also think we need to determine a migration schedule (roadmap) and each role.
I think It's going to take a lot of time to identify the tasks (including those written by @D3DeFi) that are necessary for the roadmap and to review the testing methods.
What do you think?

[D3DeFi]

Lets make it as easy and painless as possible.

Separate branch is a good idea. As we haven't implemented any branching design for the repo yet, I would say we create a (e.g. roles-migration) branch that PRs will be opened against. Everything else will be determined from there. but I can see that it goes like this:

• PR for each role against roles-migration branch
• merge
• move some of the components somewhere (dotfiles, CHANGELOG, README, etc..) still within roles-migration branch
• decide if we are satisfied with how it looks
• merge to master

Lets use project created by @sky-joker to lay down a basic road map, something like an overview. I can open the tasks if you agree with the proposed plan. Details as their arise.

As of when to migrate these amazing roles. I don't see any blocker to start working on it ASAP. We can create roles-migration branch for you right away. We can probably even make it before ansible 2.10 release if it is not planned to release in the begging of May :)

[ericsysmin]

I like the plan, my PR was basically a starting ground to help us see what would be needed, etc.

If you provide that branch I can start making some PR's to it. I've identified one role however we will have to figure out as it does have role dependencies and zabbix_web uses @geerlingguy's apache and database roles which do not have a collection yet.

I am moving a lot of our internal code to use collections and hence why I am trying to help drive this now. Since I am having to move other code to collections to get updated/patched modules, it's only natural.

[geerlingguy]

Regarding my roles; I am currently postponing moving any of them to collections for two reasons:

1. Many (like the mysql role) don't really fit in with more than one other role, so I'd like to maintain the geerlingguy.mysql name for the collection, which is not yet possible (see Allow roles to be converted to (or coexist with) collections ansible/galaxy#2253)
2. I'd like to preserve compatibility with Ansible 2.7 and below for as long as possible, and since collections don't work there I don't want to migrate until 2.7, at least, is unsupported (which will be post-2.10).

Currently roles can't depend on collections, nor is the inverse possible, so in addition to listing any pip/python library requirements that would need to be manually installed, the instructions for using the zabbix role would also need to include a blurb about needing to manually install the geerlingguy.apache and geerlingguy.mysql roles (either via requirements.yml roles key and separate install command or via ansible-galaxy role install [roles]).

One last issue I have with roles-in-collections is that the de facto way you would document a role was to have an overview, examples, and available vars in the README file, which was rendered on Galaxy. With Collections, only the main collection README is rendered, which may be okay for a 1:1 role-to-collection migration (when that becomes possible), but falls apart when you have more than one role in a collection.

In that case, it seems we'll be on the hook for rendering documentation somewhere.

[D3DeFi]

@ericsysmin sorry for the delay, community.zabbix repo now has devel-roles-migration branch ready. PRs can now be opened against it. Once we merge them, we probably need to decide what needs to be changed.

[D3DeFi]

@dj-wasabi does information from @geerlingguy somehow affect the decision regarding migration of your zabbix roles to community.zabbix repo?

[ericsysmin]

@dj-wasabi @D3DeFi We will likely need to do some testing and have a note that users need to run an included galaxy_requirements.yml file or similar that would download the roles since those won't be automatic on collections. I am working on how to migrate Molecule tests over from old role format to collection format, and how the roles should be called. I actually just finished migrating ericsysmin.docker to ericsysmin.docker.docker Collection so that my docker role is supported by Red Hat Automation Hub and Collections design.

[dj-wasabi]

@D3DeFi

I understand both of his concerns and altough the first one doesn't apply to "my" work ("my" in quotes, because a lot of people have contributed to the roles to make something beautifull on which I can and will not take the credits for), I don't think waiting on 2.7 becoming eol is important for the Zabbix roles. I do think 2.7 is the minimum ansible version configured in the various roles, but we are just talking over 5 roles. @geerlingguy has a bit more than 5 and his userbase is also a bit bigger. 😄 So I don't see it as a huge issue.

That is not the case with the 5 Zabbix Roles. So what I can do is:

for repo in zabbix-agent zabbix-server zabbix-proxy zabbix-web zabbix-javagateway;do

- Fix some low hanging fruit issues, to lower the amount of issues to move;
- Move the role via a PR to the community.zabbix repo;
- disable the issues and pr tabs;
- Once done, change the `readme.md` that this role is deprecated in favour of the community.zabbix collection and thus providing the role as a read only reference for the users having older Ansible version and that fixes are only applied to the collection;

That is what I would do: any thoughts, ideas, questions or things that I missed that should be done as well?

[ericsysmin]

@D3DeFi I could help migrate the molecule tests, however, with the new repo how should we configure that? In the past everyone has been using Travis-CI for testing and the .travis.yml file.

[sky-joker]

Since community.zabbix uses GitHub Actions, I think it's better to adapt the way we test to GitHub Actions.
For example, here's an image.

name: CI
on:
- pull_request

jobs:
(snip)
  roles-test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        zabbix_roles:
          - "role name1"
          - "role name2"
          - "role name3"

    steps:
      - name: Check out code
        uses: actions/checkout@v1
        with:
          path: ansible_collections/community/zabbix

      - name: Set up Python 3.6
        uses: actions/setup-python@v1
        with:
          python-version: 3.6

      - name: Install dependencies
        run: pip install zabbix-api molecule

      - name: Install ansible-base
        run: pip install git+https://github.com/ansible-collection-migration/ansible-base.git --disable-pip-version-check

      - name: Run role test
        run: |
          cd roles/${{ zabbix_roles }}
          molecule --version
          ansible --version
          molecule test -s ${{ MOLECULE_SENARIO }}

This is just an idea, so we'll have to see if it works as it is.

[ericsysmin]

How do you test against multiple operating systems? Is there a way to do that since installs do differ from one to another. @sky-joker Using GitHub Actions works for me as well, as long as we can keep all the same tests.

[ericsysmin]

Nevermind, I did find it, you can reference the matrix from outside of the matrix.

[ericsysmin]

@sky-joker thanks for the suggestion, I am changing my own repo now, apparently the matrix feature here is 10x better than that of Travis-CI as I can do a multi axis matrix easier.

[D3DeFi]

@sky-joker thanks for stepping in for me and helping @ericsysmin

@dj-wasabi your plan sounds good.

Btw, we've started to identify steps required for these migrations with @sky-joker in ansible-collections/community.zabbix#16 . Since @sky-joker made a project for this, we might as well use it for you guys as well if you are interested. Feel free to suggest addition, removal or modification for each step as you see fit.

I plan to create issues for some of them and can make assignements to who will be responsible for each step if we want (e.g. open PRs for roles can be assigned to @dj-wasabi for example, @ericsysmin can rework CI and so on). Lets say that I will create the issues tomorrow, so if you can state your opinion in the linked discussion until then, that will be perfect.