16:01:00 #startmeeting fuel 16:01:00 Meeting started Thu Oct 29 16:01:00 2015 UTC and is due to finish in 60 minutes. The chair is xarses. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:00 #chair xarses 16:01:01 Todays Agenda: 16:01:01 #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda 16:01:01 Who's here? 16:01:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:04 The meeting name has been set to 'fuel' 16:01:05 Current chairs: xarses 16:01:11 hi 16:01:12 hi! 16:01:13 hi 16:01:14 hi 16:01:18 hi 16:01:32 hi 16:01:32 hi! 16:01:36 hi 16:02:07 #topic Action Items from last meeting: 16:02:12 mihgen will poke QA people to review fuel-devops and fuel-ostf 16:02:53 o/ 16:03:18 mike hasn't joined us, its late in Tokyo, so maybe he's sleeping 16:03:21 teran will review IPv6 proposal on how it is gonna impact infra https://review.openstack.org/#/c/216787/ 16:04:53 hi 16:05:05 ok moving along then 16:05:31 #topic Upgrade team status (ogelbukh) 16:05:41 hi 16:06:08 finishing bug fixing and sending fuel-octane package to mos7.0-updates tomorrow 16:06:38 we also started work on new version of upgrade integrated with nailgun and library 16:06:44 yet in early stages 16:07:02 please review specs: https://review.openstack.org/#/c/224302/ 16:07:52 also working on some bugs upstream 16:08:23 ogelbukh: how do we track what QA jobs are used to show octane testing for your release? 16:09:14 I'm not sure the QA jobs are running regularly for 7.0 16:09:54 we're doing tests manually at the moment, using tests submitted to fuel-qa 16:10:06 ogelbukh: we run jobs for os upgrades in swarm 16:11:11 but it doesn't work due upgrade master node issue, yesterday issue with master nodes upgrades was fixed 16:11:34 so I think os upgrade job should work and give us results 16:11:36 nurla: thanks, good to know 16:11:55 could you send a link to those jobs, just in case? 16:12:57 ok moving on 16:13:04 #topic Bugs status (dpyzhov) http://lists.openstack.org/pipermail/openstack-dev/2015-October/078035.html 16:13:04 it is link to our private jenkins, I'll send it in email 16:13:09 hi 16:13:23 I've send the report to openstack-dev 16:13:28 In short 16:13:32 Overall situation looks ok. We have manageable 16:13:32 number of high priority bugs. Number of medium bugs is going down. It 16:13:32 doesn't look like we will fix all medium bugs by end of release but it 16:13:32 seems to be acceptable. High priority technical debt is under control. 16:13:32 Features backlog is huge and nobody expects that it will be closed by end 16:13:32 of release. 16:14:35 dpyzhov: thanks, its excellent to see these numbers go down. It will feel great to get them closed finally 16:14:44 no chance 16:14:54 we have constant income of high priority bugs 16:14:57 what's good is we're getting more test coverage in fuel-library and that should reduce the likelihood of regressions 16:15:13 so I don't expect to get 0 in any field here 16:15:21 oh, I know we are chasing 0 16:15:37 but progress on mediums is important, and we where lacking there before 16:15:42 our bugfix team is facing a lot of regressions created either in some feature work from previous release or by moving to librarian and old bugs are coming back 16:15:59 Actually there were not so many regressions 16:16:10 actual regressions number is about 30 bugs 16:16:16 mattymo: so do you see this as a gap in CI coverage? 16:16:33 xarses, noop tests were to blame for most... there's a thread from bogdando about this 16:17:29 thanks 16:17:48 #topic Multirack status (akasatkin) 16:17:59 Hi 16:18:22 SSL is in good shape, ETA - end of this week (maybe rather optimistic) 16:18:24 Now we have estimates for QA part and test drafts for some stories. 16:18:31 Progress with merging of code for dynamic dhcp setup https://review.openstack.org/#/q/status:open+branch:master+topic:bp/dynamic-dnsmasq,n,z is very slow (review is bottleneck). 16:18:39 Progress in Nailgun part is also slow as I'm the only Nailgun developer in our team and I have a number of parallel tasks. 16:18:47 Overally, status is yellow because of Nailgun which is a bottleneck currently. 16:19:00 That's it. 16:19:14 akasatkin: is there some thing we can do to get you help here? 16:19:48 we hope to get some help from python devs. 16:20:49 should we assign some one? 16:21:09 would that help? 16:21:18 if you have one, it would be great 16:21:50 ok, I will try to find help 16:22:00 moving on. 16:22:02 thank you 16:22:09 #topic Enhancements Team Status (ashtokolov) 16:22:20 hi folks 16:22:26 Enhancements weekly status: Inbox - 65(was 65), In progress - 14(was 13) 16:22:35 On review - 23(was 23), QA - 16(was 18), Done - 14(was 10) 16:22:45 and 14(was 11) to be sorted with Product Management 16:22:52 so Total: 146 (was 139) and Fix committed+Fix released = 30 (was 28) 16:23:01 #action xarses will look for additional reviewers to assign to https://review.openstack.org/#/q/status:open+branch:master+topic:bp/dynamic-dnsmasq,n,z work, python reviews are stalled 16:23:27 and also we are working on support of IP ranges for all networks in Nailgun 16:23:50 my personal pain, yay! 16:24:09 :) 16:24:20 any questions? 16:24:34 anything to note in the stats? There is some complete + some new. Is the flow sill manageable? 16:24:56 we have an open backlog 16:25:04 I know its never ending =/ 16:25:12 and each monday we re-prioritize our tasks 16:25:21 with our Products 16:25:46 thanks 16:26:05 please fill free to mark new bug-feature requests with "feature" tag 16:26:30 #topic UI team status (jaranovich) 16:26:40 Hi 16:26:40 Tthis week we have mostly switched from bugfix to feature development. 16:26:40 We are actively developing the following blueprints: https://blueprints.launchpad.net/fuel/+spec/multirack-in-fuel-ui (green feature health) which inсludes several user stories for Fuel UI, https://blueprints.launchpad.net/fuel/+spec/segment-settings-tab-logically (green feature health) and 16:26:40 https://blueprints.launchpad.net/fuel/+spec/ip-ranges-for-all-networks-in-ui. 16:26:40 Corresponding specs are actively reviewed, bdudko is doing visual mockups and requests with appropriate code also exist. 16:26:41 For now it seems, we able to deliver user stories planned for this 2nd iteration. 16:26:41 That's it. 16:27:57 jaranovich: thanks 16:28:48 #topic Remove obsolete releases code in serializers and tests (and some other places) 16:29:12 looks like ogelbukh's color maybe 16:29:29 ogelbukh: around ? 16:29:30 it is 16:29:38 ikalnitsky: o/ 16:29:56 will you describe your concerns? 16:30:34 the reason I'm asking is because I want to reuse pending_release_id parameter in cluster model 16:30:53 it is created and used for (obsolete) patching feature which I want to remove 16:31:03 yep 16:31:07 or partially replace 16:31:08 it must gone from our code base 16:31:34 but I've seen lots of 5.x stuff here and there 16:32:02 I think just file a bug for it and describe problem areas a little more detailed and if you see it start removing it 16:32:03 when tried to set openstack_version to different values :) 16:32:13 I thin every one is +1 to removing dead code 16:32:17 xarses: sounds like a plan 16:32:20 s/thin/think 16:32:33 OK, will start there and continue if have spare time 16:32:35 but we need to establish some policy (if we don't have one) 16:32:42 seems like we don't 16:32:48 how long we should support old releases? 16:33:01 one release/year? two? 16:33:01 I don't think that it's about support, in fact 16:33:28 but if we remove 5.x serializers, users won't be able to manage their old envs 16:33:34 we only 'support' current release 16:33:49 because others are unavailable/non-deployable 16:33:50 but we allow to manage (add/remove nodes) to old ones 16:34:12 there's backwards compatibility break between 5.1.1 and 6.0 16:34:44 5.1.1 stored modules under /etc/puppet/modules, while 6.0 introduces /etc/puppet/${version}/modules notation 16:34:55 (same for manifests/) 16:34:59 that's why we have a plenty of hacks 16:35:03 in fuel_upgrade script 16:35:07 I think we answered the how long question before, we need to deprecate in release and then remove in a following release, but we still need a bug to discuss this further 16:35:25 yes, we need one 16:35:32 maybe blueprint even 16:35:52 if we're talking about removing old serializers- i think bug is ok 16:35:53 I will create something 16:36:00 ogelbukh: thanks 16:36:09 thanks 16:36:13 could move one 16:36:16 *move on 16:36:16 #topic Config data processing system discussion (ogelbukh) 16:36:36 okay, that's another topic that we're going to discuss offline 16:36:50 but I wanted to give a heads up on it 16:36:58 we have ML thread about this 16:37:16 link? 16:37:46 the main idea is to replace/wrap serializers we now have so we could manage metadata used by components in more dynamic manner 16:38:13 #link http://lists.openstack.org/pipermail/openstack-dev/2015-October/077286.html 16:39:07 ok thanks 16:39:10 #topic Open discussion 16:39:24 any other items to raise before closing the meeting? 16:40:35 not from my side 16:40:42 ok thanks all 16:40:47 #endmeeting