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

Consider validation of '/system/archetype/os/name' #178

Open
jrha opened this issue Jun 4, 2018 · 5 comments
Open

Consider validation of '/system/archetype/os/name' #178

jrha opened this issue Jun 4, 2018 · 5 comments
Labels

Comments

@jrha
Copy link
Member

jrha commented Jun 4, 2018

As mentioned in quattor/configuration-modules-core#1282.

For:

  • We are relying upon it in components, so we should be able to control the contents.

Against:

  • The broker will accept almost anything, it may be some time after the OS is added to the broker before the validation is hit at compile time, this could be painful.
@ned21
Copy link
Contributor

ned21 commented Jun 5, 2018

Another potential challenge: t's used in different ways at different sites. So e.g. we use it for Linux/Solaris but in @jouvin's setup docs he uses it to differentiate between Linux distros.

@jrha
Copy link
Member Author

jrha commented Jun 5, 2018

Perhaps the validation should be nothing more than "is a complete lower-case word with no funny characters"

@jrha
Copy link
Member Author

jrha commented Jun 5, 2018

One of the types in #180 perhaps?

@jouvin
Copy link
Contributor

jouvin commented Jun 5, 2018

I think that if we want to be able to test against it in other standard templates, it would be better to have an exhaustive list of possible values. Is it really much more than linux, centos, scientific-linux, rhel, debian, ubuntu? It looks to me as a rather finite list that we can update when needed...

@jrha
Copy link
Member Author

jrha commented Jul 28, 2023

I don't think we can meaningfully validate the content in any other way than enforcing a lowercase string_trimmed.

@jrha jrha added the question label Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants