14:02:49 <szaher> #startmeeting freezer 14:02:50 <openstack> Meeting started Thu Apr 6 14:02:49 2017 UTC and is due to finish in 60 minutes. The chair is szaher. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:55 <openstack> The meeting name has been set to 'freezer' 14:03:34 <szaher> Hello everyone 14:03:46 <dstepanenko> hi 14:04:06 <raliev> hey guys 14:04:40 <szaher> daemontool raliev slashme m3m0 dstepanenko deepak_jon vnogin jiaopengju 14:07:45 <szaher> you will the agenda here https://etherpad.openstack.org/p/freezer_meetings 14:09:14 <szaher> #topic Move tempest plugins to separate repo 14:10:54 <szaher> vnogin mentioned we need to move freezer tempest plugin to a new repo 14:11:25 <szaher> I'm not sure if we really need this or not but I think it might be good, so we can tempest testing and add some more gates 14:11:57 <szaher> Can we vote on it guys ? move tempest testing to a new repo 14:12:12 <szaher> #startvote Move Freezer tempest plugin to a new repo 14:12:12 <openstack> Unable to parse vote topic and options. 14:13:06 <dstepanenko> szaher could you please clarify on this 14:13:47 <dstepanenko> the main reason why we need it is that we can't do tempest test of it while it doesn't reside in separate repo 14:13:52 <dstepanenko> am I right? 14:13:54 <szaher> dstepanenko: https://review.openstack.org/#/q/project:openstack/ironic-tempest-plugin we need to open a freezer repo like this one, only dedicated for tempest testing 14:14:59 <dstepanenko> so the answer to my question is yes, isn't it? 14:15:04 <szaher> dstepanenko: https://github.com/openstack/ironic-tempest-plugin 14:15:12 <raliev> do we have another examples using separate repo except ironic? 14:15:31 <szaher> raliev: yes we do 14:15:58 <szaher> raliev: https://github.com/openstack/tempest-horizon https://github.com/openstack/designate-tempest-plugin 14:16:25 <szaher> raliev: I'm not really sure if it's a guideline from OS or what 14:17:13 <dstepanenko> let's investigate this question and go back to it next week 14:17:31 <dstepanenko> because as far as I see we don't have enough information for making decision 14:18:00 <dstepanenko> don't think it's a good idea to start work without being sure we really need it 14:18:05 <dstepanenko> what do you think, guys? 14:18:09 <szaher> dstepanenko: +1 14:18:44 <raliev> another +1 to dstepanenko ^) 14:19:11 <m3m0> +1 14:19:19 <szaher> Cool Let's move on to another project 14:20:36 <szaher> #topic Freezer-DR 14:21:18 <szaher> Did anyone take a look at freezer-dr guys 14:21:48 <szaher> any enhancement plans ? 14:22:11 <szaher> dstepanenko: raliev Did you take a look at this component before ? 14:22:13 <dstepanenko> I looked into it several months ago but need some time to refresh my memories 14:22:23 <raliev> dstepanenko has a bit experience 14:22:36 <szaher> It's mainly for providing compute node HA 14:22:59 <szaher> We're planing to do some changes and extend it to do some sort of dr 14:23:20 <szaher> simply it monitors the compute nodes and once there is failure it move workload to another compute host 14:24:39 <szaher> The plan is to use between two different clouds to move the workload, I will try to write a bit documentation about it and put it upstream 14:24:40 <dstepanenko> as far as I remember there were a mechanism to evacuate nodes in case if something in the system went wrong 14:24:58 <dstepanenko> I mean in case if some openstack service failed or something like that 14:25:37 <dstepanenko> szaher: when you say "move the workload", do you think about it as about live migration? 14:26:07 <szaher> dstepanenko: It depends on the driver you're using, everything in freezer-dr is driver based 14:26:20 <dstepanenko> yes, I remember 14:26:32 <dstepanenko> currently it's all about EvactuateDriver 14:26:34 <szaher> we have monitors, fencers, evacuators, notifiers 14:26:45 <szaher> dstepanenko: Yes 14:27:22 <dstepanenko> StandardEvacuator * 14:27:48 <szaher> dstepanenko: Yes, we can add new drivers and so on 14:27:55 <dstepanenko> szaher: so, which new features you think it would be nice to have in freezer-dr? 14:28:26 <szaher> dstepanenko: I hope we can extend it to be the dr for OS 14:28:44 <szaher> so we can move all workloads not only VMs between clouds 14:29:47 <szaher> May be it can be extended to monitor what's inside the VM itself ?!! 14:30:15 <szaher> It might be the application running inside the VM and we have application evacuators 14:30:15 <vnogin> hi, and sorry, I'm late 14:30:26 <szaher> vnogin: Hey np :) 14:30:43 <dstepanenko> szaher: that's a good idea. Probably it would be good to have also several different monitors each of which would fit different use cases 14:30:54 <szaher> dstepanenko: so there are few ideas and how can we direct this project 14:31:28 <szaher> dstepanenko: I think the next step for monitors might be aggregated monitors 14:31:45 <szaher> we are doing something like that in Monasca driver 14:32:00 <dstepanenko> szaher: I think it would be good to create a draft containing things that we have, thing that we don't have but would like to have and discuss the ways we can achieve this and exact architecture of each feture 14:32:29 <dstepanenko> what do you think? 14:33:08 <szaher> dstepanenko: Yup. I'll try to prepare a presentation and present this component in the summit and try to dicuss the possible alternatives for freezer-dr and what needs to be done 14:33:23 <dstepanenko> szaher: sounds great :) 14:33:34 <vnogin> szaher: btw, will you join us tomorrow in hangout? 14:33:52 <szaher> I'll try to do a demo about freezer-dr like what Julia did and put it on youtube 14:34:29 <szaher> vnogin: Yes, Sure. I think I can access the link, but I'm thinking of creating a new link and send a mail to the os-dev mailing list 14:35:19 <szaher> any more questions/thoughts/ideas about freezer-dr ? 14:36:16 <szaher> Ok, let's move on 14:36:16 <vnogin> have you discussed Move tempest plugins to separate repo already? :) 14:36:27 <szaher> vnogin: Yes :) 14:36:34 <vnogin> damn :( 14:36:47 <szaher> vnogin: People need sometime to think about it and we will continue the discussion next week :) 14:36:57 <vnogin> ok ) 14:37:00 <szaher> #topic Summit brainstorming 14:37:02 <dstepanenko> vnogin: we decided to clarify the reason why we need it and go back to it next week 14:37:02 <vnogin> I'll check the log 14:37:13 <szaher> #link https://etherpad.openstack.org/p/BOS-Freezer-brainstorming 14:38:00 <szaher> Guys, I still can't see any input in the brainstorming etherpad :) no one is interested in writing down some ideas for freezer ? 14:38:34 <dstepanenko> not so fast :) I've just read through it 14:38:42 <vnogin> + 14:39:16 <vnogin> I think also we can discuss this issue during our meeting 14:39:16 <szaher> for example I would like us to take a look at this library #link https://pythonhosted.org/python-cloudservers/ref/backup_schedules.html and use a bit cleaner mechanism in scheduling backups 14:39:46 <szaher> vnogin: I planned for this already :D 14:43:21 <szaher> Ok, move on ? 14:43:27 <vnogin> ok, let's work on this doc after the meeting 14:43:30 <vnogin> yep 14:44:15 <szaher> vnogin: Ok 14:44:22 <szaher> #topic Pike-1 1st milestone release 14:44:52 <szaher> Please folks we need to finish the pending patches upstream as we need to release the first milestone next week 14:45:18 <szaher> The first milestone is Apr 10 - Apr 14 14:45:30 <szaher> the complete schedule is here https://releases.openstack.org/pike/schedule.html 14:46:18 <szaher> dstepanenko: raliev vnogin slashme szaher we all have some pending patches upstream Let's work on them and get them in the first milestone 14:46:44 <szaher> if someone can't make it, that's fine 14:46:45 <dstepanenko> szaher: nice plan 14:46:48 <vnogin> szaher: all my patches have been already merged 1 hour ago :) 14:46:58 <szaher> vnogin: Cool! 14:47:40 <vnogin> I think we need to review oslo db patches 14:48:08 <szaher> m3m0 was working on that, I think he had some questions for dstepanenko 14:48:10 <vnogin> they are most needed now, from my point of view 14:48:49 <szaher> vnogin: we need to get API v2 merged first and I think oslo.db should work on api v2 directly, what do you think ? 14:49:05 <vnogin> szaher: agree 14:49:48 <szaher> #agreed Merged API v2 and Multi-tenancy patch first then Oslo.db 14:49:50 <dstepanenko> szaher: these 2 oslo.db patches contain both db model and migrations, so they don't depend on api at all and can be merged simultaneously 14:49:59 <dstepanenko> wait wait :) 14:50:11 <szaher> dstepanenko: Yes, I know : 14:50:12 <szaher> :) 14:50:16 <dstepanenko> they can be done in parallel 14:50:22 <szaher> dstepanenko: We will merge the model asap 14:50:30 <dstepanenko> szaher: the patch with db call is coming 14:50:55 <szaher> dstepanenko: Most welcome :) we process it as soon as it lands :) don't worry 14:50:56 <dstepanenko> szaher: the 2nd patch with migrations can also be merged in parallel with api v2 patch 14:51:05 <dstepanenko> szaher: thanks :)! 14:51:55 <szaher> Ok, move on to next topic ? 14:52:11 <vnogin> dstepanenko: szaher I think Saad said that we will use this functionality only for api v2 :) right? so that;s why we need to merge it at the first place 14:53:08 <szaher> vnogin: dstepanenko Yes, I think oslo.db should work only on v2 and let's leave v1 as it's for now 14:53:26 <vnogin> as we can't backport it to stable branch (I mean oslodb) 14:54:52 <szaher> dstepanenko: is that Ok ? 14:55:50 <szaher> we are running out of time, move on ? 14:56:13 <dstepanenko> szaher: I don't think there will be any merge conflicts, but in case they will be, I can resolve them by myself asap 14:56:52 <dstepanenko> szaher: let's not create these virtual depencies netween these patches, because we don't have much time before the 10th of April 14:57:14 <dstepanenko> simply lets merge them in normal speed - any order is good 14:57:24 <dstepanenko> szaher: does it make sense? 14:58:16 <szaher> dstepanenko: Ok, np :) but I'm afraid the project_id column will be empty if we use oslo_db patch with v1 as v1 doesn't support project_id 14:59:12 <dstepanenko> szaher: yes, it's incompatible with v1, but the exact link between api and storage backend will be in next patch 14:59:12 <szaher> dstepanenko: we will process the patches as soon as they land :) we will take a look and will test it 14:59:19 <dstepanenko> so it's safe to merge it 14:59:24 <dstepanenko> szaher: thanks! 14:59:27 <szaher> dstepanenko: Yup :) 14:59:53 <szaher> #topic Docs 15:00:13 <szaher> I will try to do some effort to setup the layout for docs as we need this badly 15:00:28 <szaher> it's very hard for new developers to understand the process and start working with freezer 15:00:41 <szaher> If anyone can do some effort that will be great! 15:00:58 <szaher> I would appreciate your input on this one guys :) 15:01:24 <szaher> we have developer docs, api-ref, installation guides and may be docs on how to use freezer 15:01:37 <dstepanenko> szaher: so this doc is kind of faq for new developers, is that right? 15:01:43 <szaher> #topic reviews 15:01:49 <vnogin> szaher: yep, docs in freezer it's a total disaster... 15:02:14 <szaher> dstepanenko: not sure but it's like the first steps to work with freezer and to develop for freezer 15:02:18 <szaher> freezer : https://review.openstack.org/#/q/project:openstack/freezer+status:open 15:02:19 <szaher> freezer-api : https://review.openstack.org/#/q/project:openstack/freezer-api+status:open 15:02:19 <szaher> freezerclient : https://review.openstack.org/#/q/project:openstack/python-freezerclient+status:open 15:02:19 <szaher> freezer-dr: https://review.openstack.org/#/q/project:openstack/freezer-dr+status:open 15:02:19 <szaher> freezer-ui: https://review.openstack.org/#/q/project:openstack/freezer-web-ui+status:open 15:02:32 <szaher> Let's continue in freezer room 15:02:36 <szaher> Thanks guys 15:02:39 <szaher> #endmeeting