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