-
Notifications
You must be signed in to change notification settings - Fork 48
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
Refactor python3-observabilityclient package setup in tcib_packages #122
base: main
Are you sure you want to change the base?
Conversation
This commit makes two significant changes to tcib pkg configuration: 1. Removes the 'python3-observabilityclient' package from the common configuration. This step is taken to streamline the package setup and tailor the dependencies more specifically to the needs of different architectures and operating systems. 2. Adds the 'python3-observabilityclient' package specifically for x86_64 and el8 architectures. This addition aligns with our strategy to optimize and enhance observability and monitoring capabilities on these architectures. Additionally, a note is included to address future RHEL-specific package requirements, indicating that RHEL-specific packages can be added or uncommented once they are available. This change prepares for a more tailored and efficient package management approach in our system configurations.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: son-vyas The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
- python3-octaviaclient | ||
- python3-aodhclient | ||
- bash-completion | ||
- iputils | ||
#rhel: We can uncomment this when we have rhel specific pkgs |
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.
what will be uncommented here?
do you mean more like "we can add rhel specific pkgs to this list"
[EDIT]: ok i see what you mean now. we can uncomment "rhel:" specifically to add a new 'rhel' key and package list
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.
we shoudl not have rhel sepfcic packages in this file this is intended to work on both centos and rhel.
and we do not expect people to edit the file so i dont think this comment is relevent
#rhel: We can uncomment this when we have rhel specific pkgs | ||
x86_64: | ||
- python3-observabilityclient | ||
el8: |
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.
how/where are these 'architectures' decided. el8 is operating system specific and x86_64 is cpu architecture specific. how/where is this going to be used
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.
So, we had an issue with python3-observabilityclient pkg which we dont need in rhel now - https://redhat-internal.slack.com/archives/C04HN4L5XHV/p1706022079814729. So we want to follow the same pattern we followed with https://opendev.org/openstack/tripleo-common/src/branch/master/container-images/tcib/base/collectd/collectd.yaml#L50 to get this package excluded in rhel.
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.
ok thanks for the extra info.
as we discussed in yesterday's review call, lets keep only the one we need here (e.g. "el9" or "rhel9" or something similar) and then we will also need some further work to wire it up so that we get the right packages for rhel9
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.
we should not have any el8 related content we will be building this for 9.4
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.
observabilityclient is not built on el8, only for newer releases.
Build failed (check pipeline). Post https://review.rdoproject.org/zuul/buildset/6e1015a91d5b43cebe73bc2303a49dcb ✔️ tcib-build-containers SUCCESS in 2h 00m 17s |
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.
Is this really work? I am checking the tcib python code, and I can't see anywhere differentiating
- python3-octaviaclient | ||
- python3-aodhclient | ||
- bash-completion | ||
- iputils | ||
#rhel: We can uncomment this when we have rhel specific pkgs | ||
x86_64: | ||
- python3-observabilityclient |
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 will not install it on centos9 upstream, unless we have something like this https://github.com/openstack-k8s-operators/tcib/blob/main/container-images/tcib/base/os/nova-base/nova-libvirt/nova-libvirt.yaml#L2 here in tcib_actions. The bright side is, it will also not be installed in downstream.
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.
does python3-observabilityclient provide an oepnstack client plugin? if not I'm not sure this is strictly in the scope fo this container image.
its not intended to have a set of generic debugging clients for example this container is not expect to have ssh or virsh for example to act as a way to debug the comptue nodes or even run must-gather or sosreports.
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, it provides an openstack client plugin.
#rhel: We can uncomment this when we have rhel specific pkgs | ||
x86_64: | ||
- python3-observabilityclient | ||
el8: |
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.
ok thanks for the extra info.
as we discussed in yesterday's review call, lets keep only the one we need here (e.g. "el9" or "rhel9" or something similar) and then we will also need some further work to wire it up so that we get the right packages for rhel9
- python3-octaviaclient | ||
- python3-aodhclient | ||
- bash-completion | ||
- iputils | ||
#rhel: We can uncomment this when we have rhel specific pkgs | ||
x86_64: |
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 one can be removed as discussed yesterday, we don't want/need to distinguish on cpu arch here)
This package is already available in RDO all the way back down to Antelope release and also available in downstream for RHEL9. IMO the PR for observabilityclient should be reverted now. |
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.
IMO this is not needed any more as the package is available both for upstream and downstream.
#rhel: We can uncomment this when we have rhel specific pkgs | ||
x86_64: | ||
- python3-observabilityclient | ||
el8: |
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.
we should not have any el8 related content we will be building this for 9.4
- python3-octaviaclient | ||
- python3-aodhclient | ||
- bash-completion | ||
- iputils | ||
#rhel: We can uncomment this when we have rhel specific pkgs | ||
x86_64: | ||
- python3-observabilityclient |
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.
does python3-observabilityclient provide an oepnstack client plugin? if not I'm not sure this is strictly in the scope fo this container image.
its not intended to have a set of generic debugging clients for example this container is not expect to have ssh or virsh for example to act as a way to debug the comptue nodes or even run must-gather or sosreports.
- python3-octaviaclient | ||
- python3-aodhclient | ||
- bash-completion | ||
- iputils | ||
#rhel: We can uncomment this when we have rhel specific pkgs |
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.
we shoudl not have rhel sepfcic packages in this file this is intended to work on both centos and rhel.
and we do not expect people to edit the file so i dont think this comment is relevent
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 am not sold to this approach here.
- python3-octaviaclient | ||
- python3-aodhclient | ||
- bash-completion | ||
- iputils | ||
#rhel: We can uncomment this when we have rhel specific pkgs | ||
x86_64: | ||
- python3-observabilityclient |
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, it provides an openstack client plugin.
#rhel: We can uncomment this when we have rhel specific pkgs | ||
x86_64: | ||
- python3-observabilityclient | ||
el8: |
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.
observabilityclient is not built on el8, only for newer releases.
This commit makes two significant changes to tcib pkg configuration:
Additionally, a note is included to address future RHEL-specific package requirements, indicating that RHEL-specific packages can be added or uncommented once they are available.
This change prepares for a more tailored and efficient package management approach in our system configurations.