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