16:01:09 #startmeeting fuel 16:01:10 Meeting started Thu Jun 12 16:01:09 2014 UTC and is due to finish in 60 minutes. The chair is mihgen. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:14 The meeting name has been set to 'fuel' 16:01:19 hi Fuelers 16:01:32 #topic Announcements 16:02:00 we've released 4.1.1 this week, congratulations to everyone 16:02:06 many HA fixes were backported 16:02:24 due to my long trip I've not set tags in repo yet, but will do soon 16:02:39 Folks, I'm still worried about bugs in master 16:02:46 we need bug squashing day I think 16:03:11 I propose Tu next week to bring a team together and squash bugs 16:03:11 Hi 16:03:20 hi 16:03:31 we have 300 of them with many in non-confirmed/triaged state 16:03:52 any objections? ideas? 16:04:12 bug squashing day would be nice 16:04:17 bug squashing day sounds good, as long as it's next week :) 16:05:15 hi all 16:05:16 cool 16:05:18 #action mihgen to send an email to ML about bug squashing day on Tu next week 16:05:34 after bug squashing day we need a review-day 16:05:48 Actually I think we actually need to combine 16:05:55 ikalnitsky: so I agree 16:06:06 and some folks can do bug confirming /triaging 16:06:10 some will do fixing 16:06:15 and some - reviews 16:07:05 I suggest to not invent a wheel here and follow openstack practices - will provide in email, if it doesn't work for us - we will come up with adjustcemements 16:07:31 Ok. next topic - let me provide ideas regarding our focus for 5.1 16:08:13 After going through design docs, talking to the team, we have identified how many folks can work full time and how much we can cover 16:08:27 obviously not everything as we wish 16:09:05 so Fuelers, let's concentrate our efforts on a few essential for 5.1 things, and the rest if possible: 16:09:19 1) upgrade 5.0 -> 5.0.1, 5.0.1 -> 5.1; 2) patching of openstack 16:09:31 3) authx master node: https://blueprints.launchpad.net/fuel/+spec/access-control-master-node; 4) ML2 support 16:09:37 5) deploy openstack from master 16:09:58 these are user-facing things 16:10:04 5? 16:10:20 we also have a few essential sustaining things, e.g. fixes to HA 16:10:44 I've updated blueprints priorities to reflect it - you will see all with essential status 16:10:46 salmon_: 5 is essential for our ability to have 6.0 with juno code before is release 16:10:54 before it is released.. 16:10:56 ah, master branch 16:10:57 ok 16:11:19 mihgen: https://blueprints.launchpad.net/fuel/+spec/multiple-cluster-networks ? 16:11:30 #link https://launchpad.net/fuel/+milestone/5.1 blueprints for 5.1 16:11:38 angdraug: nope, decreased priority 16:12:11 reason is simple: let's make Fuel work ideally with <50 nodes first, and multiple cluster network is actually when you care about hundreds 16:12:22 or at least > 2 racks of servers 16:12:57 it is still High priority and intersects with refactoring of nailgun networking stuff I assume 16:13:20 any other blueprints I'm missing here which should be essential you think? 16:13:24 mihgen: we are going to get alot of push back about that, several large groups are very interested 16:13:32 zabbix, too 16:13:51 yes, zabbix 16:13:59 * odyssey4me agrees 16:14:00 just like multiple-cluster-networks, it is almost ready for merge 16:14:01 xarses: I understand. but do you agree that it's after those 5 at least? 16:14:39 mihgen: it could be #6, ya 16:14:41 priority wise, yes, but each of those 5 is a big and disruptive piece of work 16:14:45 rmoe: angdraug: zabbix is High. My expectation that we will make it in experimental mode first. It's literally almost ready for merge 16:14:46 is #3 such a high priority? 16:15:52 angdraug: if multiple-cluster-networks are almost ready, I've nothing against. However, remember that for production readiness we need to add many things to it, like acceptance testing (automated with devops), docs, etc. 16:16:08 odyssey4me: it's security. should be #1 except #1 and #2 are things that were on the top of our priorities for 3 releases now 16:16:14 we need that code anyway, but we can skip claiming it as a feature for now 16:16:34 experimental mode it is :) 16:16:43 angdraug: odyssey4me: yep, security.. 16:16:54 for multiple-cluster-networks there are also more changes beyond what's in the first review 16:16:56 actually users keep complaining it's insecure 16:17:11 however you can always workaround by placing master node in separate L2 16:17:25 but looks like it's time to finally fix it.. 16:18:00 alright - it's simple enough to manage in other ways, but I do acknowledge that it's a good to-do... I'm only questioning whether it's essential to push for it this release. 16:18:08 The thing is that 3) authx requires us not only put authx in place, but also fix all iptables rules, etc., to securing everything 16:18:35 yup - it's a big, big job when you go beyond just putting some sort of auth in place 16:18:57 so we will need to put deployment engineers to fix it, and additional python resources perhaps 16:19:34 salmon_: so actually we would need to execute stage #3 & 4 from your design in 5.1, do you think it's possible to parallelize? 16:19:42 if add resources there? 16:20:03 mihgen: 4) ML2 support ? 16:20:24 grr, stae 3 & 4? 16:20:30 salmon_: nope, I'm about authx 16:20:41 don't think so. There are some open questions there 16:21:16 salmon_: ok. will need to discuss then... 16:21:42 #action mihgen to request details on whether we could parallelize the work on authx and complete it fully in 5.1 16:21:57 mihgen: stage 4 is about LDAP, many users groups... Why do we need yhis now? 16:22:00 salmon_: neutron ml3 plugin 16:22:11 salmon_: I don't think we need LDAP in 5.1 16:22:22 I'll review you it once again 16:22:28 mihgen: ok 16:23:09 Ok fuelers let's get a status on essential blueprints in the first order 16:23:32 1) upgrade of Fuel 5.0 -> 5.0.1 16:23:55 eveniyl is in charge, but it's holiday 16:24:06 ikalnitsky: do you know anything about it by any chance? 16:24:49 as far as i know, it almost done. in last few days evgeniyl just changed some parts in more convenient way 16:25:12 i even had a successful upgrade from 5.0 to 5.0.1 16:25:21 * mihgen forgetting about using IRC commands 16:25:31 #topic upgrade of Fuel feature status 16:25:50 ikalnitsky: cool. Do you know about QA automation for it? 16:26:03 anyone from QA team here? 16:26:11 unfortunately, i know nothing about qa 16:27:13 ok, thanks for what you know. Let's move on 16:27:25 #topic Patching of OpenStack feature status 16:27:32 ikalnitsky: back to you again ) 16:28:05 today i have finally run the tarball with upgrades to patch openstack and it was done successfully. 16:28:17 unfortunately, i've met some problems 16:28:43 afaik, some of them are known and will be fixed by library team. 16:28:50 ikalnitsky: sounds that it is very close to be fully ready 16:28:57 some of them, i'll fix tomorrow 16:29:07 do you see any risks to complete it in time ensuring a great quality? 16:29:27 we can't break users workloads.. otherwise they will hate us forever ) 16:29:30 for now, i don't see such things. 16:29:45 there's a one thing with rollbacking patch 16:29:55 i need to discuss it with Dmitry I. 16:30:07 there's a manifest and i don't know who have to generate it 16:30:23 that's all 16:30:40 ok. sounds like a missing piece in design. dilyin is on holiday.. 16:31:08 ikalnitsky: > run the tarball with upgrades to patch openstack and it was done successfully - did you run upgrade tarball to get patching done? 16:31:11 can you please clarify 16:31:30 my expectation is that you run tarball to upgrade / add new release info 16:31:37 and then you run patching from Fuel UI 16:32:03 like you have existing env, and on Actions tab you choose what version of OpenStack you would like to update it to 16:32:35 yeah, sure. but this tarball has additional stuff: puppet manifests/modules, repos and so one. this stuff have to be installed. 16:33:20 ikalnitsky: yep, that's my understanding. Very well, thanks. 16:33:24 i mean that i've finally install this stuff with some fixes and run upgrade from ui 16:33:25 what about system tests for this? 16:33:36 cool 16:33:40 i didn't run it yet 16:33:53 ikalnitsky: do we only have new puppet because we don't have puppet upstream yet? 16:33:57 who is assigned to do QA of design /implementation? 16:34:12 ie if we have puppet upstream, do you need it in the tar? 16:34:49 Tatyana is QA but looks like she is not here 16:34:59 good question … 16:35:14 xarses: i'm not sure, but as far as i know we need it in tarball to make different upgrades. for example: 5.1 -> 6.0 or 5.1 -> 5.2 16:35:30 Tatyana or Andrey (who is not here too) 16:35:41 ykotko: thanks 16:35:52 hmm I don't quite follow the question about puppet 16:36:24 xarses: do we have it in upgrade package always, is that what you mean? 16:36:46 i thought we where talking about patching openstack 16:36:57 xarses: yes, we are 16:36:58 didn't think we needed alot of manifest around it 16:37:13 xarses: we may need them 16:37:18 the thing is that we need to upgrade Fuel first to introduce packages 16:37:20 so we need to be prepared 16:37:23 and possilby manifests 16:37:24 I only thought it would be needed more when we upgrade fuel version 16:37:26 to make patching 16:37:48 mihgen: ya, i figured that out 16:38:23 ok folks let's get details in #fuel-dev, we need to move on now, ikalnitsky - thanks for status, looks like we are in good shape 16:38:35 the only thing unclear to me is QA, but I'll figure it out 16:39:12 #topic Securing Fuel master node, authentication for UI and REST API 16:39:21 #link https://blueprints.launchpad.net/fuel/+spec/access-control-master-node 16:39:28 there is still some disqusion about blueprint, but in the meantime I'm working on installing/using keystone. Vitaly prepared GUI part, Matt prepared code for integration with fuelmenu. Stage I should be ready soon. 16:40:38 salmon_: very good. I'll provide my answers regarding stage 3/4 soon 16:40:49 any risk items? 16:41:23 mihgen: for now I don't see any 16:41:30 ok, thanks 16:41:33 #topic ML2 support in Neutron 16:41:48 research into ml2 plugin is done, design doc is nearly done (today), started sorting out differences between upstream puppet module https://github.com/xarses/puppet-neutron/compare/fuel-neutron?expand=1 16:42:09 xarses: cool. Where is the design doc? 16:42:19 omg diff is huge 16:42:28 it will get smaller still 16:42:33 but it was twice as big 16:42:56 xarses, We have task to update our manifests to upstream so it’s related to ml2 too 16:43:01 ok.. how risky do you think to play this game with syncing upstream manifests? 16:43:28 holser: my expectation is that xarses is actually doing exactly this 16:43:37 I see 16:43:43 syncing upstream neutron to get upstream ml2 support 16:43:46 mihgen: holser: yes, that's what he's doing 16:43:51 and fix remaining issues 16:43:56 looking at it, most of our changes are deprecated, the only main risk i think is with keeping HA support 16:44:28 xarses: whoops.. we need to start thinking about it in parallel. Did you talk to xenolog about it? 16:44:50 just static analysis of code might help .. 16:44:55 I was speaking with puppet-openstack folks yesterday, and we agree that it should probably be in an outside wrapper module. I also found out that we don't need to use pacemaker for DHCP-agent HA 16:45:15 holser: yes, pulling upstream module is the goal 16:46:00 mihgen: no, I'll start now that the design doc is mostly done 16:46:00 xarses: ok. please sync with xenolog on regular basis.. dhcp agent ha might be there for a reason. all this ha stuff is always tricky 16:46:34 Ok thanks for status. Looking forward to see it in action.. 16:46:45 moving on 16:46:50 mihgen: we don't need to do it with pacemaker since grizzly, dhcp-agent is internally HA ready 16:47:19 xarses: hmm ok. I trust you guys in such details :) 16:47:27 #topic deploy openstack from master 16:47:41 rvyalov is in charge, he is holiday though 16:48:10 I know a bit about it. the idea is to modify our build system so the Fuel should be able to build openstack packages on the fly 16:48:20 using our spec files and upstream openstack code 16:48:47 so it's slow progressing, gerrit / CI for it are still in design phase I believe 16:49:10 moving on 16:49:18 mihgen: I'm working on this feature. It's still on the PoC stage, I plan to get PoC working tomorrow 16:49:40 oh dude that's cool 16:49:54 brain461: sorry actually you are assignee for that blueprint 16:50:05 yep 16:50:37 brain461: very good. We really need this feature for our community presence and for full CI/CD with openstack upstream 16:50:55 brain461: I hope you guys gonna use Infra's stuff to get gerrit up and running for it 16:51:09 ok, moving on, not much time left.. 16:51:12 #topic Galera HA and other HA improvements 16:51:21 holser: can you provide the status pls 16:51:44 Galera HA improvements I meant :) 16:52:15 We had meetings regarding Rabbit so I was helping bogdando 16:52:40 Galera is still in progress, thinking to finish it by end of week and commit 16:53:10 also it requires cs_shadow removal 16:53:11 good. Will it fix the issue of rebuild in case of power outage of whole cluster? 16:53:54 didn’t have chance to talk to Dmitry Illyn regarding that 16:54:13 I ripped out all cs_shadow for now 16:54:25 to be able to test Galera 16:54:28 holser: ok, please do.. power outage may happen in small installs.. 16:54:45 k 16:54:55 that’s all from me 16:55:01 ok thanks. moving on 16:55:03 #topic Mellanox features support 16:55:14 do we have anyone from Mellanox around? 16:55:29 yes 16:55:50 aviramb: hi, can you provide a short update on where we are ? 16:56:04 did you get reviews for design doc? 16:56:12 mihgen: yes thanks 16:56:28 mihgen: any more reviewers are welcome 16:56:48 yep, I think we need to get someone with networking background.. 16:56:59 aviramb: looks nice 16:57:13 besides reviews, what are the next steps now? 16:57:18 mihgen: that would be great, we are at the end of our POC based on the master and ML2 plugin (manually) 16:57:22 I was confused, do you need neutron ML2 plugin. the title implies you do 16:57:31 ahh ok 16:57:45 ok that was my question too 16:57:48 mihgen: next steps - finish automating drivers installation (made custom small package of MLNX_OFED) 16:57:59 mihgen: there is a 4.1 iso with it 16:58:01 actually we need to mark blueprint then as dependent on ml2 16:58:01 mihgen: and integrate to fuel-library 16:58:03 and a nice write up 16:58:16 mihgen: yes 16:58:22 aviramb: will it require any nailgun/UI changes? 16:58:30 #link http://community.mellanox.com/docs/DOC-1449?et=watches.email.document 16:58:49 mihgen: yes, new section for installing mellanox SRIOV plugin or just drivers 16:59:10 mihgen: and iSER support (iSCSI over RDMA) 16:59:26 need to wrap up the meeting.. I have a few more questions but will add them in the design doc then 16:59:30 mihgen: checkbox, near iSCSI (in storage section) 16:59:45 aviramb: ok, I see. Thanks for the status 17:00:05 folks as usual any unaddressed things can be continued in #fuel-dev 17:00:14 thanks everyone for participation! 17:00:18 #endmeeting