add system uptime capability

[guangyee]

Add the ability to upload the system uptime logs, produced by the suse-uptime-tracker daemon, to SCC/RMT as part of daily heartbeat report. We need to ability to track system uptime to hourly granularity so MSPs can utility that data accordingly (i.e. billing).

This feature is optionally enabled by installing the suse-uptime-tracker package and enabling the suse-uptime-tracker.timer service.

[digitaltom]

@guangyee don't we need a config option in suseconnect to enable the uptime collection? What's the planned way for customers to turn the collection on/off?

[guangyee]

@guangyee don't we need a config option in suseconnect to enable the uptime collection? What's the planned way for customers to turn the collection on/off?

Per my understanding, in the short term, by installing and enabling the uptime-tracker service constitutes an opt-in to uptime collection. We'll document it as such. However, in the long run, we will consider the configuration aspect via REST API.

[digitaltom]

Per my understanding, in the short term, by installing and enabling the uptime-tracker service constitutes an opt-in to uptime collection. We'll document it as such. However, in the long run, we will consider the configuration aspect via REST API.

I don't think it's a good idea to assume customer agreement on collecting system uptime data by presence of a specific package. The package could already be installed on the image, or get pulled in unintentionally.
Having it as an option in the suseconnect config also creates the base for receiving that setting from the server, and setting it intentionally in provisioning or manually.
The target audience for metering are MSP systems. It's technically possible to enable it for 'normal' customers, but it shouldn't be the default and should be an informed decision to enable it for the customer.

[guangyee]

Per my understanding, in the short term, by installing and enabling the uptime-tracker service constitutes an opt-in to uptime collection. We'll document it as such. However, in the long run, we will consider the configuration aspect via REST API.

I don't think it's a good idea to assume customer agreement on collecting system uptime data by presence of a specific package. The package could already be installed on the image, or get pulled in unintentionally. Having it as an option in the suseconnect config also creates the base for receiving that setting from the server, and setting it intentionally in provisioning or manually. The target audience for metering are MSP systems. It's technically possible to enable it for 'normal' customers, but it shouldn't be the default and should be an informed decision to enable it for the customer.

Sorry I wasn't clear earlier. It's not just the presence of the uptime-tracker package. Customer will also need to explicitly enable the uptime-tracker.timer service, which is similar to the keepalive heartbeat timer, in order to enable system uptime tracking. If that's not good enough, then I can also add a flag in SUSEConnect to enable the sending of system uptime log itself. But the drawback would be the increase in complexity in enabling the feature. Please let me know if that the direction we want to go.

[digitaltom]

Please let me know if that the direction we want to go.

I think that needs to get decided in the project planning regarding what is the desired UX enabling that feature.
I would tend to having an option in the suseconnect config because that is very explicit.

[jeremy-moffitt]

Please let me know if that the direction we want to go.

I think that needs to get decided in the project planning regarding what is the desired UX enabling that feature. I would tend to having an option in the suseconnect config because that is very explicit.

my understanding is the feedback is to have configurations for both connect-ng and the uptime tracker... I'm not sure why we want to require the customer to enable it twice, in addition to having the required packages and services configured. If we put a config option in suseconnect-ng, then for the tracker service itself, the presence of the package and the service running should be sufficient... That would look something like:

1. suseconnect has an explicit config
2. the uptime tracker is considered enabled if the service is running and does not additionally have a config

[guangyee]

@digitaltom @jeremy-moffitt I will add a flag enable_system_uptime_tracking to control the sending of the system uptime tracking log.

CLI flag missing

[ngetahun]

@guangyee enable_system_uptime_tracking is not shown as a cli option because it's missing from flag parsing logic here. Please add it so I can manually test with the uptime_tracker package.

[guangyee]

@guangyee enable_system_uptime_tracking is not shown as a cli option because it's missing from flag parsing logic here. Please add it so I can manually test with the uptime_tracker package.

Per my understanding, we will not be exposing this option in CLI as it is meant to control whether keepalive heartbeat will send the system uptime log. Sending system uptime log is only meaningful when working in conjunction with keepalive.

[felixsch]

Per my understanding, we will not be exposing this option in CLI as it is meant to control whether keepalive heartbeat will send the system uptime log. Sending system uptime log is only meaningful when working in conjunction with keepalive.

I agree on this. We spoke about this in one of the MSP syncs and all agreed there is no need for a CLI option. Maybe you can provide test instructions how to test this pull request?

[ngetahun]

@guangyee this PR is good to merge but need to do 2 things:

1. Rebase/merge from/unto main
2. add an entry into changelog for release 1.9.0 (suseconnect-ng.changes)

[guangyee]

@guangyee this PR is good to merge but need to do 2 things:

1. Rebase/merge from/unto main
2. add an entry into changelog for release 1.9.0 (suseconnect-ng.changes)

Done. Thanks for the suggestion.

[guangyee]

Per my understanding, we will not be exposing this option in CLI as it is meant to control whether keepalive heartbeat will send the system uptime log. Sending system uptime log is only meaningful when working in conjunction with keepalive.

I agree on this. We spoke about this in one of the MSP syncs and all agreed there is no need for a CLI option. Maybe you can provide test instructions how to test this pull request?

We have created some preliminary instructions for the MSPs on how to enable the feature. We can use that for our testing. https://confluence.suse.com/display/CloudSolutions/White+paper+documentation

[chajain]

Performed the end to end testing along with SCC latest PR https://github.com/SUSE/happy-customer/pull/7339 and RMT PR SUSE/rmt#1091 and verified following scenarios

• Downloaded the latest suse-uptime-tracker rpm package from OBS and started the suse-uptime-tracker.timer service and the /etc/zypp/system-uptime.log is populated with the system_uptime data
• When enable_system_uptime_tracking flag set to true, the payload contains the online_at params and system_uptimes table is populated on SCC/RMT when the keepalive hearbeat is sent

Also Validated backward and forward compatibility tests

• older version of connect-ng still works with latest SCC/RMT PR
• upgraded connect-ng(this PR) talking to an older version of SCC/RMT which does not recognize system_uptime and it does not crash on the extra payload

[mssola]

LGTM! 🚀