Let's say "designed", not "expected" :P. I'll double-check the `/delete` endpoint, but if our tools and UI behave that way, I guess it's fine.
>When you then deleted version "latest", you deleted ssl/myds-latest. I believe >if you do a GET with ?version=5 Yes, that's what happened (and the previous version I tried, 3, actually didn't exist, making me think they'd all been deleted). But that leaves the SSL keys in an unusable state for our tools, because everything gets `latest`, and the API even returns that (=not found) when the version isn't specified. It deeply unsettles me that I expected to `delete?version=x` and delete that version in the db, and have "latest" now be the prior, and likewise for `delete?version=latest` to delete the actual key, under both the riak key and the real key. I very much did *not* expect `/delete?version=latest` to delete a copied key, appear to have deleted all the keys, and break all of TC that uses it. In both cases, I expected the version queries to get and act on the real key, not for there to be multiple keys actually stored, and not for `delete?latest` to delete the key stored there (breaking all our tools), and not the actual latest key, and for `?latest` to always return the real latest key in the db. If I delete `version=6`, I expect `?latest` to return version 5. If I delete `version=latest`, I expect version 6 to be deleted, and `?latest` to return 5. Again, I won't hold up this PR if `/delete` works as designed. But I seriously think we should rethink our design. If anyone else misunderstands or shares my intuitive expectations, it could lead to some serious production problems for them. [ Full content available at: https://github.com/apache/trafficcontrol/pull/2853 ] This message was relayed via gitbox.apache.org for [email protected]
