14:03:41 <slashme> #startmeeting freezer
14:03:41 <openstack> Meeting started Thu Jan 19 14:03:41 2017 UTC and is due to finish in 60 minutes.  The chair is slashme. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:45 <openstack> The meeting name has been set to 'freezer'
14:03:56 <slashme> Hello everyone :-)
14:04:10 <raliev> hey slashme, hey everyone :)
14:04:11 <szaher_> Hello everyone
14:06:20 <slashme> As usual, you can find the meeting notes and agenda here: https://etherpad.openstack.org/p/freezer_meetings
14:07:43 <dstepanenko> hello everyone
14:10:16 <slashme> #topic pike_ptl
14:10:46 <slashme> As most of you know, I won't be running for PTL for the Pike cycle
14:11:27 <slashme> I posted an email in the mailing list to announce that, but I'd like to take a minute to thank all of you
14:12:01 <slashme> Thanks for contributing to Freezer :-)
14:12:13 <yangyapeng_> thank you slashme
14:12:15 <szaher_> I would like to apply to be the Pike PTL that would be a great chance for me to contribute do more with freezer
14:12:18 <szaher_> Thanks slashme
14:12:20 <raliev> slashme, thank you for your work :)
14:12:37 <slashme> I think that's a great idea. szaher
14:13:03 <dstepanenko> thank you too, slashme :) as for me you payed enough attention to all the things I asked to take a look, so thanks for that :)
14:13:06 <szaher_> It would be a great chance for me to work closely with the existing great team to keep freezer moving forward and add more features
14:13:29 <slashme> Also, I would like to nominate raliev to a position in the core team.
14:13:44 <szaher_> +1
14:13:53 <yangyapeng_> +1
14:14:00 <dstepanenko> +1
14:14:32 <slashme> We have the policy of waiting for a developper to contribute one big feature before adding them. As soon as this https://review.openstack.org/#/c/409796/ gets merge, you qualify.
14:14:35 <raliev> slashme, guys -  thank you a lot! This is a great honor for me :)
14:14:44 <slashme> I'm sure other will follow soon :-)
14:15:15 <slashme> I'll send the email later today or tomorrow. Please check your inbox and +1 on the mailing list as usual.
14:15:55 <slashme> I guess that's it for the administrative part
14:16:04 <slashme> #topic Optimize freezer-web-ui
14:16:06 <szaher_> slashme raliev I will be testing this one https://review.openstack.org/#/c/409796/ very soon to get it merged
14:16:20 <slashme> I am testing it as well at the moment
14:16:38 <slashme> Optimize freezer-web-ui (Solicitation bug):  https://review.openstack.org/#/c/421634
14:17:43 <raliev> slashme, szaher_  okay, if you have any questions or comments -  I'll reply
14:18:15 <szaher_> Thanks raliev
14:18:33 <yangyapeng> szaher_:  slashme
14:18:33 <slashme> #topic Pending Reviews:
14:18:45 <slashme> I updated the list here: https://etherpad.openstack.org/p/freezer_meetings
14:19:01 <yangyapeng> please review this patch  about the client register https://review.openstack.org/#/c/421634
14:19:59 <slashme> Patch in the "Small" list should be quick to review. Please take some time to review some of the patch in the "Big" list, they are the one needing more attention.
14:20:00 <szaher_> yangyapeng ?
14:20:25 <yangyapeng> Sorry, i forget it . that client register could register have more clinet_id in a host name
14:22:03 <yangyapeng> szaher_: why is it that register more one client_id in a hostname
14:22:33 <yangyapeng> szaher_: if we should have a limit
14:23:18 <szaher_> The client registration uses the hostname as client id
14:23:44 <slashme> We want to change that at some point: https://blueprints.launchpad.net/freezer/+spec/better-client-id
14:25:11 <yangyapeng> slashme: szaher_ now, freezerclient   freezer client-register  can register more one client
14:26:27 <yangyapeng> slashme: oh, i see the spec, it is better
14:28:48 <raliev> We need to change mechanism of registering clients (schedulers) according to the bp
14:29:45 <szaher_> I could be nice if we can manage the clients from freezer-api, like allowing clients to register jobs or not, what kind of jobs this client can do and stuff like that
14:30:14 <szaher_> that might be useful for admins to manage their backups and clients from a centralized point of view
14:30:23 <raliev> yep and we should track what clients are available for the moment
14:30:41 <slashme> raliev: +1
14:30:52 <yangyapeng> if we have a hostname in a conf, as a same as nova-compute
14:31:02 <slashme> This is planned in the blueprint with last_poll_date
14:32:31 <yangyapeng> so, https://review.openstack.org/#/c/422349/ this patch could need more a change in the future
14:36:23 <slashme> Yes it might require some change.
14:36:28 <slashme> #topic free
14:36:42 <slashme> Anything else that you want to discuss ?
14:36:54 <dstepanenko> yep
14:37:21 <dstepanenko> there's a blueprint for freezer-dr https://blueprints.launchpad.net/freezer/+spec/quasi-live-vm-backup
14:38:27 <dstepanenko> I was looking into freezer-dr tool and wonder why this strange quasi-live backup was chosen instead of using normal live migration
14:38:49 <dstepanenko> or probably I'm missing something and these are 2 different features which can exist on the same time
14:38:54 <yangyapeng> i think szaher_ should have a good idea
14:39:04 <yangyapeng> hello Allen_
14:39:10 <yangyapeng> ping Allen_
14:39:12 <dstepanenko> so, what was the original purpose of quasi live backup thing
14:40:16 <slashme> In freezer-dr, we use evacuation instead of migration (same thing in the end)
14:40:38 <slashme> As far as I know. We never implemented that blueprint. It is very very old
14:41:15 <yangyapeng> evacuate --on-share-storage
14:41:16 <dstepanenko> ok, what about using live migration? Did we have such plans? Judging by documentation we has
14:41:28 <dstepanenko> but do we have them now?
14:42:14 <dstepanenko> because in https://github.com/openstack/freezer-dr/blob/master/README.rst you can find
14:42:35 <dstepanenko> Any evacuation driver (currently supports evacuate api call, may be migrate ??)
14:43:41 <slashme> Yes, I guess we could implement an evacuate driver.
14:43:56 <slashme> szaher ? Any comment on that ?
14:44:09 <dstepanenko> as far as I know there's already implementation of evacuate driver
14:44:56 <dstepanenko> the question is - is there any reason we use live migration as an alternative for that purposes? there are customers which are interested in it
14:45:22 <dstepanenko> is there any reason we can't use live migration
14:45:29 <dstepanenko> sorry, misspeled
14:46:40 <yangyapeng> live-migration api must be nova-compute is up and enable
14:47:20 <slashme> evacuation is meant to be used when the compute node is down. Live migration is meant to be used when the compute node is up. These are two different usecase
14:47:45 <dstepanenko> yes, you're right
14:48:28 <yangyapeng> :)
14:48:29 <dstepanenko> then I'm gonna propose blueprint for being able use live migration in case compute node is up
14:48:44 <dstepanenko> don't you mind?
14:50:01 <yangyapeng> dstepanenko: but ,if nova-compute is up, what is freezer-dr a role?
14:52:55 <dstepanenko> I think there are use cases when node is alive, but there are some issues on it
14:53:16 <dstepanenko> so, it's allowed to do live migration but it's not in a good shape
14:53:36 <dstepanenko> because of some of it's services which are not relevant to live migration ability
14:53:41 <dstepanenko> does it make sense?
14:54:00 <slashme> It makes sense
14:54:12 <slashme> I did not think about this usecase
14:58:38 <slashme> Okay. We are running out of time.
14:58:54 <slashme> Thank you all for your participation :-)
14:59:01 <slashme> #endmeeting