According to @dustymabe tuned is not currently installed on Fedora Atomic Host. OpenShift would like to make use of tuned profiles so we'd like to ensure that it's installed and enabled on atomic host.
We're not clear on the best way to deliver openshift specific tuned profiles to atomic host so we'd be interested in hearing if you have suggestions there. If nothing else is presented we'll likely drop them via our install playbooks.
Metadata Update from @dustymabe: - Issue tagged with: host
Yeah, we have a few issues of package drift like this across distros :frowning: (Another example is that strace exists on FAH by default).
strace
This particular case was discussed before: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2016-October/msg00005.html
I'm not opposed to adding tuned, though honestly I've never liked the architecture (another persistent-in-RAM python daemon). Longer term it feels like tuned's job should really more be Ansible playbooks or something?
Worth noting that git grep tuned in https://pagure.io/fedora-comps has zero hits (i.e. neither Workstation nor Server ship it by default either).
git grep tuned
assigning to @rubaoredhat - he should be able to take care of this as he recently learned how to compose ostrees
Metadata Update from @dustymabe: - Issue assigned to rubaoredhat
Hey, I have tested to add tuned to the tree json files to three different branches ( f26, f27, and fedora-rawhide (master) ).
For f26, the rpm-ostree compose works, the rebase also seems functioning properly with the additional tuned packages, the output can be found here: https://paste.fedoraproject.org/paste/-D7Ii7LP-qpkOeM0njMPFA
For f27: it errored out at the stage of trying to compose an rpm-ostree, I am assuming it is based on the metalink that the repo defined did not show up yet: The error is as follows: https://paste.fedoraproject.org/paste/MdNDIUIoPqe8hez3WBOLAg
For fedora-rawhide: the compose actually works fine; however, when trying to do a rebase to the fedora-rawhide, it appears that because all of the packages in rawhide is f27, the caches are looking for metalink url with 27 as releasever, as a result, it also fails. The error is the following: https://paste.fedoraproject.org/paste/52RKvUDTWhCyHlPJFcpmuQ
Tho.... my testing so far might be wrong in terms of steps.... but just provide it as a source of information :)
Hey, I have tested to add tuned to the tree json files to three different branches ( f26, f27, and fedora-rawhide (master) ). For f26, the rpm-ostree compose works, the rebase also seems functioning properly with the additional tuned packages, the output can be found here: https://paste.fedoraproject.org/paste/-D7Ii7LP-qpkOeM0njMPFA
so this is interesting. in your paste it looks like the tree you composed is an f25 tree (note all the f25 strings in the rpm names)
yeah that is not surprising - they are in the middle of branching f27 so I wouldn't worry about this one.
For fedora-rawhide: the compose actually works fine; however, when trying to do a rebase to the fedora-rawhide, it appears that because all of the packages in rawhide is f27, the caches are looking for metalink url with 27 as releasever, as a result, it also fails. The error is the following: https://paste.fedoraproject.org/paste/52RKvUDTWhCyHlPJFcpmuQ Tho.... my testing so far might be wrong in terms of steps.... but just provide it as a source of information :)
probably also an issue with branching right now. Let's just worry about getting f26 working and for the other branches we'll just make the same change and go with it.
Hey, will this https://paste.fedoraproject.org/paste/GuHFocJzhdkCZVdvatZsWQ look better? It turns out that I have to redo the tree compose in order to regenerate this output... sorry for the time gap in between
thanks @rubaoredhat -
looks like we have this group of new packages:
dbus-python-1.2.4-6.fc26.x86_64 dmidecode-1:3.1-1.fc26.x86_64 ethtool-2:4.11-1.fc26.x86_64 hdparm-9.51-1.fc26.x86_64 kernel-tools-4.12.5-300.fc26.x86_64 kernel-tools-libs-4.12.5-300.fc26.x86_64 pciutils-libs-3.5.5-1.fc26.x86_64 python-gobject-base-3.24.1-1.fc26.x86_64 python-linux-procfs-0.4.10-2.fc26.noarch python-perf-4.12.5-300.fc26.x86_64 python-schedutils-0.5-2.fc26.x86_64 python2-asn1crypto-0.22.0-4.fc26.noarch python2-configobj-5.0.6-8.fc26.noarch python2-decorator-4.0.11-2.fc26.noarch python2-pyudev-0.21.0-3.fc26.noarch python3-asn1crypto-0.22.0-4.fc26.noarch tuned-2.8.0-3.fc26.noarch virt-what-1.18-1.fc26.x86_64
kind of unfortunate to be adding to the base
For the most part testing with rpm-ostree install tuned is going to be fine and easier.
rpm-ostree install tuned
yes, but testing a real compose with the edited json is probably more valuable. since peter had never done a tree compose before I asked him to do that.
@walters, any issues with the reported "new rpms" ?
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1482568 to involve the tuned maintainer.
does this block us from including tuned today? or just document how we would like it improved over time?
Hi, Tuned maintainer here :)
We are still trying to improve the memory consumption. But at the moment the most of the memory is consumed by the interpreter itself and by libraries (especially udev and dbus). If you don't need the daemon functionality (i.e. dbus control, tuning of the hot-plugged devices, tuning of newly created processes, etc.) and are OK with the one-shot tuning you can disable Tuned daemon mode in: /etc/tuned/tuned-main.conf, daemon=0.
Regarding Python 3 we are working on the switch. The main problem is lack of the Python 3 support in some libraries (e.g. python-perf which came from the kernel upstream), but we would like to have the full Python 3 support ready till end of this year.
One thing I'd like to understand better is what exactly is failing with openshift-ansible and further, whether adding tuned as it is today will fix things.
tuned
The playbooks seem to detect it and add a conditional:
- name: Check for tuned package command: rpm -q tuned
It certainly looks to me like some of the code it's then going to try to call isn't going to work:
$ tuned-adm profile atomic-guest Requested profile 'atomic-guest' doesn't exist.
Because those bits only live in the RHEL tuned. Hm, I just remembered we'd discussed something related to this before:
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2016-October/msg00005.html
Yeah, I think we'd want parity of profiles between Fedora and RHEL tuned.
@walters @jeder - how do we resolve this?
Login to comment on this ticket.