Install fallback.cfg

[marquiz]

Describe the solution you'd like

The binary packages we build should contain /etc/cri-resmgr/fallback.cfg, not a sample

Why this is needed

sudo cp /etc/cri-resmgr/fallback.cfg.sample /etc/cri-resmgr/fallback.cfg

is totally unnecessary installation step. Sample can be preserved under /usr if needed

[klihub]

That is exactly how it used to be. Then it was decided that we should give a very strong hint to the user to take a look at the sample fallback configuration file, by forcing it to be at least renamed. I'm fine with either way, as long as we can come to a decision that we can then stick with.

[marquiz]

The extra cp step just looks useless user-harassment to me 😄 I mean the user can still start cri-resmgr without any fallback config. Also, I think the implicit hint hidden in the cp step is bad and can be missed by the user. IMO a better/stronger hint would be to instruct the user to do e.g. sudo vim /etc/cri-resmgr/fallback.cfg directly.

WDYT?

[klihub]

The extra cp step just looks useless user-harassment to me I mean the user can still start cri-resmgr without any fallback config.

Not if the command line explicitly references a fallback config file which is not there.

Also, I think the implicit hint hidden in the cp step is bad and can be missed by the user. IMO a better/stronger hint would be to instruct the user to do e.g. sudo vim /etc/cri-resmgr/fallback.cfg directly.

If we really want the user to take a look at the config file with instructions, then IMO it is better to make it sure that the installed configuration file does not pass the validity check on first start up. And make it obvious in the file content 1) that this is deliberate, and 2) and what trivial modifications are needed to make it kosher. That usually significantly enhances the intensity and the span of the user's attention.

WDYT?

I don't have a strong opinion about whether the service should be auto-startable or not after an unattended installation. Both choices have good and bad points. Generally speaking, if the defaults are insanely sane and switching from them to a different config is not painful, then IMO it's usually a better idea to let everything start up without user intervention. If not, then the other choice is better.

[askervin]

Generally speaking, if the defaults are insanely sane and switching from them to a different config is not painful, then IMO it's usually a better idea to let everything start up without user intervention

I second this. And I also think we should aim delivering insanely sane defaults so that one can get measurable performance benefits in typical setups just by installing cri-resmgr on their Xeon nodes.

As the numbers with the default configuration look good already, I'd be tempted to make it default as is - without user intervention. That's how it goes with kubelet and container runtimes, too, yet they have tons of configuration options.