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