Skip to content
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

Read-only config properties #9

Open
raybellis opened this issue Jun 17, 2024 · 3 comments
Open

Read-only config properties #9

raybellis opened this issue Jun 17, 2024 · 3 comments

Comments

@raybellis
Copy link
Contributor

Is there a list anywhere of the properties that are read-only and/or otherwise not intended to be written to (c.f. the note about subscription.saved_state in the documentation) ?

I'd like to extend the openvpnas_config type so that those properties are not visible to Puppet as resources, and instead expose them as Puppet facts.

@sahaqaa
Copy link
Collaborator

sahaqaa commented Jun 19, 2024

Hello, i will ask developers and will reply back within approx 1-2 days

@sahaqaa
Copy link
Collaborator

sahaqaa commented Jun 20, 2024

@raybellis Reply from developers: only "subscription.saved_state" property has this behavior (i.e. even if you overwrite that value, AS will put a new value in by itself to 'fix it').

All other settings are regular i.e. "what you put in it - is what you get".

If you could make "subscription.saved_state" to be not visible so no one would try to configure it - it would be good.

But exposing "subscription.saved_state" as a Puppet fact, in my opinion, doesn't make sense. Because it is not used by anything for anything.

Facts are supposed to be used or referenced in some way or to help in node classification. In this case exposing "subscription.saved_state" as Puppet fact will not bring any advantages.

@raybellis
Copy link
Contributor Author

raybellis commented Oct 5, 2024

I didn't get notified of the followup comments. I'll send a PR to exclude subscription.saved_state from the Puppet openvpnas_config types exposed.

Re: the latter point, though, Facts have a lot more use than that. Custom facts are often the best way to expose system state, especially if you need Puppet manifests to make conditional decisions based on that state, which can't actually be done with resources.

For example, upgrade.current_version exposed as a Fact could be used to check whether the running version differs from the installed version, to trigger a restart. I use similar Facts on our BIND and Apache servers for this purpose.

(I note that contrary to what the developers have said it would seem to make no sense to allow Puppet to overwrite that particular informational config property, ditto for upgrade.initial_version!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants