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