ocket8888 commented on pull request #5539: URL: https://github.com/apache/trafficcontrol/pull/5539#issuecomment-876698593
Usages in `cache-config/` are in GoDoc comments - it looks safe to change them since the information they're conveying isn't actually specific to that API version. I can do that if you want, but it shouldn't affect anything. Usage in docs example has been updated Usage in the ORT.py package is irrelevant, since that is due for removal. Pointless to change now, since it can't possibly work now that `atstccfg` has been removed, and whatever I do will be deleted anyway. Usage in Grove is in a comment that wouldn't even appear in package documentation. I can get rid of it if you want, but it's not affecting anything. I don't tend to touch anything in `infrastructure/docker` (except in the `build` subdirectory) because those Dockerfiles are archaic, they're parsing that API output in a way that may not be trivial (e.g. getting/setting server IP addresses), and their use is nowhere recommended or even documented. I don't even know if those work. I can change it, but it might break things in weird and unexpected ways, which doesn't seem worth it for something we don't even really support. Usage in `lib/go-tc` is in GoDoc comments, which I can change if you want. Usage in `load-test.jsx` is not referring to a Traffic Ops host - you can tell because it's passing a hostname for a Traffic Ops instance as a query parameter. `test/router/server.go` is the server serving that API, so the only real change necessary should be in there. But on the other hand - that test suite doesn't work. All browsers I've tried (Firefox, Chrome, Opera, all at latest versions) will refuse to load the `.jsx` file on the grounds of CORS request failure. If those tests are intended to work, they'll need to be reworked anyway, so the changes could just take place then. `cfg_test.pl` is a script that, I believe, has not worked for longer than your involvement in the project. Possibly longer than mine. It was replaced by the `compare` tool, which has since been removed because it no longer serves any purpose. This script should not exist. Usage in restapi.py is for a generic API, an API base URL containing an `api/1` segment is perfectly valid in that context. In `tosession.py` it's in a comment on an example - which itself works afaik - and doesn't appear in any documentation. I can change it if you want, but it's not affecting anything. Usage in `copy-pgdata.sh` has been updated. I thought that was for migrating from a mysql database to postgresql, but the comment header implies otherwise. Regardless, the usages are trivial enough to change easily. Usage in `traffic_ops/testing/` is in non-documenting comments, which I can change if you want but it's not affecting anything. Usage in `traffic_ops/traffic_ops_golang/` in GoDoc comments has been updated, as it was incorrect - except for one instance, which is still technically correct. One usage as a hard-coded value in a response header and one usage in a test have both been updated. The usages in the routing test are specifically checking for APIv1 not existing, and so should remain. The URL used in the DS Stats test is arbitrary, I can change it, but it won't be any more or less valid; only the headers on the request actually matter. Swagger is not actually supported by Traffic Ops. The `traffic_ops/traffic_ops_golang/swaggerdocs/` directory and any and all sub-packages thereof should be deleted, in my opinion. Unless someone is going to make them work, in which case they ought to update them to be correct themselves. But I don't think that's actually possible, in general, without significant code changes and some way to integrate the output with our existing documentation system (which doesn't exist afaik). Usage in TP was previously removed, but must have been re-introduced during rebase with the commit that added/updated the `stable` API version. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
