I agree on the repo moves, yes. Honestly I hadn't considered the tests, but it does make sense to move them -- and perhaps generalize them so they can test every implementation the same way.
I also concur that the CLI can probably stay as-is, at least for the time being. I do see value in making it a plugin, but as a separate effort. Your suggestions of caching and the like are my main rationale there -- adding a --caching=true flag to an api create command only makes sense for those gateways that know how to cache. Same for e.g. tracing. So I see that as an eventual thing, but I would suggest we do this in smaller increments so the PRs don't become unmanageable -- and so I don't go slightly crazy trying to manage that much change at once. On Fri, Aug 10, 2018 at 8:13 PM Dascalita Dragos <[email protected]> wrote: > I assume Henry's suggestion is to colocate (as a start) APIGW + apimgmt > actions in a folder, probably in "incubator-openwhisk-apigateway". > In that repo there would be a folder for each impl: GW + apimgmt together. > Henry please keep me honest here. > I assume that apimgmt tests would also move along. > > The existing WSK CLI impl for apimgmt, even though it could be improved, > it's something I was able to work with when writing an alternate > implementation. We could keep it as-is, and ask the other apimgmt actions > to adhere to the existing API. > > Supporting other implementations of Gateways ( Traefik, Envoy, and others ) > should be a great addition to the ecosystem. I would also mention the > feature of "Caching HTTP Responses" of web actions as an additional > capability of new Gateway impl, besides API Management. > > On Fri, Aug 10, 2018 at 10:27 AM Rodric Rabbah <[email protected]> wrote: > > > Hi Henry > > > > Fundamentally, I agree with you and think what you're proposing is a good > > way forward. > > > > Specifically, based on my own experience helping others integrate their > own > > API gateways, I've found a few issues which I've tried to slowly fix. > > > > 1. The openwhisk deployment and route management packages were tied > > together. A PR that was finally merged yesterday breaks this dependence, > so > > that the API gateway and route management package are entirely optional. > > (This affects ansible deployments, doesn't necessarily address other ways > > of deploying the system). > > > > 2. I also posite that the route management package (and all of its > > corresponding tests) should be consolidated in the same place that ties > > them to the implementation (i.e. the actual API gateway being used). > > > > 3. The wsk CLI needs to be refactored to break several hard coded > > assumptions (which are not necessary in my assessment) about the > underling > > route management implementation and what the gateway implementation > > supports. Simply put, hard coding of the JSON responses and the > parameters > > that can be passed to the gateway is wrong and should be generalized. > > > > I believe that the way OpenWhisk provides a level of indirection to > > impedance match against many API gateways that are out there is a good > > engineering of the system, and that it bootstraps actions to extend the > API > > is a good design to preserve... so that from the OpenWhisk clients > > perspective we're defining a canonical experience. > > > > In short, I'm in favor of the proposal but caution there will be a bit of > > grunt work ahead to fully realize this (based on my recent experience). > > > > -r > > > > > > -r > > > > > > On Fri, Aug 10, 2018 at 12:35 PM, japhar81 <[email protected]> wrote: > > > > > This is a follow-up to a Slack conversation with @dragos.dascalita and > > > @csantanapr. As I've been struggling to stand up the API Gateway for > > > OpenWhisk, it occurred to me that I would actually prefer to use a > > > different GW entirely. In my case, Traefik fits nicely in one spot, and > > > Istio integration would be very handy in another. > > > > > > I'm happy to implement both, but the current state makes it hard to > > > contribute. A couple options and opinions came out of our discussion > that > > > could use more input; > > > > > > 1. Splitting the routemgt stuff out of incubator-openwhisk either > into > > > openwhisk-apigateway or the cli repo. My preference is a dedicated > > > repo, as > > > it makes more sense from a new users' POV -- I had a rough time > > getting > > > things to work and it was unclear in the current structure. > > > 2. We can either ship APIGW+routemgt combos for each implementation, > > or > > > we can potentially make the api commands in wsk a plugin, shipping > an > > > APIGW > > > + a wsk cli plugin to match. > > > > > > My personal opinion is this; if the APIGW is optional, the routemgt > > actions > > > must be as well -- one is pointless without the other. They're also > > tightly > > > coupled to the specific implementation. As such, I would suggest that > > both > > > pieces move to their own repo, with a folder for each implementation, > as > > > well as deployment docs for all things APIGW in the same place. > > > > > > Thoughts/comments welcome! > > > > > > Thanks, > > > Henry > > > > > >
