99% sure not done on purpose. good catch. On Fri, Sep 21, 2018 at 11:55 AM Schmidt, Andrew (Contractor) < [email protected]> wrote:
> Where is this being used? Traffic Router is definitely not examining the > version when it pulls the keys. > > > On 9/21/18, 11:38 AM, "Dave Neuman" <[email protected]> wrote: > > Yes we need to keep it. This functionality has saved us on more than > one > occasion. > > > On Fri, Sep 21, 2018 at 10:06 AM Rawlin Peters < > [email protected]> > wrote: > > > Hey Traffic Controllers, > > > > So while working on the TO Go DS sslkeys endpoints [1], I found that > > we lost a feature in the transition from the old TO Perl UI to the > > Perl API, and since the since the TO golang is basically just a > > rewrite of the Perl endpoints, this feature of the Perl UI was > > overlooked so far in the rewrite. > > > > This feature is delivery service SSL key versioning, where adding new > > SSL keys to a delivery service would increment the version of > > deliveryservice.ssl_key_version and store the new keys in Riak using > > the incremented version (as well as store them as the 'latest' > > version). This means that all the previous ssl keys of the DS are > > stored in Riak and saved indefinitely, so if need be you can always > > get to the previous ssl keys of the DS. > > > > This feature was somehow left out of the Perl API implementation, so > > currently the API is just overwriting the 'latest' (and whatever the > > existing ssl_key_version of the DS is) keys whenever you add new ssl > > keys to the delivery service. Since ssl_key_version isn't > incremented, > > this means you can no longer retrieve your previous ssl keys for a DS > > once you've added new ones. > > > > My hunch is that this wasn't done on purpose, but I can't confirm > > since the Perl API predates me. We would still want that > functionality > > in the API, right? I've opened a GitHub issue [2] to track this. > > > > - Rawlin > > > > [1] https://github.com/apache/trafficcontrol/pull/2853 > > [2] https://github.com/apache/trafficcontrol/issues/2855 > > > > >
