16:01:43 <vkozhukalov> #startmeeting Fuel 16:01:44 <openstack> Meeting started Thu Aug 7 16:01:43 2014 UTC and is due to finish in 60 minutes. The chair is vkozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:48 <openstack> The meeting name has been set to 'fuel' 16:01:50 <vkozhukalov> #chair vkozhukalov 16:01:51 <openstack> Current chairs: vkozhukalov 16:01:56 <angdraug> hi 16:02:01 <dpyzhov> hi 16:02:09 <vkozhukalov> #topic Greetings and announcements 16:02:18 <vkozhukalov> agenda as usual here 16:02:28 <vkozhukalov> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda 16:02:46 <vkozhukalov> #topic 5.0.1 bugs status 16:02:56 <vkozhukalov> nurla: around? 16:03:21 <angdraug> #link https://launchpad.net/fuel/+milestone/5.0.1 16:03:25 <angdraug> #link https://launchpad.net/mos/+milestone/5.0.1 16:03:35 <vkozhukalov> angdraug: thanx 16:03:48 <angdraug> I can see that rabbitmq ha bugs are still in progress 16:04:04 <angdraug> sounds like we won't have an RC today 16:04:27 <angdraug> there's a new Medium bug in 5.0.1 today: 16:04:32 <angdraug> #link https://bugs.launchpad.net/fuel/+bug/1353945 16:04:34 <uvirtbot> Launchpad bug 1353945 in fuel "Nailgun returns 500 error, amqp error: PLAIN login refused: user 'naily' - invalid credentials" [Medium,New] 16:04:43 <angdraug> anyone can explain what a Medium bug is doing in a stable release series? 16:05:10 <vkozhukalov> is it ok that it is medium? 16:05:34 <angdraug> looks like nurla thinks it's a one-off problem, so she downgraded it 16:05:48 <angdraug> I'll move it to 5.0.2 until it's confirmed to be a Critical 16:05:59 <vkozhukalov> angdraug: +1 16:06:09 <angdraug> that's it for 5.0.1 bugs 16:06:23 <vkozhukalov> everyone else: any objections? 16:06:34 <vkozhukalov> dpyzhov: around? 16:06:42 <vkozhukalov> what do you think? 16:06:55 <angdraug> is there some sort of holiday in Russia today? :) 16:07:05 <vkozhukalov> some sort ) 16:07:06 <angdraug> (aside from all bosses travelling) 16:07:14 <dpyzhov> vkozhukalov: I’m reading bug description 16:07:28 <vkozhukalov> couple of our colleagues are visiting a conference 16:07:28 <dpyzhov> no objection 16:07:42 <xarses> angdraug: we never talked about https://review.openstack.org/111010 16:08:01 <angdraug> xarses: +1 16:08:04 <xarses> Should it be in 5.0.1? 16:08:26 <dpyzhov> xarses: it required for patching and will be merged after 5.0.1 16:08:50 <xarses> yes, but if we dont have it, will it make downgrades (back to 5.0.1) harder? 16:09:01 <xarses> maybe even break them 16:09:07 <dpyzhov> we will install this fix on existing 5.0 and 5.0.1 environments during upgrade 16:09:37 <xarses> so, then we might as well include it in 5.0.1 anyway? 16:09:49 <vkozhukalov> evgeniyl: any information about that? 16:09:52 <dpyzhov> xarses: we need it fo 5.0 envs anyway 16:10:31 <evgeniyl> ikalnitsky: ^ 16:10:36 <dpyzhov> As I understand, this fix will not block downgrade 16:10:50 <dpyzhov> after downgrade user will have this patch on his environments 16:10:58 <xarses> ok, so we might as well merge it in 5.0.1 16:11:28 <dpyzhov> xarses: we might, but we don’t have to 16:12:06 <vkozhukalov> resume, 16:12:17 <vkozhukalov> we have 2 criticals for 5.0.1 16:12:43 <vkozhukalov> sorry, no valid criticals 16:12:59 <angdraug> we have 2 in mos, both related to oslo.messaging 16:13:19 <vkozhukalov> so, looks like there are no obstacles for RC 5.0.1 from Fuel side 16:13:30 <vkozhukalov> and 2 from MOS side 16:13:38 <angdraug> yes 16:14:06 <vkozhukalov> so we still can not make RC for 5.0.1 16:14:13 <angdraug> yes 16:14:14 <vkozhukalov> ok let's move on 16:14:27 <vkozhukalov> #topic 5.1 bugs status 16:14:32 <angdraug> we have 42 New bugs: 16:14:37 <angdraug> #link http://bit.ly/1m1AqTO 16:14:42 <angdraug> I think having New bugs that were raised more than 1 day ago is as bad as having red smoke tests in Jenkins 16:14:47 <angdraug> triaging New bugs should take priority over everything except fixing confirmed Critical bugs 16:15:00 <angdraug> we also still have 21 Medium/Low bugs targeted for 5.1, these should all go to 6.0 16:15:05 <angdraug> #link http://bit.ly/1u01qLB 16:15:13 <angdraug> our In Progress count has gone down from ~70 to ~40 over the last 2 weeks 16:15:20 <angdraug> #link http://bit.ly/1kKanWx 16:15:25 <angdraug> looks like we're running out of easy stuff, bugs take more time to fix 16:15:31 <angdraug> on the plus side, we're not wasting time with low priority bugs anymore :) 16:15:50 <angdraug> finally, we have at least 32 Critical/High bugs to fix before we can release 16:15:56 <angdraug> #link http://bit.ly/1toriAj 16:16:02 <angdraug> considering that we were supposed to have hard code freeze today, that's way too many 16:16:08 <angdraug> we should aim for having 0 Critical/High bugs left by this time next week 16:16:14 <angdraug> questions? 16:16:38 <vkozhukalov> angdraug: no questions ( 16:16:55 <vkozhukalov> hcf is out of the day 16:17:13 <vkozhukalov> dpyzhov: any comments? 16:18:09 <dpyzhov> vkozhukalov: 3 new criticals - no questions 16:18:31 <vkozhukalov> dpyzhov: estimations? 16:19:42 <angdraug> as I said, we ran out of simple bugs :( 16:19:55 <angdraug> probably hard to estimate how much time remaining bugs will take 16:19:56 <nurla> lets spin HCF according our politics about it 16:20:28 <angdraug> still, we should at least make sure there's no unassigned critical bugs and keep them updated daily 16:20:44 <angdraug> anyone not working on critical bugs should be triaging new bugs 16:20:53 <nurla> agree 16:21:15 <vkozhukalov> moving on? 16:21:19 <angdraug> yup 16:21:34 <vkozhukalov> #topic Features 16:21:44 <vkozhukalov> #topic patching OpenStack 16:21:57 <dpyzhov> #link https://etherpad.openstack.org/p/patching-status 16:22:18 <dpyzhov> We have several patches in stable/5.0 waiting for 5.0.1 release 16:22:38 <dpyzhov> Right now we have two issues 16:22:45 <dpyzhov> https://bugs.launchpad.net/fuel/+bug/1352896 16:22:48 <uvirtbot> Launchpad bug 1352896 in fuel "[update] Rollback failed with error in puppet about package verions" [Critical,Confirmed] 16:22:53 <dpyzhov> https://bugs.launchpad.net/fuel/+bug/1354050 16:22:54 <uvirtbot> Launchpad bug 1354050 in fuel "[Update] Patching fails on neutron enviroments" [Critical,Confirmed] 16:23:20 <dpyzhov> ci infrastructure is done 16:24:12 <vkozhukalov> ok 16:24:17 <vkozhukalov> thanx 16:24:20 <dpyzhov> qa is working on automated tests 16:24:53 <dpyzhov> thats all about status for patching 16:25:01 <vkozhukalov> moving 16:25:09 <nurla> yep, we've already created jobs for patching and update 16:25:27 <vkozhukalov> #topic 6.0 blueprints 16:26:00 <dpyzhov> Does anybody knows what this topic is about? =) 16:26:03 <angdraug> #link https://launchpad.net/fuel/+milestone/6.0 16:26:26 <dpyzhov> we have a lot of blueprints and we have limited time in 6.0 16:26:26 <angdraug> the topic is about your proposal on how to deal with them :) 16:26:33 <xarses> =) 16:26:42 <angdraug> personally, I vote in favor 16:26:50 <dpyzhov> So we should move part of them to future/next release 16:27:04 <angdraug> lets move everything to next and only target to 6.0 when blueprint was properly described 16:27:14 <tzn> +1 16:27:26 <xarses> and actually expected to be worked 16:27:32 <dpyzhov> I like this idea 16:27:42 <alex_didenko> +1 16:27:49 <xarses> +1 16:27:50 <dpyzhov> Let’s keep our release page clean 16:27:53 <angdraug> xarses: yes, our definition of "described" should include an assignee 16:28:17 <angdraug> we have a consensus! 16:28:23 <tzn> but what about bps that actually have assignees? 16:28:25 <vkozhukalov> I would say, not only properly described but also spec should be on review 16:28:42 <angdraug> vkozhukalov: +1 16:28:43 <nurla> and some PoC as minumum 16:28:53 <vkozhukalov> nurla: )) 16:29:01 <nurla> :) 16:29:10 <angdraug> tzn: if it has an assignee, their team lead should confirm the assignment, and unassign if it doesn't fit the schedule 16:29:53 <dpyzhov> Let’s move all blueprints without priorities or assignees out of 6.0 16:29:55 <xarses> part of the point of brining up bp's during SCF -> HCF is that we should attempt to take time every day to maybe review 1 bp, this way we are in shape to start work and dont spend alot of time waiting on others 16:30:49 <angdraug> xarses: yes, and first step is making sure that 6.0 only has BPs that really need being looked at 16:30:55 <xarses> =) 16:30:57 <angdraug> there's 124 there at the moment 16:31:27 <angdraug> I expect at most 10 that actually have enough info on them to stay there 16:31:28 <nurla> nice) 16:32:11 <angdraug> but yes, we shouldn't forget about BPs during code freeze 16:32:12 <vkozhukalov> i am not if we have enough people to implement all of them even if we assign a person for couple of blueprints 16:32:45 <angdraug> vkozhukalov: of course not, there's enough work there to keep us busy for a few years :) 16:33:17 <angdraug> so priorities, revised: 16:33:27 <vkozhukalov> ok looks like everyone agree to move most of those BPs to the future 16:33:54 <nurla> lets create 6.1 milestone? 16:33:55 <angdraug> 1) critical bugs; 2) new bugs; 3) blueprints (1 hour a day); 4) high priority bugs 16:34:06 <angdraug> nurla: no, we have "next" milestone for that 16:34:26 <dpyzhov> nurla: let’s have ‘next’ milestone and move blueprints from it during design session 16:34:27 <angdraug> lets finish with defining scope for 6.0 first 16:35:15 <nurla> next also have 82 BP) 16:35:28 <angdraug> next can have a 1000, it's our backlog 16:35:32 <vkozhukalov> angdraug: actually we can just think of 6.0 as next or future 16:36:09 <vkozhukalov> ok everyone agree 16:36:12 <angdraug> vkozhukalov: no, 6.0 and next should be different milestones in LP 16:36:36 <angdraug> the point is to scope 6.0 from 0 up to a list of BPs we can actually do 16:36:40 <vkozhukalov> #action dpyzhov moves all 6.0 unassigned BPs to next milestone 16:36:47 <angdraug> +1 16:37:00 <xarses> +1 16:37:37 <angdraug> looks like we can move on to open discussion 16:37:57 <vkozhukalov> #topic Open discussion 16:38:25 <vkozhukalov> couple of comments about re-implementing build system 16:38:46 <vkozhukalov> we've created kinda ci framework 16:39:12 <vkozhukalov> which we (with dpyzhov) agreed to extend 16:39:31 <vkozhukalov> so as to make it possible to build artifacts with it 16:39:52 <angdraug> is there a bp/poc? 16:40:24 <vkozhukalov> we agreed next week i'll make a demo of building target os images and bootstrap and probably something else 16:40:35 <vkozhukalov> will schedule a meeting for that 16:40:54 <vkozhukalov> poc is going to be ready next week 16:41:22 <angdraug> what about bp? 16:41:23 <vkozhukalov> there is still no spec and bp 16:41:39 <vkozhukalov> angdraug: will write bp 16:41:48 <angdraug> thanks 16:41:57 <angdraug> looking forward to it! 16:42:03 <vkozhukalov> ok 16:42:14 <vkozhukalov> any other comments, questions? 16:42:32 <angdraug> can we talk about 5.0.2? 16:42:53 <vkozhukalov> let's try 16:43:23 <angdraug> as far as I understand, our 5.1 upgrade tarball includes an entity called 5.0.2 16:43:33 <nurla> yes 16:43:36 <angdraug> it's a release in the Nailgun definition of the word 16:43:48 <nurla> and manifests too 16:43:51 <angdraug> but it's not related to 5.0.2 release milestone in LP 16:43:54 <nurla> and packages 16:44:11 <evgeniyl> nurla: is right, it's new release of manifests and packages 16:44:20 <angdraug> the manifests in that release, are they from fuel-library master or stable/5.0? 16:44:21 <evgeniyl> it's not about nailgun at all 16:44:51 <angdraug> evgeniyl: so it's not a release a user can choose to deploy? 16:44:57 <nurla> from stable/5.0 of all repos 16:45:03 <angdraug> the packages, which repository is it from? 16:45:13 <angdraug> http://fuel-repository.mirantis.com/fwm/5.0.2/ ? 16:45:37 <angdraug> stable/5.0 currently has what's going to become 5.0.1 16:45:47 <evgeniyl> Yes, user can have 5.0.1 and 5.0.2 release at the same time, and upgrade from 5.0.1 to 5.0.2 16:46:01 <evgeniyl> ikalnitsky: am I right? 16:46:56 <angdraug> actual GA release of 5.0.2, if it at all happens, will be after 5.1 is released 16:47:25 <dpyzhov> angdraug: 5.0.2 will be shipped with 5.1 at the same time on the same iso 16:47:31 <dpyzhov> s/iso/tarball/ 16:47:37 <angdraug> is what's included in 5.1 under name 5.0.2 an upgrade tarball with the current state of stable/5.0 as of the moment of 5.1 GA? 16:47:45 <dpyzhov> there will be no separate 5.0.x releases after 5.0.1 16:47:47 <evgeniyl> In nailgun we call this release something like 2014.1.1-5.0.1 and 2014.1.1-5.0.2 it's two separate bundles repos+manifests 16:48:11 <dpyzhov> angdraug: yes 16:48:17 <angdraug> what's the difference between 5.0.1 and 5.0.2? 16:48:40 <dpyzhov> angdraug: small amount of security fixes, I guess 16:48:51 <nurla> 5.0.1 isn't released yet 16:49:02 <angdraug> hopefully it will be released before 5.1 16:49:36 <angdraug> but they're going to be pretty close the way things are going 16:49:44 <angdraug> so why not just have 5.0.1? 16:49:46 <dpyzhov> If our 5.0.1 will not be released befor 5.1, we can ship it with 5.1 and forget about 5.0.2. But our users will kill us =) 16:50:08 <angdraug> no, if 5.0.1 isn't ready to be released, we can't release 5.1 either 16:50:16 <nurla> +1 16:50:17 <angdraug> all bugs we currently have in 5.0.1 apply to 5.1 too 16:51:12 <angdraug> given that we don't plan to have a proper release cycle for 5.0.2, 16:51:26 <dpyzhov> angdraug: we thought that there will be more time between 5.0.1 and 5.1. At the moment looks like we can ship 5.1 with 5.0.1 16:51:34 <angdraug> I think we should just have 5.0.1 and 5.1 as installable releases 16:51:55 <angdraug> dpyzhov: yes, that's where I'm going with my questions :) 16:52:49 <dpyzhov> angdraug: but for patching we need to rebuild a lot of packages 16:52:57 <angdraug> it would only make sense to call that thing a 5.0.2 if we had a separate QA cycle for it 16:53:09 <dpyzhov> it can affect our release schedule for 5.0.1 16:53:22 <angdraug> then it will affect it 16:53:32 <angdraug> assuming that we're not still fixing oslo.messaging by then 16:53:50 <dpyzhov> do we have any estimates about oslo.messaging? 16:53:55 <angdraug> what I'm saying is that we can't publish a release we didn't properly test 16:54:12 <angdraug> dpyzhov: our estimate on oslo.messaging is still the same: maybe tomorrow 16:54:25 <vkozhukalov> angdraug: ) 16:54:26 <dpyzhov> angdraug: nice. I love stability 16:54:42 <nurla> all patches about 5.0.1 should be in 5.0.2 16:54:50 <angdraug> I'd rather we rebuild those packages now and include in 5.0.1 and test that as part of 5.0.1 16:55:02 <vkozhukalov> 5 minutes 16:55:12 <angdraug> otherwise we'll have to retest everything again just for 5.0.2 16:55:35 <angdraug> nurla: I'm trying to save you from more work ) 16:55:37 <dpyzhov> angdraug: we can’t be sure that our 5.1 release will not be delayed 16:55:51 <angdraug> even if it is delayed 16:56:05 <dpyzhov> if we delay 5.1, 5.0.1 will be delayed 16:56:06 <angdraug> we still can't include untested 5.0.2 packages and manifests 16:56:16 <nurla> we test it 16:56:25 <angdraug> so we test 3 releases in parallel right now? 16:56:39 <nurla> only via systests 16:56:58 <nurla> not manually 16:57:01 <dpyzhov> angdraug: 3 releases + upgrades =) 16:57:10 <vkozhukalov> 3 minutes 16:57:17 <nurla> + pathching 16:57:28 <vkozhukalov> are we going to make a decision right now? 16:57:31 <angdraug> no 16:57:34 <angdraug> I presented my point 16:57:43 <angdraug> we should take it to the mailing list 16:58:00 <vkozhukalov> angdraug: +1 16:58:12 <vkozhukalov> ok looks like we are done 16:58:23 <vkozhukalov> thanx everyone, great meeting 16:58:28 <vkozhukalov> closing 16:58:35 <vkozhukalov> #endmeeting