16:00:42 #startmeeting Fuel 16:00:43 Meeting started Thu Mar 26 16:00:42 2015 UTC and is due to finish in 60 minutes. The chair is kozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:47 The meeting name has been set to 'fuel' 16:00:50 #chair kozhukalov 16:00:51 Current chairs: kozhukalov 16:01:00 hey guys 16:01:03 hi all 16:01:04 o/ 16:01:06 hello 16:01:10 agenda as usual 16:01:20 #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda 16:01:36 is anybody else here? 16:01:39 hi 16:01:44 hi 16:01:55 hi 16:01:59 great at least 6 persons 16:02:07 let's start 16:02:09 hi 16:02:09 hi, 7 now 16:02:11 hi 16:02:15 o/ 16:02:21 #topic External ubuntu mirrors and pinning (ikalnitsky, brain461) 16:02:29 o/ 16:02:45 i'm glad to announce that consume-external-ubuntu feature is in master. it finally merged. 16:02:52 +1 16:02:57 though, there are some improvements we have to do 16:03:14 ikalnitsky: including? 16:03:29 for instance, we should allow users to change repos after deployment 16:04:07 or we should add some warning banner that he need additional steps to run his ubuntu cloud 16:04:32 except this, we have issues with apt-pinning 16:04:52 currently, we're using pin template (which is hardcoded in Nailgun) 16:05:08 also build image script needs to be re-written in python and even more today bvt failed because of this script 16:05:17 btw, floating bug 16:05:31 and it may lead us to some issues, when the remote repo has another.. properties 16:05:32 we are working on improving this part 16:05:34 attributes 16:05:49 looks like that's it from my side. 16:06:10 to change repos after deployment on master node or on all slaves? 16:06:13 and yeah, we obviously need to sync our jobs with patching story 16:06:25 maximov, on all slaves 16:06:42 for instance, user wants to add new nodes to existing env 16:06:50 ikalnitsky: why not simplify apt pinning preferences by not having separate entry for each component? 16:06:52 and his repos aren't available 16:07:07 we still have the same priority for all components in a single archive 16:07:32 angdraug, what do you mean exactly? 16:07:41 it looks like we misunderstood each other 16:08:00 you have separate pinning entries for main and restricted 16:08:04 both pinned at 1050 16:08:09 yep 16:08:20 it doesn't work in one entry 16:08:21 if you don't specify c=main explicitly, such entry would cover all components of an archive 16:08:49 angdraug: because we have template 16:09:19 angdraug: and it is not very beautiful to have ifs for plenty of different cases 16:09:33 now you've lost me 16:09:34 it is better to have a loop over all sections 16:10:11 guys, here's what we have for mos component 16:10:13 #link http://xsnippet.org/360594/raw/ 16:10:36 as far as i understand, angdraug means why do we have two pins declarations instead of one? 16:10:39 the issue with pinning now is that we are not able to have different priorities for different repos if they both have the same suite and the same section 16:10:40 am i correct? 16:10:49 and you could have: http://xsnippet.org/360595/ 16:11:18 angdraug, and what if i want to pin main from mos6.1 with another priority? 16:11:29 i just add additional repo 16:11:34 with exactly main section 16:11:40 and set another prio 16:11:49 different from restricted section 16:11:55 what i have to do then? 16:11:56 on my debian system, I have different pin priorities for stable, testing, and unstable 16:12:06 they each have the same set of sections 16:12:09 works fine 16:12:25 for debian yes 16:12:25 why would you ever want a different pin priority for main and restricted? 16:12:40 but sections are not fixed 16:12:47 angdraug, why not? it's possible technically 16:13:00 it doesn't cause any problems 16:13:43 the issue is that it looks like we don't have enough data for setting pinning properly 16:13:47 no, no immediate problems, just giving user more ways to shoot themselves in a foot, and making it harder to read the preferences file 16:13:58 url + suite + section is not enough 16:14:31 this is taking too much time, lets discuss it later 16:14:56 it looks like in the future it is better to download Release file and set pinning according to metadata in this file 16:15:07 yes 16:15:13 move on guys 16:15:22 if there are no other q let's move on 16:15:46 #topic IBP (agordeev, kozhukalov) 16:15:50 hi 16:16:05 I'll start with the listing of current IBP activites: 16:16:14 1) Rewriting fuel-image in python is in progress now. ETA 1w 16:16:16 2) Work on progress bar hasn't been started. We are going to ask some help from our fuel-ruby team on next week. 16:16:18 3) Pinning for image building process isn't finished yet. We are waiting for help from more experienced engineers. 16:16:20 4) Our ubuntu BVT is red for today due to fuel-image script breakage, I'm working on its fixing, ETA today 16:17:15 agordeev: is it still red? 16:17:25 i thought it is a floating bug 16:17:41 yep 16:17:45 i see that bvt are green 16:17:51 though ubuntu smoke is still red 16:18:07 ok, needs to be fixed 16:18:10 kozhukalov: i don't know. I'm fixing the script 16:18:13 agordeev, please ping devs for review when it's ready 16:18:22 it's important to merge it asap 16:18:22 ikalnitsky: sure, i'll do 16:18:39 the error was that build image script could not find loop device 16:19:24 agordeev: thanx for working on this 16:20:18 and looks like some people still don't see the advantages of IBP, i think we need to write kind of blog post maybe 16:20:28 ok, are there any other q? 16:20:59 kozhukalov: the advantages for users to be exact 16:21:35 let's skip next topic since aglarendil is not available right now 16:21:52 agordeev: yep 16:22:08 #topic Bugs status (dpyzhov) 16:22:37 dpyzhov_: how far are we from scf? how many bugs are there? 16:22:56 Well, we have five days until SCF 16:23:13 and we have a huge number of bugs 16:23:54 some of them are not actually bugs but feature requests. right? 16:24:06 about 700 confirmed bugs and almost 150 bugs in progress 16:24:38 We are trying to separate tech debt and feature requests from this list 16:24:51 I've added 'feature' tag for such stuff 16:25:22 'feature' means: this bug needs either proper design or it is not a bug at all 16:25:45 Also I'm not sure if we really have 150 bugs in progress 16:26:21 It's a really big number and maybe some of them are orphaned 16:27:05 any in progress bug that wasn't updated for more than a week is orphaned 16:27:27 I think that we really need to walk through 'feature' bugs and decide how to deal with them\ 16:27:31 any in progress bug that wasn't updated for more than a day is probably orphaned too 16:27:48 Most of this bugs are travelling from one release to another 16:28:20 are they attached to blueprints? 16:28:27 guys, what do you think of the idea to try to deal with loads of bugs using kind of bayesian algorithm? 16:28:43 write an AI to fix bugs? 16:28:45 at least for categorizing them 16:28:57 angdraug: yes, we should ping owners of hanged bugs. no, most of this bugs are just suggestions 16:29:26 angdraug: don't exaggerate me 16:29:34 our workflow for blueprints is even worse then our workflow for 'feature' bugs 16:29:36 kozhukalov: sorry, couldn't resist :) 16:30:04 I'm just not sure "feature" tag is necessary, we already have wishlist priority for such thing 16:30:29 I think that our list of blueprints was not revised for a long time 16:31:02 angdraug: actually some of 'feature' bugs represent real user pain 16:31:23 so we need to have priorities for this wishlist 16:31:24 if they are more important than a wishlist bug, they must have a blueprint 16:32:04 angdraug: maybe 16:32:37 angdraug: so your proposal is to start working with blueprints more carefully? 16:32:46 yes 16:33:09 maybe make it part of bugs triage duty, or have a separate duty 16:33:20 how are you guys able to read them? i mean do you sleep sometimes? 16:34:01 most of our blueprints only have a title, so not a big deal :p 16:34:15 all you need is ESP to read the mind of blueprint creator ) 16:34:30 -) 16:35:04 seriously, identifying bugs that should be associated with a blueprint should be a part of bugs triage 16:35:15 triaging blueprints themselves is an entirely different story though 16:35:45 but I don't see a way around it 16:35:53 angdraug: we have 381 blueprint 16:36:07 no so many, right? -) 16:36:15 holy smoke thats a lot 16:36:28 tbh we have even more product backlog items 16:36:54 so it's about 1000 user stories 16:37:12 most of them overlap, so probably more like 500 16:37:28 is there a chance we address them all somewhen before end of the Universe? 16:37:30 should we throw away half of them? 16:37:43 we're addressing several dozen in each release, don't we? 16:37:56 so we only got 2-3 years worth of user stories there 16:38:28 and yes, we should throw away some of them, but it's only part of the problem 16:38:29 angdraug: but we getting new stories faster 16:39:01 that's normal, as long as we have a process in place to prioritize them 16:39:24 which is exactly what product backlog is for 16:40:00 we do need something like that on the community side of the project, though 16:40:16 xarses: around? 16:40:27 ok, guys, maybe it is better to move our chatter to the open discussion 16:40:37 looks like we are done with bugs 16:40:39 so we should convert all 'feature' bugs to blueprints, add blueprints to the backlog and let backlog owners deal with it? 16:40:55 all feature bugs that are higher priority than wishlist 16:41:12 I think it's fine to leave wishlist bugs as just bugs 16:41:43 and keep them targeted at next instead of current release series, so that we don't have to move them every release 16:42:00 good point about 'next' release 16:42:08 +1 16:42:41 I'm tired of moving all the 'volume manager refactoring' bugs each release 16:42:47 ) 16:42:57 ok, moving on 16:43:09 #topic Open discussion 16:43:10 thank you, it was productive discussion 16:43:36 how about activities from US and Polish teams? 16:43:49 is there anything interesting? 16:44:32 angdraug: is there? 16:44:41 I hit a little bump with nailgun tests, but need to put more work to diagnose it and show eventual solution, so maybe I will have sth for agenda next week 16:45:13 mkwiek: great 16:45:34 looking forward 16:45:51 nothing interesting on the us side, rmoe is working on bugs, and xarses on openrc related cleanup 16:45:57 seriously guys, we need to share info between locations 16:46:49 dpyzhov_ angdraug what about merging this one https://review.openstack.org/#/c/155698/? 16:47:18 looks like enough +1s 16:48:03 this one is also have two +1 https://review.openstack.org/#/c/165537/ 16:49:06 kozhukalov: merged. both of them 16:49:09 one more time, if you guys have anything to share: status, issue, question, please don't hesitate to add this into agenda 16:49:30 it is extremely simple https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda 16:49:44 dpyzhov_: great, thanx 16:50:32 ok, looks like no one has anything more to discuss 16:50:40 ending then? 16:50:56 thanks everyone for attending 16:51:01 thanks! 16:51:07 #endmeeting