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