ansible-opnsense
ansible-opnsense copied to clipboard
naturalis
OpnSense Collection?
Are there any plans to convert this to a collection or implement a collection, such as pfSensible.core?
yeah would love this as a collection. With simple docs, module and parameters. Then add examples etc.
I believe that roles are particularly useful when designing bits of automation that should be reused often in multiple projects. I would argue that deploying and configuring opnSense is not something done really all that often. I think most people who use this have a playbook for their initial configuration of the firewall and then maybe sprinkle in extra configuration when deploying other services, such as setting custom DNS or port forwards and what not.
I genuinely think that having this available as a collection would make for a much better developer experience. I personally find a playbook to be way more readable and maintainable as opposed to a vars file where I customize the role and then the only content in the playbook is just importing said role.
Having it as a collection will also enable us to do the tasks in specific orders as opposed to the order they are currently implemented in the role, should that be required, as well as improve the performance by not having to go through any task that is not necessary, if, for example, all i want to do is change the hostname, I can simply have a task that does it as opposed to having to import a role for it then the role going through all the tasks and skipping 99% of them.
I just don't see much of a reason for this to be a role as opposed to a collection. I think this should be converted. I am willing to help in that regard if the developer is down to take this challenge!
@zerwes @fpieters @rudibroekhuizen @krauthosting Sorry for directly tagging you, but I was wondering if there is any interest in moving in this direction.
I do, however, consider that such a change is not to be implemented in this repo, as to not remove the role and break compatibility for those who still depend on it, rather to start a new repo and slowly migrate this role to a collection and eventually adding a deprecation notice here. Any opinions or thoughts on this?
Other resources you have linked in this repo could also be brought into that new collection, such as the opnsense_facts.
Am i barking at the wrong tree here? 😆
Hello && Salut @mikeanth-dev I am not the owner / maintainer of this repo, but as I used and extended the role during the last months (I am not sure, but I think there where approx 20-30 PRs during the last 1 1/2 years), I dare to respond here, not in the name of the other contributors, just speaking for me and myself. Having a collection with (maybe multiple) roles targeting opnsense merged into a collection might be a good option and would help some people just starting with opnsense and ansible, but from my point of view there are some other topics that have a bigger priority and are in fact basic conditions for the start towards a collection.
- a improved documentation, covering all tasks and VARs (Here I have to admit that none of my PRs have somehow improved the docs! But at least I have tried to show some examples in the comments in some tasks)
- some (real live and working) examples
- a
handlermanagement - maybe some ci/cd integration
We already had some discussions regarding a major and basic change in the role by moving away from the brute
xml(re)writing towards using the opnsense API (https://docs.opnsense.org/development/api.html) So to be honest, I will concentrate my spare time (if I have any) on these topics, as a good documented, reliable and improved role is IMHO much more valuable then just the same stuff converted to a collection. To sum it up: IMHO there are bigger tasks to do here, then converting this into a collection, even if those tasks are not of much prestige.
Thanks for your response, @zerwes!
While I do see your point, I also think that most of these issues could be addressed by starting fresh.
Let me explain. You said you were considering changing the role by moving away from xml rewriting to using the OPNSense API, which I agree would be a very good move. Instead of simply rewriting this role, why not implement the tasks in a collection format to begin with? While doing that, we could also impose the rule that no new task/feature can be merged unless it has documentation attached to it and provide some examples in said documentation. This would single handedly address your first two points. While yes, the handler management issue would still remain, implementing it in a collection wouldn't be much different from implementing it here, am I right?
And when it comes to CI, we could again set rules as to not allow new features without some tests written for them.
It could be a way to start doing it "properly" from the ground up.
I also believe that examples would be easier to write in a collection as opposed to a role, as you can showcase the tasks and passing in vars as opposed to just providing vars snippets (what examples can we really provide for the role outside of that?).
While I agree that there are other tasks that should be taken care of as well, I believe that they could be better and more systematically addressed in a collection.
I believe that they could be better and more systematically addressed in a collection
Yes, I agree to this, but from my point of view the format to choose is secondary, the lack of resources for the tasks required is the main obstacle. But, yes, you get a full ACK from me that choosing the right format from the beginning is important.
Maybe @rvalle and others involved in https://github.com/Rosa-Luxemburgstiftung-Berlin/ansible-opnsense/issues/2 and #38 should be involved here too. As far as I can see, the focus of the people from naturalis has moved away from this role (@rudibroekhuizen et al.: this is no reproach, just a ascertainment and I can fully understand that focus, preferences and resources change during the time; I am just happy I found your work and can extend it for my needs :+1: ). I had some contact to thomas-krenn regarding supporting this in some way (as they offer some services regarding opnsense), but unfortunately I got no response after the first enthusiastic comments :-( . Maybe there could be some support from other side, as I do not think this can be handled as a 1...2...3... man show.
And finally we should always take some considerations regarding opnsense.com i.e. decisio, as we all are just beneficiary of and depend on the great work they do!
Fair point.
I guess we'll wait to see what the others have to say about this, in that case.
Anyway, I would be down to starting a separate project on implementing an OPNSense collection that handles the tasks via their API if I can find others willing to join in. Just putting that out there😄
Hell, I'd join in but do not know how to do this. Learning experience for me.
Can use this as a base. pfsensible.core I have not looked deep into it but im sure the api is not too different, some refactoring. Also started this repo for it, just cloned the template from ansible-collections.
I've used the pfsensible.core collection in the past, and while it is great, it had a few limitations, so we'll have to see about that. As for the repo, i think we should wait to see if/how many other developers we find. Just like zerwes said, this isn't a 1-3 man show :))