17:01:04 #startmeeting murano 17:01:05 Meeting started Tue Jul 7 17:01:04 2015 UTC and is due to finish in 60 minutes. The chair is kzaitsev_mb. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:06 o? 17:01:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:10 The meeting name has been set to 'murano' 17:01:11 o/ 17:01:15 o/ 17:01:17 hi all 17:01:20 o/ 17:01:26 o/ 17:01:30 hi) 17:02:33 I'd like to start with the elephant in the room, and say, that we currently have some problems with dsvm job. freerunner and I are looking into it, but we would appreciate any help from you guys =) 17:02:44 hi 17:03:03 hi! 17:03:20 We skiped our prev meeting, cause we had no agenda and no action items 17:03:30 so there's no point in reviewing that 17:03:55 But I've added a couple of items, I'd like to discuss to todays meeting agenda 17:03:56 :d 17:04:15 #topic Spec review process 17:05:42 1) I'd like to ask everyone to review specs more. Some of us tend to dismiss a patchset if it has -1 from someone. 17:05:53 I believe that should not be the case for spec reviews 17:06:22 agreed here 17:07:09 specs has many points to discuss always, so -1 from someone couldn't be a real marker of something bad 17:08:48 I'd like to remind, that L-2 is around the corner, and I believe we have only merged a spec or two =) 17:09:13 Really hope, that we'll improve the situation soon 17:09:42 will it help if I split my spec to 2 specs? :) 17:09:53 which one mgershen? 17:10:05 https://review.openstack.org/#/c/198559/ 17:10:23 Which brings me to the second point about specs — shouldn't we introduce something like a spec-freeze? A date, after which no specs would be merged? 17:11:56 I am considering splitting it anyway, since i would like to start working on what is agreed on 17:12:25 nova has it (and it actually happened last week I think). The reasoning is that reviewing specs takes a lot of time, and having a deadline would encourage people to work on specs faster and possibly review them more. 17:12:28 mgershen: I think this spec shouldn't be split to 2. it looks consistent 17:12:36 kzaitsev_mb: I agree with you here. 17:13:04 I think splitting in 2 is a good idea 17:13:33 kzaitsev_mb: but we have a some kind of rule set for this freeze 17:14:15 I'm not really sure, that we should agree on such a measure, when our PTL is on a vacation, though +))) 17:14:52 :D 17:15:20 we can just collect views 17:15:30 I generally like the idea to have a spec-freeze at l-2 (and later at m-2 and so on). 17:15:34 without an official poll 17:16:14 Let's discuss it in ML then 17:16:45 sure 17:17:01 #action kzaitsev start spec-freeze discussion in ML 17:17:54 #topic dropping db downgrades 17:18:09 Next topic then 17:19:14 I've been looking through bugs for l-2 and stumbled upon this one https://bugs.launchpad.net/murano/+bug/1399151 17:19:14 Launchpad bug 1399151 in murano "Error during execution of database downgrade" [Medium,Confirmed] 17:19:50 Recently some of the OS projects have dropped db downgrades completely, AFAIK 17:20:04 nova and glance, to name the few (I might be wrong though) 17:20:07 kzaitsev_mb: neutron for example 17:20:24 and I think sahara 17:20:51 Nikolay_St: so it looks like a trend =) 17:21:10 kzaitsev_mb: yeap, it's one of the latest community practices 17:21:16 + for dropping 17:21:16 and we should follow 17:21:26 +1 17:21:39 +1 17:21:51 +1 17:21:59 +1 17:22:16 +1 as well 17:22:20 I wanted to start a vote, but looks like everyone agrees anyway =) 17:22:56 for sure 17:23:08 kzaitsev_mb: so, for official, u can start vote =) 17:23:47 freerunner: I think I'll just add agreed hash-tag to save us some time =) 17:24:34 #agreed we decided to drop support for migration downgrades 17:25:05 We should update our docs accordingly, I guess then =) 17:26:04 and the last topic for today, then 17:26:14 #topic nightly builds 17:27:12 I'm not sure if it is possible, or even a good idea, but it seems, like a nice idea to check our stable branches from time to time? 17:28:04 The idea came from some discussion in horizon (it was rejected there though, but the purpose was different there) 17:28:34 we had this idea for a long time 17:29:22 The idea is to have a nightly build of every stable branch of every of our projects. This should help us detect gate blocks sooner, since stable branches are not updated that often. 17:30:46 StanLagun freerunner aderyugin is it even possible with current jenkins infrastructure? 17:30:49 Even though I like the idea, I haven't seen anything like that in any project =( 17:32:18 kzaitsev_mb: You mean dsvm jobs, yep? 17:33:12 freerunner: something like that. The easiest and dirtiest way to do this would be to push a commit for review, but I dislike this approach for obvious reasons ) 17:34:40 So I suppose no one really does it, right? 17:35:26 kzaitsev_mb: I think nope. 17:36:43 this means we can be first =) but also means that it would probably be a lot of work to setup such a system nicely =( 17:39:18 Does anyone want to volunteer to investigate how we can do such a thing? =) 17:39:24 I guess no one =) 17:39:25 ok I'll do it then 17:40:15 #action kzaitsev look for a way to run periodic nightly builds of stable branches 17:40:41 I'll try to contact infra guys, we can't be the first team to want a thing like that =) 17:41:04 ok, so we're out of topics, moving to open discussion 17:41:11 #topic Open Discussion 17:43:05 A thing I've noted about previous guys meeting (containers) — is that they have permanent links to their agendas. And they link them during meetings. I'll try to adopt that approach during our next meeting =) 17:43:58 sounds cool :) 17:44:15 Hm, I remember that we wanted to make some mid-cycle virtual meetup. 17:45:28 Is the idea dead? I belive Serg was the one driving it though. 17:46:20 kzaitsev_mb: I've think we can discuss this, when Serg goes back from vacation =) 17:46:31 *I think 17:47:07 freerunner: yep. sounds good 17:50:08 looks like we can finish a bit early 17:50:34 looks like my client was kicked off from channel :( 17:50:39 kzaitsev_mb: One more sec =) 17:51:11 kzaitsev_mb: I have one idea for next meeting. We can discuss a better versioning of muranoclient. 17:52:10 freerunner: let's add it tour next meeting agenda then. 17:52:27 I'll update it accordingly. 17:52:46 #idea (by freerunner) discuss a better versioning of muranoclient 17:53:04 kzaitsev_mb: Cool =) 17:53:54 freerunner: it would be nice if you would prepare some write up beforehand, so that everyone could read it, though =) an etherpad would be awesome. 17:54:19 *short writeup =) 17:54:32 kzaitsev_mb: Sure ;) 17:57:07 ok, before time runs out. I'd like to remind everyone (even non-core developers) to review https://review.openstack.org/#/q/status:open+project:openstack/murano-specs,n,z some specs, and do so even if there is a -1 from someone there. 17:59:40 let's end the meeting =) I believe it was rather productive =) 18:00:05 #endmeeting