14:00:42 <m3m0> #startmeeting freezer
14:00:47 <openstack> Meeting started Thu Apr 14 14:00:42 2016 UTC and is due to finish in 60 minutes.  The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:50 <openstack> The meeting name has been set to 'freezer'
14:00:53 <slashme> Hello m3m0 :)
14:01:01 <clsacramento> m3m0: hello
14:01:08 <yangyape_> hello m3m0
14:03:19 <szaher> Hello memo
14:03:28 <m3m0> sup guys
14:03:32 <daemontool> o/
14:03:47 <m3m0> first topic of the day
14:04:10 <m3m0> slashme wants to start his reign
14:05:05 <daemontool> like Napoleon
14:05:21 <daemontool> :)
14:05:26 <daemontool> m3m0,  do we have topics_
14:05:27 <daemontool> ?
14:05:56 <slashme> I'd like to propose szaher as a freezer core. His contributions have been highly valuable integrating multiple oslo components into freezer. I'l send the ML email later. Please answer with your +1/-1.
14:06:01 <m3m0> yes the topics for today are here: https://etherpad.openstack.org/p/freezer_meetings
14:06:05 <daemontool> ok
14:06:14 <m3m0> +1
14:06:21 <clsacramento> +1
14:07:25 <yangyape_> szaher: good
14:07:28 <daemontool> all good, next?
14:07:48 <m3m0> #topic Freezer-api: should be switch the /v1/backups/ endpoint from backup_id to backup_uuid
14:08:38 <m3m0> we need the backup_id to be uuid like
14:08:54 <m3m0> but what will be the repercussion of changing this?
14:10:20 <ddieterly> o/
14:12:36 <m3m0> so should we force the api and elasticsearch to query by uuid rather that id, vannif what do you think?
14:14:36 <daemontool> if we have somewhere a mapping of id -> uuid
14:14:47 <daemontool> then we can keep querying the id
14:14:55 <daemontool> otherwise not, we need to query by uuid
14:15:10 <vannif> a uuid seems more reasonable. the backup_id is actually a computed value. we can add it as a field, but it does not actually add any information.
14:15:28 <vannif> and we can always add queries based on backup_id
14:15:53 <m3m0> so, we need to force the _id of the document to be the uuid?
14:16:04 <m3m0> that would break older versions right?
14:17:34 <daemontool> we need to add a mapping
14:17:38 <daemontool> if we do not want to break anything
14:17:57 <vannif> atm the _id of the backup documents is leaft to elasticsearch to compute
14:18:12 <vannif> s/leaft/left
14:18:24 <daemontool> I think that make sense
14:18:42 <daemontool> so we can add the uuid in the document also
14:18:48 <daemontool> so we have in the document
14:18:51 <daemontool> id and uuid
14:18:56 <daemontool> and the mapping can be done
14:19:19 <vannif> there is already a backup_uuid in the backup document
14:19:36 <daemontool> ok
14:19:46 <daemontool> even better
14:19:52 <daemontool> for what are we using the id currently_
14:19:53 <daemontool> ?
14:20:19 <daemontool> if we have both values already
14:21:19 <daemontool> there's not backward incompatibility
14:21:22 <daemontool> we need to change only
14:21:26 <daemontool> the query
14:21:28 <m3m0> the easiest thing will be force the api to query by backup_id rather than _id
14:21:35 <daemontool> ok
14:21:47 <m3m0> sorry backup_uuid
14:22:06 <m3m0> but this is vannif terrritory
14:23:23 <vannif> yes.. with backup_uuid we have the usual uniqueness of uuid
14:23:56 <vannif> with a computed backup_id there might be conflict concerns
14:23:57 <m3m0> : would you like to do it vannif? or clsacramento do you want to work on it?
14:24:24 <vannif> I can do it.
14:25:05 <m3m0> perfecto
14:25:08 <m3m0> can we move forward?
14:25:11 <daemontool> ok, please take also in consideration to include clsacramento in case  she's interested
14:25:15 <daemontool> yes
14:25:18 <vannif> sure
14:25:23 <m3m0> #topic Freezer-web-ui mitaka tagging
14:25:43 <m3m0> we need to create a branch for mitaka in the ui, how can we proceed daemontool?
14:26:09 <clsacramento> m3m0: I'm interested too
14:26:30 <m3m0> clsacramento: sync with vannif on this please
14:26:37 <clsacramento> sure
14:26:58 <daemontool> m3m0,  yes
14:27:04 <daemontool> I had this conversation
14:27:18 <daemontool> with slashme , I'm going do to it today or tomorrow EOD
14:27:28 <daemontool> sorry this week I've been too much busy
14:27:42 <m3m0> np :)
14:27:47 <daemontool> :)
14:28:02 <m3m0> can we move forward then?
14:28:10 <daemontool> ++
14:28:13 <m3m0> #topic Backup-consistency review
14:28:21 <m3m0> clsacramento slashme ^^
14:28:54 <m3m0> yangyape_: by the way do you have something you would like to discuss?
14:29:50 <daemontool> I want to discuss the backup as a service if possible
14:30:00 <daemontool> (a bit pdantic I know)
14:30:15 <daemontool> we need to include metadata backup in the cinder native backup
14:30:17 <m3m0> sure, I would like to discuss that as well
14:30:34 <daemontool> and also we need to start thinking on the dedup
14:30:37 <daemontool> write a bp
14:30:40 <m3m0> but wait, let's move this topic for later then
14:30:43 <daemontool> have a more tangible discussion
14:30:43 <daemontool> ok
14:30:51 <m3m0> #topic backup as a service
14:30:52 <daemontool> at your convenience :(
14:30:54 <daemontool> :)
14:31:03 <m3m0> now :)
14:31:11 <m3m0> we need oslo.policy first
14:31:14 <daemontool> ok
14:31:22 <daemontool> anyone is working on that?
14:31:30 <szaher> me
14:31:33 <m3m0> szaher I think
14:31:56 <daemontool> brilliant
14:31:58 <szaher> Also I moved freezer-api to context which will help somehow in policy https://review.openstack.org/#/c/303390/7
14:32:18 <daemontool> then when it's done please Saad let's discuss this
14:32:21 <szaher> Sure
14:32:22 <daemontool> as it it a trend hot topic :)
14:32:33 <m3m0> do we need this before the summit?
14:33:48 <daemontool> I don't know
14:33:55 <daemontool> sooner the better
14:33:59 <daemontool> as a general rule
14:34:01 <daemontool> :)
14:34:05 <daemontool> for sure in Newton
14:34:22 <daemontool> I think we can move next
14:36:21 <m3m0> ok :)
14:36:32 <m3m0> #topic     Tar bug: https://bugs.launchpad.net/freezer/+bug/1570304
14:36:42 <m3m0> reldan?
14:36:43 <openstack> m3m0: Error: Could not gather data from Launchpad for bug #1570304 (https://launchpad.net/bugs/1570304). The error has been logged
14:37:08 <reldan> Yes, bug. Very bad. I’m trying to fix it. But don’t sure about success
14:37:58 <m3m0> do you need any help on this?
14:38:50 <reldan> You know it is more like investigation. It seems to be a well known bug in tar
14:39:01 <reldan> At the moment no
14:40:01 <m3m0> ok ok, in case you need help you know where we are :)
14:40:13 <reldan> Thank you m3m0!
14:40:19 <m3m0> can we move forward?
14:40:50 <slashme> The backup consistency code written by clsacramento is almost ready : https://review.openstack.org/#/c/300080/
14:40:51 <slashme> Just need to finish some testing.
14:40:51 <slashme> It adds the --consistency_check option during a backup. That will output a chacksum as part of the backup metadata.
14:40:51 <slashme> You then need to pass that checksum back during the restore with the --consistency_checksum option.
14:40:51 <slashme> These options will allow the user (and our CI) to be sure that a restored directory is in the *exact* same state than when it was backed up.
14:40:52 <slashme> Please feel free to review the code.
14:41:36 <daemontool> ok clsacramento well done
14:41:49 <clsacramento> daemontool: thank you!
14:42:49 <m3m0> that seems very nice :)
14:43:06 <clsacramento> yes, it is failing on dvsm gate because I'm not used to this process yet, but will be soon fixed and most of it is already done, so please start reviewing when you can
14:43:12 <m3m0> as soon as the review process finish let's merge this and include our testing to handle this
14:43:27 <yangyape_> i have a recheck
14:43:30 <m3m0> can we move forward?
14:44:13 <m3m0> I have an offtopic topic :) , should we talk with the nova and cinder team to move their backup code to our project/
14:44:14 <m3m0> ?
14:46:47 <daemontool> m3m0, I don't know, probably not for now
14:46:54 <daemontool> for sure we acn ask them their opinion
14:47:00 <daemontool> or request feedback to the ml
14:47:11 <daemontool> but I think for native backups mode
14:47:21 <daemontool> it should probably be in the related os service
14:48:00 <daemontool> imho
14:48:36 <m3m0> I agree, we need the feedback from the community
14:49:22 <daemontool> but if there's any advantage
14:49:29 <daemontool> why should we move it
14:50:54 <daemontool> *if there isn't
14:51:23 <m3m0> we manage the backups, we get more contributors, freezer gets bigger :)
14:53:40 <m3m0> we have 7 min left guys
14:53:46 <m3m0> can we move forward?
14:58:02 <m3m0> guys I'm ending the meeting, thanks all for participating
14:58:13 <m3m0> #endmeeting