+1 That reminds me, we went through this same thing with cdn.conf. It used to be a Perl hash, but we converted it to JSON a while back. I'm pretty sure we provided a script to do that, but I'm not sure if it's this one or not:
traffic_ops/app/bin/config2json Possibly relevant PR: https://github.com/apache/trafficcontrol/pull/1350/files Maybe this will jog someone's memory that went through that process a couple years ago, but you should see if that config2json script already does what you want. If the rewritten API fails to parse the expected JSON, we should fail with an appropriate message including the location of the script they can use to convert their existing Perl config to json. However, we should probably still give users a period of one release to become aware of the breaking change before actually breaking them nicely. Or, maybe this can be handled with the TO API routing blacklist. If operators of existing installations don't want to update their config to be json, they can disable the Go route until the following release where the Go route becomes no longer blacklist-able. In that case maybe it should be included in the blacklist by default. - Rawlin On Wed, Nov 13, 2019 at 9:00 AM Williams, Adam <[email protected]> wrote: > > I'm converting the `/osverions` Traffic Ops endpoint [0] from Perl to Go [1]. > The Perl version of this endpoint reads a configuration file > and performs an `eval` of the contents [2]. The default location for this > config file is: /var/www/files/osversions.cfg. > > As part of the conversion to Go, I'd like to propose the following changes: > > 1. The config file's format be changed from Perl to JSON. > 2. Provide a tool to convert config files from Perl to JSON. As a onetime > step, users would be required to update existing config files, either with > the mentioned tool or by other means. > In practice, the config data represents a list of key/value pairs, so there > shouldn't a loss of expressiveness going from Perl to JSON. > > Alternatives that were considered: > - Implement a Perl interpreter in Go. Not practical. > - Perform a regex operation on the config file to extract the key value > pairs. Error prone. > - As part of the Go endpoint, invoke a Perl interpreter to process the file > and return its contents as JSON or some other common format. This would > create a dependency on a Perl interpreter being available to the TrafficOps > binary. > - Inspect the config file's extension and/or contents. If determined to be a > common format (e.g. JSON), parse it directly. Otherwise, either proxy to the > Perl endpoint or invoke a Perl interpreter to parse the config file. This > would provide backwards compatibility, but wouldn't break the dependency on > Perl for this endpoint. > - Use a different file format, such as YAML. Go's standard library has > support for JSON but not YAML. Also, JSON is the "native" representation of > the data as returned by the endpoint. > > [0] > https://traffic-control-cdn.readthedocs.io/en/latest/api/osversions.html#get > [1] https://github.com/apache/trafficcontrol/issues/3800 > [2] > https://github.com/apache/trafficcontrol/blob/b5e85d3ad913e67af03027f79eea473ddc9e7f8b/traffic_ops/app/lib/API/Iso.pm#L62
