14:01:27 #startmeeting freezer 14:01:28 Meeting started Thu Jun 9 14:01:27 2016 UTC and is due to finish in 60 minutes. The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:31 The meeting name has been set to 'freezer' 14:01:40 who's here for the freezer meeting? 14:01:44 o/ 14:02:10 o/ 14:02:13 o/ 14:02:20 (<---- yuval from smaug) 14:03:00 O/ 14:03:15 Hello Yuval 14:03:29 Hello 14:03:56 Hi 14:05:08 Hello 14:05:44 o/ 14:06:02 ok guys, let's start 14:06:11 the agenda: https://etherpad.openstack.org/p/freezer_meetings 14:06:21 I think we don't have any topics yet 14:07:10 #topic Smaug 14:07:32 any thoughts on that? 14:07:44 I'm ok with that 14:07:50 as long as the scope is define 14:08:04 sure 14:08:07 https://wiki.openstack.org/wiki/Smaug 14:08:34 so for DR I think there's overlap 14:08:39 https://review.openstack.org/#/c/326724 14:08:47 also in the repo there isn't that much 14:09:34 daemontool: Smaug's scope is not DR, but rather Data Protection 14:10:01 yuval, ok, please check my comment on that 14:10:04 on https://review.openstack.org/#/c/326724 14:10:29 daemontool: Smaug's API can be used to enable DR. Smaug is not doing health check, fencing, etc 14:10:36 so I suggest to put more focus on this meeting on the Freezer related tasks 14:10:48 yuval, thanks for your feedback 14:11:05 daemontool: Sure, we will be happy to collaborate 14:11:15 yuval, :) 14:11:48 yuval, I think it is more effective if you talk with slashme about that as he's the PTL 14:13:14 daemontool: thanks, we will 14:13:27 all set with this topic? 14:13:42 anyway I've already gave my +1 on that 14:14:21 ok let's move forward 14:14:42 #topic Status tracking in respect to the Road Map 14:14:59 https://wiki.openstack.org/wiki/FreezerRoadmap 14:16:33 just an observation, there's no mention of newton in the roadmap 14:16:45 ddieterly, yes I think it needs to be updated 14:16:53 yes it needs to be updated 14:16:54 ddieterly: I will update that 14:16:57 but there's a roadmap wiritten by slashme 14:17:04 as far as I can remember 14:17:23 it's a 'double secret' roadmap ;-) 14:17:37 :) 14:17:44 I think is the one from the last meet up 14:17:58 probably 14:18:08 I can't remember 14:18:20 if anyone of us is writing or started to work on the deduplication bp 14:18:37 daemontool: not for now. 14:18:40 ok 14:19:01 what are the next outstanding priorities? 14:19:51 Integration tests / refactoring / oslo policy 14:20:00 DR kick off 14:20:08 ok 14:20:23 so testing, stabilization, oslo and dr 14:20:27 sounds good 14:20:37 after that we'll focus on feature? 14:20:40 block based if you can make it 14:20:43 ok 14:21:04 I'm negotiating time for upstream now 14:21:07 And then, regarding features: deployment automation (puppet, ansible, heat, ... ) 14:21:12 I should be able to work on it couple of days a week 14:21:17 starting from July&August 14:21:18 Deduplication 14:21:22 ok 14:21:34 sounds good 14:22:00 everywhere I'm being asked for a better baas 14:22:08 with volumes mainly 14:22:21 daemontool: first step for this is oslo policy 14:22:29 ah ok brilliant 14:23:00 there's the tripleo and ironic based backup 14:23:01 also 14:23:31 for distros like RH OSP 14:24:11 daemontool who is asking for baas? 14:24:39 do you want the names of the companies? 14:24:52 it's in the Bid requirements 14:25:01 daemontool yes 14:25:01 of any big company that is using openstack 14:25:05 in the backup part 14:25:22 the PS service guys for sure have visibility on this 14:25:43 where are the 'bid requirements'? 14:26:09 ok ddieterly I'll explain this to you offline after the meeting :) 14:26:16 ok 14:27:19 probably we can move forward to the next topic 14:27:24 any new reqs? 14:27:50 the req I have so to be able to backup tripleo based distros 14:28:16 otherwise freezer it cannot be used in solutions where triple is used, 14:28:22 tripleo 14:28:31 also there's the 14:28:42 tenant resources backup 14:28:57 as metadata, volumes and alike 14:29:30 but I think we need to setup well the freezer-specs repo 14:31:03 nothing else from me 14:31:27 Freezer spec review is ready if I remember well 14:31:27 https://review.openstack.org/#/c/316865/ 14:31:43 Ohh, I need to find what the problem is... 14:32:42 can we move forward? 14:32:44 yes 14:34:51 #topic logging convention [-] [*]. i.e, what is that 14:34:54 I think we need to do a full code check on logging, in order to streamline messages and log levels. 14:35:14 +1 14:35:46 looks like nobody knows the reason for [*] 14:35:51 slashme: we said that many times and we never did it :) hope this time we can do it 14:36:06 daemontool knows why :) 14:36:30 I've added it in the very beginning 14:36:39 so easily identify freezer logs 14:36:47 but now that we are using oslo 14:36:53 the name of the service is written in the log 14:36:57 so it is not needed anymore 14:37:19 ok, we can safely remove that then 14:37:20 :) 14:37:37 #topic Pending Reviews 14:37:53 how about the [-]? 14:38:07 daemontool thanks for clarifying the [*] mystery 14:38:29 https://review.openstack.org/#/c/325943/ 14:38:29 https://review.openstack.org/#/c/326093/ 14:38:30 https://review.openstack.org/#/c/326157/ 14:38:30 https://review.openstack.org/#/c/327241/ 14:38:31 https://review.openstack.org/#/c/324529/ 14:38:32 https://review.openstack.org/#/c/325512/ 14:38:32 https://review.openstack.org/#/c/319182/ 14:38:47 is [-] not set by oslo? 14:39:08 i think it is supposed to be the id of something 14:39:15 not sure what though 14:40:36 #topic Reminder about code reviews 14:40:48 I would like to remind you of what reviewing some code means: 14:40:48 - !! Test the code !! 14:40:48 - Read the code 14:40:49 - Check for the presence of a bug-id or blueprint-id 14:40:49 - Check for documentation of the code (Both comment and addition to the doc) 14:40:49 - Check if the mappings have been updated accordingly if necessary 14:40:49 - Check for the presence of unit and integration tests 14:40:50 As you all know, we are still working on adding more integration tests, that means that CI will not always catch errors and we can't rely only on it. 14:40:51 The scheduler is currently broken on master because of this patch: http://git.gozer.hpcloud.net/cgit/openstack/freezer/commit/?id=b16f8b1692294a48316aa406d036c09f4e5d05b6 14:40:52 This one has been approved by daemontool and ddieterly, but we all fall for the facility of trusting the developper to test its patch sometime. 14:40:52 Please be carefull. 14:41:52 i tested that on my local dev box 14:42:30 how can I approve a commit in gozer :) 14:43:10 ddieterly: this is the related bug: https://bugs.launchpad.net/freezer/+bug/1590787 14:43:10 Launchpad bug 1590787 in Freezer "Scheduler fails due to incompatibilities with keystoneauth1" [Undecided,In progress] - Assigned to Jonas (jonas-pfannschmidt) 14:43:58 maybe you didn't test specifically the 'start' command in freezer-scheduler? 14:43:58 i see 14:44:11 yes, clearly, my testing was inadequate 14:44:22 ah ok got it now 14:44:39 i was trying to be a good citizen by doing reviews and moving things along 14:46:08 please continue doing this. I don't want to blame anyone. we had similar issues in the past with different people involved (incl. myself) 14:46:38 I am not blaming anyone, this is not a big deal, and we need to move things along in order to avoid accumulating patch to review. 14:46:38 Things are going to be easyier the more integration tests we have. 14:46:45 the good news is that I catched this problem while writing my integration test. so once that's merged (hopefully today) we have another safety net 14:47:02 jonaspf that's great! 14:49:37 +1 14:51:39 seems to have gone quiet here 14:52:56 A little bit... 14:53:13 folks must be reviewing like crazy or something 14:53:18 lol 14:54:12 daemontool i can always count on you for humor ;-) 14:54:49 always 14:55:03 so I don't think we have any other point to discuss? 14:55:42 #endmeeting