Optimize bluechictl-is-enabled test

[mwperina]

To improve performance of bluechictl-is-enabled test we will skip
checking existing unit file, if we already checked a unit with the same
enablement status before, when we traverse over list of all existing
unit files.

Relates: #972
Signed-off-by: Martin Perina [email protected]

[coveralls]

coverage: 83.141%. remained the same
when pulling aa04351 on mwperina:optimize-is-enabled-tests
into bad95d5 on eclipse-bluechi:main.

[mkemel]

LGTM

[engelmi]

In general LGTM

By using the list-unit-files feature, we rely on the state of the machine (container/vm/etc.) - so it might behave differently in our container vs multi-host setup. In addition, the list-unit-files is quite expensive and takes quite a while to complete.
Therefore I'd like to raise the question if it is really necessary to aim for checking all systemd unit file states or to "just" select a few and enforce these - e.g. create a quadlet file, do a reload and check if the file is "generated".

[mwperina]

In general LGTM

By using the list-unit-files feature, we rely on the state of the machine (container/vm/etc.) - so it might behave differently in our container vs multi-host setup. In addition, the list-unit-files is quite expensive and takes quite a while to complete. Therefore I'd like to raise the question if it is really necessary to aim for checking all systemd unit file states or to "just" select a few and enforce these - e.g. create a quadlet file, do a reload and check if the file is "generated".

I used units from list-unit-files, because I haven't been able to find out a way to create services with all possible enablement statuses to make sure we simulate systemctl behavior as much as possible. So using list-unit-files we are currently checking services with following enablement statuses (at least on my laptop):

• static
• alias
• disabled
• enabled
• indirect
• enabled-runtime

And the manually we check for non-existent unit file.

So for now I'd merge the code to unblock slower platforms and later we can investigate better solution as a part of #976

[engelmi]

I used units from list-unit-files, because I haven't been able to find out a way to create services with all possible enablement statuses to make sure we simulate systemctl behavior as much as possible. So using list-unit-files we are currently checking services with following enablement statuses (at least on my laptop):

* static
* alias
* disabled
* enabled
* indirect
* enabled-runtime

And the manually we check for non-existent unit file.

That was my previous point - it relies on the machine we run it on. In this list the states generated and transient are missing, for example. So it is not exhaustive. Because of this I am wondering if we are optimizing the wrong thing and if a more static approach with just a few state checks should be chosen - which doesn't need investigation, we'd just need to decide.

So for now I'd merge the code to unblock slower platforms and later we can investigate better solution as a part of #976

Sounds reasonable to me. Both, merging now or changing the approach, is fine.