Move routeros modules and plugins to own collection?

[felixfontein]

Since the routeros modules and plugins are actively supported, and we're currently discussing moving some things out of the monoliths community.network and community.general, I've suggested to move the routeros modules and plugins into their own collection community.routeros. What do you think about this?

Some background and pro/cons etc.: ansible-collections/overview#117 (comment)

@heuels what do you think?

Also, @jplitza @altf4arnold @renatoalmeidaoliveira @danpospisil @NikolayDachev @adeptvin1, as contributors and users (you all created routeros-related issues/PRs here), what do you think?

[NikolayDachev]

routeros_api is a pretty much independent from the rest in community.network which is ok, however I'm not sure for the other modules .
Also I have 0 idea what will happen with CI/CD .. should we have different one, what about general management etc. ?
I'm relatively new here so the other guys probably have better idea from me .. as general look ok

[felixfontein]

@NikolayDachev all routeros parts are independent from the rest of community.network. They only need things from ansible.netcommon, which would be a dependency of the community.routeros collection.

CI coverage would stay the same. I'll probably switch to GitHub actions instead, since that totally suffices for such a small collection. This also makes us more flexible; for example if we ever want to add more complex tests (maybe with some routeros 'emulator'), we could simply do that without somehow having to integrate it into community.network's CI.

About management: we would be a lot more flexible than here, i.e. we can make releases whenever we want (and we don't have to bump the major version every 6 months, but only if we do a backwards incompatible change), and more people (in particular @heuels) can have commit rights or things like that. Also it's easier to subscribe to the repository, since you will get only notifications on routeros, and not on everything that's in community.network :)

[gundalow]

We (Ansible Community) can help setup CI

[adeptvin1]

Dear colleagues, hello.
I really liked the more detailed explanation of this action. I support this innovation, because someday RouterOS 7 will happen and it is quite possible that you will have to finish certain functionality in fast mode and it will not be very convenient to maintain large time intervals.

[renatoalmeidaoliveira]

I think tah might be a great change, not only on for maintance porpouses but for the end user because with minor changes it will be possible to simplificate the modules names and the namespace for a more semantic aproach like:
Now:
community.network.routeros_config
To
community.routeros.config

[heuels]

I agree! That sounds like a great idea. I would also love to help with CI. It would also be possible to add integration tests against a RouterOS CHR (I believe I saw a sample setup utilising Docker somewhere).

Also, notifications will finally be manageable 🙂

[felixfontein]

@renatoalmeidaoliveira I think this has already been done by several network collections. There's a disadvantage/problem though: if anyone uses the (dreaded) collections: keyword, they can simply write config: in their roles/playbooks, which gets very confusing. (Or just api: if we rename routeros_api to api.) I'm kind of neutral on this, since I don't like the collections: keyword anyway ;)

Maybe a quick poll for everyone participating here: what do you prefer:

1. community.routeros.routeros_api, community.routeros.routeros_command, community.routeros.routeros_facts 👎
2. community.routeros.api, community.routeros.command, community.routeros.facts 👍

Use 👍/👎 on this comment to vote!

[renatoalmeidaoliveira]

@felixfontein in most of my work with Ansible i look for an multi-vendor paradigm, for example creating roles for each vendor, but if there was any consent on module naming the end user could write theirs plays in a agnostic paradigm, like a class interface. In that way it would be very scalable and reusable, with something like:

collections: "community.{{ansible_network_os}}"

tasks:

config:
     path:

interface:
  ....

That way with only one play you could configure any vendor, and with a little bit of YANG and JINJA get a very flexible environment

[felixfontein]

@renatoalmeidaoliveira I've never tried: can you actually use jinja2 syntax in the collections: keyword? So far I assumed you couldn't. (Even if you could, you would get one global result, not one per host.)

What you could do is probably some YAML magic to make the action name configurable for a task. But even there you'd have to chose one name for all hosts.

[renatoalmeidaoliveira]

@felixfontein it isn't possible i think, it is only an idea, but it could be a great feature.
The namespace selection based on ansible_network_os and the modules names following an convetion

[NikolayDachev]

@renatoalmeidaoliveira I think this has already been done by several network collections. There's a disadvantage/problem though: if anyone uses the (dreaded) collections: keyword, they can simply write config: in their roles/playbooks, which gets very confusing. (Or just api: if we rename routeros_api to api.) I'm kind of neutral on this, since I don't like the collections: keyword anyway ;)

Maybe a quick poll for everyone participating here: what do you prefer:

1. community.routeros.routeros_api, community.routeros.routeros_command, community.routeros.routeros_facts 👎
2. community.routeros.api, community.routeros.command, community.routeros.facts 👍

Use 👍/👎 on this comment to vote!

both look ok but in 1 .. too much routeros :)

[felixfontein]

Looks like 2. wins, i.e. community.routeros.api, community.routeros.command, and community.routeros.facts. Fine for me :)

[NikolayDachev]

Do we have a general idea what we should do for this transition to be done like a,b,c, etc. ?

For example if we go with separate CI/CD I guess will take a time .. what about this time period .. I'm not sure but I think in all cases changes in CI/CD will be needed. I guess the manual testing will be a option otherwise any bug fix or new implementation will be hard for manage
Also I guess imports in uniti test will not be fixed magically :) ..

[felixfontein]

@NikolayDachev I plan to do the migration next week. Setting up basic CI to do the same tests as right now shouldn't take long. My aim would be to make a quick 0.1.0 release by the end of next week, which contains the renamed modules. Then we have some time to test this, add more CI, ..., as we want, maybe have a 0.1.1 or 0.2.0 release, until we're confident that the collection is in a good state, and we can release 1.0.0. From then on, the collection can get included in Ansible 2.10.x. We should get that done until the end of the year.

[felixfontein]

@gundalow created the collection repository and I've set up the content: https://github.com/ansible-collections/community.routeros

Please try this out :) I've renamed the modules and flattened the directory structure. It contains all routeros-related commits from community.network, so at least that part of the history is not lost.

I'll look with @gundalow that we can make a 0.1.0 release the next days, so we have something that's easier to test for people who don't want to work with the git repo :)

[felixfontein]

I've just published version 0.1.0 on galaxy: https://galaxy.ansible.com/community/routeros

If you want to see how the docs look like: https://ansible.fontein.de/collections/community/routeros/

[felixfontein]

Let's continue further discussions in ansible-collections/community.routeros#1. (Or create a new issue in the repo if you want to discuss something not directly related.)