Errata Install to Content Host takes too long and doesn't scale well
We have a report that installing a number of erratta takes a long time. There is no info about what the bottleneck is, so we need to investigate.
When applying (installing) errata on a Content Host from the server, it takes a very long time. For example, installing ~556 errata on a single content host was observed to take ~44 minutes. Most of that time (~36 minutes) was during the 'initiating the install' phase of the task (i.e. executing the pulp consumer content install). While this may not sound too bad a first glance, it won't scale well as the behavior is linear. As a result, if there were 100 content hosts, that same action could take ~3 days.
Improves performance of errata installation.
Pulp API no longer translates errata into a list of packages applicable to a consumer. Errata ids are passed to the agent on the consumer where yum and security plugin take care of the translation. The new functionality is equivalent to running
yum update-minimal --advisories=<errata_id>,<another_id>
on the consumer.
#10 Updated by firstname.lastname@example.org over 5 years ago
The problem stems from the fact that Pulp takes each errata and turns it into a list of packages. As the number of errata grows, the amount of time it takes to translate them into package lists grows.
The proper solution is to smarten up the Katello agent/pulpplugin for Gofer to be aware of errata as a content type. This way Pulp can completely avoid having to generate lists of packages. Yum is very good at figuring out what packages belong to what errata.
I have tested this solution with yum 3.4.3 on RHEL7.
I have also tested this with yum 3.2.22 and yum-security 1.1.16 on RHEL 5.10.
I have confirmed that Yum 3.2.22 ans yum-security 1.1.16 have shipped with RHEL 5 since update 5.
Please register to edit this issue