17:01:22 <dschultz> #startmeeting functions
17:01:23 <openstack> Meeting started Tue Mar  7 17:01:22 2017 UTC and is due to finish in 60 minutes.  The chair is dschultz. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:27 <openstack> The meeting name has been set to 'functions'
17:02:07 <dschultz> Hello all! Welcome to the first project meeting for project Picasso - Functions as a Service for OpenStack
17:02:28 <denismakogon> what's up?
17:02:31 <dschultz> can we do a quick roll call to see who's with us? then we'll get started
17:02:39 <denismakogon> o/
17:03:50 <dschultz> perhaps they fell silent or will join us later. let's resume
17:04:16 <dschultz> #topic Discuss time slot for future meetings
17:04:39 <dschultz> Current cadence is biweekly (even weeks) on Tuesdays at 1700 UTC.
17:04:46 <denismakogon> i'm in UTC+2 (east europe)
17:05:07 <robputt> hi everyone
17:05:08 <robputt> :-)
17:05:24 <dschultz> 1700 is about the earliest i can do while still being caffeinated, but open to later times if that works best for the majority
17:05:31 <dschultz> hi rob!
17:05:45 <dschultz> do you have any preference on meeting time?
17:06:27 <robputt> nope
17:06:30 <robputt> right now is cool for me :-)
17:06:31 <dschultz> i'm UTC-7 (Colorado)
17:06:38 <dschultz> ok, cool
17:06:46 <robputt> I am in UTC time zone at the moment, but in summer months I am in BST (aka UTC+1)
17:06:55 <denismakogon> so i think we're fine with having meeting in CT timezone, should be fine for all of us
17:07:09 <dschultz> So let's keep current schedule for now
17:07:13 <dschultz> #topic New project name to replace Picasso
17:07:59 <robputt> btw I moved all the stuff in the dev mailing list into the etherpad
17:08:07 <denismakogon> yeah, pretty hot question, Picasso is registered trademark https://trademarks.justia.com/854/80/picasso-85480361.html
17:08:13 <robputt> ohhh
17:08:15 <robputt> O_o
17:08:18 <dschultz> So, it's come to our attention that we'll need to change the project name from Picasso due to legality of the name, as Denis mentioned.
17:08:21 <robputt> the name itself?
17:08:27 <robputt> or just the shape and style?
17:08:33 <dschultz> Just the project name
17:08:45 <robputt> wow, Picasso dental wax
17:08:52 <robputt> don't wanna annoy these guys :-P
17:09:02 <robputt> they might have an army of dentists come after us :-P
17:09:04 <denismakogon> we need to ask folks from Foundation for help i think
17:09:15 <robputt> look
17:09:25 <robputt> I'll be honest the reason why I became interested in this project
17:09:35 <dschultz> So, I'd like us to come up with some alternatives and vote on it at the next meeting. Sound good? I'd like community input here, but I was thinking we could maybe just call it Functions?
17:09:39 <robputt> was because we already have our own internal Function as a Service built on an OpenStack ecosystem
17:09:53 <robputt> maybe we could just steal the name from my project if Rackspace is happy with it?
17:09:56 <robputt> "Exequor"
17:10:01 <robputt> it's short hand latin for "to execute"
17:11:04 <denismakogon> i think we need couple options that we can present to Foundation
17:11:24 <dschultz> ha, i like it. want to make note of that? Current options: Functions, Exequor (pending approval)
17:11:37 <robputt> who is making notes?
17:11:46 <robputt> want me to add them to the etherpad?
17:11:49 <denismakogon> chat bot, no?
17:12:18 <dschultz> chat bot will do some notes, but best to keep it in etherpad.
17:12:27 <denismakogon> makes sense
17:12:28 <dschultz> thank you robputt
17:13:56 <dschultz> anything else on the project name topic?
17:14:07 <robputt> errr, nothing else from me at the moment
17:14:13 <robputt> but maybe I can think of some other options
17:14:30 <robputt> btw is the intention to keep appending successive meetings to the etherpad?
17:14:43 <robputt> if so we can just copy this topic to the next meeting and let people add their thoughts in the ehterpad
17:15:31 <denismakogon> makes sense, dschultz what you think?
17:16:06 <robputt> hey rtrox :-)
17:16:11 <rtrox> hiya
17:16:14 <dschultz> i think it would be best to have a new etherpad for each meeting, using the date timestamp of the meeting. but at first, since this project is in the early stages i don't see any issue with doing as suggested
17:16:43 <denismakogon> So, project name is still quite open, we don't have deadline for now since we're a bit far away from becoming a BigTent project
17:17:00 <robputt> wow, you guys are very ambitious :-D
17:17:09 <robputt> I think BigTent status takes alot
17:17:23 <dschultz> right, it's not urgent but something we need to consider moving forward.
17:17:37 <denismakogon> rught
17:17:40 <denismakogon> right
17:18:07 <dschultz> ok, moving on
17:18:16 <dschultz> #topic Roadmap and blueprints
17:18:28 <denismakogon> dschultz: may i step in?
17:18:34 <dschultz> sure!
17:20:00 <denismakogon> So, the main thing on our roadmap is to build Picasso V2 that wouldn't be a thin API layer in front of IronFunctions, but would be a set of extensions and middleware for IronFn
17:20:16 <denismakogon> Next thing - bring more container techmologies
17:20:32 <denismakogon> like K8t, roket.io
17:21:01 <robputt> are these container functionality under IronFunctions or directly under Picasso / whatever we call it?
17:21:09 <denismakogon> third thing - support building functions from source code
17:21:52 <robputt> By this do you mean providing it with a Python package etc... rather than a prebaked Docker image?
17:21:57 <denismakogon> functionality is inside of IronFunctions lib called runner that is an abstraction above Docker (for now)
17:22:03 <dschultz> robputt: IronFunctions has a backend container driver (default: Docker), which is pluggable to support drivers for K8s, rkt, etc. #link https://github.com/iron-io/runner
17:23:01 <denismakogon> robputt: yes, some sort of, but such feature will involve couple OpenStack services like Glance, Glare and Swift
17:24:33 <denismakogon> So, the main thing we'd do is to switch from Python code to Go code because IronFunctions is pure Go.
17:24:41 <robputt> ok...
17:24:52 <robputt> How does the community feel about this?
17:25:07 <robputt> having two projects in different languages doesn't prevent them co-existing or interacting with eachother
17:25:30 <denismakogon> according to the latest info if there's a tech reason to use Go there's no objections
17:25:51 <robputt> I know in the past there was alot of push back when Swift team wanted to use some GoLang components for performance reasons as Go was (and to my knowledge still isn't) an official OpenStack unless you have extenuating circumstances
17:25:52 <denismakogon> it was said by TC members
17:27:11 <dschultz> yes, Go is a hot topic as far as community support. let's make sure we approach this the right way...
17:27:27 <dschultz> denismakogon: we do not yet have a blueprint on what you proposed, right? should that be an action item? maybe highlight the pros/cons
17:27:36 <denismakogon> Go language was decided to be accepted as second valid language for backend development in OpenStack, there are somethings that are requiring to be done in infra to support Go, but Swift already has feature branches that are including Go code
17:27:47 <denismakogon> dschultz: right
17:28:17 <denismakogon> i'll make spec by the next meeting
17:28:20 <dschultz> #action denismakogon to create blueprint for moving from Python to Go
17:28:23 <denismakogon> objections/recommendations?
17:28:30 <dschultz> awesome, added action item
17:28:47 <notmyname> good luck
17:28:50 <robputt> I personally object unless there is a real reason to use GoLang
17:29:34 <robputt> a good example is alot of OpenStack stuff hasn't been ported to GoLang
17:29:42 <robputt> e.g. Keystone-AuthMiddleware, Oslo Packages and so on...
17:29:49 <denismakogon> So, the thing is Picasso is fully mimics IronFunctions API plus two features - keystone auth and public/private functions
17:30:00 <robputt> I think a GoLang based service would be very alien to OpenStack deployers
17:30:47 <robputt> True, in it's current form Picasso is a proxy layer with auth for IronFunctions
17:31:05 <robputt> however proxy layers don't really need to be the same language as the underlying technology
17:31:09 <denismakogon> robputt: you are right, that's why we'll invest time into helping infra and oslo teams to build the same set of libs in Go
17:31:39 <robputt> Well, if we are willing to put in the work to bring OpenStack standard set of libs into GoLang
17:31:56 <robputt> and are happy to maintain them accross future releases then I guess its more of an interesting proposition
17:31:58 <rtrox> denismakogon what is the big selling point for a port to GoLang?
17:32:17 <robputt> but if we cannot commit to that, I think we are doing a disservice to the community by leaving them between a rock and a hard place with some Go stuff which gets out of date
17:32:19 <denismakogon> yes, in any case we'll align with all requirements to join big tent someday
17:33:00 <robputt> The reality is there are ALOT of oslo libs, and stuff like keystone-authmiddleware which ideally would need to be ported to Go and maintained for this to be a positive move
17:33:18 <rtrox> because so far, the "pro" that I've seen is just that ironfunctions is written in go, is there some functionality or use-case that is leading you to want a go rewrite?
17:33:44 <denismakogon> robputt: all of this will be done as complete Go integration
17:34:20 <robputt> I have to say Go worries me as a direction for the project
17:34:28 <robputt> its alot of overhead for not alot of gain
17:34:44 <robputt> and simply because IronFunctions is Go doesn't really mean Picasso should be Go too
17:34:54 <denismakogon> rtrox: we'd reduce amount of code, we'd reduce number of services to 1 service with pre-built load balancer
17:35:11 <robputt> Is there anyone from the community we can refer to to decide under which extenuating circumstances we should use an alternative language to Python?
17:35:39 <robputt> denismakogon: by moving this to Go, would is literally be absorbed into IronFunctions with 100% vendor lock in?
17:36:18 <denismakogon> IronFunctions is not vendor-locked
17:36:27 <robputt> no but Picasso is
17:36:52 <robputt> It's like saying "libvirt is not vendor locked so Nova should only have a libvirt driver and nothing else"
17:37:02 <robputt> the reality is what if someone wanted to use Fission behind Picasso?
17:37:12 <robputt> or dare we say it even a lambda driver if they so choose todo so?
17:37:47 <dschultz> well keep in mind IronFunctions is open-source, and the idea behind it is to get away from vendor lock-in like AWS
17:38:01 <dschultz> IronFunctions actually supports importing Lambda functions
17:38:31 <robputt> True I get this, but for me the vendor lock in should be at the Picasso level not at IronFunctions level
17:38:44 <robputt> as a precedent no other big tent API has lock in to a particular backend driver
17:38:55 <denismakogon> even with Fission, you can build a driver to IronFunctions
17:39:12 <robputt> I think you are missing the point here,
17:39:29 <robputt> in it's current form with Picasso you MUST use IronFunctions
17:39:35 <robputt> there is no freedom to choose and alternative
17:39:55 <robputt> I understand IronFunctions is opensource and so on, but the real thing behind FOSS software is freedom
17:40:04 <robputt> as well as being opensource
17:40:20 <dschultz> I think I follow robputt: but from an architecture view, it seems like a tall order to be able to support multiple platforms/frameworks, when the common denominator is the container execution engine, which should be pluggable
17:40:47 <robputt> to be honest, if we are simply adding keystone auth to IronFunctions
17:40:55 <dschultz> don't get me wrong, i agree with your comments and concern. just not sure how we can approach it
17:41:13 <robputt> I don't really think there is a project here, it may as well just be part of IronFunctions with the ability to turn on or off keysotne auth in the config file
17:41:37 <robputt> Well, we should look to Nova, Neutron, Cinder, Swift and so on
17:41:54 <robputt> to understand how they implemented multiple backend drivers
17:42:20 <rtrox> unless you're discussing the entire ironfunctions code base become part of not-picasso?
17:42:40 <robputt> Cinder is probably a good one to consider as there are lots of multiple vendor backends for Cinder
17:42:54 <robputt> from simply having the block device on a disk on a Linux box, to different SANs and NAS configurations
17:43:13 <robputt> I am confident if they can get multiple pluggable back end drivers for such an array of vendors, it can be done in Picasso too
17:43:27 <robputt> initially yes there may only be 1 backend driver, for IronFunctions
17:43:53 <robputt> but it should be a pluggable choice for the deployer to make in my opinion... and then maybe as a contributor I may add drivers for my preferred backend function running thingy...
17:44:16 <robputt> for sure atleast I'd like to see Fission and IronFunction backend drivers
17:45:09 <denismakogon> ok, so, the question is still open.
17:45:45 <dschultz> worth exploring this idea more. thanks for the input. i wanted to touch on 1 or 2 blueprint topics before going to open discussion (if time permits)
17:45:46 <robputt> yep
17:45:57 <robputt> I think we need a bigger input of opinion to resolve this one...
17:46:03 <dschultz> agreed
17:46:34 <robputt> the other option
17:46:39 <robputt> is to make IronFunctions as a thing
17:46:42 <robputt> OpenStack Functions
17:46:53 <rtrox> yea, that's what I asked above
17:46:53 <robputt> this way, they have a pluggable back end
17:46:54 <denismakogon> Let's assume that we'll have Picasso as is, we'd need to support oslo libs stack, i'd say that those libs are designed to work through evenlets
17:48:22 <robputt> denismakogon: I am not 100% sure what you are getting at here
17:48:43 <robputt> some stuff in Oslo is eventlet driven, such as some stuff in Oslo.Db project and Oslo.AsyncIO
17:48:54 <rtrox> me either, when we were talking about oslolibs we were talking about things like oslo.config, oslo.log, oslo.db, etc
17:48:56 <rtrox> yea
17:49:00 <rtrox> oslo.messaging
17:49:21 <robputt> but no all of oslo is eventlet based
17:49:29 <robputt> it depends if eventlet suits that particular libs use case
17:50:03 <denismakogon> Picasso doesn't use eventlets and it wouldn't use at all
17:50:20 <robputt> is there something in particular against eventlet?
17:50:25 <denismakogon> so, i see value in supporting oslo.log and oslo.config only
17:50:38 <robputt> there is a call for oslo.db not to use eventlet
17:50:56 <denismakogon> robputt: yes, why do we need eventlet if we have native event loop with uvloop policy?
17:51:19 <robputt> well, does everything want to wait for the loop?
17:51:25 <robputt> thats the question, it is really down to usecase
17:51:28 <dschultz> ##info discussing Oslo libs
17:51:36 <dschultz> #link https://blueprints.launchpad.net/picasso/+spec/oslo-config
17:51:39 <dschultz> #link https://blueprints.launchpad.net/picasso/+spec/oslo-logging
17:51:47 <rtrox> and actually eventlet is optional in oslo.db https://github.com/openstack/oslo.db/blob/master/oslo_db/concurrency.py#L60-L66
17:52:26 <denismakogon> if oslo.db would support fully async operations through async/await we'll come back to it, before that it's suitable
17:53:21 <denismakogon> oslo.db does not support asyncio API and it's blocker
17:53:29 <robputt> I think we are missing the point here
17:53:38 <robputt> Oslo.Db is designed to be deployed accross many diverse environments
17:53:43 <robputt> with varying Python versions etc...
17:53:52 <rtrox> and varying backend drivers
17:53:55 <robputt> I beleive async and await is only really around since either Python 3.4 or 3.5?
17:53:58 <rtrox> to various backend DBs
17:54:09 <denismakogon> Picasso is Python 3.5+
17:54:26 <robputt> There are alot of OpenStack deployers out there who deploy old versions of Python, old OpenStack versions
17:54:38 <robputt> in the operators space I don't know anyone who is firmly using Mitaka yet
17:54:52 <denismakogon> so, before oslo.db will support asyncio API, we'd build an abstraction to support more than one DB if needed
17:54:55 <robputt> lots are still on Kilo and Liberty and running Python 2.7.2 across their environment
17:55:23 <robputt> so, I would like to understand here
17:55:54 <robputt> is the async stuff in > Python 3.5 and absolute requirement for Picasso (and if so why?) or is it just more convenient?
17:56:37 <denismakogon> Picasso was designed to work over asyncio API to provide pretty fast layer in from of IronFunction to get function execution proxying fast as possible.
17:57:27 <denismakogon> robputt: absolute requirement
17:58:12 <denismakogon> let's move this discussion to Slack or IRC, we're running out of time
17:58:26 <denismakogon> dschultz: let's move to next topic
17:58:49 <robputt> yep lets move on
17:59:05 <dschultz> The last blueprint update I'd like to cover is async  tracking: #link https://blueprints.launchpad.net/picasso/+spec/async-tracking
17:59:14 <robputt> yep
17:59:14 <dschultz> we are tracking that here #link https://github.com/iron-io/functions/issues/415
17:59:20 <robputt> so
17:59:26 <robputt> this i think is already covered in IronFunctions
17:59:33 <robputt> if I send a non blocking execution
17:59:45 <robputt> it returns some ID which I can poll against for the result of the function
17:59:57 <robputt> but that ID does not appear to be proxied back to Picasso
18:00:03 <denismakogon> robputt: not really, tracking is available while function runs, its status is not available when async execution is finished
18:00:03 <robputt> and there is no way to poll a result in Picasso
18:00:40 <robputt> ok
18:00:56 <denismakogon> robputt: IronFunctions doesn't have an API to track specific execution rather than querying all statuses
18:00:58 <robputt> so how do you get results from a function run which is non returning?
18:01:12 <robputt> unless you implement some call back yourself in the function?
18:01:25 <denismakogon> robputt: for now, there's no such capability
18:01:29 <dschultz> see the PR linked above. IronFunctions team is working on a solution for this.
18:01:32 <dschultz> sorry guys, running out of time here. we can continue in our channel
18:01:38 <robputt> ok
18:01:38 <denismakogon> dschultz: right
18:01:42 <robputt> lets move to openstack-functions
18:01:44 <dschultz> thank you all for attending! sincerely appreciate your input!
18:01:47 <dschultz> #endmeeting