Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storage Configuration - Renewal of cloud storage credentials #423

Open
wants to merge 15 commits into
base: development
Choose a base branch
from

Conversation

jmelancongen
Copy link
Contributor

With the current specification, a cloud provider must continuously renew the credentials assigned to a device using the SetStorageConfiguration API. This means that a cloud provider must keep track of all devices and attempt to refresh this configuration, generally over Uplink, regularly to ensure that there is no loss of recording.

Instead of a manual procedure by the cloud provider, we propose that the device manage the lifecycle of its credentials on its own, by accepting an endpoint to a simple API that provides credentials to the device on-demand. This will allow the device to refresh credentials much faster in case of outages, where the device comes back online after a while and wants to resume recording as quickly as possible.

@jmelancongen jmelancongen requested a review from ubkr May 21, 2024 18:41
doc/Core.xml Show resolved Hide resolved
wsdl/ver10/device/wsdl/devicemgmt.wsdl Show resolved Hide resolved
@jmelancongen
Copy link
Contributor Author

To be Added: An OpenAPI document defining the schema of the response that device should expect from the API

@jmelancongen jmelancongen changed the title Proposal: Storage Configuration - Renewal of cloud storage credentials Storage Configuration - Renewal of cloud storage credentials Jun 7, 2024
Copy link
Contributor

@bsriramprasad bsriramprasad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added feedback

@jmelancongen
Copy link
Contributor Author

Updated based on feedback from F2F:

  • Removed the content-type completely. So application/json is just assumed, but has no impact.
  • Removed LocalPath & Type fields from the renewal response. It doesn't make sense to change those during a renewal.
  • Clarified that null values are expected to clear the corresponding optional parameter
  • Clarified that the storage configuration shall be updated with the values from the renewal. So that further GetStorageConfigurations will see the current values.

@bsriramprasad
Copy link
Contributor

bsriramprasad commented Oct 17, 2024

@jmelancongen Once PR #481 is approved, you may want to update the CertPathValidationPolicyID used to validate the renewal endpoint server certificate. requirement to reflect proposed changes in #481 ?

meantime to avoid service disruption.
</para>
<para>
Once the device has called the renewal endpoint, the corresponding <literal>StorageConfiguration</literal> shall be updated with the

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really necessary to update the static configuration on flash? Besides the unwanted side affect of writing to flash unnecessarily often it does not seem logical to change the static configuration with the dynamic fetching of tokens.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the alternative was pushing an update to the configuration anyway it doesn't feel too different. Of course the requirement does not mandate the device writes it to persistent storage, as long as it gives the right response on GetStorageConfiguration the device may remember it anywhere it wants I feel.

The main reason I see this as needed is to facilitate troubleshooting in case something goes wrong. The client can query the device state to figure out what is currently in use and attempt to resolve the situation

Copy link
Contributor

@kieran242 kieran242 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to approve. Only 1 suggested correction.

doc/Core.xml Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants