-
Notifications
You must be signed in to change notification settings - Fork 13
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
rewrite trento community checks regarding 'package version' #124
rewrite trento community checks regarding 'package version' #124
Conversation
…-1130, jsc#CFSA-1131, jsc#CFSA-1109, jsc#CFSA-1108, jsc#CFSA-1134, jsc#CFSA-1067, jsc#CFSA-1125, jsc#CFSA-1137)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice to see how this is proceeding, nice job!
What doesn't really click for me is the usage of the package_version
to determine OS Flavor and OS Version in checks CAEFF1 and D028B9.
facts: | ||
- name: os_flavor | ||
gatherer: package_version | ||
argument: SLES_SAP-release |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This usage of the package_version
gatherer would result in the following command
$ rpm -q --qf "%{VERSION}" SLES_SAP-release
Is this the way to determine that the OS is SLES4SAP? Asking because I might very well ignore it 😅
I tried it on a SLES 15 sp3 of ours - not a 4SAP though - and it returns package SLES_SAP-release is not installed
If the package_version
gatherer is not suitable to determine the OS, we might need a different gatherer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, your right. It is a workaround, but a reliable working 'workaround'. The package 'SLES_SAP-release' is only available on SLES for SAP systems. On a plain SLES you will have the 'SLES-release' package.
The recommended way (as we told our partners) is to evaluate /etc/products.d/baseproduct and search for '<name>', '<cpeid>' or '<productline>' depending on the use case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@angelabriel We can merge as it is by now, and open a new ticket to maybe implement a new gatherer to get the version. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arbulu89 Sounds good. Having a gatherer for the os version (based on /etc/os-release or /etc/products.d/baseproduct ) and the os flavor (based on /etc/products.d/baseproduct ) would be really nice.
But it's not urgent as by now we can live with the workarounds.
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice again!
facts: | ||
- name: os_flavor | ||
gatherer: package_version | ||
argument: SLES_SAP-release |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@angelabriel We can merge as it is by now, and open a new ticket to maybe implement a new gatherer to get the version. What do you think?
priv/catalog/D028B9.yaml
Outdated
- https://documentation.suse.com/en-us/sbp/all/single-html/SLES4SAP-hana-sr-guide-PerfOpt-15/ | ||
|
||
facts: | ||
- name: SLES_SAP_version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would stick to small case here for the name
…e characters in 'facts', 'expects' and 'expectations'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good from my side!
facts: | ||
- name: exclude_package_pacemaker | ||
gatherer: package_version | ||
argument: pacemaker,2.0.3+20200511.2b248d828 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could very well done as before, just letting the version in the values, and comparing with the package version string, as we simply wanted a different value.
But both work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the new changes to the package version gatherer I guess only check CAEFF1 - Operating system vendor is supported needs to be adjusted.
All other checks are comparisons that should work identically as before.
Done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we can go with these by now 🚀
using gatherer 'package_version' to fix jsc#CFSA-1130, jsc#CFSA-1131, jsc#CFSA-1109, jsc#CFSA-1108, jsc#CFSA-1134, jsc#CFSA-1067, jsc#CFSA-1125, jsc#CFSA-1137