Re: [openstack-dev] [FaaS] Introduce a FaaS project

[Robert Putt]

Hi,

I am very interested in FaaS coming to OpenStack, it totally makes sense to 
have it as part of the platform. I have observed the current OpenStack Picasso 
project although I too am concerned about vendor lock in to IronFunctions with 
the Picasso project. I think it is also important not to alienate the current 
OpenStack community by introducing non standard components or languages, I am 
hopeful the new releases of Python can provide reasonable performance so it is 
possible to keep Python as a primary language for a FaaS project. My main 
concern is that we seem to have several FaaS projects with different approaches 
rather than having us all work on one superior FaaS solution. Is there a way we 
can win over the Picasso project team to be more understanding of the vendor 
lock in and language concerns?

For me the important things are:


a)   Sandboxed code in some container solution

b)   Pluggable backends for said sandbox to remove vendor lock in

c)   Pluggable storage for function packages, the default probably being 
Swift

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.

e)   Integration with Neutron so functions can access tenant networks.

f)A web services gateway to create RESTful APIs and map URIs / verbs / 
API requests to functions.

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.

Just some thoughts. If you’d like these converted into basic blueprints for the 
project let me know, I know some of them may seem like very stretched goals at 
the moment but I am sure their time will come.

Best Regards,

Rob


From: Lingxian Kong 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, May 15, 2017 at 10:56 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [FaaS] Introduce a FaaS project

On Mon, May 15, 2017 at 8:32 PM, Sam P 
mailto:sam47pr...@gmail.com>> wrote:
Hi Larry,
 Thank you for the details.
 I am interested and like the idea of no vendor/platform lock-in.

 However,  I still have this stupid question in me.
 Why FaaS need to be in the OpenStack ecosystem? Can it survive
outside and still be able to integrate with OpenStack?

In OpenStack ecosystem, I mean put this project under OpenStack umbrella so 
that it could leverage OpenStack facilities, and integrating with other 
OpenStack services means it is an option to be deployed together with them and 
be triggered by event/notification from them.

 This FaaS must able to well integrated with OpenStack ecosystem and
no argument there.

>>IMHO, none of them can be well integrated with OpenStack ecosystem.
Can you share more details on this?  If you have done any survey on
this,  please share.
Crating FaaS with pure OpenStack means, we need to create something
similar to OpenWhisk or IronFunctions with existing or new OpenStack
components.
I just want to make sure it is worth it to recreate the wheels.

Yeah, you are right, as I said at the beginning, I'm sort of recreating the 
wheels. I hope the new project can be easily installed together with other 
OpenStack projects using similar methodology, it can provide a beautiful 
RESTful API to end users, it's easy for OpenStack developers to understand and 
maintain. I don't think it is that easy if we go with OpenWhisk or 
IronFunctions. Actually, in container world, there are already a lot of 
projects doing the same thing. But again, I'm OpenStack developer, we are 
running an OpenStack based public cloud, I don't want to mess things up to 
introduce things which will probably introduce other things.



Jsut for the info, I think this [0] is your previous ML thread...
[0] http://lists.openstack.org/pipermail/openstack-dev/2017-May/116472.html


Thanks to find it out :)



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ.

Re: [openstack-dev] [picasso] First meeting on 7th of March

[Robert Putt]

Good morning / afternoon / evening,

Not sure if you have seen the agenda etherpad posted in the Slack channel - 
https://etherpad.openstack.org/p/picasso-first-meeting. Might be worth putting 
our thoughts in there, I already had a few questions about integration with the 
OpenStack community and so on.

Here are a few of my biggest sticking points with the project which I feel we 
should really address early on:


a)   Currently the project does not appear to use the standard OpenStack 
Oslo libraries and as such the configuration and behavior of the project is 
inconsistent with other projects. This could be particularly confusing for 
operators as even simple things like the config file (there isn’t one yet that 
I am aware of, stuff is passed In via args at daemon run time) is completely 
different to the usual section based config files we see in most OpenStack 
projects.

