17:01:21 #startmeeting murano 17:01:22 Meeting started Tue Jun 2 17:01:21 2015 UTC and is due to finish in 60 minutes. The chair is serg_melikyan. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:26 The meeting name has been set to 'murano' 17:01:30 o/ 17:01:42 Hi folks, today is awesome day :) 17:01:54 We have 2 new core reviewers in our team :) 17:01:56 gday =) 17:02:05 kzaitsev - congrats! 17:02:12 o/ 17:02:24 0/ 17:02:42 yay! 17:03:23 o/ 17:03:36 sorry for being l8 guys 17:04:29 hi 17:05:35 I'm going to quote Uncle Ben: With great power comes great responsibility =) 17:06:17 hi! 17:06:21 hi 17:06:25 FilipBlaha: My congrats!! 17:06:45 Thanks:) 17:07:21 Let's get started :) and proceed with my minute of shame :) 17:07:33 #topic Action Items Review 17:08:05 http://eavesdrop.openstack.org/meetings/murano/2015/murano.2015-05-26-17.02.html - meeting minutes from previous meeting 17:08:32 #1 sergmelikyan create a doodle to select date for overview meeting 17:08:58 Was not able to do that :( 17:09:07 I promise tomorrow we will be voting :) 17:09:14 #action sergmelikyan create a doodle to select date for overview meeting 17:10:21 #topic Roadmap for Liberty 17:10:37 Folks, we still don't have a clear roadmap on our wiki 17:10:45 https://wiki.openstack.org/wiki/Murano/Roadmap 17:11:27 We already have several BPs that we agreed (at least initially) to work on during the liberty cycle, let's gather them in one etherpad and assign to the milestone 17:11:31 any thoughts? 17:11:35 and do we have clear roadmap in general? 17:12:40 katyafervent2: it OpenStack :) Starting from liberty was decided that we don't need to assign BPs to milestone, but I still think that it is usefull 17:13:45 * serg_melikyan searching for the e-mail with announcement 17:14:28 http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg53892.html 17:14:45 ^ Liberty release management and tracking 17:15:21 so huge :) 17:15:50 Read only TL;DR: section ) 17:17:04 So what about creating etherpad and putting there BPs? No objections? 17:17:59 No 17:18:07 no 17:18:39 To discuss - may be. Then we need to move them to wiki 17:18:44 #link https://etherpad.openstack.org/p/murano-liberty-etherpads 17:19:05 #info we will gather BPs in etherpad and move them to Wiki 17:19:10 ativelkov: sure, that is idea 17:19:52 #link https://etherpad.openstack.org/p/murano-liberty-bps 17:19:56 Correct link ^ 17:20:34 Does it mean, that any BP, that we want to implement in liberty should go to the etherpad? 17:21:21 kzaitsev: may be not all of them, but we need to start with biggest ones to form our Roadmap 17:22:40 got it. Actually... The fact that we have to add BP's for Liberty in an etherpad kind of means, that launchpads ui fails =(( 17:23:31 kzaitsev: not exactly - only drivers may add them to launchpad, but not only drivers propose bps 17:23:41 nevertheless will do. =) I've got a couple of smaller ideas, that are yet to be filed as BPs. 17:23:41 launchpad ui has been failing for a long time 17:24:19 but the etherpad is just a quick starting point 17:24:39 we will not rely on it for the whole cycle: it's just a document for the next meeting 17:25:02 ativelkov: you read my mind :) Scary :P 17:25:13 serg_melikyan: that's exactly my point. There's no convinient way to filter BPs. =) Not ranting anymore =) 17:28:06 kzaitsev: there are a bunch of scripts which may be used for various kinds of batch operations in LP 17:28:12 #topic Open Discussion 17:28:31 Any topics to discuss for today? 17:29:18 FilipBlaha: We discussed number of topics on the summit - do you plan to convert them to BPs on launchpad? 17:29:20 wanted to gather some requirest on what do people want from the next generation of package repo 17:30:05 FilipBlaha: https://etherpad.openstack.org/p/murano-liberty-contributors-meetup <- I mean these 17:30:27 oh! I have a question. How about we drop py26 and start supporting py34? I've written a letter today to murano, but since everyone's here.. 17:30:29 ativelkov: I think it's better to start mailing thread about that 17:30:49 serg: Radek is working on that but I am no sure right know. I will discuss it with him tomorrow 17:30:58 kzaitsev: nope :) We should not drop py26, and I am all for py3 job 17:32:14 Why not drop py26? only python-muranoclient uses it right now, not even agent is guaranteed to be py26 compatitable. 17:32:42 kzaitsev: did you read e-mails from me and Alex? 17:32:52 oh. sry. will do. 17:34:22 Ok. Got it. Client is going to be py26 compatitable, and i'll look into py34 some time soon 17:34:56 kzaitsev: the general idea is that "normal" openstack services are supposed to live in "normal" environments, which are usually up-to-date etc 17:35:18 Agent is supposed to run in VM, which means that we have even better control over its env 17:36:17 but clients are going to be used in ANY envs, including the legacy ones 17:36:56 ativelkov, yeah, now I see the difference, thanx! 17:37:39 BTW, there is an issue in yaql1.0 under py26 17:38:04 it fails couple of tests on its built-in functions 17:40:23 and I had some issues with yaql 0.2 when launching murano under py34 today. =) This is going to be a rather fun feature to implement I guess =) 17:40:57 kzaitsev: we need to upgrade python-muranoclient to newer versoion of YAQL 17:43:22 and release client again?) 17:43:56 why not? 17:44:29 just asking 17:45:18 "release early, release often" =) 17:50:15 Looks like we exhausted topics for today :) 17:50:19 #endmeeting