16:00:46 #startmeeting fuel 16:00:46 Meeting started Thu Jul 9 16:00:46 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:46 #chair xarses 16:00:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:50 The meeting name has been set to 'fuel' 16:00:51 Current chairs: xarses 16:00:59 Todays Agenda: 16:01:00 #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda 16:01:34 hi, who's here? 16:01:37 hola 16:02:05 hi 16:02:09 hi 16:02:44 lets get started 16:03:24 #topic Seperate criteria for UX bug priority (xarses) 16:03:53 We often have bugs which create really poor User eXperience (UX) but our current bug priority criteria prevent nearly all of them from being higher than medium. We need to identify what should qualify as a critical, or high UX defect so that they can receive appropriate attention. 16:04:36 I was wondering how we should define them so that they can receive appropriate attention 16:04:47 hi 16:05:18 hi 16:05:59 can we use the size of the workaround required to rank them? 16:06:07 or at least the method 16:06:23 like custom node yaml = high? 16:06:30 like if an alternate command should be used (and must be documented) then it's a medium, but if you have to hack any files high+ 16:06:50 for me custom yaml or anything is high+ 16:07:08 that kind of stuff is confusing and very error prone 16:07:28 we can barely make custom node yaml work, so I agree 16:07:36 +1 from me too 16:08:35 so I think we can critical, requires massive effort to work around including un/under documented commands and config files 16:09:04 sounds reasonable 16:09:32 high could be modification of config files including custom node yaml, but is documented 16:09:57 medium would be straight forward commands in the cli 16:10:28 ok, I will write up this and pass it around on the ML for further comment 16:10:45 moving on 16:10:51 #topic flexible networking (akasatkin) 16:11:03 spec: https://review.openstack.org/#/c/195109/ 16:11:04 network roles descriptions are merged so we can move with them to remove 16:11:04 hardcode from serializer, rework allocation of VIPs, proceed with verification 16:11:04 of network roles in template. 16:11:12 tasks in progress: 16:11:12 Nailgun: complete templates API and serialization, removing of hardcode from serializer, Nova-Network support in Nailgun 16:11:12 Library: network roles separation, no-op tests, test Nova-Network 16:11:12 QA: test Nova-Network, templates, writing tests for templates 16:11:22 Observed issue with Nova-Network: https://bugs.launchpad.net/fuel/+bug/1472529 16:11:22 Launchpad bug 1472529 in Fuel for OpenStack "[kilo] Swarm tests for nova network on ubunru failed on openstack-controller with No ability to determine if nova_floating_range exists " [Critical,In progress] - Assigned to Ivan Berezovskiy (iberezovskiy) 16:11:22 Successful deployment with templates is not confirmed for now. But we had successful deployment before Kilo was merged. 16:11:22 It takes time to separate issues with our code from issues with recently merged Kilo. 16:11:22 Now we don't have our CI green, it is a merge blocker for library team. 16:12:30 akasatkin: are we on track for landing before SCF? 16:12:52 do you need anything from other teams? 16:12:57 yes, if we'll get our CI green recently 16:13:39 fantastic 16:13:43 no, apparently, additional help is now strongly required but we could land some more into nailgun.. 16:14:03 not strongly required 16:14:15 so we need more reviewers in nailgun 16:14:27 ok, lets poke some people if thats the case 16:14:30 we could cover more flexible story if any... 16:14:59 yep, reviewes are welcome 16:15:02 Help from Murano team may be required. 16:15:38 xenolog: what do we need? 16:15:46 I will request it. if required, at monday 16:15:58 ok boris sits behind me now 16:16:25 ok moving on 16:16:30 #topic removing classic provisioning (agordeev) 16:16:40 hi 16:16:42 Moving RMQ to a dedicated network may affect their infractructure. 16:16:53 Feature implementation is mostly done. 16:16:55 Proposed change was merged just yesterday. 16:16:57 QA will try the feature within few days, once 7.0 ISO becomes more stable. It's too tricky to get operatable ISO these days due to Kilo has been merged. 16:18:47 agordeev: so do you have any blockers you want to raise? 16:19:05 xarses: nope, i don't have any 16:19:20 fantastic, let us know if it changes 16:19:51 moving on 16:19:57 #topic Granular deployment (mattymo) 16:20:04 thanks xarses 16:20:09 We've overcome many of our nailgun issues and gotten everything related to to plugins merged. I have a working initial plugin here. 16:20:13 https://github.com/mattymo/detach-db 16:20:40 It works overall, but there are some glitches in our haproxy manifests that require tweaks. mwhahaha is working on straightening that out 16:21:04 and dilyin is working on fixing our top level task for virtual_ips to make that more flexible with what's in hiera 16:21:05 cool, do we have a separate plugin with just the override function in it? 16:21:18 a separate plugin for just override hiera doesn't make a lot of sense... 16:21:28 xarses, each plugin would need its own override 16:21:35 I've been talking with some people about it for other cases 16:21:44 it would be good to have it as an example 16:22:00 yeah, this is just an example. I expect we'll get this example even simpler after we clean up haproxy and vips 16:22:06 it also makes custom node yaml function nearly obsolete 16:22:11 Little to report this week about project progress, except for finding some new holes (VIPs and haproxy tasks) in our separating work in fuel-library. 16:22:19 The light at the end of the tunnel is very close. We're nearly ready for the keystone client-driven endpoint/user creation to be merged, but we had some requirements shift at the end of last week, and we have to refactor a bit more. 16:22:19 The next big jump is separate neutron and its agents, which started development this week. 16:22:20 (it really does with network templates) 16:22:43 mattymo: any other issues / blockers ? 16:22:51 besides haproxy 16:23:10 we're not blocked by custom VIPs, node roles, etc, because we have workarounds 16:23:21 but they will be delivered by feature freeze 16:23:45 OSTF workaround still needs to be tested.. so I'll report on that probably early next week 16:24:00 any adverse impact expected from them landing? 16:24:11 I hope not :) 16:24:19 ok 16:24:45 moving on 16:24:51 thats the end of the schedule 16:24:55 #topic open discussion 16:25:08 anything anyone wants to raise / discuss? 16:26:28 xarses, I saw part of your demo on multiple l3 16:26:43 xarses, any plans to add a deploy mode to vbox scripts? 16:27:24 mattymo: I'm not sure that It will be easy to setup. I spoke with rmoe at length to improve the story in kvm, it's hard there too. 16:27:46 I'm gonna work through the video and prepare a writeup / blog post / docs 16:27:53 xarses, okay. let's move that to a mailing list thread 16:27:55 maybe record another video to share externally 16:28:37 at that point we may have enough people on board with the topic to help getting it setup in virtualbox 16:28:42 sounds good 16:29:14 if there's nothing else. I'll close the meeting 16:29:24 in a minute 16:31:11 ok thanks guys 16:31:18 #endmeeting