16:00:55 #startmeeting fuel 16:00:55 Meeting started Thu Jul 23 16:00:55 2015 UTC and is due to finish in 60 minutes. The chair is xarses. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:55 #chair xarses 16:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:59 The meeting name has been set to 'fuel' 16:01:00 Current chairs: xarses 16:01:07 ahoy 16:01:08 Todays Agenda: 16:01:08 #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda 16:01:08 Who's here? 16:01:10 hi 16:01:10 hi 16:01:10 \o/ 16:01:13 hi 16:01:13 hi 16:01:19 hi 16:01:22 hi 16:01:25 o/ 16:01:30 hi 16:01:32 hi 16:01:32 hi 16:01:36 hi 16:01:40 #topic Auto-abandon and current status with code reviews (mihgen) 16:01:40 hi 16:01:43 hi 16:01:45 hi 16:01:47 hi 16:02:12 hi 16:02:30 mike's not here, lets circle back 16:02:40 #topic The status of fuel-upgrade code and upgrading of the Fuel Master node to 7.0 (ogelbukh) 16:02:42 hi 16:03:49 0/ 16:04:03 alex_didenko: o/ 16:04:13 sorry folks I'm late. I wanted to say about upgrades & FFE request - we need to get Nailgun cores to reply on ogelbukh email in openstack-dev 16:04:18 risks needs to be estimated 16:04:32 ogelbukh, please let's call it fuel-octane to avoid confusing with fuel-upgrade which is master node upgrade 16:04:52 hi 16:04:54 and if we have any suggestions on how to mitigate risks - please propose those. 16:05:09 o/ 16:05:16 ok, lets star over here, ogelbukh is not responing 16:05:25 mike lets start with auto-abandon 16:05:32 xarses: sure 16:05:43 #topic Auto-abandon and current status with code reviews (mihgen) 16:06:22 folks I looked at date, and for all reviews we have recently (in last weeks) - we are doing very, very good job with reviews, providing prompt feedback 16:06:23 hi 16:06:43 though at the same time, most of reviews come from cores, which means they are getting over loaded 16:06:57 so that means that we need to have other developers reviewing more 16:07:11 I'll come up with more detailed data separately. 16:07:27 Now, regardarding stackalytics stats. They are in terrible shape still 16:07:46 as we still didn't clean up all stalled reviews which sit there for months 16:07:56 (at least as per yesterday's investigations) 16:08:24 So do you guys agree that we looked into it, and now just need to enable auto-abandon? 16:08:36 for everything which hangs for over a month? 16:08:36 I guess mostly all things that sit for months are outdated and irrelevant 16:08:56 +1 for enabling auto-abandon 16:08:58 +1 16:09:02 +1 16:09:03 +1 16:09:06 mihgen: +1 to enable -1 for 1moth 16:09:07 agree. but there are exceptions like specs. 16:09:13 lets start with 2 mo for now 16:09:25 +1 for auto-abandon for requests with at least one "-1" 16:09:25 +1 fwiw 16:09:26 and asses what is still in 1-2 moth old and why 16:09:29 xarses: what is the reason for 2 month? 16:09:33 akasatkin: we need to provide feedback there then? 16:09:36 xarses: I think 1 month should be just fine. 16:09:44 I don't think the specs are exception 16:09:47 items with -1,-2 because of FF 16:09:52 mihgen: yep, right 16:10:02 dev wont touch them untill release most likely 16:10:34 So folks but simple comment in there would reset the time, right? 16:10:41 Would it? 16:11:03 well, it's not that difficult to activate something abandoned 16:11:07 #link http://stackalytics.com/report/reviews/fuel-group/open 16:11:09 As far as I know commenting works fine. 16:11:42 yep. So according to comment from Neutron team I think, you can always make it back 16:11:48 when it's time to look into it again 16:11:49 we talk more 16:12:17 loooks like we're all in agreement here :) 16:12:40 so guys I think we just need to move forward with this. I can't get real numbers without doing this, and I really want real numbers as I still hear complaints that Fuel team doesn't do good job on code review 16:13:03 ok. bookwar - how can we enable it? 16:13:07 auto-abandon? 16:13:19 anyone from devops team ? 16:13:32 i don't think we can enable it on gerrit, we should just write script which does it 16:13:48 we need to figure out how other teams do it 16:13:59 https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh 16:14:00 I think there should be something in infra.. 16:14:02 for example 16:14:04 or rather reuse one out of existing ones 16:14:34 can we have it as an action item for devops team? 16:14:40 ok, can we move this along, the schedule is full 16:14:42 to run it this week 16:14:53 and then enable it periodically? 16:14:54 bookwar: can I assign it to you? 16:15:06 xarses: no, on teran 16:15:09 ok 16:15:22 lets move on, and write the results to the ML 16:15:23 thanks guys, sorry it took long 16:15:35 #topic Features requiring FF exception (mihgen) 16:15:50 it has two subtopics, let's go into them 16:16:02 #topic Cluster Upgrade FF exception request (ogelbukh) 16:16:18 I formally requested FFE for cluster upgrade nailgun API extensions 16:16:27 python team - we need to respond on it 16:16:37 major things we have to consider is how risky changes are 16:16:43 can they introduce regressions 16:16:43 the patches are being actively worked on 16:16:57 and how much effort would it take from cores to review / test / land 16:16:58 mihgen: ogelbukh I will provide my thoughts about it in ML 16:17:18 they are mostly separated from core functionality 16:17:21 so we'd understand if it will lead to slip of the release dates or not. 16:17:34 As for essential features we pretty much need to give exception 16:17:53 ogelbukh: ok thanks 16:18:05 other exception? xarses ? 16:18:22 #topic (FFE) Separate services from controller status (matt) <- Discuss gray area of plugin development 16:19:22 mattymo: ? 16:19:23 mattymo^^ 16:19:38 hi sorry 16:19:41 nick is messed up 16:19:50 #action teran will enable script to abandon stale commits over 1 moth and run it every once and a while 16:19:56 happens 16:20:11 so Andrew Maksimov asked me to bring this up in FFE section because it's a gray area 16:20:18 All core features to fuel-library are merged. All dependent features (network templates, VIP as plugin, role as plugin) are also merged. 16:20:28 There are 3 plugins that demonstrate this feature's capability: https://github.com/mattymo/detach-database https://github.com/mattymo/detach-keystone https://github.com/mattymo/detach-rabbitmq 16:20:29 The plan is to publish these plugins, but they are not part of fuel. 16:20:53 The whole point of plugins is that they don't have to conform to our release schedule 16:20:59 so I think this is a no-brainer 16:21:01 the catch is they're not 100% ready. database and rabbitmq seem okay so far, but haven't been very extensively tested yet. keystone is a couple days from ready 16:21:10 if its 100% a plugin, then you don't need FFE 16:21:24 if you need something in fuel's core still then we need to discuss that 16:21:30 the reason they're behind is because on Monday my dependent features became ready, and I just haven't finished refactoring the plugins and removing workarounds 16:21:46 yeah, though you need to ensure they are good for release time, along with good documentation 16:21:49 I just want a verbal okay that these plugins don't impact FFE for delivery of this feature, which is, in fact, done 16:22:11 mattymo: so, will we end up with something into fuel core as a result of not using the work arounds? 16:22:26 xarses, I'm sorry, I don't understand you 16:22:32 in my opinion they don't directly impact, however we have to understand that success of the feature is when it's documented and people can take these plugins and use 16:22:57 xarses: nope mattymo just need to polish plugins 16:22:59 as part of un-winding the workarounds, do you see any issues that might cause you to need to make new changes to fuel? 16:23:07 guys, did you think about moving integrated db/amqp/keystone into plugins instead? 16:23:14 xarses, I found some neat bugs, but no show stoppers yet 16:23:28 and have core working with some abstract external entities of them 16:23:30 ok, so then you are in the clear as your plugin is not a fuel feature any longer 16:23:32 fuel core allows you to separate components already, but don't provide any UI for it - this is job for plugins 16:23:33 so far it looks like our features are implemented correctly 16:23:33 ok, not keystone 16:23:53 ogelbukh, we've enabled the _capability_ of a plugin devel to do this. You can just view the plugins and see how it's done with hiera 16:24:16 k good 16:24:21 ok so it's clear I think - I'm worried that instead of working on bugs, you'll need to spend time on plugins polishing 16:24:36 When can you finish with it and switch to bugs? 16:24:40 mihgen, it's just a couple more days for keystone. and the rest is bugs time for sure 16:25:18 ok good thanks 16:25:25 we need you on bugs asap.. 16:25:28 ok, so lets wrap this one, I'll write a ML about the feature state of plugins 16:25:32 bugs need me to be on them 16:25:35 you are the most active bug squasher ) 16:25:47 let's move on thanks mattymo_ 16:25:50 #topic (FFE) flexible networking (akasatkin) 16:26:00 We have one CR which is on review still: 16:26:00 https://review.openstack.org/#/c/204321/ 16:26:00 It is CLI support for API for creation/removal of networks. 16:26:00 Other stuff is merged. Including 2 patches were landed today. 16:26:16 #action xarses will write ML about plugins not being features, and their exemption from FF 16:26:41 sounds like almost excellent 16:26:53 if it's only CLI, then it should not be very big deal... I hope 16:27:04 akasatkin: right 16:27:06 ? 16:27:07 I hope we can merge it tomorrow. 16:27:22 rmoe: it's -1ed by CI..., are you on it? 16:27:30 It requires unit tests and testing. 16:27:36 yeah, I'll fix it up today 16:27:39 should we grant FF on the 2 CR's or the whole feature? 16:27:54 only for patch, why 2? 16:28:00 I thought there where 2 16:28:09 oh, 2 where landed 16:28:09 ok 16:28:13 We've landed other stuff today.. 16:28:17 Only for CLI for flexible networking, I'd expect everyone else to focus on bugs right away 16:28:22 been busy =) 16:28:41 we are in terrible situation with bugs, that's why I don't want us to derail on anything else now.. 16:28:49 python-fuelclient cores? 16:28:50 Okey. 16:28:59 same here - we need other python cores to reply in openstack-dev 16:29:22 about risks, etc. It seems like it's not risky at all to me, as it doesn't touch any core pieces 16:29:35 ikalnitsky: will you reply.. ? ^^ 16:30:00 xarses: moving on..? 16:30:06 yep 16:30:10 #topic The status of fuel-upgrade code and upgrading of the Fuel Master node to 7.0 (ogelbukh) 16:31:47 seems ogelbukh is missing 16:31:49 just wanted to clarify the status of the upgrade tarball and scripts 16:31:51 nvm 16:32:26 I have related question about bootstrap on ubuntu & upgrades.. 16:32:28 currently upgrade scripts are located in new repo 16:32:36 stackforge/fuel-upgrade 16:32:52 i am working on getting rid of tarball 16:33:26 i need to modify script itself to make sure it works 16:33:35 without tarball 16:33:41 kozhukalov: you want to make a package instead? 16:33:48 yes, 16:33:53 rpm package 16:33:59 kozhukalov: how much it will take? 16:34:17 without venv and without rpm and deb mirrors inside 16:34:34 mihgen, hard to say, probably another week 16:34:40 I'm asking as we are in a pretty shaky situation with bugs and we need to focus on stabilization and bugs at first 16:35:14 so if there are anything related to your area of expertise I'd say I'd love to see some progress in bugs.. 16:35:23 we've been always in such situation 16:36:00 so i hope to deal with tarball with minimum affection on our whole process 16:36:39 ok I'll follow up on this separately let's move on 16:36:42 mihgen, sure, i am trying to help with review 16:37:00 #topic Separate services from controller status (mattymo) 16:38:30 mattymo_: ^^ 16:38:45 xarses: let's move on 16:39:27 #topic The status of node labels feature (jaranovich) 16:39:33 the feature includes 3 requests, 2 of them are already merged (spec and ui part). The latest one is the CLI changes https://review.openstack.org/#/c/204524/ 16:39:37 This request is on review, its author is fixing comments and we are going to merge it asap. Today we showed a demo on this request. The base node labels flow in cli was approved, the gaps are discussed. So, the question is about fixing some comments and collecting +1s 16:40:17 jaranovich: is there any risk for this not being merged today? 16:40:41 guys this is +390, -35 16:40:41 i think yes 16:40:42 no reviews 16:40:50 I don't see a way for it 16:40:52 there were +1s 16:41:03 but the only one -1 and we are working on it 16:41:03 jaranovich: should we get FFE for this? 16:41:08 there were decent review activity during today 16:41:12 -1 from SMEs 16:41:22 guys you'd need email in openstack-dev with FFE then 16:41:24 I don't like it 16:41:37 its all fuelclient 16:41:42 so it might be ok for FFE 16:41:44 it's not an essential feature, and we already requesting exception for flexible nets 16:41:45 ok, i'll write to openstack-dev 16:41:47 but we should request it 16:41:49 in same area 16:42:06 jaranovich: any other risks? 16:42:13 so before we are done with flexible networking I won't even work on this one 16:42:15 yep, UI and backend parts are merged, I don't think we should postpone thes feature because of fuelclient 16:42:24 we'll request FFE 16:42:26 no, the base flow of cli commands was accepted on the demo. we need just +1s 16:42:32 it's a patch to fuel2. i think there's a minimal risk that it breaks something 16:42:44 there should be clear focus for everyone: essentials at first, and keep bugs in manageable state 16:42:51 ok, moving on then 16:43:03 yep.. 16:43:05 #topic Bugs status & focus for the team (mihgen) 16:43:49 so folks I mined data 16:43:57 and we still keep our bugs # growing 16:44:16 we are above the guideline for sure to converge by HCF 16:44:23 which is 3rd of September 16:44:54 so guys I urge you to switch to bugs right after you are done with feature work 16:45:10 we can't work on other features just yet if we want to hit release dates 16:45:36 I'll be tracking it and will present data next meeting 16:45:46 any comments? 16:46:16 xarses: let's move on.. 16:46:22 #topic fuel-devops 2.9.10 released (bookwar) 16:47:20 just an announcement 16:47:28 so fuel-devops has been released today 16:47:34 and we plan to switch to it 16:47:38 any page with new features / bug fixes? 16:47:39 now with virtualbox? 16:47:51 bookwar: when do we plan to switch? 16:47:55 I hope before SCF ;) 16:47:57 fuel-qa requirements has not been updates yet, so fuel-qa is still working with 2.9.9 16:48:03 and not these few hot days 16:48:28 but as soon as we switch everyone will need to update local copy 16:48:37 because tests will become incompatible 16:49:10 looks like we'd need more details for dev teams? 16:49:28 qa team requested to switch today, but it looks like we should wait for FF, so we delaying the switch for weekend or next week 16:49:29 action item for QA? Who has been working on new fuel-devops..? 16:49:47 bookwar: +1 for not doing it in the next couple of days 16:50:11 anyone from QA? 16:50:31 we should probably ask dtyzhnenko to send the announce to openstack-dev 16:50:48 #action maximov ask QA to email everyone about new fuel-devops 16:50:57 I'll do it this way ) ^^ 16:51:00 xarses: moving on? 16:51:02 so that's it from me :) 16:51:07 #topic (?) update iso build process(rpm\deb\repositories\nailgun pinning\IBP) (azvyagintsev) 16:51:08 thanks bookwar for raising this 16:52:45 azvyagintsev is not here, moving on 16:52:55 #topic Enable deployment through Packer and Vagrant, and/or publish vagrant boxes and Vagrantfiles for "standard" deployments locally (crimi) 16:53:25 crimi seems to be not here too 16:53:46 #topic is it ok to split fuel-web git repo after FF? (kozhukalov) 16:54:03 ok, guys, i am working on this 16:54:17 and i should know if it is ok 16:54:34 I don't really like to work on this after FF. As I said, we are in bad situations with bugs 16:54:37 we need this 16:54:42 my opinion here is it is the most suitable time for this 16:54:52 and we would ideally do it before FF 16:55:16 now it would need not only your time, but also devops, and other developers to review / test 16:55:22 QA 16:55:29 mihgen, we are in bad with bugs because we never invest enough time to improve our development processes 16:55:30 splitting ans setting up CI may take even week 16:55:37 and all of those have not planned for it 16:55:38 *and 16:55:47 kozhukalov: then it means we have to do better planning 16:55:57 but once we are committed, we are committed 16:56:06 we need to meet deadlines 16:56:15 no slip this release 16:56:48 just question who managed to notice that fuel-upgrade in new repo since the beginning of this week? 16:56:55 or fuel-agent? 16:57:02 nothing broken 16:57:16 developers are not blocked 16:57:42 the only problem is re-submitting patches, I've noticed few 16:57:52 I provide my POV. You increase risk of delivery in time 16:58:01 Goal is to deliever quality code in time 16:58:09 you are working on orthogonal now 16:58:20 even though from best ideas, which we need 16:58:28 but it's just not the right timing for it 16:58:47 ok, when the right time for this? 16:58:48 alex_didenko's team trying their best with bugs, dedicated team, and bugs ## still grows 16:59:06 we will never have enough time and stable enough code to do this 16:59:07 kozhukalov: after we get better with bugs situation, and in next release timeframe 16:59:17 plan for it 16:59:28 it has to be agreed way before FF 16:59:37 this simply was not in the scope 16:59:41 let's discuss this p2p later, ok? 16:59:56 small changes are ok to be done without planning, but before FF 16:59:58 sure 17:00:17 looks like other topics should go to openstack-dev.. 17:00:23 xarses: let's close .. 17:00:25 thanks guys 17:00:26 yep 17:00:27 thanks 17:00:30 #endmeeting