13:59:19 <m3m0> #startmeeting freezer_25_02_16
13:59:20 <openstack> Meeting started Thu Feb 25 13:59:19 2016 UTC and is due to finish in 60 minutes.  The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:59:23 <openstack> The meeting name has been set to 'freezer_25_02_16'
13:59:42 <m3m0> as always all the notes for the meetings at https://etherpad.openstack.org/p/freezer_meetings
14:00:03 <m3m0> we are having a code walkthrough at https://plus.google.com/hangouts/_/hoaevent/AP36tYeCYbeLPLRFolLHC3JwalYKv2jWaA-if17K-P8lUdvzbxdPuw?hl=en&authuser=0
14:00:14 <m3m0> we are disucssing parallel backups
14:05:34 <m3m0> so guys who is here? o/
14:06:37 <daemontool_> hi all
14:06:43 <daemontool_> m3m0,  you run the meeting?
14:07:06 <daemontool_> sorry for the delay there was until now the freezer source code walk thru session until now
14:07:12 <m3m0> ddieterly will run the first part
14:07:14 <yangyape_> ping EinstCrazy
14:07:22 <EinstCrazy> I'm here
14:07:28 <daemontool_> recording available here  https://www.youtube.com/watch?v=G8nG5l8u5Yg&feature=youtu.be
14:07:46 <zhangjn> thanks
14:07:52 <m3m0> #topic mid-cycle meeting
14:08:11 <daemontool_> meetings notes available hre https://etherpad.openstack.org/p/freezer_meetings
14:08:12 <m3m0> ok guys what do you think about the 16th of march
14:08:35 <m3m0> the day after is st patricks day here in ireland so you can enjoy the party after
14:08:39 <daemontool_> so first topic is freezer meet up?
14:08:50 <daemontool_> I think we need at least 2 days
14:08:51 <m3m0> yes, we need to agree on a date
14:08:58 <m3m0> 15-16?
14:09:28 <daemontool_> sounds good to me
14:09:30 <m3m0> tuesday and wendsday
14:09:46 <zhangjn> what's time 15~16?
14:09:58 <daemontool_> zhangjn,  is a freezer meet up
14:10:08 <daemontool_> mid cycle in Ireland
14:10:15 <daemontool_> Galway
14:10:19 <daemontool_> but we need to agree on the date
14:10:26 <daemontool_> zhangjn, if you can't make it
14:10:34 <daemontool_> we can work at the Summit
14:10:52 <m3m0> I think I cannot make to the summit
14:11:04 <szaher> Guys Freezer code walk through video is available here https://www.youtube.com/watch?v=G8nG5l8u5Yg
14:11:20 <m3m0> at least until we know the results of the speech voting
14:11:25 <daemontool_> m3m0,  ty
14:11:26 <daemontool_> ok
14:11:29 <daemontool_> np
14:11:38 <daemontool_> so 15-16 of march sounds good to me
14:11:45 <daemontool_> zhangjn,  if anyone from you guys could god
14:11:50 <daemontool_> s/go/god/
14:11:51 <daemontool_> would be good
14:11:55 <m3m0> does anyone disagree on this date?
14:11:56 <daemontool_> it will be 2 days full
14:12:00 <daemontool_> I'm ok
14:12:02 <daemontool_> I'm even
14:12:05 <daemontool_> available to do 3 days
14:12:06 <daemontool_> is possible
14:12:10 <daemontool_> Mon, Tue, Wed
14:12:34 <daemontool_> so we can discuss many things taht can be furtherly worked out during the summit
14:12:41 <daemontool_> ddieterly, sounds good to you?
14:12:45 <m3m0> we definetly need to speak with our manager and frescof on this
14:12:52 <ddieterly> which days, exactly?
14:12:59 <daemontool_> 14,15,16 March
14:13:01 <m3m0> 15 and 16 of march
14:13:43 <ddieterly> 3 days or 2 days?
14:13:54 <daemontool_> I'm available 3 days
14:14:15 <zhangjn> no budget to Galway, (:
14:14:20 <daemontool_> zhangjn,  ok np
14:14:30 <ddieterly> so, should i go for 3 or 2?
14:14:41 <daemontool_> go for 3
14:14:46 <daemontool_> so you can stay also with the other guys
14:14:51 <daemontool_> I think I'll go for 3
14:15:08 <daemontool_> ok
14:15:09 <ddieterly> are we sure about 14,15,16? is it a go?
14:15:16 <daemontool_> yes
14:15:16 <ddieterly> that is only 3 weeks away
14:15:27 <daemontool_> ddieterly, I advice you to stay until Friday
14:15:29 <ddieterly> the ides of march then
14:15:32 <daemontool_> as the 17th is St PAtrick day
14:15:39 <daemontool_> we are going to have great time
14:15:40 <daemontool_> there
14:16:02 <ddieterly> ok, we'll see about that
14:16:07 <daemontool_> so agreed?
14:16:40 <ddieterly> 15,15,16 for sure
14:16:46 <ddieterly> s/15/14
14:16:46 <m3m0> frescof are you here?
14:17:44 <daemontool_> ok
14:17:47 <daemontool_> so next topic?
14:18:25 <daemontool_> Disaster Recovery bp
14:18:37 <m3m0> #topic disaster recovery bp
14:18:45 <daemontool_> we need to add the outcomes from past conversations
14:18:47 <daemontool_> to the review
14:19:09 <daemontool_> and send an email to the openstack ml to ask for feedback
14:19:13 <frescof> yes, and some more architectural details
14:19:19 <m3m0> https://review.openstack.org/#/c/278242/
14:19:24 <daemontool_> frescof,  can you add that?
14:19:30 <daemontool_> also szaher ?
14:19:37 <m3m0> frescof regarding to the midcycle meeting, can we book a room for 3 days?
14:19:44 <frescof> on how the implementation in freezer would look like
14:19:55 <frescof> m3m0, yes sure
14:20:00 <daemontool_> frescof, yes please
14:20:09 <daemontool_> I'm going to galway for this and would be good to have 3 days
14:20:30 <frescof> no problem I will reserve a room
14:20:36 <daemontool_> ok
14:20:43 <daemontool_> next
14:20:46 <frescof> the date has already been agreed ?
14:20:52 <daemontool_> ssh restore bug ?
14:20:54 <m3m0> 14 - 16 march
14:20:56 <daemontool_> ddieterly, ?
14:20:59 <frescof> ok
14:21:10 <daemontool_> did anyone took a look at the bug you  filled?
14:21:11 <ddieterly> yes
14:21:21 <ddieterly> not sure if anyone looked at it
14:21:26 <daemontool_> ok we need to work on it
14:21:35 <reldan> I was trying to reproduce ssh bug
14:21:38 <m3m0> ddieterly: back me up for 15 min
14:21:39 <reldan> And wasn’t able
14:21:52 <reldan> It creates ssh directory for me
14:22:00 <reldan> Probably I’m doing something wrong
14:22:10 <daemontool_> reldan,  can you work out this with ddieterly  after the meeting?
14:22:13 <daemontool_> offline?
14:22:17 <reldan> yes, sure
14:22:24 <daemontool_> thanks a lot
14:22:29 <daemontool_> next
14:23:08 <daemontool_> #topic testing dsvm
14:24:02 <daemontool_> we need to have the basic integration tests we have
14:24:07 <daemontool_> execute automatically by the dsvm
14:24:15 <daemontool_> ddieterly, are you familiar with dsvm?
14:24:15 <ddieterly> m3m0: i'm not sure what 'back me up for 15 min' means
14:24:24 <ddieterly> yes
14:24:28 <daemontool_> ddieterly,  it is to run this meeting
14:24:28 <ddieterly> unfortunately
14:24:33 <daemontool_> but it's not a problem
14:24:40 <daemontool_> ddieterly,  do you want to fix that?
14:24:45 <daemontool_> otherwise I'll do it after
14:25:01 <daemontool_> the testr swift on freezer-api (including py34 porting)
14:25:02 <ddieterly> fix what exactly?
14:25:14 <daemontool_> we need to execute automatically the integration tests we have
14:25:23 <ddieterly> ah, yes
14:25:23 <daemontool_> from the dsvm gate job
14:25:26 <ddieterly> sure
14:25:33 <ddieterly> i can start to look into that
14:25:35 <daemontool_> ok ty, brilliant
14:25:39 <daemontool_> next
14:25:41 <ddieterly> how do you run the integration tests manually?
14:25:56 <daemontool_> we should have a guide there
14:26:07 <daemontool_> I'll send you the link after the  meeting
14:26:11 <zhangjn> devstack install freezer is start
14:26:12 <ddieterly> great, thanks
14:26:25 <zhangjn> but devstack is not work now.
14:26:29 <daemontool_> yes
14:26:32 <daemontool_> I'm working on it
14:26:38 <daemontool_> it's related to the testr and py34 patch
14:26:43 <daemontool_> I'm fixing here
14:26:44 <zhangjn> We can fixed some devstack problem.
14:26:50 <daemontool_> https://review.openstack.org/#/c/260950/
14:26:57 <daemontool_> zhangjn,  if you could look there
14:26:59 <daemontool_> what the problem is
14:27:02 <daemontool_> that'd be grat
14:27:03 <daemontool_> great
14:27:09 <daemontool_> only the dsvm gate job is failing
14:27:16 <daemontool_> sounds?
14:28:00 <daemontool_> ok, zhangjn  let me know if you are availe
14:28:02 <daemontool_> next
14:28:07 <daemontool_> #topic tenant based backups
14:28:16 <daemontool_> I have requirements from the company I work on
14:28:29 <daemontool_> ddieterly,  did you per chance added the requirements you have to the freezer wiki?
14:28:37 <ddieterly> yes
14:28:40 <daemontool_> brilliant
14:28:43 <daemontool_> do you have the link?
14:29:12 <daemontool_> ok let me know
14:29:22 <daemontool_> reldan, I think we need to move forward with that
14:29:28 <ddieterly> https://blueprints.launchpad.net/freezer/+spec/hpe-requirements
14:29:38 <daemontool_> ddieterly,  ok
14:30:09 <reldan> if we have requirements and you can say, that what we are going to do is exactly what we need - great
14:30:14 <reldan> let’s start
14:30:37 <daemontool_> ok
14:30:40 <daemontool_> I have to add mines there
14:30:43 <reldan> if you can show me requirements it should be great
14:30:45 <daemontool_> but the requirements are general
14:30:48 <daemontool_> sure
14:31:10 <reldan> ddieterly: It doesn’t look for me like requirements
14:31:26 <daemontool_> ddieterly,  do you mind adding the notes here? https://etherpad.openstack.org/p/freezer_meetings
14:31:32 <reldan> like - Vertica DB - it is topic probably, but not requirement from my point of view
14:32:00 <daemontool_> reldan,  yes, unfortunately the product owner in my company sent me something similar
14:32:03 <daemontool_> I think we have to deal with that
14:32:07 <daemontool_> in soem way
14:32:30 <reldan> I just suppose that product owners just don’t know what they wants
14:32:34 <daemontool_> lol
14:32:38 <daemontool_> ++
14:32:51 <reldan> and it is very easy that they will say - it is not what we had in mind
14:32:57 <daemontool_> so, let's see how we can work that out
14:32:59 <reldan> it is completelly different
14:33:02 <daemontool_> I agree
14:33:16 <daemontool_> also we should focus on tenant based backups
14:33:28 <ddieterly> what's different from 'topic' and 'requirement'?
14:33:39 <daemontool_> so requirements for instances, volumes and tenant related info
14:33:58 <daemontool_> verticadb is like a topic
14:34:13 <daemontool_> the requirements would be, have incremental backups of verticadb without downtime
14:34:39 <ddieterly> ok
14:34:41 <reldan> ddieterly: For me requirement is something like this: We have application x, that uses such database, such volumes and virtualmachines. We would like to make backups of vm (but we don’t need floating ip backup) and database. They should be / shouldn’t be syncronized
14:35:11 <daemontool_> ok reldan ddieterly  we can see this in the freezer chan after the meeting
14:35:17 <ddieterly> ok, looks like level of detail is the difference
14:35:19 <daemontool_> is that ok?
14:35:24 <daemontool_> ddieterly, well yes
14:35:24 <reldan> yes, sure
14:35:42 <ddieterly> sure
14:36:00 <daemontool_> #topic rsync block based incremental backups
14:36:08 <daemontool_> we need to revive that :)
14:36:11 <daemontool_> it's really important
14:36:18 <daemontool_> and also we need to abstract that part
14:36:22 <daemontool_> so we can have
14:36:50 <daemontool_> something like
14:36:54 <daemontool_> incremental_types
14:36:56 <daemontool_> or incremental_modes
14:37:08 <daemontool_> like rsync, tar, btrfs, zfs
14:37:09 <daemontool_> and so on
14:37:33 <daemontool_> kvm native feature
14:37:37 <daemontool_> qemu native features etc
14:37:45 <daemontool_> but we need to abstract that and make it pluggable
14:37:48 <yangyape_> what is the  backend of  the volume for  incremental backups
14:38:03 <daemontool_> yangyape_,  that a good qeustion
14:38:05 <daemontool_> I think it should be
14:38:16 <yangyape_> gluster? or ?
14:38:19 <daemontool_> one of the current back end we support such as, swift, ssh, local fs
14:38:20 <daemontool_> ah ok
14:38:28 <daemontool_> you mean the backend of cinder
14:38:37 <daemontool_> yes
14:38:37 <yangyape_> yes
14:38:41 <daemontool_> that's what we need
14:38:50 <daemontool_> bluster, btrfs, zfs
14:38:52 <zhangjn> we can use cinder-backup to backup volume.
14:38:53 <daemontool_> gluster
14:39:11 <daemontool_> zhangjn,  yes, I think we need to provide flexibility
14:39:25 <daemontool_> so if a user wants to use the cinder-backup api, with the current incremental mechanism
14:39:33 <daemontool_> he/she can
14:39:42 <daemontool_> but if the user
14:39:53 <daemontool_> want to use a different mechanism
14:39:57 <daemontool_> like glusterfs or btrfs
14:40:22 <daemontool_> to backup the volumes located on the brik or btrfs vol and zfs
14:40:27 <daemontool_> we should provide that too
14:40:32 <zhangjn> cinder-backup can cofigure backup driver
14:40:41 <daemontool_> zhangjn, that's a good options
14:41:00 <daemontool_> szaher,  yangyape_ do you like to write a bp for that?
14:41:07 <daemontool_> I feel you have a strong background on that
14:41:26 <daemontool_> then we can discuss it together
14:41:28 <daemontool_> and after that
14:41:35 <daemontool_> request feedback on the openstack ml
14:41:38 <daemontool_> sound?
14:42:15 <daemontool_> we have to define also what we want to do from the cinder api and what from the freezer api
14:42:21 <daemontool_> of volumes backup
14:42:25 <daemontool_> s/of/for/
14:42:39 <daemontool_> zhangjn, yangyape_ ok let me know if you are interested
14:42:59 <daemontool_> reldan, of course ^^
14:43:18 <daemontool_> reldan,  any thought?
14:43:29 <zhangjn> we have interested, but we have starter with freezer.
14:43:31 <EinstCrazy> this bp is about the incremental backup for block ?
14:43:50 <daemontool_> yes
14:44:05 <zhangjn> use cinder-backup api
14:44:06 <daemontool_> it's part the tenant resources backups
14:44:17 <reldan> Incremental with —incremental and --force?
14:44:23 <daemontool_> so volumes, instances, user metadata
14:44:24 <daemontool_> etc
14:44:25 <yangyape_> We can temporarily use cinder - API to do an incremental backup，
14:44:29 <yangyape_> --force
14:44:38 <daemontool_> yangyape_, I think reldan  did something about that?
14:44:48 <daemontool_> reldan,  we needed to add the metadata right?
14:44:52 <daemontool_> do I remember well?
14:44:58 <reldan> https://review.openstack.org/#/c/276685/
14:45:02 <reldan> We can do it
14:45:10 <daemontool_> brilliant :)
14:45:15 <reldan> But actually for the first implementation it should be enough
14:45:26 <daemontool_> ++
14:45:40 <reldan> The actual question for me is how to unify our architecture
14:45:47 <daemontool_> reldan, add on the README
14:45:50 <daemontool_> some information about that
14:45:59 <reldan> daemontool_: Ok
14:46:07 <daemontool_> reldan, please extend
14:46:28 <daemontool_> like pluggable?
14:46:32 <reldan> daemontool_: I know that saad amd pier have a blueprint
14:46:32 <reldan> yes
14:46:45 <reldan> pierre
14:46:45 <daemontool_> szaher, ^^ ?
14:47:23 <reldan> daeontool_: I even have some attempt in this direction https://review.openstack.org/#/c/280602/
14:47:44 <reldan> But what I am afraid - is to have multiple unrelated backup mechanism
14:47:44 <daemontool_> ah ok
14:47:46 <daemontool_> I see it now
14:47:48 <reldan> with different workflows
14:48:08 <daemontool_> this is one of the thigns we need to talk at the summit
14:48:12 <daemontool_> and mid cycle
14:48:24 <reldan> and the really hard question is how to intergrate cinder/nova backups to this architecture
14:48:36 <reldan> and how to integrate tenant backup
14:48:51 <reldan> because now it is somethign absolutly different from local tar backup
14:49:01 <daemontool_> reldan,  yes
14:49:25 <reldan> So I would like to force acceptance this document as our roadmap
14:49:30 <daemontool_> for cinder I think yangyape_  and zhangjn  can provide some inputs?
14:49:37 <daemontool_> reldan,  ++
14:49:46 <reldan> and have all our new features have alligment with this architecture
14:49:52 <daemontool_> frescof, ^^
14:50:04 <daemontool_> #agreed
14:50:11 <daemontool_> ok
14:50:14 <daemontool_> so 10 minutes left
14:50:21 <frescof> yes, I agree, we need to do few things
14:50:34 <frescof> code refactoring/cleanup
14:50:59 <frescof> preparation to a more pluggable architecture
14:51:32 <frescof> that will allow us to have the dr and the other backup mechanism
14:52:05 <daemontool_> ok, but that's not a blocker to write bp for block based backups for cinder, nova, rsync etc
14:52:18 <daemontool_> it's more an architecture related task
14:52:22 <daemontool_> vs features
14:52:22 <frescof> you are right
14:52:37 <daemontool_> we also need that
14:52:48 <daemontool_> we need to think mainly if we want to use only the cinder api
14:53:05 <daemontool_> or also have the agent installed directly on the storage nodes
14:53:11 <daemontool_> and compute nodes to execute actions
14:53:16 <ddieterly> how does this intersect with what ekko is doing?
14:53:27 <frescof> I think that those are kind of 2 different things
14:53:29 <ddieterly> ...block based backup, that is
14:53:39 <daemontool_> ddieterly,  I don't know there's still very little there
14:53:59 <daemontool_> so, no interstection now
14:54:08 <ddieterly> ok
14:54:18 <frescof> leverage cinder backups is very important
14:54:26 <daemontool_> ok, and we do that now
14:54:30 <daemontool_> at least partly
14:54:41 <frescof> and pretty easy to implement in liberty+
14:54:56 <daemontool_> ok
14:55:05 <daemontool_> we have that
14:55:09 <daemontool_> what we do not have
14:55:12 <frescof> more advanced kind of backups
14:55:15 <daemontool_> is incremental nova instances backups
14:55:20 <zhangjn> now cinder-backup can support incremental backup.
14:55:25 <daemontool_> yes
14:56:25 <EinstCrazy> but cinder incremental backup may be somehow inefficiency
14:56:37 <zhangjn> yes
14:56:38 <frescof> leveraging the storages, for example, 3par is kind of a different matter
14:56:54 <yangyape_> yes
14:57:04 <daemontool_> yes
14:57:11 <daemontool_> so we need to write bps for that
14:57:18 <daemontool_> deep thinking on it
14:57:21 <frescof> very interesting, but more complex and lot of work
14:57:21 <daemontool_> and get feedback
14:57:32 <daemontool_> frescof, this cinder incremental api par tis here https://review.openstack.org/#/c/276685/
14:57:42 <daemontool_> that is probably ready to merged after this meeting
14:57:49 <daemontool_> the only thing woud be to add also the metadata
14:57:53 <daemontool_> as next commit
14:57:56 <daemontool_> ok
14:58:01 <zhangjn> LOL
14:58:18 <daemontool_> zhangjn, I mean
14:58:23 <daemontool_> the volumes metadata
14:58:28 <daemontool_> it needs to be included in the backup
14:58:31 <m3m0> sorry guys for the delay
14:58:38 <m3m0> just remember we are short in time
14:58:41 <daemontool_> otherwise the restore can be done only on limited circumstances
14:58:43 <daemontool_> ok
14:58:50 <daemontool_> so anything else to add?
14:59:02 <daemontool_> I'd like to do
14:59:05 <daemontool_> 2 weekly meeting is possible
14:59:12 <daemontool_> for the next 8 weeks
14:59:15 <daemontool_> s/is/if/
14:59:30 <daemontool_> there are many things we need to figure out
14:59:33 <daemontool_> let's think about it
14:59:41 <daemontool_> so anyone has anything to say?
14:59:48 <m3m0> and let's move to #openstack-freezer channel
14:59:48 <daemontool_> anyone wanted to say anything and didn't have the chance?
14:59:54 <m3m0> we can finish the disussion there
15:00:01 <daemontool_> m3m0,  you can close the meeting then
15:00:02 <daemontool_> thanks all
15:00:07 <m3m0> thanks all :)
15:00:08 <m3m0> #endmeeting