[Wishlist] Add the ability to configure both isolcpus and CPUAffinity

[dashmage]

Today, it is not possible to configure both isolcpus AND CPUAffinity using the same instance of a sysconfig charm. There are cases where it could be useful to do so. For example, when deploying Juniper Contrail, the recommendations from Juniper are to isolate the CPUs used for Nova with isolcpus and to use CPUAffinity to give some cores to the OS. The rest of the cores being assigned to the vRouter. A simple example woud be:

Machine with 16 cores used like this:

• Cores 0 and 8 for the OS
• Cores 1 and 2 used by the vRouter (their siblings 9, 10 are not used)
• Cores 3-7 and 11-15

We should then isolate the cores:

• Isolcpus: 3-7,11-15
• CPUAffinity: 0, 8

It is unfortunately not possible today.

---

Imported from Launchpad using lp2gh.

• date created: 2020-01-13T13:10:09Z

• owner: npochet

• assignee: arif-ali

• the launchpad url

[dashmage]

(by arif-ali) I am now looking at this as part of a customer issue, possibly the same customer.

With the latest updates of the sysconfig charm, in-fact after sysconfig-6 was release a patch was added to add 90-sysconfig.conf in /etc/default/grub.d and therefore if a customer wanted to update the configuration in /etc/default/grub, and re-ran update-grub then we would lose all the configs from /etc/default/grub, and have a base clean config from the sysconfig charm

This is now an issue on the customer site, as they don't really want to re-deploy and ultimately would like to use the system as is. So I would suggest deprecating the cpu-range config, and we have cpu_affinity_range and isolcpus for the 2 respective configurations

[dashmage]

(by mfo) Moving the Importance from wishlist to medium.

Even though this is a limitation (not a bug) in the charm as currently is, and fixing a limitation can fairly be considered a wishlist item, this has field impact to cloud deployments.

Thus asking for a bit higher importance level, if at all possible.

Thanks! Mauricio

[dashmage]

(by mfo) Can the importance of this bug be changed from Wishlist to Medium?

Even though this is a limitation (not a bug) in the charm as currently is, and fixing a limitation can fairly be considered a wishlist item, this has field impact to cloud deployments.

Thus asking for a bit higher importance level, if at all possible.

Thanks! Mauricio

[dashmage]

(by arif-ali) Are we able to say when we'll see in the -next charm, and then an ETA on landing this fix to the stable charms?

[dashmage]

(by arif-ali) cs:sysconfig now has the fix