I was in the midst of doing that, but the immediate snag is travis -- it doesn't support a separate travis.yml per subdirectory ( https://github.com/travis-ci/travis-ci/issues/3540) and the mess it created to try and matrix subdirectories and languages is just a huge fail. For instance, my current hack of traefik is a node.js app, adding that in made the config so unreadable I couldn't PR it with a clean conscience. Add a few more gateways in a few more languages, and it'll be an unmaintainable mess..
On Fri, Aug 10, 2018 at 9:21 PM Rodric Rabbah <[email protected]> wrote: > What about subdirectories instead of repos? I admit not having thought too > deeply about this yet but I find that we have too many repos and generally > makes things harder to work across many components. > > -r > > > On Aug 10, 2018, at 9:17 PM, japhar81 <[email protected]> wrote: > > > > As I started poking at incubator-openwhisk-apigateway, it may be > preferable > > to make this a repo that just holds documentation and ansible scripts, > and > > each apigateway is a submodule. For instance the current gateway would > move > > to incubator-openwhisk-apigateway-openresty or something along those > lines. > > Then we could add incubator-openwhisk-apigateway-traefik, etc. This would > > mean easier maintenance, simpler travis configs, etc. I see lots of > upside > > and no real downside. Obviously I don't have rights to do this myself, > but > > Id be curious if you folks agree, and if someone with enough github > rights > > might be willing to help me get it done.. > > > >> On Fri, Aug 10, 2018 at 8:24 PM japhar81 <[email protected]> wrote: > >> > >> I completely agree, it's model is a bit rigid -- I'm happy to take on > that > >> work as well, though it might take me a bit, I've just started playing > with > >> golang. Regardless, I do think it should come as a follow-on effort, > with > >> the current model being the first plugin we build -- which will > >> coincidentally work against at least the current gateway and the traefik > >> one I'm trying to implement. > >> > >>> On Fri, Aug 10, 2018 at 8:21 PM Rodric Rabbah <[email protected]> > wrote: > >>> > >>> My point about the cli is that current implementation is unnecessarily > >>> opinionated and while you can work with it, it’s just not necessary to > have > >>> to fit into its current model. I opened several issues to try to > address > >>> these shortcomings. It is absolutely true that this can be viewed > >>> separately from consolidating the route management package with its > >>> gateway. > >>> > >>> -r > >> > >> >
