16:03:52 #startmeeting Fuel 16:03:53 Meeting started Thu Apr 16 16:03:52 2015 UTC and is due to finish in 60 minutes. The chair is kozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:03:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:57 The meeting name has been set to 'fuel' 16:04:04 #chair kozhukalov 16:04:05 Current chairs: kozhukalov 16:04:15 is anybody here? 16:04:19 hi 16:04:20 hi 16:04:21 hi 16:04:24 hi 16:04:26 hello 16:04:32 hello 16:04:44 great 16:04:53 o/ 16:05:01 hey! 16:05:05 tiny announcement 16:05:18 hi 16:05:52 yesterday dpyzhov wrote the letter where suggested to cancel our meeting 16:06:14 looks like current format is not the best what we can have 16:06:52 so, my suggestion is to continue running this meeting 16:07:08 but we definitely need to change its format 16:07:35 what format do you propose? 16:07:36 and in the end of this meeting i'd hear your ideas guys on this 16:08:00 let's start from first topic 16:08:07 it is more important 16:08:26 #topic Need help on this https://bugs.launchpad.net/fuel/+bug/1444459 16:08:29 Launchpad bug 1444459 in Fuel for OpenStack "Boot sector signature not found in case with changed disks configuration for Ceph node" [High,Confirmed] - Assigned to Vladimir Kozhukalov (kozhukalov) 16:08:58 short: a node is successfully provisioned but then it is unable to boot 16:09:18 why? 16:09:42 what is bad is this bug appeard 3 times today on the scale lab 16:09:51 i don't know 16:10:10 a month ago we fixed similar bug 16:10:26 but we managed to reproduce it in VMs? 16:10:33 the reason was that a node was rebooted using sysrq 16:11:05 yes, Nastya managed to reprduce it on her lab 16:11:10 on vbox 16:11:34 actually any ideas what it could be are welcome 16:11:40 may be we should run sync before sysrq? 16:11:55 why would we run sysrq, and not reboot? 16:12:27 i mean, we install image on a node, we check its md5, everything is ok, then we mount it and run grub-install in chroot 16:12:55 grub is installed (according to log) but then a node can not boot 16:13:19 this time is not sysrq 16:13:30 likely not sysrq 16:13:33 not sure 16:13:40 do you have that node to take a look if actually there is a grub installed / other stuff saved? 16:13:46 it was previous similar bug 16:14:26 there is should not be any magic, if data is correct on disk then it would boot 16:14:34 sounds like data is not correct 16:14:36 yes, the problem is this bug is floating 16:15:00 then question is whether data was not completely saved before reboot, or corrupted during reset 16:15:10 yes 16:15:12 did it run grub on the wrong disk? 16:15:25 but what could damage the data? 16:15:45 running sync before is not going to help 16:15:58 may it be related to disk caches? we can add few sync() calls in fuel-agent to be sure that we've asked system to sync data. 16:16:00 because afaik sync flushes file systems 16:16:20 disk cache? 16:16:21 mwhahaha: we install grub on all disks 16:16:38 but an orderly shutdown/reboot does trigger a cache flush AFAIK 16:16:40 mihgen: what do you mean? hardware cache? 16:16:48 yes 16:16:55 docaedo: yes 16:17:20 i believe we need even more detailed loggin 16:17:40 not sure if any logging would help if it's hardware cache 16:17:59 we just need to ensure that we do a trigger to cache flush 16:18:18 sorry, trigger a cache flush I meant 16:18:42 mihgen: i mean we probably need kinda debug mode which will read some data from disk and compare them with some patterns 16:18:48 kozhukalov: did you see what was actually corrupted? 16:19:19 have not had a chance to go deep into this 16:19:56 any ideas what command should i run to trigger disk cache? 16:20:29 can we temporarily at least replace sysrq with shutdown/reboot? 16:21:07 google says: echo 3 | sudo tee /proc/sys/vm/drop_caches 16:21:11 ok, i am going to try to reproduce this on my lab, and do some research on this, but any assistance is really welcome 16:21:57 mihgen: ok, nice, will read about this 16:22:02 kozhukalov: http://stackoverflow.com/questions/9551838/how-to-purge-disk-i-o-caches-on-linux 16:23:22 ok, i think right now we can not end up with something working 16:23:27 not sure if this bug is related to virtual envs only. Have anyone able to reproduce it on real hw? 16:23:56 agordeev: scale lab 16:24:02 3 times today 16:25:10 they are able to reproduce, but unfortunately it is extremely inconvenient to do research on their lab 16:26:11 due to long response delay 16:26:18 ok moving on 16:26:40 #topic Weekly meeting format: suggestions, ideas, whatever 16:26:42 scale lab is not the right place for research :9 16:27:18 like i sad many people are not happy with our current meeting format 16:27:31 s/sad/said/ 16:27:37 sad, too :) 16:28:11 and the idea is to stop forcing people to attend and share their development statuss 16:28:43 let's try making our meeting more like hacking forum 16:29:19 I would add couple of weekly items which will be on agenda if there is nothing more, something like "hot topics of the week" and "bug trends of the week" 16:29:23 i mean any news, features, other interesting points 16:29:49 This will create the initial impulse for further discussions 16:29:49 I'm afraid this will deteriorate this meeting even further, you'll end up talking to yourself 16:29:55 well maybe to me :p 16:30:03 bookwar: ok, and who is going to prepare this? 16:31:06 Script 16:31:35 angdraug: what exactly? i mean it impossible to understand which statement you are trying to argue 16:32:00 I mean, if we stop discussing development status 16:33:04 yes, but currently we are trying to discuss dev status with couple people 16:33:26 no one interested in reporting their status here 16:33:42 maybe we should fix the reason why they're not interested? 16:33:49 cause we have plenty of other channels 16:34:10 what is the reason in your opinion? 16:34:15 instead of avoiding the problem and trying to invent meaning for what you aptly called a cargo cult 16:34:32 if everyone feature lead would report their status here, then we would need more that 1 hour 16:34:43 and no one will be interested in reading all 16:34:44 we do have plenty of communication channels, and for some reason we're preferring not to use IRC 16:35:18 so it might make sense to keep meeting for smaller group actually 16:35:18 and somehow we use slack… 16:35:36 when everyone is involved in the discussion 16:35:37 should we move status updates to ML then? 16:35:44 mihgen: what if we focus on those features which are more likely interesting to community 16:36:02 alex_didenko: that could be helpful 16:36:22 kozhukalov: for instance. but again, if it's gonna be broad - 16:36:39 it won't fly, as some people will be sitting un-interested in reading all 16:36:40 barthalion: you're right, I think introducing slack has contributed to the shift away from irc 16:37:04 still, we had the same problem with skype before: 16:37:06 slack, irc, skype, hangout, email - of course it's too much 16:37:34 angdraug: I think it's not the main reason though 16:37:41 despite many calls to use open channels for everything that doesn't contain secrets and passwords, people stuck to the closed communications channels 16:37:49 main reason is audience. Now it's like for all about nothing 16:38:03 it's one of the reasons, a lot of things is discussed internally even if it could take place on freenode 16:38:17 audience is a very good way to highlight the problem 16:38:23 we shouldn't using irc "for audience" 16:38:24 so if we, let's say, focus on one certain area - let's say underlay networking 16:38:26 so when we start to actually have an audience, nobody will even care about irc 16:38:40 perhaps the irc meeting should be more focused on bugs, community/impacting issues and conversations around feature changes? 16:39:15 my favorite idea was discussion about what's new in openstack community and how it may affect or may be integrated into fuel 16:39:21 also, would be great if we could actually move new bug notifications from #fuel-dev 16:39:24 mwhahaha: again, most of attendees will be silent all the time, as we have so broad expertise 16:39:44 still, I maintain that changing the meeting format is secondary to figuring out its purpose 16:39:59 angdraug: +1 for news in Openstack and how it affects us 16:40:00 it generates useless noise that nobody pays attention to 16:40:10 barthalion: +1, move all the bug notification to slack, for example. To keep IRC chat clean 16:40:18 barthalion: I would agree actually, I think bug reports introduce too much noise in fuel-dev now. 16:40:26 separate channel in IRC is Ok 16:40:28 One of the reasons IRC meetings started in the first place for open source projects 16:40:31 (as far as I can tell) was to gather together folks who were normally spread all 16:40:34 around in different time zones, to quickly come to consensus on issues. When we need 16:40:37 that now, it happens either on openstack-dev ML, or on internal mailing lists. 16:40:54 docaedo: again to gather around single issue 16:41:12 we ended up with having too broad topics at the same place at the same time 16:42:01 for openstack news, you would need people preparing the news 16:42:01 I think part of the reason why there is low participation on IRC is that nobobdy waits around to discuss stuff here. When there's an issue, we discuss on email and get the attention it needs 16:42:19 I still think the goal of the meetings is to discuss issues / blockers / live chat on things that are not carrying well on the ML. Its ok that we don't need the full hour, but It should not limit participation 16:43:42 xarses: the problem is that when we have an issue we can not wait until next meeting 16:44:10 we usually ping a right person in slack or skype or email 16:44:43 I strongly believe that organizing meeting for some community is wrong. We _are_ the community, and we need to organize meeting for _us_ first, and then if there will be external part - that's OK, but if not - so be it. Talking about phantom community just kills all the real motivation, because you start to consider the meeting to be the showroom and not the real thing. 16:45:09 bookwar: +1 16:45:11 mihgen: actually we have weekly news reports 16:45:15 what I'm wondering about is how to determine what should "wait" for IRC meeting. This is great for situations that need real-time participation, but in general, nobody waits to discuss things, we just reach out and start the conversation... 16:45:16 you don't start, it became a showroom already 16:45:24 people are pasting their statuses 16:45:26 but they are more wide then just openstack 16:45:47 we have people spread out across world right now 16:46:01 we don't have a meeting where all fuel-library folks would be at the same time, for instance 16:46:24 so if we focus around smaller area, like fuel-library, and get everyone once a week in a text mode, that might be good 16:46:41 also, said that, participation isn't the easiest thing when meeting is starting 6PM, and I finish work 2 hours earlier 16:46:42 pasting the status if fine, it saves time, and is useful as a starting point of a discussion, IF people are interested 16:47:28 but I guess it's price of being international 16:48:14 ok, let's try to summarize 16:48:19 I thought current timing is actually pretty convenient for everyone whom we have (UA, RU, PL, US-east/west) 16:48:23 angdraug: it saves time, and makes the whole thing somehow creepy, as it looks like meeting with my manager 16:48:39 it's not only my opinion 16:48:48 mihgen: I don't think there is a convenient time for all our time zones :) 16:48:50 also, the other thing, people often have nothing to say 16:48:54 I'll let your manager know you think he's creepy ;p 16:49:17 all meetings are creepy when you come from non-business open source :p 16:49:55 I'm not a feature lead, so I don't really know what topics I'm supposed to put in agenda 16:50:20 1) we are community and this meeting is not showroom 16:50:39 2) reporting status makes meeting more like meeting with managers 16:51:08 so something that the opnfv folks where doing was running irc for links, but audio for their actuall meeting 16:51:08 3) potentially we could discuss news (fuel and openstack related) 16:51:24 we could report statuses just to openstack-dev 16:51:45 +1 for reporting statuses to openstack-dev 16:51:59 if a particular status kicks off a discussion it can be carried over into irc meeting 16:52:06 this news thing seems not useful 16:52:46 4) meeting is good for syncronous discussions but usually can not wait until next meeting if we have something to discuss 16:52:47 +1 angdraug on discussing something in IRC if it seems like a lot of people have much to say on something 16:53:04 and +10 on reporting statuses on openstack-dev 16:54:16 I want also to point out that usually questions are left unanswered on #fuel-dev 16:54:29 and #fuel 16:54:36 barthalion: xarses: +1 16:54:41 I don't think it should happen, but I don't really have knowledge to help 16:54:49 that's what I was trying to say in the beginning: we're not using irc as much as we should 16:55:04 ok, what do you guys think, do we need this meeting at all, or maybe it is better to take a break and see if we will miss it? 16:55:11 another problem I see is that we have too many channels 16:55:13 it seems most people shuffled to slack and have forgotten irc 16:55:40 #fuel-{devops,osci} should really be merged with #fuel-dev 16:55:52 barthalion: in both ways? 16:56:02 what do you mean? 16:56:16 yes, both in irc and slack 16:56:43 no idea about slack 16:57:00 yes, we have too many channels in irc and even more in slack 16:57:01 not sure about slack, but definitely +1 for merging in IRC and removing bot from there 16:57:10 #startvote Do we need to take a break and stop running this meeting? 16:57:11 Begin voting on: Do we need to take a break and stop running this meeting? Valid vote options are Yes, No. 16:57:12 Vote using '#vote OPTION'. Only your last vote counts. 16:57:13 but if I'd be external contributor, I'd go postal when someone would tell me I need to go to #fuel-foobar to achieve something 16:57:28 #vote yes 16:57:32 #vote yes 16:57:35 #vote No 16:57:55 or actually… 16:58:00 #vote no 16:58:01 #vote no 16:58:10 #vote no 16:58:10 #vote no 16:58:11 #vote no 16:58:15 #vote no 16:58:25 #vote no 16:58:37 #vote no 16:58:39 #vote no 16:58:59 ) 16:59:09 ok, looks like majority of attendees are for continuing this meeting 16:59:37 I'm still insisting on having themes per meeting 16:59:44 I think we need to fix our openness (including this meeting), not abandon it 16:59:45 so, let's make it more interesting, don't hesitate to add your topics to agenda next week 16:59:57 time is over 16:59:58 let's say , one week is about networking, another week is about plugins, etc. 17:00:03 let's discuss it on mailing list 17:00:06 thanks everyone 17:00:10 thx 17:00:10 closing 17:00:14 bye 17:00:17 #endmeeting