16:02:05 #startmeeting openstack-freezer 26-11-2015 16:02:06 Meeting started Thu Nov 26 16:02:05 2015 UTC and is due to finish in 60 minutes. The chair is m3m0_. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:09 The meeting name has been set to 'openstack_freezer_26_11_2015' 16:02:14 All: meetings notes available in real time at: https://etherpad.openstack.org/p/freezer_meetings 16:02:26 daemontool, you are first 16:02:29 ok 16:02:51 I've been doing mainly code reviews 16:03:17 started to reintegrate 16:03:26 the block based incremetnal 16:03:28 to mster 16:03:34 I think we'll have it for mitaka, 16:03:39 stretch goal for liberty 16:04:01 I need to modify the mission statement for freezer in openstack/governance 16:04:11 enable the dsvm gate jobs in the 3 repos as voting 16:04:19 and as soon as we can 16:04:27 do the branching for liberty 16:04:38 there's a discussion going on on the openstack-dev ml 16:04:42 for stable branching 16:04:46 what about having the need for 2 cores to approve a commit? 16:04:49 we might have to change 16:05:02 our branches name 16:05:11 m3m0_, yes, I think that make sense 16:05:17 even more for stble branch 16:05:24 1 eng give +2 and one give +A 16:05:37 allthogh we need to devine 16:05:40 define 16:05:45 how to manage urgent situation 16:05:50 like hotfix, security patches 16:05:56 and something that is really critical 16:06:12 I think on that case one eng can give +2+A but at any rate 16:06:30 the same person that submit the patchset, shouldn't approve his/her own code 16:06:45 I agree on those special sitations but still we have several cores at the same time available 16:06:53 oh yeah thats for sure 16:07:00 not even in remote cases 16:07:18 yep. Other than that, I need to create a asap the openstack/python-freezerclient 16:07:29 repo and also the openstack/freezer-specs 16:07:39 so we can put our specs ther like other projects are doing 16:07:51 how long will it take? 16:08:01 creating the repo is fast 16:08:09 splitting the code I don't know 16:08:19 but we need to do that for Mitaka for sure 16:08:48 I also have the perception 16:08:53 that we are not writing bp 16:08:57 like before 16:09:00 even for simple tasks 16:09:04 that's important 16:09:12 as if there's a new contributor 16:09:18 that want to start with easy things 16:09:23 now it's difficult 16:09:26 you are correct there, should we start giving -1 if a bp is not present? 16:09:33 yes 16:09:43 jenkins should give -1 16:09:46 bp or bug 16:09:56 also 16:10:05 I think we need to add in the wiki 16:10:06 #action every commit have to have bp or bug associated with it 16:10:12 #agreed 16:10:22 we need to add to the wiki 16:10:37 probably who's mainly working on something 16:10:46 that help us to organize etter 16:10:47 better 16:10:53 do you want to do that? 16:10:54 as i.e. m3m0_ can write the bp for web ui 16:11:03 vannif, can write bp for api 16:11:05 and so on 16:11:26 so if there's someone that looks for someone on some specific component 16:11:35 we have the guy/girl right there 16:11:49 just a thought, not sure it make sense or not 16:12:22 it makes a lot of sense 16:12:48 each one of us should be responsible/accountable for one component 16:12:48 altough I'm not so sure if everyone has to have knowledge of all the components 16:12:56 exactly 16:13:01 that's also one of the reasons 16:13:38 also... 16:13:43 we need to thing, what we can do 16:13:48 to involve more people in the project 16:13:56 we need to be more 16:14:14 how can we do that? 16:14:19 I don't know 16:14:21 events 16:14:22 meet up 16:14:25 talks 16:14:27 sessions 16:14:29 and so on 16:14:36 like the one you wanted to do at pycon 16:14:40 that things helps a lot 16:14:57 things is 16:15:07 that now it's not very easy to start contributing on freezer 16:15:14 we need to make that more simple 16:15:35 let's first start with the bp, wiki and roadmap 16:15:40 ok 16:15:56 so that way at least new people will have an idea on what they can contribute 16:16:17 it's not like they will be bound to that path but its a good starting point 16:16:17 yes 16:16:32 yep 16:16:59 we need to document things like 16:17:13 if you want to add a new storage media, do this this and that 16:17:26 if you want to add a new application aware backup touch here and here and there 16:17:36 web ui the same 16:17:37 api the same 16:18:09 I completly agree on that point, even for us sometimes is difficult to modify code :P 16:18:14 question is, in the new company where I'm going... if there are people interested (and there will be) 16:18:24 where should tey start? 16:18:31 s/tey/they/ 16:18:45 read the roadmap 16:18:46 how can we make thigns easy for new comers 16:18:48 yes 16:18:52 that ok 16:18:57 even coming on irc 16:19:00 and reading all the docs 16:19:04 yes of course 16:19:05 and play with devstack 16:19:09 that's documented 16:19:18 but how to be orientated 16:19:22 within the code 16:19:27 that's the difficult part 16:19:32 I will suggest that new people start documenting stuff (boring I know but useful) 16:19:38 yes 16:19:47 so that's all from me 16:19:47 inline comments will be perfect 16:19:49 yes 16:20:02 once we have the bp in place 16:20:08 and the specs 16:20:11 will be easier 16:20:14 yes 16:20:21 ok, thanks daemontool 16:20:24 each one of us 16:20:32 please let us know when the repos are available 16:20:36 should probably spent 20 minutes every week 16:20:48 writing bp of things that we need have to be improved 16:20:55 small or big 16:20:58 ok 16:21:18 I did this template 16:21:19 https://blueprints.launchpad.net/freezer-web-ui/+spec/template-blueprint 16:21:52 is quite specific to the ui 16:22:06 but can be implemented for the whole project 16:22:11 m3m0_, we just said the same engineer doesn't give +2 +A if there's not +2 already by some different engineer 16:22:13 https://review.openstack.org/#/c/250474/ 16:22:13 :) 16:22:20 ok 16:22:41 hahahaha I was under preasure :) and those changes are only backported to kilo :P 16:22:43 even more in kilo 16:22:50 but won't happen again :P 16:22:53 to modify stable/kilo 16:22:55 or any stable 16:23:10 we need to have 2 or more people 16:23:10 ok 16:24:40 do you have anything more to say daemontool? 16:25:29 m3m0_, nope all good 16:26:04 thanks a lot :) 16:26:10 vannif, you;re next 16:26:31 thanks mr chairman 16:27:31 besides some code reviews and quick fixes, I've been looking to the user point of view 16:27:38 that means 16:27:55 the BaaS aspect 16:28:11 so. backup of cinder volumes, ephemeral volumes, VMs 16:28:34 and how to make it usable from the ui for a "normal" user 16:29:20 I'm also messing with screen recordings and video editing to record some demos 16:29:31 perfect 16:29:38 in particular, the first would be the backup and restore of mysql on the control plane 16:29:53 BTW have you think about including elasticsearch as a mode in freezer? 16:29:55 the type of demo we have been presenting from time to time 16:30:21 you mean, backing up of elasticsearch besides mysql ? 16:30:28 yes 16:30:38 no. I think that postgres and oracle have precedence 16:30:53 but that's my idea 16:31:10 not so sure about this, at least we should have a way to backup ourselves 16:31:23 daemontool Slashme any thoughts? 16:32:10 maybe elasticseaarch is easy to backup 16:32:43 at least freezer stuff 16:33:58 as long as we can flush the data shouldn't be that difficult 16:34:44 Actually elasticsearch is more like swift. You can setup as many replics as you want 16:35:25 so, should be worried about that? 16:36:46 I don’t know actually. In case if we have possiblity to lose all replicas with hdd. and it is criticall data - it have sense to have backup 16:37:16 https://www.elastic.co/guide/en/elasticsearch/guide/current/backing-up-your-cluster.html 16:37:45 But I suppose just file level backup of elasticsearch isn’t best option 16:39:13 let's think about this further 16:39:25 vannif do you have anything more to say? 16:39:29 no 16:39:32 thanks 16:39:35 cool, thanks a lot 16:39:39 reldan you are next 16:39:54 Thank you m3m0_ ! 16:40:21 I have an amazion pull request, please review it - https://review.openstack.org/#/c/247840/ 16:40:51 Today we had a discussion with m3m0 about parallel backup 16:40:56 all, please review this https://review.openstack.org/#/c/247840/ 16:41:14 I really believe everyone should take a look and say his opinion 16:41:38 and as we agreed, the next iteration should have a way to continue storing the backups even if one or more than one but not all storages fails 16:42:25 m3m0_ is right, next thing will be policies / new version of metadata (we should discuss format) 16:42:55 do you want to setup and irc or local meeting when you are ready for discussion? 16:42:57 Because now we can have a lot of containers / ssh-usernames / ssh-ports in one config file and we should show result accordiingly 16:44:06 I think you can have a local meeting, came up with something written 16:44:09 and organize a meeting 16:44:11 I would to prefer have a review first and answer any questions about this pull request. In this case everyone will have understanding how it works and will be able to have his own opinion 16:44:14 publicly 16:44:21 even asking feedback on openstack-dev 16:44:31 what do you mean about "show result accordiingly"? 16:45:18 I mean result of execution. Now if we have only one storage we are binary - backup success / backup fail or restore success /restore fail 16:45:34 After having different plicies it may be 16:45:50 Backup success (storage1 success, storage2 success, storage3 fail) 16:45:59 yep yep I agree with that 16:46:18 please all review the parallel backup commit 16:46:32 reldan do we have test case scenarios for this? 16:47:22 Now I have only one policiy - one fails - all fails. But I’m going to add one success - all success policy 16:47:37 And it is an open question - how I should inform user 16:47:56 That some storages are failed, some are succeed 16:48:01 And what does it mean 16:48:34 reldan, that's what we discussed in the past 16:48:40 logging.warning? 16:48:40 ? 16:48:49 policy for multiple storage 16:48:58 Yes, let’s say we have policy 16:49:10 different - but we should define output format for task 16:49:23 before policices it may be - failed/succeed 16:49:26 yes write down a few lines bp 16:49:29 so we can elaborate on that 16:49:42 now it may be succeed for 3 storages, failed for 1 16:49:43 agree with daemontool_ 16:49:47 Agree 16:50:10 But please review my request ) 16:50:12 Thank you 16:50:23 reldan, yes it takes a bit of time 16:50:29 to review it, try it 16:50:34 with different scenarios 16:50:50 I'll do my best to test and review it tomorrow 16:51:17 Thank you, please give me any feedback not only about bugs in my code, but also any comments about approach/architecture are were appreciated 16:51:42 It’s all from my side 16:51:49 thanks reldan 16:51:58 Thank you! 16:52:02 Slashme anything on your side? 16:52:24 I want to do some updates on the wiki 16:52:49 And work a few demo to put on youtube 16:53:05 cool, that really great 16:53:07 Slashme, brilliant 16:53:12 I was thinking: freezer-intro / freezer-install / freezer-cli /freezer-web-ui 16:53:23 Also please review : https://review.openstack.org/#/c/243021 16:53:42 are we going to have french, italian, russian and spanish subtitles? 16:53:45 That's all from my side 16:54:03 m3m0_: good idea for subtitles 16:54:12 jajaja I'll do the russian ones 16:54:23 lol 16:54:24 :) 16:54:30 there's something I think we should do... 16:54:31 I'll manage the arabic :) 16:54:37 we need to write in the commit message 16:54:42 why we are doing that 16:55:41 agree at least a short description of why, what and how 16:55:43 we need to think about api v2 16:55:51 when why what in it 16:55:53 yes 16:56:08 so, all. 16:56:27 after this commits, every single commit has to have a bp or a bug, and a meaningful commit message 16:56:45 otherwise will get -1 by default is that ok with everyone? 16:56:46 yes 16:56:48 ++ 16:56:52 #agreed 16:57:15 #agreed 16:57:30 http://cdn.meme.am/instances/65275854.jpg 16:57:51 cool, does anyone have anything to say? 16:58:41 samuelBartel, hi 16:58:54 m3m0_, lol 16:59:37 we are running out of time 16:59:49 thanks everyone 16:59:57 Thank you! 17:00:00 #endmeeting