Well let me ask this: which of these - if any - work/still work today? Some of them have been described as "proof-of-concept"s which leads me to believe that they wouldn't really do anything with a modern install of Traffic Control. "Postgrest" in particular just seems to contain a Dockerfile that installs "postgrest". So it really doesn't prove much besides that postgres itself exists and runs.
If someone has plans to expand on something or continue working on something that's different, though. But if all we have is some limited functionality that doesn't with our system in any special way and nobody has any plans to do anything with it, then idk if I see the point in keeping it around. On Tue, 2019-11-12 at 17:47 -0700, Rawlin Peters wrote: > I'm definitely +1 on removing experimental code that has been > superseded. I'm also +1 on removing experimental code that has > stagnated and currently represents a maintenance cost that is not > worth the benefit of keeping it in the repo. If it's not actively > being worked on, there's not much benefit to keeping it in the repo, > and like Michael said it will always be in the git history if it ever > needs to be revived again. > > If moving all experimental things to the top-level experimental > directory helps alleviate the maintenance cost by allowing us to > effectively ignore that directory for all intents and purposes, then > I > think I can get on board with that approach to keeping experiments > around. That said, at what point should we declare an experiment too > stagnated to keep in the repo? Do we still keep them around forever > if > they never "graduate" to production? > > - Rawlin > > On Tue, Nov 12, 2019 at 1:09 PM Hoppal, Michael > <[email protected]> wrote: > > Thanks for the background!!! > > > > I more lean towards removing code that is unmaintained / unused. > > That and git would allow us to get it back if we ever did want to. > > > > The trafficcontrol repo is a MONSTER of a repo and it makes it very > > confusing/daunting to anyone new coming in (I know first-hand). > > > > That being said if others agree not to remove those I would be fine > > leaving them in there but suggest we move them to the other > > experimental directory in the repository > > https://github.com/apache/trafficcontrol/tree/master/experimental. > > > > On 11/12/19, 12:20 PM, "Robert O Butts" <[email protected]> wrote: > > > > infrastructure/test/api has been superseded by the TO API > > Tests. > > infrastructure/test/apitest has been superseded by the TO API > > Tests. > > infrastructure/test/ui/traffic_ops/traffic_ops_test.go has been > > superseded > > by the Portal Tests. > > traffic_ops/client_tests has been superseded by the TO API > > Tests, which > > test the client (also, it's empty). > > traffic_ops/experimental/ats_config has been superseded by the > > atstccfg > > Config Generator. > > traffic_ops/experimental/server has been superseded by > > traffic_ops_golang > > > > I wrote all of the above, and I'm +1 on removing them as > > superseded. > > (Though the fact that I wrote them shouldn't prevent someone > > else from > > claiming something as useful, if anyone thinks so.) > > > > traffic_ops/experimental/goto has been superseded by > > traffic_ops_golang, +1 > > to remove. > > > > traffic_ops/experimental/auth is an experimental auth > > microservice for > > TO/TC. It hasn't been superseded by anything. We probably > > aren't going this > > direction any time soon, but I'm still hesitant to remove it as > > an > > experimental PoC. > > > > traffic_ops/experimental/postgrest hasn't been directly > > superseded by > > anything. We chose to go the traffic_ops_golang route, but > > PostgREST is > > still a valid alternative, and maybe worth keeping the PoC > > around. > > > > traffic_ops/experimental/traffic_ops_auth hasn't been > > superseded by > > anything in production; but it serves essentially the same > > purpose as > > traffic_ops/experimental/auth and it's much smaller. I'd be -0 > > on removing > > it. > > > > traffic_ops/experimental/url-rewriter-nginx hasn't been > > superseded by > > anything, and serves to complement > > traffic_ops/experimental/postgrest as a > > PoC for a particular way of doing TO. I'd kind of like to keep > > it around, > > for the same reason. > > > > traffic_ops/experimental/webfront is along the same > > "microservices" lines > > as traffic_ops_auth, url-rewriter-nginx, and postgrest. I'm +1 > > on keeping > > them around, as a PoC of a different way to do things. > > > > > > On Tue, Nov 12, 2019 at 11:57 AM ocket 8888 < > > [email protected]> wrote: > > > > > A PR was recently opened ( > > > https://github.com/apache/trafficcontrol/pull/4095) > > > to remove a bunch of cruft from the codebase, and it looks > > fine to me but > > > before merging I wanted to make sure nobody was using this > > stuff. It mainly > > > deals with some things under infrastructure/test, > > traffic_ops/experimental, > > > and some client testing cruft. Here's an abbreviated list (GH > > will show you > > > every file in a directory individually, I believe I've > > collapsed it as much > > > as I can) of everything being removed: > > > > > > - infrastructure/test/api/ > > > - infrastructure/test/README.md > > > - infrastructure/test/apitest/ > > > - infrastructure/test/ui/ > > > - infrastructure/test/environment.json > > > - infrastructure/test/environment/ > > > > > > - traffic_ops/experimental/ > > > > > > - traffic_ops/client_tests/ > > > > > > - traffic_ops/testing/api/log/ > > > - traffic_ops/testing/test/ > > > > > > note that a lot of those are directories. > > > > > > >
