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