Open Stack

Hi, Rob,

Appreciate your suggestions. Please see my inline comments.

On Mon, May 15, 2017 at 11:17 PM, Robert Putt <Robert.Putt at rackspace.co.uk>
wrote:

> For me the important things are:
>
>
>
> a)       Sandboxed code in some container solution
>
Yeah, it's on the roadmap (may happen in several days.)

> b)       Pluggable backends for said sandbox to remove vendor lock in
>
c)       Pluggable storage for function packages, the default probably
> being Swift
>
Qinling already supports plugable storage. In order to make it easy to
test, the default is local file system. But it's up to deployer to decide
which storage solution to use.

> d)       Integration with Keystone for auth and role based access control
> e.g. sharing functions with other tenants but maybe with different
> permissions, e.g. dev tenant in a domain can publish functions but prod
> tenant can only execute the functions.
>
Qinling supports Keystone for authentication. RBAC is on the roadmap.

> e)       Integration with Neutron so functions can access tenant networks.
>
This needs to be discussed further. Currently, the code is executed inside
container which locates in orchestration system. Not sure it's easy to make
that container access tenant network.

> f)        A web services gateway to create RESTful APIs and map URIs /
> verbs / API requests to functions.
>
Currently, user could invoke function by calling Qinling's rest api, but I
agree with you that an API Gateway service is indeed necessary to provide
more flexibility to end users.

> g)       It would also be nice to have some meta data service like what
> we see in Nova so functions can have an auto injected context relating to
> the tenant running it rather than having to inject all parameters via the
> API.
>

Cheers,
Lingxian Kong (Larry)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170516/e5de513e/attachment.html>