+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. >when you delete the ?version=latest keys, you're really just deleting the Riak >record that is a copy of the most recently added certs. This leaves the >remaining DS SSL keys in a basically unusable state And yeah, that doesn't ever make sense. It seems like things that don't ever make sense shouldn't be possible. [ Full content available at: https://github.com/apache/trafficcontrol/issues/2877 ] This message was relayed via gitbox.apache.org for [email protected]
