repository-service-tuf/repository-service-tuf-worker

Task: metadata update start using roles expiry

MVrachev opened this issue · 3 comments

MVrachev commented

What is the task about?

In discussions with @kairoaraujo we have decided that the metadata rotation should accept the expected role bumps (in days) in the metadata update:
https://github.com/repository-service-tuf/repository-service-tuf-api/blob/main/tests/data_examples/metadata/update-root-payload.json

That's why we should start using that information when bumping the online roles.
Currently, we don't use it in any way.
What steps I think we should do are:

  1. check if settings exists in the payload
  2. checking if settings["expiration"] exists in the payload
  3. replace the repository settings in Redis related to roles expiry with the new values given in the metadata update payload

All those three steps must happen before we call run_bump_online_roles:
https://github.com/repository-service-tuf/repository-service-tuf-worker/blob/13744ac60299d916e14e18479298902b68b692ec/repository_service_tuf_worker/repository.py#LL1021C43-L1021C43
and inside the LOCK_TARGETS lock.

Parent feature

No response

References

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
kairoaraujo commented
  1. replace all environmental variables related to roles expiry with the new value given in the metadata update payload
    Do you mean the settings repository in Redis? Maybe:
  1. replace the repository settings in Redis related to roles expiry with the new value given in the metadata update payload
MVrachev commented
  1. replace all environmental variables related to roles expiry with the new value given in the metadata update payload
    Do you mean the settings repository in Redis? Maybe:
  1. replace the repository settings in Redis related to roles expiry with the new value given in the metadata update payload

Yes, you are right, updated the comment.

  • 👍1
kairoaraujo commented

I'm closing this issue.
It was replaced by: