14:00:12 <m3m0_> #startmeeting freezer
14:00:14 <openstack> Meeting started Thu Jun 23 14:00:12 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:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:18 <openstack> The meeting name has been set to 'freezer'
14:00:26 <slashme> Hi m3m0_ :)
14:00:30 <m3m0_> hello guys, who is here for the freezer meeting?
14:00:31 <yangyapeng> hi m3m0_
14:00:41 <yangyapeng> :)
14:00:47 <yangyapeng> ping iceyao
14:01:41 <iceyao> present
14:02:28 <ddieterly> present
14:02:41 <timothyb89> hello all
14:02:52 <szaher_> hi
14:02:56 <Marcellin> hello
14:03:03 <m3m0_> as always topics for the meetings are here:https://etherpad.openstack.org/p/freezer_meetings
14:03:05 <daemontool_> o/
14:03:23 <m3m0_> #topic Should we backport integration tests to mitaka?
14:03:34 <daemontool_> +1
14:04:01 <m3m0_> according to the openstack guidelines is not a "good" thing to backport this kind of code, it should be always only bug fixes
14:04:19 <m3m0_> but I agree that we should backport this
14:04:24 <daemontool_> how do we discover bugs if we do not have tests running on it_
14:04:24 <ddieterly> can someone list the pros/cons?
14:04:26 <daemontool_> ?
14:05:21 <ddieterly> i don't think we should backport because of the os guidelines
14:05:39 <ddieterly> seems like mitaka is supposed to be fully baked by now
14:05:49 <ddieterly> ymmv
14:06:01 <liudan> ping yangyapeng
14:06:11 <yangyapeng> here liudan
14:06:12 <ddieterly> if we backport, then we might have to pull in many commits to make the tests pass
14:08:51 <daemontool_> are there bugs in master that has been backported to mitaka after the tests execution_
14:08:52 <daemontool_> ?
14:09:27 <daemontool_> I mean if the bug fix was backported
14:09:46 <daemontool_> for bugs discovered in master by the new tests
14:10:19 <ddieterly> not sure
14:11:24 <daemontool_> if the bugs are fixed for the same code in master and mitaka
14:11:27 <daemontool_> then no need to backport
14:11:50 <m3m0_> slashme any input?
14:11:57 <daemontool_> as the tests would be the same and no additional work would be required
14:12:22 <ddieterly> if the bugs are fixed in mitaka, then we don't need to backport the tests ;-)
14:12:33 <daemontool_> but if we have no idea if the current tests would discover any unfixed bug in mitaka... then we should backport probably
14:12:49 <ddieterly> i knew you were going to say that
14:12:57 <slashme> I'd like to have jokke_ opinion.
14:13:18 <daemontool_> can we execute the current tests against mitaka without merging?
14:13:25 <daemontool_> I think we can
14:13:37 <jokke_> ping me back in an hour ... I have triple booking of meetings for 1500-1600
14:14:41 <daemontool_> ddieterly, I see you are gaining critical thinking over time lol
14:15:10 <daemontool_> :)
14:15:11 <ddieterly> i took a class on critical thinking ;-)
14:15:29 <szaher_> :)
14:15:41 <daemontool_> ok so?
14:16:12 <daemontool_> let's think about that and next?
14:16:22 <ddieterly> sounds good
14:16:39 <m3m0_> ok, let's discuss this offline with jokke_
14:16:51 <m3m0_> #topic fullbackup_intereval https://etherpad.openstack.org/p/fullbackup_interval   yangyapeng
14:17:04 <yangyapeng> hi
14:17:37 <yangyapeng> about fullbackup and incremental in freezer-scheduler
14:18:48 <daemontool_> yangyapeng, that would simplify
14:18:55 <daemontool_> the interval
14:19:08 <daemontool_> syntax and definition
14:19:11 <daemontool_> +1
14:19:45 <daemontool_> and I totally agree about the volume meta
14:19:51 <daemontool_> store that in the backup
14:20:01 <daemontool_> so we can restore the volume even if the db is lost
14:20:02 <slashme> Just to clarify a point. Would this only apply for backups made with cindernative ?
14:20:45 <yangyapeng> now, we apply for cindernative
14:21:40 <yangyapeng> about cinder-vol-id  nova-inst-id  it is unavailable to incremental
14:22:35 <daemontool_> the way to define intervals, probably should be
14:22:44 <daemontool_> consistent
14:22:51 <daemontool_> _
14:22:52 <daemontool_> ?
14:23:16 <yangyapeng> scheduler trigger have two idea, 1, trigger: cron 2. trigger: interval
14:24:17 <szaher_> Can we discuss in more details in the mid-cycle meetup ?
14:24:45 <ddieterly> what mid-cycle meetup? we haven't scheduled one
14:25:02 <yangyapeng> what mid-cycle meetup?
14:25:03 <daemontool_> szaher,  yes, but let's at least have options
14:25:07 <daemontool_> or advance anything
14:25:23 <daemontool_> so when we get together we have something more specific to discuss?
14:25:48 <liudan> what mid-cycle meetup ?
14:26:01 <szaher_> daemontool_ Ok
14:26:23 <ddieterly> i added mid-cycle meetup to the agenda
14:26:24 <szaher_> ddieterly I think we agree on that and you was here, it should be at the end of July ...
14:26:44 <ddieterly> yes, but we don't have a specific date
14:26:54 <ddieterly> or a duration
14:26:56 <szaher_> slashme, I think we agreed on fixed date, do we ?
14:27:08 <slashme> 15 July
14:27:21 <slashme> One day
14:27:24 <szaher_> any way let's finish this point
14:27:39 <slashme> At least that's what we defined last time
14:28:11 <slashme> I did not send the communication yet, so this is still moveable I guess
14:28:39 <slashme> We agreed it would be mostly virtual as many won't be able to join physicaly
14:29:30 <daemontool_> so
14:29:39 <m3m0_> guys, could we please stay on topic?
14:29:50 <daemontool_> do we agree that we need a better way to set intervals on backup executions?
14:29:53 <slashme> Sorry m3m0_
14:29:54 <yangyapeng> yeah.
14:30:31 <yangyapeng> 1. we  fullbackup for cindernative in cron. it is ok?
14:31:03 <yangyapeng> 2.  above it is ok, we shoud have several of the lastest fullbackup
14:31:22 <yangyapeng> and between fullbackups, the incremental backup
14:31:57 <yangyapeng> delete other backup
14:32:06 <szaher_> daemontool_ yangyapeng What are we trying to discuss here is to have a better way of scheduling backups ?
14:32:27 <daemontool_> szaher,  better syntax as far as I can understand
14:32:59 <daemontool_> also yangyapeng  is proposing to leverage the incremental features intervals
14:33:08 <daemontool_> avaialble in cinder, yangyapeng right?
14:33:34 <daemontool_> and include the metadata of the volume in the backup, does this resume it yangyapeng ?
14:34:26 <szaher_> this will be available only in cinder ?
14:34:39 <yangyapeng> yeah, only in cinder.
14:35:05 <yangyapeng> about other backup_media, it is not realize
14:35:17 <daemontool_> ok, but probably we shouldn't have different ways of setting intervals?
14:35:46 <daemontool_> it is confusing for a user
14:35:48 <liudan> nova,cinder,cindernative,fs
14:35:55 <daemontool_> ok
14:36:07 <szaher_> +1 daemontool_
14:36:08 <daemontool_> yangyapeng, can you write something more detailed and organized?
14:36:20 <daemontool_> slashme, are you ok with this?
14:36:44 <yangyapeng> ok,  i shoud do it, later
14:36:51 <daemontool_> like, if we make it better for one backup engine, then let's make our work reusable for other engines?
14:39:01 <daemontool_> ok
14:39:03 <slashme> That definetly sounds like something we want to implement
14:39:20 <slashme> And that should be defined very precisely before implementation
14:39:27 <daemontool_> +1
14:39:42 <yangyapeng> continue?
14:39:47 <slashme> Also, as you said, it makes sense to have it available for all engines (or multiple
14:40:52 <slashme> This qualifies to be a topic we discuss durring the midcycle
14:41:03 <daemontool_> ok
14:41:05 <daemontool_> next
14:41:24 <yangyapeng> 3. If we manage the backup for cinder-bakcup
14:42:00 <yangyapeng> now,  freezer-scheduler backup-list , it may not to manage cinder-backuplist
14:42:30 <yangyapeng> if we shoud manage it by freezer, not cinder backup-list
14:42:37 <yangyapeng> freezer-ai
14:42:40 <yangyapeng> api
14:43:13 <yangyapeng> about freezer-scheduler backup-delete  the same
14:43:56 <szaher_> I think we are running out of time we only have 15 minute left yangyapeng can you write a well defined more detailed document and share it with us ? m3m0 ?
14:44:13 <yangyapeng> whether I make myself clear
14:44:26 <liudan> clear
14:44:52 <daemontool_> yangyapeng, clear
14:45:11 <iceyao> detailed in etherpad
14:45:21 <daemontool_> m3m0_,  next
14:45:37 <m3m0_> #topic elasticsearch_dsl
14:45:53 <m3m0_> https://review.openstack.org/#/c/332874/
14:45:59 <m3m0_> we should move to this library
14:46:14 <m3m0_> it will make more user friendly the interaction with es
14:46:38 <m3m0_> and we can catch mapping errors before we hit es, rather than dealing with the error
14:46:48 <m3m0_> I'm working in the bp for this
14:46:54 <daemontool_> m3m0_,  do we need to add anything in requirements and global-requirements?
14:47:00 <m3m0_> yes,
14:47:13 <m3m0_> elasticsearch_dsl>=2.0.0
14:47:43 <daemontool_> ok make sure to add it here https://review.openstack.org/#/c/332874/
14:47:50 <m3m0_> I will
14:47:59 <daemontool_> and have that commit depending on the global requirements change
14:48:11 <daemontool_> or the check-requirements gate job will fail
14:48:26 <m3m0_> and by doing this, we can ensure we have all the mappings for freezer, currently we only have around 70% of the arguments mapped
14:48:41 <m3m0_> yes, this still is a WIP
14:49:03 <szaher_> +1
14:49:36 <m3m0_> if there are no objections on implementing this we can move forward
14:50:02 <m3m0_> ok :)
14:50:05 <m3m0_> #topic deduplication status
14:50:11 <m3m0_> who's working on this
14:50:12 <m3m0_> ?
14:50:18 <ddieterly> daemontool_ was working on this?
14:50:31 <ddieterly> is there a bp?
14:50:43 <daemontool_> ah, don't recall that
14:50:45 <daemontool_> ok
14:50:48 <daemontool_> I'll write it
14:50:49 <daemontool_> sorry
14:50:56 <ddieterly> ok, thanks
14:51:59 <m3m0_> any status on it?
14:52:19 <ddieterly> i think daemontool_ will write bp
14:52:24 <ddieterly> that is the status
14:52:32 <m3m0_> ok :)
14:52:35 <m3m0_> next?
14:52:44 <daemontool_> yep
14:52:45 <m3m0_> #topic tar incremental limitatations: Restore error: /bin/tar: Cannot rename ‘./test’ to ‘./heat’: Directory not empty
14:52:55 <ddieterly> this tar error is coming up again
14:53:10 <ddieterly> i don't think we have a workaround, do we?
14:53:13 <daemontool_> ok did anyone try to remove the --incremental flag for the restore?
14:53:25 <daemontool_> or --listed-incremental=/dev/null ?
14:53:30 <daemontool_> to see if the problem is still there?
14:53:31 <ddieterly> it was an incremental backup
14:53:42 <daemontool_> ok, so?
14:53:47 <daemontool_> you can do it
14:53:58 <daemontool_> but the removed filed will not be removed
14:54:04 <daemontool_> for that level
14:54:14 <daemontool_> I don't know if it works
14:54:20 <ddieterly> mmm... not sure anyone tried not using the listed-incremental on an incremental backup
14:54:22 <daemontool_> but it can be a possible work around
14:54:35 <ddieterly> we can try it
14:54:44 <daemontool_> so if the restore fail
14:54:50 <daemontool_> it will restart only for that level
14:54:55 <daemontool_> the restore without --incremental
14:54:56 <slashme> daemontool_: I testest all of this
14:55:13 <daemontool_> ok? does it make sense what I'm saying?
14:55:23 <ddieterly> slashme no joy, on all your tests, right?
14:55:24 <daemontool_> I mean does the theory works in practice?
14:56:43 <m3m0_> guys we have less than 5 minutes left
14:56:53 <ddieterly> slashme let me rephrase that: you did not find a workaround, right?
14:57:14 <slashme> No
14:57:41 <ddieterly> i think this is going to be a continuing problem that has to be solved
14:57:43 <daemontool_> mmmhhh
14:57:46 <daemontool_> yes
14:57:48 <daemontool_> top critical
14:57:56 <daemontool_> blocker I'd say
14:58:06 <ddieterly> yea
14:58:15 <daemontool_> ddieterly,  open a tt to the PS
14:58:15 <daemontool_> haha
14:58:16 <ddieterly> so, dar did handle this case
14:58:17 <daemontool_> :)
14:58:19 <ddieterly> i proved that
14:58:30 <ddieterly> szaher_ suggested a dar engine
14:58:37 <m3m0_> why don't we use that as an engine ?
14:58:50 <ddieterly> that is a possibility
14:58:53 <m3m0_> guys one minute
14:58:57 <slashme> That requires to rewrite a lot of code ...
14:59:00 <daemontool_> yes
14:59:13 <daemontool_> let's go to the freezer chan
14:59:13 <szaher_> I have a patch in review since too long we need to merge it to have more enignes !
14:59:17 <szaher_> engines *
14:59:17 <m3m0_> not really
14:59:30 <m3m0_> ok guys, see you on the other channel
14:59:31 <m3m0_> #endmeeting