b)   The project only works with IronFunctions, not saying that 
IronFunctions is a bad choice for sure a driver for IronFunctions should be 
included, but it would be good to allow other Function as a Service platforms 
to make use of Picasso in a pluggable fashion, e.g. a driver for Fission, or a 
raw driver based on top of Nova / Heat. For me vendor neutrality is a really 
important aspect of OpenStack services and having the freedom to choose the 
backend of these APIs is crucial.

Best Regards,

Rob

From: Derek Schultz 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, March 7, 2017 at 5:19 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [picasso] First meeting on 7th of March

Update: the patch to openstack-infra/irc-meetings was merged, so we should be 
good to go. The only change was moving the meeting time from 1800 UTC to 1700 
UTC.

Meeting details can be found here 
https://wiki.openstack.org/wiki/Meetings/Picasso

On Mon, Mar 6, 2017 at 6:45 PM Derek Schultz 
mailto:schultz.de...@gmail.com>> wrote:
All good points, it's important that we do not diverge from the community. 
Today I created an #openstack-functions channel on IRC and have submitted the 
necessary patches to the openstack-infra project-config and irc-meetings 
repositories. Due to this, I may have to move the first meeting from this 
Tuesday to another day or week as we wait for approval.. I'll keep this thread 
posted as soon as I know more.

Regards,
Derek

On Thu, Mar 2, 2017 at 11:54 AM Paul Belanger 
mailto:pabelan...@redhat.com>> wrote:
On Thu, Mar 02, 2017 at 05:41:24PM +, Derek Schultz wrote:
> Hi Emilien,
>
> Thanks for the feedback! I'm aware that IRC is the standard for OpenStack
> folks, but at this current stage it's just easier to hold the discussion in
> Slack as Picasso ties into the IronFunctions open source project and
> important context would be lost if we were to maintain different chat
> platforms. That said, I think we can move Picasso from Slack to IRC in the
> future (once we prepare for the big tent).
>
I agree with Emilien here, by using a proprietary platform you are potentially
alienation existing openstack developers from contributing to your project.
Yes IRC would be needed for big tent, but why start consuming IRC out of the
gate?

Are are already hosting code on git.openstack.org, 
seems like the next step
would be to move to IRC.

> Regards,
> Derek Schultz
>
> On Wed, Mar 1, 2017 at 7:49 AM Emilien Macchi 
> mailto:emil...@redhat.com>> wrote:
>
> > On Tue, Feb 28, 2017 at 12:30 PM, Derek Schultz 
> > mailto:schultz.de...@gmail.com>>
> > wrote:
> > > Hello all,
> > >
> > > The Picasso team will be running our first meeting next Tuesday. All
> > those
> > > interested in the project are welcome!
> > >
> > > For those of you not familiar with Picasso, it provides a platform for
> > > Functions as a Service (FaaS) on OpenStack [1].
> > >
> > > Tuesday, March 7th, 2017 Meeting Agenda:
> > > Starting at UTC 18:00
> > >
> > > 1. From Python to Go. (What Picasso needs from IronFunctions to implement
> > > multi-tenancy)
> > > 2. Blueprints [2]
> > > 3. Figure out best time slot for future meetings.
> > > 4. Roadmap discussion.
> > >
> > > How to join:
> > > http://slack.iron.io in the #openstack channel
> >
> > I would recommend using IRC for consistency with other projects.
> > Nothing forces you to do so, unless you plan to apply to the Big Tent.
> > My personal recommendation would be to use IRC so you can get more
> > visibility, since most of OpenStack folks are on IRC (and not always
> > on Slack).
> >
> > Good luck for your first meeting!
> >
> > > Etherpad:  https://etherpad.openstack.org/p/picasso-first-meeting
> > >
> > > [1] https://wiki.openstack.org/wiki/Picasso
> > > [2] https://blueprints.launchpad.net/picasso
> > >
> > >
> > >
> > >
> > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Un