Skip to content

Vpn management creation#562

Draft
asmodehn wants to merge 5 commits into
openwisp:masterfrom
asmodehn:vpn_management_creation
Draft

Vpn management creation#562
asmodehn wants to merge 5 commits into
openwisp:masterfrom
asmodehn:vpn_management_creation

Conversation

@asmodehn

Copy link
Copy Markdown
Member

Checklist

  • I have read the OpenWISP Contributing Guidelines.
  • I have manually tested the changes proposed in this pull request.
  • I have written new test cases for new code and/or updated existing tests for changes to existing code.
  • I have updated the documentation.

Reference to Existing Issue

First Draft for implementing the server part of #201.
Only tested in molecule for now.

Description of Changes

  • If openwisp2_openvpn_setup is set to true
  • If there is no VPN objects in openwisp
    A 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...

@asmodehn
asmodehn marked this pull request as draft November 14, 2025 10:40

@DominatrixiaALLATU DominatrixiaALLATU left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe

@openwisp-companion

Copy link
Copy Markdown

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:

  • The issue will be reassigned to you
  • Your contribution is still very welcome

If you need more time or have questions about the requested changes, please let us know. We're happy to help! 🤝

@openwisp-companion

Copy link
Copy Markdown

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 nemesifier left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

  1. openwisp2_openvpn_setup defaults to true in defaults/main.yml. A new feature that installs and starts OpenVPN must default to false, otherwise every existing deployment that re-runs the role suddenly gets an OpenVPN server. Opt-in only.
  2. Missing trailing newline in defaults/main.yml and molecule/resources/collections.yml (yamllint will complain).
  3. The regex for openwisp2_vpn_name is greedy to end of line and will capture trailing whitespace / CR; even in a corrected design, parsing names this way is brittle.
  4. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants