#315 Need tuned in Fedora Atomic Host
Opened 6 years ago by sdodson. Modified 6 years ago

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

6 years ago

Yeah, we have a few issues of package drift like this across distros :frowning: (Another example is that strace exists on FAH by default).

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).

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

6 years ago

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)

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

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.

For the most part testing with rpm-ostree install tuned is going to be fine and easier.

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.

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.

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.

Metadata