16:00:27 #startmeeting Fuel 16:00:28 Meeting started Thu Jul 17 16:00:27 2014 UTC and is due to finish in 60 minutes. The chair is vkozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:31 The meeting name has been set to 'fuel' 16:00:37 #chair vkozhukalov 16:00:38 Current chairs: vkozhukalov 16:00:39 Hi 16:00:48 hi 16:00:53 Hi Dr. Nick 16:00:55 o/ 16:00:55 #topic Greetings, announcements 16:01:25 #topic 5.1 feature freeze status 16:01:26 hi 16:01:35 hi 16:01:46 hi 16:01:52 dpyzhov: do you have any details on this topic 16:02:55 afaik we merged a lot of new code and found a lot of new issues 16:03:05 doesn't look like we have any changes WRT features since last week 16:03:17 bug numbers from the Tuesday's bug squashing are here: 16:03:17 #link https://docs.google.com/a/mirantis.com/spreadsheets/d/10mUeRwOplnmoe_RFkrUSeVEw-__ZMU2nq23BOY-gzYs/edit#gid=1298115632 16:03:39 thanx angdraug 16:03:47 we should be making this much progress everyday to fix enough high priority bugs by 5.1 release 16:04:12 mihgen proposed to have soft code freeze next thursday 16:04:33 current topic is feature freeze for 5.1 16:05:27 so, I will replace mihgen 16:05:59 we have almost all features merged into the master, except some of mlnx code 16:06:08 we are waiting for CI to pass for this code 16:06:30 there is a floating bug related to swift that breaks ubuntu CI pass 16:06:33 #link https://review.openstack.org/#/c/107749/ 16:06:58 as soon as it is merged we can retrigger jobs and if they pass - merge mlnx code into fuel-library 16:07:10 also, there is some code in merge queue for fuel-web 16:07:22 dpyzhov can provide update on it 16:07:36 aglarendil: what about NSX? did it land? 16:07:42 angdraug: yep 16:07:55 angdraug: also there is galera improvements code that we need to merge into fuel-library 16:08:19 yes a lot of requests in fuel-web are waiting to be merged 16:08:33 #link https://review.openstack.org/#/c/106516/ 16:08:42 it is also blocked by swift failure 16:08:52 xarses: can provide update on ML2 support 16:09:05 I see two unmerged mellanox reviews: https://review.openstack.org/#/c/106007/ and https://review.openstack.org/#/c/104501/ 16:09:37 All other mellanox code is in master 16:10:08 aglarendil: the last update in the ML is still correct. HA is still a problem because of OCF scripts and upstart are fighting to run the services 16:10:31 xarses: we do not know about this issue. you need to land override scripts for upstart 16:10:35 aglarendil wrote ^^^ that they are waiting for mlnx code to pass ci tests 16:10:53 vkozhukalov: I’m talking about fuel-web repo only 16:10:55 xarses: as we did in our code for other neutron agents 16:10:55 aglarendil: correct, that is the next step 16:11:07 xarses: in our current code it is already done 16:11:26 xarses: regarding swift bug, you can apply https://review.openstack.org/#/c/107749/ 16:11:31 dpyzhov: what about fuel_agent stuff? there are 3 requests 16:11:47 2 for fuel-main and 1 for fuel-web 16:12:01 aglarendil: the code in our puppet-neutron is very inconsistent with how each service is stopped, so I'm trying to work out how much beating each service needs 16:12:45 xarses: we are using two approaches: 1) disable default provider's management of services 2) add override files for upstart 16:13:14 3) use an exec to ensure that it's killed 16:13:35 xarses: this is pretty harsh way. I would not use it 16:13:47 We already do 16:14:01 which is why im iterating through how much 'beating' the services need 16:14:20 xarses: let's move it to follow up and discuss separately in fuel-dev after the meeting 16:14:25 yes 16:14:31 doesn't sound like ML2 is making it to 5.1 16:14:52 it's already past its FF exception deadline 16:14:57 I mean upstream ML2 16:15:31 angdraug: unless we do very thorough testing and merge it carefully 16:15:45 angdraug: but I would move it to 6.0 along with all the other upstream manifests merge 16:15:52 +1 16:16:08 moving on? 16:16:15 moving 16:16:17 also, upstream manifests merge is half completed 16:16:22 just a moment, guys 16:16:25 #link https://blueprints.launchpad.net/fuel/+spec/merge-openstack-puppet-modules 16:16:27 #topic 5.0.1 release status 16:17:00 we still have 2 bugs blocking 5.0.1 afaiu: 16:17:11 #link https://bugs.launchpad.net/fuel/+bug/1342719 16:17:13 Launchpad bug 1342719 in fuel "Rabbit is unavailable" [Critical,Confirmed] 16:17:16 #link https://bugs.launchpad.net/fuel/+bug/1305826 16:17:18 Launchpad bug 1305826 in fuel/5.1.x "Swift Ringbuilder rebalance fails" [Critical,In progress] 16:17:30 anyone got update on those 2? 16:17:58 I have 16:18:04 the first one should be addressed by oslo.messaging patch 16:18:12 which is under development and testing now 16:18:22 it should have been by previous 2 versions of that patch 16:18:43 it requires more work as it seemed 16:19:04 #link https://bugs.launchpad.net/fuel/+bug/1340711 16:19:08 Launchpad bug 1340711 in fuel/5.0.x "[OSCI] building oslo-messaging for rpm and deb" [Critical,In progress] 16:19:08 is this the same thing? 16:19:33 looks like 16:19:44 also, why is #1305826 different priority for 5.0.1 and 5.1? is it critical in 5.0.1 or not? 16:19:59 angdraug: it is not breaking current deployments 16:20:08 angdraug: but may if puppet changes ordering of resources 16:20:11 do we need to sqash those bugs? 16:20:14 angdraug: and it is blocking CI now 16:20:26 there is fix available already 16:20:40 #link https://review.openstack.org/#/c/107767/ 16:20:43 anyone from QA around? 16:21:24 yes 16:21:28 is ISO #135 our RC2? 16:21:42 latest comment on the rabbitmq bug is that it's fixed there 16:21:55 if it is, I think it should be the RC2 16:22:02 looks like no. because we wait new iso with oslo path 16:22:22 if it's not, then we need to make another ISO and that means we can as well merge the fix for swift ringbuilder bug 16:22:23 path only in custom repo 16:22:49 yes, fix for swift we can merge 16:22:56 thanks! 16:23:16 uw) 16:23:23 summary for 5.0.1 status: 2 more fixes to merge before we can build an RC, links above 16:23:49 ok, moving 16:24:05 #topic LP tags vs [tags] in bug summary vs LP karma 16:24:29 rmoe: around? 16:24:34 he's typing 16:24:34 yep 16:25:01 starting tuesday (maybe?) I noticed a whole bunch of title updates adding free-form tags like [nailgun] 16:25:03 I like duplicate of [tag] and tag 16:25:05 1. why are we doing this? 16:25:09 2. why was there no discussion of this? 16:25:37 launchpad already has tags so adding [tag] to everything seems dumb 16:25:53 it also breaks email update threads 16:26:07 yes 16:26:09 yes, it is a little bit strange 16:26:22 and takes away horizontal space from bugs table that could be used for information that's actually useful 16:26:27 and all free-form tagging systems devolve into messes of 20 variations of each tag 16:26:34 I'd rather have a short and descriptive title than a mix of tags 16:26:41 especially if there's more than 2 of them on the bug 16:27:19 proposal: let's stop doing this for now and have a discussion on ML 16:27:32 +1 16:27:33 I agree. 16:27:34 does launchpad allow to delete tags we think are not needed? 16:27:39 of course 16:28:14 automatically? api? 16:29:02 or we need to go through all bugs and remove [tags] manually? 16:29:30 I think we should do it manually 16:29:35 in titles? lets just leave them alone 16:29:41 You can move “oficial” tag to “unofficial” tag list 16:29:41 and while at it, improve bug titles 16:29:50 xarses: actually yes 16:30:09 if you can improve a bug title, just remove [tags] from it while you're at it 16:30:24 otherwise, let's just avoid even more spam and email thread breakage 16:30:59 ok, moving 16:31:18 #topic Fuel public builds 16:31:27 * xarses cheers 16:31:30 Recently we had updated the status of our task to publish nightly builds 16:31:30 #link https://bugs.launchpad.net/fuel/+bug/1308502 16:31:30 Currently it’s publicly available to download with torrents 16:31:32 Launchpad bug 1308502 in fuel "[devops] publish nightly builds for seeding" [High,Confirmed] 16:31:32 #link https://fuel-jenkins.mirantis.com/view/ISO/job/publish_fuel_community_iso/ 16:31:34 Please feel free to use :) 16:31:42 +100500 16:32:06 The only left item in that case is to set up smoke tests for them, and we'll done it soon 16:32:26 that's icehouse based builds? 16:32:37 or juno/master? 16:32:39 yeah, it's master 16:32:46 woot! 16:32:47 icehouse 16:32:51 boo :( 16:32:51 icehouse 16:32:57 also there are some ideas how to make it faster building iso 16:33:53 briefly the idea is to move from file based build system to artifact build system 16:33:58 what about juno packages? 16:34:00 #link https://blueprints.launchpad.net/fuel/+spec/build-packages-for-openstack-master-rpm 16:34:18 combined with above, would be really really awesome 16:34:25 this feature will be available on osci-ci) 16:34:56 my ultimate dream here is to use fuel ci for commits in openstack master branches 16:34:58 vkozhukalov: as long as we can still build ISO's with out needing lots of tools that are hard to build on your own, like your on Jenkins server 16:35:13 hello 16:35:22 about tagging bugs. 16:35:50 dilyin: we agreed to have further discussion on ML 16:35:55 We moved on, we asked to stop doing it in titles, and will discuss further in ML 16:36:52 xarses: it is not supposed to make harder to build iso on one's own 16:37:05 let's discuss it next time 16:37:15 vkozhukalov: sounds good! 16:37:33 i am going to recall my experience in this field from my previous job 16:38:23 ok, sounds like we have more than 20 minutes for open discussion 16:38:50 is anyone from mlnx here ? 16:38:54 it does not make much sense to discuss statuses of particular features 16:39:06 yes 16:39:06 #topic open discsussion 16:39:10 i'm from mellanox 16:39:27 aviramb_: you can discuss partiuclar questions with fuel-web guys if you want 16:40:21 nuritv: aviramb_ please feel free to add topics in agenda https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda if you have something to discuss 16:40:40 we still need some reviews for https://review.openstack.org/#/c/104501/11 and https://review.openstack.org/#/c/106007/ 16:41:13 dpyzhov: can anyone from fuel-web go through these? 16:41:31 I'm plan to have a look later today but I'd prefer to have more than one pair of eyeballs on it 16:41:48 AndreyDanin: is going to review some of your patches 16:42:10 already fixed some comments of angdraug 16:42:11 aviramb_: I’ll review these PR today 16:42:30 centos packages checked and will be merge soon 16:42:40 then https://review.openstack.org/#/c/101126/ can be merged 16:42:50 about bootstrap 16:42:58 angdraug: I’ve added meow-nofer to reviews in fuel-web 16:43:04 iSER rename+manifests(library) https://review.openstack.org/#/c/104323/ , https://review.openstack.org/#/c/104621/ waits to pass CI 16:43:51 library commits already passed many review cycles 16:43:53 nuritv aviramb_: and we are looking forward for unit tests 16:44:17 dpyzhov: will be ready early next week! 16:44:27 nuritv: great 16:45:10 we need some POC to work with on that, in order to make this efficient, talked about it with Evgeniya 16:45:22 (UT) 16:46:52 also, we still have this bug that affects us (https://bugs.launchpad.net/fuel/+bug/1341486). 16:46:53 dpyzhov: what about https://review.openstack.org/#/c/101126/ ? 16:46:55 Launchpad bug 1341486 in fuel "[provision] additional kernel_params not reflected in ubunut /boot/grub/grub.cfg" [High,Confirmed] 16:47:19 vkozhukalov: no 16:47:42 We will have separate bootstrap for now 16:48:03 Because we need to be really sure that extra modules do not affect anything 16:48:32 dpyzhov: what does it mean separate? 16:48:39 dpyzhov: we only load it on mlnx HW and we also did some test in our lab 16:48:42 it will be another bootstrap image 16:48:47 do you need us to do anything else? 16:49:00 dpyzhov MLNX team changed the implementation 16:49:01 nuritv: did you test it on other hardware? 16:49:04 this is the way centos loads mlnx in case of mlnx hw 16:49:36 the MLNX kernel modules uploads only if MLNX HW is in place 16:49:37 dpyzhov: we tested it on VM with no MLNX driver 16:49:51 nuritv: nice 16:50:04 dpyzhov: afaiu we gonna have saparate bootstrap for every extra kernel module? right? 16:50:05 i have a test report btw 16:50:11 dpyzhov: confirmed, the way it's implemented now won't impact non mlnx hw configurations 16:50:14 will share it with the QA team 16:51:03 dpyzhov: if so then it is a bit strange. isn't it? 16:51:44 vkozhukalov: plan was to use separate bootstrap as a temporary solution 16:51:55 good that we do not need it now 16:52:18 +1 from me, and our osci team will merge it after update of our mirrors 16:52:40 dpyzhov: great 16:54:29 ok, looks like we've managed to discuss everything we had 16:54:35 closing? 16:54:48 thanx everyone 16:55:01 #endmeeting