You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2018/09/28 17:13:06 UTC

[GitHub] rob05c commented on issue #2877: TO API 2.0: handle SSL key versioning in the DS SSL key APIs rather than the client

rob05c commented on issue #2877: TO API 2.0: handle SSL key versioning in the DS SSL key APIs rather than the client
URL: https://github.com/apache/trafficcontrol/issues/2877#issuecomment-425504527
 
 
   +1
   
   If the TO API itself manages the "latest" key in Riak, rather than exposing it, it seems a lot more intuitive and what people naturally expect (feel free to disagree, if anyone's intuition doesn't match mine).
   
   For example, suppose the latest key is version 6. It's ok if under-the-hood we always store a copy of the real latest version in Riak at the Riak `latest` key, but then `DELETE /key?version=latest` should (1) delete the internal copy at Riak key `-latest`, (2) delete the real latest at Riak key `-version6`, (3) create a new key `-latest` by copying the previous `-version5`.
   
   Which is to say, "latest" should be treated as an "alias" by the API itself, and not allow direct manipulation of it in Riak by users, and always treat user calls to manipulate the "latest" version as if it were the real latest version, 5 or 6 or whatever.
   
   Again, that was my intuition, and if that's the common natural expectation, we should do that, to minimize catastrophic accidents.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services