openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hamann <matthew.ham...@gmail.com>
Subject Re: Pluggable API Gateways
Date Sat, 11 Aug 2018 03:06:33 GMT
Great discussion. I wholeheartedly agree with the notion of making gateways
pluggable. It's a fairly complex issue, given the various differences in
each gateway implementation, whether it be feature parity or even the way
each feature is implemented.

One possibility would be to create a layer that sits in between Whisk
"proper" and a given gateway implementation that knows how to take a common
set of directives and translate them into whatever DSL the target gateway
understands. One could conceivably even use this to target 3rd-party cloud
gateways like AWS, Azure, IBM, etc. That way, Whisk only needs to maintain
one repo containing the translation layer, while Whisk adopters can deploy
their gateways of choice.

At a surface level, I'd liken this to something akin to Terraform or
Ansible, where a somewhat common set of directives can be used to target
any number of cloud providers.

On a potentially controversial note, the OpenResty gateway could continue
to be the "officially" packaged gateway implementation for Whisk unless we
collectively see a reason to use something else. I do think we should have
an opinion.

-Matt
matthew.hamann@gmail.com


On Fri, Aug 10, 2018 at 9:25 PM japhar81 <japhar81@gmail.com> wrote:

> 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 <rodric@gmail.com> 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 <japhar81@gmail.com> 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 <japhar81@gmail.com> 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 <rodric@gmail.com>
> > 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
> > >>
> > >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message