Vpn management creation#562
Conversation
|
Hi @asmodehn 👋, This pull request has been marked as stale due to 163 days of inactivity after changes were requested. As a result, any linked issues are being unassigned from you so other contributors can pick them up. However, you can still continue working on this PR! If you push new commits or respond to the review feedback:
If you need more time or have questions about the requested changes, please let us know. We're happy to help! 🤝 |
|
Hi @asmodehn 👋, This PR has been inactive for 164 days since changes were requested. Are you still working on it? If yes, push new commits or reply to let us know. If you've moved on, please close the PR or comment so another contributor can pick it up. |
nemesifier
left a comment
There was a problem hiding this comment.
Thanks for tackling #201, this is a genuinely useful direction and I appreciate that you flagged the fragility yourself in the description. Let me answer the design question directly because it determines the whole approach.
The core design problem you raised is the blocker
Capturing openwisp2_vpn_id / openwisp2_vpn_name by regex-parsing the load_initial_data.py stdout and only on the run that prints created is not robust:
- If anything after the DB insert fails, the id/name are lost and every subsequent run skips the block, so the server is left half-configured with no automatic recovery.
- It is also not idempotent: re-running the role on a healthy install does nothing useful because the facts are only set on the creating run.
Your own suggestion is the right one: use a well-known, fixed VPN name (for example derived from a role variable), and on every run look the VPN up by that name via the management script or API instead of parsing creation output. That makes the play idempotent and self-healing: "ensure a VPN named X exists, then fetch its id, then configure openvpn". Please pursue that path; the stdout-regex approach should be dropped.
Other issues to fix once the approach is settled
openwisp2_openvpn_setupdefaults totrueindefaults/main.yml. A new feature that installs and starts OpenVPN must default tofalse, otherwise every existing deployment that re-runs the role suddenly gets an OpenVPN server. Opt-in only.- Missing trailing newline in
defaults/main.ymlandmolecule/resources/collections.yml(yamllint will complain). - The regex for
openwisp2_vpn_nameis greedy to end of line and will capture trailing whitespace / CR; even in a corrected design, parsing names this way is brittle. - Needs real tests and docs before merge (both unchecked, which is honest, just noting it for the final pass).
Good initiative. Once you switch to "lookup by fixed name, idempotent" and make it opt-in, I am happy to review the next iteration in detail.
Checklist
Reference to Existing Issue
First Draft for implementing the server part of #201.
Only tested in molecule for now.
Description of Changes
openwisp2_openvpn_setupis set to trueA VPN server object is created by the load_initial_data.py script.
Its name and id are known by ansible only for this run, which makes it possible to download the configuration and start the openvpn server.
That is if there is no error...
If an error occurs somewhere after adding the VPN object in the DB, the name and id of the VPN will not be available on the following runs, which means the setup must be completed manually...
Not sure if this is acceptable and/or if there is a better way to address that problem (known unique vpn_server_name that we can look for on every run instead ?)
In any case, let me know what you think about this...