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