-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move routeros modules and plugins to own collection? #135
Comments
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 . |
@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 :) |
We (Ansible Community) can help setup CI |
Dear colleagues, hello. |
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: |
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 🙂 |
@renatoalmeidaoliveira I think this has already been done by several network collections. There's a disadvantage/problem though: if anyone uses the (dreaded) Maybe a quick poll for everyone participating here: what do you prefer:
Use 👍/👎 on this comment to vote! |
@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:
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 |
@renatoalmeidaoliveira I've never tried: can you actually use jinja2 syntax in the 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. |
@felixfontein it isn't possible i think, it is only an idea, but it could be a great feature. |
both look ok but in 1 .. too much routeros :) |
Looks like 2. wins, i.e. community.routeros.api, community.routeros.command, and community.routeros.facts. Fine for me :) |
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 |
@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. |
@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 :) |
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/ |
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.) |
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?
The text was updated successfully, but these errors were encountered: