16:00:23 #startmeeting fuel 16:00:23 #chair xarses 16:00:23 Todays Agenda: 16:00:23 #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda 16:00:23 Who's here? 16:00:27 hi 16:00:29 Meeting started Thu Oct 8 16:00:23 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:29 \o 16:00:29 o/ 16:00:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:32 hi 16:00:33 hi 16:00:33 The meeting name has been set to 'fuel' 16:00:35 Current chairs: xarses 16:00:39 yo 16:00:42 hi 16:00:45 hi 16:01:06 #topic Action Items from last week 16:01:19 mihgen will task a core from each repo to start the first version of the MAINTAINERS file 16:01:27 #link https://review.openstack.org/#/q/topic:maintainers,n,z 16:01:40 looks like good progress 16:01:53 yea, nice 16:01:55 thank you guys. Let's push it forward to be fully done by next IRC meeting 16:01:59 hi 16:02:02 angdraug will task fuel-infra team to update core groups 16:02:07 I suggest to check in details next time 16:02:09 #link http://lists.openstack.org/pipermail/openstack-dev/2015-October/076390.html 16:02:17 angdraug: is script ready? 16:02:20 mostly done, except parts waiting for openstack-infra 16:02:24 hey 16:02:27 hi 16:02:33 hi 16:02:35 to automatically add reviewers based on maintainers files? 16:02:44 mihgen: no 16:02:52 ETA?.. 16:02:56 bug #? 16:03:07 will need to find.. don't remember 16:03:17 lets take it offline then 16:03:21 ok 16:03:42 thanks for getting core groups to the good shape 16:04:07 xarses: moving.? 16:04:14 #topic premature backport cherry-picks considered harmful (mattymo) 16:04:23 #link http://lists.openstack.org/pipermail/openstack-dev/2015-October/076066.html 16:05:01 everyone, please have a good look at this thread and our bugfix backporting policy 16:05:23 yep 16:05:25 I skimmed through 16:05:32 cherry-picking a commit to a stable branch before it is merged to master creates noise and extra work for reviewers 16:05:36 I agree with mattymo and you guys 16:05:59 so I think we should go ahead and update our engineering process 16:06:11 and don't create backport before code is merged into master.. 16:06:18 I through that was our process 16:06:19 mihgen: our engineering process definition already reflects that, we just need to get better at following it :) 16:06:36 #link https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Backport_bugfixes_to_stable_release_series 16:06:51 note the word in bold :) 16:06:59 oh then it's call for cores to reflect that in comments when someone creates backport earlier than needed.. 16:07:27 usually it happened when we need to deliver on time, before important milestone 16:07:52 maximov: premature optimization is root of all evil (D. Knuth) 16:08:15 if we strictly followed this rule, I don't think we would have released 7.0 on time 16:08:33 maximov: why so.. ? 16:08:37 ci takes hours 16:08:38 how is it related? 16:08:54 it is related because when you finish with master 16:09:02 usually it takes 2 days 16:09:11 you would need to repeat this process for stable 16:09:16 no 16:09:28 you don't have to repeat the review process for stable 16:09:31 it should not take 2 days to backport to stable 16:09:36 you're supposed to merge exactly what went into master 16:09:53 core reviewer can cherry-pick as soon as they've voted workflow+1 16:10:06 all you have to do is wait for CI, which is 2-4 hours 16:10:29 ok, who will do cherry picks? core or author of bugfix ? 16:10:32 compared to 48h average on master, that's 8% overhead 16:10:56 core 16:11:00 see above link 16:11:16 ok, if core then ok 16:11:18 "When you approve a bugfix commit for master branch... For all series where backport should exist and doesn't, create a backport review request yourself" 16:11:27 I don't think that core should do that. Author should know if it requires backporting and solve conflicts. 16:11:31 folks let's analyze it deeply. maximov - if you or someone else has concerns, let's bring it up in email thread then 16:11:44 I thought it's resolved in ML.. 16:11:53 there was a strong consensus on openstack-dev 16:11:59 mihgen: + 16:12:13 see comments from evgenyl above 16:12:15 it sounds like we need more discussion on the ML 16:12:23 so questions like who should backport it - we need to reflect in email thread 16:12:31 I have a big meta concern about this 16:12:48 the thread on ML was a week ago 16:12:48 I suggest to move on to highlight other updates.. 16:13:16 lets keep moving 16:13:16 ok lets move on 16:13:21 #topic OpenStack Infra jobs enabled in non-voting mode https://review.openstack.org/#/c/228204/. Status for repos reorg (mihgen, kozhukalov) 16:13:35 enabled for almost all of the repos. Now we've got to fix our repos structure, introduce tox.ini, etc. 16:13:41 In fuel-agent repo I believe once we merge https://review.openstack.org/#/c/203005/, we can switch jobs to voting and remove Fuel CI from there. What about docs job there.. how can we fix it? 16:13:51 What is the status for other repos folks? What / whom do we need to fix it in the other repos? 16:14:40 I am working on this 16:14:41 mkwiek: any eta on when your patch can be landed? 16:15:10 mihgen: this patch is waiting for bvt to pass, but here is apparently some lag there 16:15:11 aah no, it is not what i meant 16:15:32 kozhukalov: provide update on fuel-web repo pls 16:16:00 there are no patches on review yet, but I am working on this 16:16:09 kozhukalov: yeah, I am waiting for bvt to pass 16:16:27 next week infra is going to move all the projects from stackforge to openstack 16:16:28 kozhukalov: what about 4 databases we use to speed-up unit tests? i mean fuel-web 16:16:31 there were some strange failures before, if they happen again I may need some assistance, but I will let you know 16:16:31 kozhukalov: any eta / specific plan how to appoach it? 16:16:38 does openstack infra support this? 16:16:42 http://lists.openstack.org/pipermail/openstack-dev/2015-August/072140.html 16:17:24 they said that they will continue to create new repos for existent stackforge projects to prevent namespace splitting 16:17:48 but i don't think it is a good idea to do this before the migration 16:17:58 i mean once this migration is done 16:18:12 +1 16:18:17 i'll send a set of patches to create new projects 16:18:21 in openstack 16:18:30 is it only about creating new repos? 16:18:40 what about repo restructure, tox, etc. 16:18:42 openstack-infra is not likely to review any infra commits before 17th 16:18:48 including shotgun , network-checker, fuelmenu, 16:18:52 is there any specific plan for it? 16:18:58 ...that are not related to stackforge->openstack ns migration 16:19:22 first we need to create all necessary files that we need for fuel-ci 16:19:30 i mean test interface 16:19:34 run_tests.sh 16:20:18 and then we need to announce code freeze and extract corresponding directories 16:20:41 it is exactly the same as we did for fuel-agent for example 16:20:56 I have kind of checklist 16:20:57 kozhukalov: can you prepare a mail on the ML so we can move along? 16:21:07 the most complicated case is fuel-ui 16:21:16 kozhukalov: Igor already asked this question: what about 4 databases we use to speed-up unit tests in nailgun? 16:21:34 how we will tackle this? 16:21:36 we need to modify our testing approach cuz it requires nailgun for testing 16:22:02 kozhukalov: we may need your checklist for other folks, so that we move quick and easy 16:22:07 xarses: sure, i'll send a separate e-mail for every subproject 16:22:12 Do we have people who plan to work on it for other repos.. fuel-main, fuel-ostf, etc. ? 16:22:30 mihgen: it will in ML, like it was for fuel-agent 16:22:30 prmtl: it seems we're ignored. :/ 16:22:34 ikalnitsky: :/ 16:23:07 #action kozhukalov will update ML with plain to separate each sub-project in fuel-web 16:23:16 prmtl: 4 databases? 16:23:25 ikalnitsky: prmtl please bring it up on the ML, we need to move along 16:23:37 xarses: ok 16:23:39 #topic code review backlog status: http://bit.ly/1G4Xsn9 (mihgen) 16:23:51 These are patchsets which are 5+ days without feedback. 16:23:59 Majority of them are in fuel-specs. What would be the best approach here folks? 16:24:05 I think that we need to just take action items for core reviewers of corresponding repos to deal with it. 16:24:13 For fuel-specs, I'd say it should be PTL - who would find experts and assign them to review. 16:24:37 this reminds me: all, please update your fuel review inbox links if you're using Firefox 41 or later 16:25:22 mihgen: that seems good. angdraug ? 16:25:25 +1 16:25:37 we just need to ensure that cores delegate review work to maintainers 16:25:51 and PTL to some of the subject matter experts to review fuel-specs 16:26:15 mihgen: the approach is to wait for core reviewers to get back from PTO or Sick Leave 16:26:37 I want to highlight that queue was 4x longer actually couple of days ago. So I'd like to thank everyone for dealing with it 16:26:58 #action angdraug will update fuel-specs reviews to assign SME's to review 16:27:08 aglarendil: I'm not sure that so many are on sick leave/vacation.. 16:27:32 no feedback means even non-cores didn't vote 16:27:36 maximov: can you please take an action item to deal with it and assign cores to figure out particular patchsets.. ? 16:27:45 ok mihgen 16:27:50 thank you... 16:28:10 moving then 16:28:12 #topic Status on IPv6 in tenant networks research (veremin) 16:28:27 yottatsa: ^^^ 16:28:41 I've done some research about IPv6 status on OpenStack Liberty 16:28:45 #action maximov will look over stale review queue and ensure that cores are assigned to them 16:29:00 and put some thought on etherpad https://etherpad.openstack.org/p/tenant-ipv6 16:29:27 woops it doesn't work with DVR? 16:29:28 shortly: IPv6 is working is provider networks with external routers just fine 16:29:47 DVR didn't yet support IPv6 16:30:28 and VRRP? 16:30:29 As for tenant networks, there is good news that we can implement it with few patches 16:30:32 what about fuel changes needed to enable what is supported? 16:30:47 yottatsa: that would be awesome 16:30:49 Didn't test for VRRP, will ask Sergey Vasilenko 16:31:17 There is no changes will be needed in fuel except tseting AFAIK 16:31:27 It should be additionally tested after 16:31:51 support of VRRP was be implemented for IPv4 16:32:14 SNAT and Floating IP is not working with IPv6, will need to implement 16:32:29 also, there some cases with radvd, will need some support from fuel and neutron 16:32:29 yottatsa: ok let's think about how it has to be tested, I mean what already works 16:32:52 and we need to collect list of things which should be fixed in openstack and pass to neutron team to deal with.. 16:32:58 thank you for research yottatsa 16:33:12 mihgen, I'll finish my ressearch on testing today and put it to report 16:33:21 cool, thanks 16:33:25 i'm just a lurker, but IPv6 has no plans on doing SNAT or floating IPv6 in neutron 16:33:55 haleyb, AFAIK there is no blueprints for it 16:34:12 haleyb: is that because it's not needed? or its not planned 16:34:27 yottatsa: well, the neutron team has decided against doing it, not needed if tenants are using global addresses 16:34:31 haleyb, but I believe it very neat feature 16:34:53 haleyb, thank you for information. 16:35:06 haleyb: thanks 16:35:18 looks like yottatsa you'd need to articulate why it's needed to neutron team) 16:35:34 feel free to corner the neutron cores and plead your case 16:36:08 xarses: moving on.. ? 16:36:12 yep 16:36:13 #topic Enhancements Team Status (ashtokolov) 16:36:25 Enhancements status briefly: 16:36:37 Inbox - 62, In progress - 12, On review - 20, QA - 17, Done - 2 16:36:46 and 12 to be sorted with Product Management 16:37:00 One of our story «Rewrite fuel-createmirror» takes more than 5 man-days 16:37:08 looks like a good progress, thanks for driving this! 16:37:16 Bulat could you provide a status of this story? 16:37:17 yeah that's gonna be exception one :( 16:37:27 that would be our next agenda item 16:37:28 it's in agenda 16:37:28 we have topic for create mirror just next 16:37:44 moving? 16:37:46 ashtokolov: those 17 in qa - those are implemented? 16:37:49 the proof of concept will be provided to QA 16:37:53 or in review? 16:38:04 mihgen: yes, Fix committed 16:38:23 that's cool. we will finally get rid of many gaps.. 16:38:37 thanks ashtokolov, no more questions from my side. 16:38:39 #topic Status on fuel-createmirror.(bgaifullin) 16:38:56 the proof of concept was provided to QA -team. 16:39:09 they are testing it now. 16:39:19 where can we look at code..? 16:39:29 on review 16:39:48 https://review.openstack.org/#/c/231535/ ? 16:40:08 https://review.openstack.org/#/c/231535/ 16:40:24 #link https://review.openstack.org/#/c/231535/ 16:40:28 3 times does the charm :) 16:40:39 ok thanks. do you get reviewers.. ? 16:41:01 I need to prepare specification before, and a change interfaces little bit. 16:41:09 ok thanks bgaifullin 16:41:32 xarses: moving on.. ? 16:41:37 #topic UI team status (vkramskikh) 16:41:45 Hi, this week we've fixed 11 bugs, and have 56 bugs left. There is only 1 high bug (which is in progress), and others are mediums and lower. We also have quite a few low-hanging-fruit bugs which we can fix quickly. We'll continue to fix the bugs. 16:41:48 that's it :) 16:42:04 vkramskikh: hey any plans for multi-rack? 16:42:10 other advanced networking pieces? 16:42:39 mihgen: multirack is one of 8.0 features, but currently we're working only on bugs 16:42:52 yes we plan to deliver multirack in UI in 8.0 16:43:00 mihgen, I've got initial info from xenolog13 about multirack, and I'm still in progress 16:43:27 yottatsa: in progress of what in terms of multirack...? 16:43:44 vkramskikh: I asked rvyalov to create a spec for the changes in js deps packaging that asilenkov is working on 16:43:52 vkramskikh: sound good. thanks. Do you know if http://demo.fuel-infra.org:8000/ is compressed now.. ? 16:44:00 please review when it's available 16:44:08 mihgen: trying to fit IPv6 deployment in multirack case 16:44:18 I'd like to make sure that this time we don't leave it in a state where it can block your team again 16:44:21 mihgen: nope, development UI is still used 16:44:27 yottatsa: oh ok. thanks. 16:44:51 #topic Bugfix team status (dpyzhov) 16:44:55 angdraug: thanks a lot 16:45:01 Hi again 16:45:05 angdraug: please prioritize the work for demo instance if possible.. it's likea a face of Fuel 16:45:13 Here is our current stats. I’ll show it in format “total (UI / python / librar)" 16:45:13 Critical and high bugs: 49 (1/26/22). Last week it was 48 (2/31/15) 16:45:15 Medium, low and wishlist bugs: 252 (64/125/63). Last week it was 241 (72/119/50) 16:45:15 Features tracked as bug reports: 134. Last week it was 133. 16:45:15 Technical debt bugs: 88. Last week it was 72. 16:45:15 bug 252 in gnome-system-tools (Ubuntu) "Remove absolute reference from icon .desktop file " [Low,Fix released] https://launchpad.net/bugs/252 - Assigned to Sebastien Bacher (seb128) 16:45:37 #left 16:45:42 We had some really tricky bugs and it affected our velocity 16:46:01 Now they seem to be nailed down 16:46:12 So I hope that we will be better next week 16:46:18 dpyzhov: but its good to get them done 16:46:21 I’ve walked through our tech-debt bugs and shared my proposals in openstack-dev list last week. 16:46:21 I haven’t got any objections so looks like we cool here. 16:46:21 We have several tech-debt bugs in High priority and we should fix them. 16:46:21 All other tech-debt bugs can be postponed or fixed in a background without any priority. 16:46:37 Right now we are focused on maintenance update for 7.0. Fixes for most of bugs are in progress and about 10 bugs are not touched yet. 16:46:52 dpyzhov: thanks. Looks like it's good progress overall! 16:47:04 2 bugs for MU1 are on review 16:47:08 dpyzhov: what about "features" 16:47:14 is those are enhancements? 16:47:22 Yest 16:47:25 it doesn't seem to be in sync with report from ashtokolov 16:47:36 feature-bugs are ehnancement bugs 16:47:48 I've just provided some stats 16:48:08 well, it doesn't look good for me 16:48:14 ashtokolov: can you please check why numbers are different..? 16:48:17 Because numbers are almost the same 16:48:36 looks like we are like Alisa, running as fast as we can in order to be on the same place 16:48:59 feature bugs also include bugs tied to blueprints 16:49:09 that are not in ashtokolov area 16:49:19 sorry for misleading 16:49:50 Also I’ve created new bug tag ‘regression-8.0’ for bugs that were introduced in 8.0 release. 16:49:51 oh I misinterpreted some numbers .. I see it almost doesn't move now.. 16:50:08 ok let's take it offline.. we need to figure out what to do here 16:50:14 yep 16:50:33 xarses: moving on? 16:50:35 #topic Multirack status (alex_didenko) 16:50:45 let's try to fit 3 topics in 10min 16:50:49 We're working on this list of bugs https://goo.gl/wzIGl5 - when High bugs are resolved we should have a working multi-rack deployment with static routes. 16:50:49 We have a fix/solution for the most of bugs, some of them are on review already. 16:50:51 The only bug without solution/fix is https://bugs.launchpad.net/fuel/+bug/1502842, but I think we'll have a solution for it on the next week. 16:50:51 Our main goal right now is to upload all the patches to gerrit, build custom ISO and test it on both standard and multirack topologies. 16:50:51 Launchpad bug 1502842 in Fuel for OpenStack 8.0.x "Need to re-configure routing after we add a new nodegroup (rack)" [High,Triaged] - Assigned to Aleksey Kasatkin (alekseyk-ru) 16:51:09 we are focused on mu1. You can see our status here: https://etherpad.openstack.org/p/fuel-python-7-0-mu1-bugs https://etherpad.openstack.org/p/fuel-library-7-0-mu1-bugs 16:51:17 multirack done, next :) 16:51:29 alex_didenko: wait, is it all static routes? 16:51:37 yep 16:51:44 how do we do HA in multirack here? 16:51:53 can you place controller per rack? 16:52:08 nope, controllers should be in the same L3 segment 16:52:13 no, it's impossible now 16:52:21 mihgen: no, not with out separating l3-agent and haproxy/vip 16:52:44 ok.. I'll sync offline with you xarses in the office then.. 16:52:55 yottatsa: did you discuss it with xenolog13 in the office? 16:53:18 in general, how you did it before and how we are doing it .. we need fresh feedback on things 16:53:43 alex_didenko: do we have a design spec for multirack.. ? 16:53:53 well, besicaly we're imporving and fixing nodegroups, so there's nothing new 16:54:02 ok.. 16:54:06 but we do have a spec for it 16:54:21 spec started, attached to the task 16:54:26 https://review.openstack.org/230943 16:54:27 can you find please and share with yottatsa - I want him to review it 16:54:30 mihgen, I've discussed it, but I'm still think on it in connection with IPv6 routers 16:54:53 ok, thanks. xarses - let's move on.. if no more questions here.. 16:54:55 #topic last call for votes for PTL (angdraug) 16:54:58 just wanted to remind everyone that the PTL vote closes in a few hours (23:59 UTC), please vote now if you haven't already 16:55:01 alex_didenko, got the spec 16:55:17 next topic please :) 16:55:19 Spec for dynamic multi-rack will be here: https://review.openstack.org/#/c/195640/ 16:55:36 #topic Networking configuration as a service (rmoe) 16:55:46 yottatsa: this one is more important to review (dymamic routes) ^^ 16:55:56 I'm currently working on separating network configuration from nailgun into a standalone service that is not nailgun-specific. 16:55:56 I'm building a PoC to figure out the data structures and API. I'm also researching os-net-config as a way 16:55:56 to realize the host network configurations stored in this new service. As soon as I'm done with the PoC I'll take 16:55:56 what I've learned and put it all into a spec. 16:56:25 spec should be up by the next meeting here 16:56:31 rmoe: do you have a scratch repo with the code up on github? 16:56:51 everything I'm doing will be on github by the end of today 16:57:01 thanks rmoe. Do you solely work on this or whom do you sync up with on this matter.. ? 16:57:19 cool, can you post it to the ML when it's ready? 16:57:21 right now just me, but once we're past this initial poc 16:57:37 vova will be helping with the design 16:57:54 which vova.. aglarendil ? 16:57:57 yes 16:58:26 cool. and I assume akasatkin, xenolog13 will be in sync as well here..? 16:58:40 I hope so, i would definitely rely on their input as we get further along 16:58:49 thanks rmoe 16:58:53 1 min 16:59:04 yo 16:59:07 open discussion? 16:59:13 we just fit agenda yo 16:59:19 jk 16:59:24 sorry hurried a little bit 16:59:24 thanks everyone, if you have something to raise, please do in the ML 16:59:45 #endmeeting