16:00:29 #startmeeting Fuel 16:00:31 Meeting started Thu Dec 18 16:00:29 2014 UTC and is due to finish in 60 minutes. The chair is kozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:35 The meeting name has been set to 'fuel' 16:00:38 hi everyone 16:00:45 #chair kozhukalov 16:00:45 hi 16:00:45 Current chairs: kozhukalov 16:00:56 agenda as usual 16:01:03 hi 16:01:06 hey 16:01:06 #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda 16:01:13 hey 16:01:17 hi 16:01:28 #topic Announcements (dpyzhov) 16:02:51 hi 16:03:01 dpyzhov: around? 16:03:08 Hi. I’m pretty busy with agile trainings these days. As I see, we are pretty close to finally release 6.0 16:03:33 There are 3 High bugs in progress 16:03:47 #link https://bugs.launchpad.net/fuel/+bug/1403798 16:03:53 Launchpad bug 1403798 in fuel "[Upgrade] Upgrade of fuel failed on upgrading openstack stage withHTTPError: 401 Client Error: Unauthorized " [High,In progress] 16:03:59 This one should be moved to 6.1 16:04:13 #link https://bugs.launchpad.net/fuel/6.0.x/+bug/1402641 16:04:14 Launchpad bug 1402641 in fuel/6.0.x "No logs from neutron openvswitch agent" [High,In progress] 16:04:19 #link https://bugs.launchpad.net/fuel/6.0.x/+bug/1393557 16:04:22 Launchpad bug 1393557 in fuel/6.0.x "Quick Start scripts cannot locate Fuel ISO in 'iso' directory when executed inside Cygwin" [High,In progress] 16:04:29 I’m not sure about this bugs 16:04:42 But we have a rule to merge only Critical bugfixes 16:05:21 Does anyone has info about this bugs? 16:05:58 looks like there are no criticals 16:05:59 virtualbox scripts are not shipped with the iso, so we can fix them on master and publish that 16:06:50 AFAIK, bug with logs should be mentioned in release notes and moved to 6.1 16:06:59 +1 16:07:03 So for me it looks like we are ready for new RC 16:07:28 do you mean we keep #56? 16:07:42 yep it is rc3 16:08:01 do we have any merged fixes after #56? 16:08:32 no logs from neutron agent? its that in master or locally or at all? 16:08:57 xarses: on master. Actually logs are on master node. But in wrong place 16:09:15 ok, but they are somewhere 16:09:41 xarses: yes 16:09:48 also we've got similar bug with sahara https://bugs.launchpad.net/fuel/+bug/1403877 16:09:51 Launchpad bug 1403877 in fuel/6.1.x "Sahara logs don't present in UI because it was renamed to "sahara-all"" [Medium,In progress] 16:09:56 ok thx, editing name to reflect that 16:09:57 any risk of those logs, due to being in the wrong place not getting rotated leading to out of disk space eventually? 16:10:02 User have to log in to the master node and read the file locally 16:10:15 It is a really annoying bug, but not Critical 16:10:37 the only changes we have merged since #56 are two commits in fuel-main 16:11:10 angdraug: anything critical? 16:11:15 i fixed name to make it not sound critical 16:11:20 #link https://review.openstack.org/142511 16:11:22 docaedo, unmatched logs are still at /var/log/remote of master node and this dir rotated as always 16:11:28 #link https://bugs.launchpad.net/fuel/6.0.x/+bug/1402641 16:11:33 Launchpad bug 1402641 in fuel/6.0.x "No logs from neutron openvswitch agent" [High,In progress] 16:11:36 #link https://review.openstack.org/142483 16:12:03 angdraug: I see only test fixes 16:12:11 yes, Medium and High priority 16:12:30 so no, nothing Critical 16:12:47 excellent, we don’t need to respin RC =) 16:13:14 I don’t see nurla in the meeting. Does anyone know status of our acceptance tests? 16:14:44 Looks like raw estimate is about a week for testing 16:14:58 Unfortunately there is noone here to confirm 16:15:47 dpyzhov, thanks 16:15:53 are you done? 16:16:07 thats all from my side 16:16:20 ok, moving on then 16:16:25 #topic Ubuntu 14.04 update (msemenov) 16:16:32 hi all 16:16:42 So, it's official - we are moving to Ubuntu 14.04 (trusty) in 6.1 scope 16:16:50 Now we can build ISO with trusty based on 6.0 branch 16:16:57 Alexei Sheplyakov is working on it (asheplyakov) 16:17:04 There is a heap of requests related to trusty 16:17:12 #link https://review.openstack.org/#/c/138010 16:17:12 #link https://review.openstack.org/#/c/138110 16:17:12 #link https://review.openstack.org/#/c/138298 16:17:12 #link https://review.openstack.org/#/c/142404 16:17:12 #link https://review.openstack.org/#/c/142405 16:17:13 #link https://review.openstack.org/#/c/142406 16:17:14 #link https://review.openstack.org/#/c/142407 16:17:16 #link https://review.openstack.org/#/c/142408 16:17:20 For these and further requests we need assistance of fuel-main and fuel-library teams 16:17:28 I mean review and some help if it's needed 16:17:43 Also, today we scheduled a weekly cross-team sync up about Ubuntu 14.04 in MOS 6.0 16:17:52 msemenov: unfortunately, i did not have time today to review them 16:18:05 msemenov: were you able to deploy on 14.04 with these fixes? 16:18:06 i hope tomorrow i will 16:18:51 dpyzhov: I think no, today we can just build iso and boot the master node. I'm not sure about the whole deploy 16:19:22 msemenov: Ok, looking forward for it 16:19:26 ok 16:20:17 any other questions on this topic? 16:20:54 wait wait wait 16:20:55 msemenov: we’ll review patches 16:20:59 fuel master node on Ubuntu? 16:21:45 no, ISO containing trusty 16:22:02 oh just meeting requirements based on Trusty. got it 16:22:04 deployment on the nodes doesn't work well 16:22:29 because of astute problems for example 16:23:01 https://bugs.launchpad.net/mos/+bug/1385079 16:23:03 Launchpad bug 1385079 in mos "astute erroneously decides that puppet on nodes has hung and aborts the deployment" [High,Triaged] 16:24:22 msemenov: ok, looks like it is a wise decision to move this feature to 6.1 16:24:32 moving on? 16:24:38 + 16:24:52 #topic Artifact based build process (nmarkov) 16:25:19 so, I'm already working on POC of build system for several days 16:25:58 it's not really ready to show right now, but kozhukalov is also monitoring progress and we made multiple important architecture decisions 16:26:15 #link https://review.openstack.org/#/c/138994/2/specs/6.1/artifact-based-build-system.rst 16:26:31 good to hear we are on the same page about its design now 16:26:38 also, there were a couple of meetings with OSCI team on how their system is building packages and how we can integrate together in the future 16:26:54 kozhukalov, mostly, yes 16:26:56 angdraug: yes, thanks for link 16:27:34 so, our current target is to provide somewhat working POC next week and maybe some beautiful scheme of how it will work 16:27:42 apart from spec itself 16:28:25 meow-nofer: ok, when ready, please ping me earlier to assist with assemblingPOC infrastructure 16:28:28 is there a transition plan? 16:28:30 as for me, current code looks promising, but I'm its author and may be not objective 16:28:42 kozhukalov have a side look 16:29:00 is it going to be a gradual transition or a single point where we introduce all artefacts? 16:29:09 angdraug, transition from make, you mean? 16:29:13 yes 16:29:24 angdraug: gradual 16:29:30 angdraug, first of all, we'll be able to run our system on top of make 16:29:42 and then move on step by step with no hurry 16:29:51 at first we are going to split make system into a set of independent parts 16:30:07 and create a set of jenkins jobs for them 16:30:53 next step is to run make scripts from inside new build system 16:30:56 the first achievement should be, we'll be able to build ISO much faster than we do it now 16:31:52 meow-nofer: i think there will be many many questions during POC presentation 16:32:20 sounds good, looking forward to see the POC 16:32:22 kozhukalov, sure, but as for me, our current implementation is as simple as an axe 16:32:44 meow-nofer: we need to start documenting architecture as well as cases 16:32:51 kozhukalov, and test it 16:33:30 unit testing is strongly required before we'll run something "in production" 16:33:38 that's all from me on topic 16:33:44 ok 16:33:47 thanks 16:33:52 moving 16:34:06 #topic Open discussion 16:34:29 does anyone has any q? 16:34:34 #link https://blueprints.launchpad.net/fuel/+spec/merge-openstack-puppet-modules 16:34:50 can we talk about breaking up this bp? 16:35:29 I think it's an ongoing effort, and since it's not something that requires much design discussions, we can track it as bugs 16:35:49 one bug per module, e.g. "update puppet-haproxy to 0.9.0" 16:35:53 aglarendil: around? 16:36:29 aglarendil raised a point over email that we agreed not to track non-defect work in bugs 16:37:03 I think we should be pragmatic about this case 16:37:40 (just to be clear, I think pacemaker-improvements should still be tracked in blueprints, not bugs) 16:37:53 thoughts anyone? 16:38:17 There are 2 types of blueprints 16:38:24 simple and complex 16:38:44 a complex blueprint must have a specification 16:38:52 but a simple one doesn't 16:39:23 we can track little improvements as simple blueprints 16:39:36 good point 16:39:51 and let developer to file and implement them after FF but before SCF 16:40:22 that far, I wouldn't go 16:40:36 is there special field in BP (simple or complex) or it is on BP reporter? how can i know which of them are simple? 16:40:41 I'm quite ok with not doing upstream manifest merges after FF 16:41:08 kozhukalov: I guess it just wouldn't have a link to specification 16:41:57 angdraug: or maybe it is better to put that into description template we use now for all our BPs 16:42:07 angdraug, kozhukalov: we can explicitly specify that it’s a simple BP w/o spec 16:42:28 i think this is not angdraug's point 16:42:32 yes, explicitly specifying is better, would help to tell if we don't need a spec or simply haven't created a spec yet 16:42:41 we run massive bp cycle over cycle 16:42:43 its bad 16:42:50 its hard to trak 16:43:05 xarses: I think even aglarendil has agreed that it's bad, based on his email from this morning :) 16:43:15 =) 16:43:46 the only downside with tracking upstream merges as simple bp's instead of bugs is that there'll be a lot of them 16:44:06 (hopfully :) 16:44:29 adanin: could you please put your idea about simple/complex BPs to ML thread 16:44:32 ? 16:44:46 aren't we going to eventually stop merging upstream altogether though 16:44:47 kozhukalov: yes, I will 16:45:17 as I mentioned on that thread, we can only stop merging upstream when we continuously use latest upstream 16:46:00 and that's definitely not in scope for 6.1 16:46:30 angdraug: is it possible? isn't that going to break anything? i mean using latest upstream 16:46:47 it is possible in theory, but a lot of work to get there in practice 16:47:15 most of the changes we do to upstream manifests can either be pushed to upstream, or moved to the openstack module 16:47:53 +1 16:47:54 not to mention that we'll need a much better ci for puppet modules 16:48:13 so that we can quickly catch and fix breakage introduced by upstream changes 16:48:28 same as we currently beginning to do with openstack master in mos 16:48:38 angdraug: and if you are going to push your changes to upstream it means you are going to slow down your development process, am i right? 16:49:11 kozhukalov: if you move most of your customizations to openstack module, you won't have to push to upstream that often 16:49:19 nope, we can push change upstream and apply it on our copy of module 16:49:39 you can implement an external fix first, then propose native fix to upstream, then remove external fix when upstream version having your fix lands 16:49:50 and what alex_didenko said, too 16:50:20 ok, sounds like a great plan 16:50:25 before we consider that we need to meet 2 large goals 16:50:32 1) finish catching up to upstream 16:50:41 2) expand scope of ci for fuel-library 16:50:58 that's why I don't think we can even consider this in 6.1 16:51:19 yes, it is not so easy 16:51:36 I think we're done with this topic, anyone else for open discussion? 16:51:42 o/ 16:52:01 OKosse: hi 16:52:05 We've already finished acceptance tests of vcenter , vcenter+glance, nsx, vcenter+vlan on rc2. We are in progress of testing our features on rc3. we have 3 bugs in progress and moved to 6.1, but they are not critical 16:52:05 OKosse: please 16:52:29 that's great news 16:53:46 OKosse: good to hear, thanks 16:53:56 anything else? 16:54:18 looks like we are done 16:54:34 thanks everyone 16:54:36 closing 16:54:42 #endmeeting