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 > > >
