14:05:53 <slashme_> #startmeeting freezer
14:05:54 <openstack> Meeting started Thu Dec  8 14:05:53 2016 UTC and is due to finish in 60 minutes.  The chair is slashme_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:05:58 <openstack> The meeting name has been set to 'freezer'
14:06:04 <slashme_> Hello everyone :)
14:06:09 <yangyapeng> hello slashme_
14:06:15 <zhusz1> hello everyone :)
14:06:17 <yangyapeng> \o
14:06:42 <raliev> hi everyone :)
14:06:53 <dstepanenko> hi
14:06:58 <neilus_> hi everyone
14:07:21 <szaher> hello slashme
14:07:26 <szaher> hello slashme_
14:08:37 <slashme_> As usual, meeting notes and agenda are available here: https://etherpad.openstack.org/p/freezer_meetings
14:08:46 <slashme_> #topic oslo.db
14:09:12 <slashme_> Thank you neilus_ for drafting the spec.
14:09:43 <slashme_> If everyone could have a look at it, it would be great : https://review.openstack.org/#/c/408014/
14:09:55 <neilus_> my pleasure
14:12:08 <raliev> I've already put my comment to spec
14:12:34 <raliev> And one more thing
14:13:29 <raliev> neilus_, slashme_ regarding Clients structure, I think that we could get smth ideas from here https://blueprints.launchpad.net/freezer/+spec/better-client-id
14:13:57 <neilus_> thx, raliev
14:14:01 <slashme_> Yes, exactly what I was commenting on the bp
14:14:34 <raliev> I've thought about it, and I have one proposal
14:15:22 <raliev> I think there is need to add field where we could put kind of 'fingerprint' of host
14:15:40 <raliev> for identifying particular client
14:15:50 <raliev> and not to store uuid in config
14:16:12 <raliev> I mean this point from bp - '- Once generated, store the id in the freezer-scheduler config file (I think this is the right one).'
14:16:48 <slashme_> Let's take a usecase:
14:17:03 <slashme_> You have a VM1 running freezer-scheduler
14:17:14 <slashme_> At start an uuid is generated
14:17:20 <slashme_> Your VM dies
14:17:29 <slashme_> So you start a VM2
14:18:27 <slashme_> You install the scheduler on it and then retrieve the old uuid and start the scheduler (No uuid will be generated as you are prtoviding it)
14:19:05 <slashme_> Your VM2 is then considered VM1 by the API, which is what you want in this case
14:19:18 <slashme_> If you use a fingerpring, they will be different
14:19:31 <raliev> yep, you're right
14:19:57 <raliev> but in this case I think we should add field 'State' for client
14:20:14 <slashme_> What would be the values ?
14:21:48 <raliev> smth like 'active', 'down' maybe
14:22:07 <raliev> because client may be registered, but then stopped
14:22:24 <raliev> and it's is not able to perform actions
14:22:39 <slashme_> Why not, but I think you could guess that from the 'last_poll_date' field
14:24:08 <raliev> yep, but this will be more obvious for the end user, I think
14:25:49 <raliev> user wants to perform some action on node where scheduler is stopped, we could notify him that performing action is unavailable now
14:26:18 <raliev> or remove stopped client from list when add client to the job
14:26:28 <slashme_> I agree. But how would this field be modified then ? We define a policy in the freezer-api configuration like 'consider_client_down_after' ?
14:27:24 <raliev> we can do two things:
14:28:23 <raliev> 1. when 'freezer-scheduler stop' executed, we can send update to API
14:29:11 <raliev> 2. define heartbeat for scheduler. if last_poll_date is old, then make in down
14:29:29 <slashme_> I think 2 is better.
14:29:43 <slashme_> Because number 1 only deals with intentional stop.
14:30:19 <slashme_> What about the vm crash, has no network access, freezer-scheduler stops because of an exception, ...
14:30:56 <raliev> yep, in this cases heartbeat more preferred than only update
14:31:52 <slashme_> We don't really need a heartbeat, as the schedulers already query the API regularly to check for new jobs. This could work as our heartbeat
14:32:56 <raliev> yeah, poll jobs
14:33:13 <slashme_> I guess we could even only keep the last_poll_date in the database, and have the python-freezerclient compute the status from it everytime it queries for a client.
14:34:05 <raliev> sounds good
14:35:12 <raliev> we only need to implement that is API, when client polls jobs then update last_poll_date
14:35:19 <raliev> in API*
14:35:24 <slashme_> Yes
14:35:46 <slashme_> Okay. Next topic ?
14:36:06 <slashme_> #topic release python-freezerclient
14:36:30 <raliev> version 2.0.0?
14:37:08 <slashme_> Hmm, I need to figure out the version number.
14:37:42 <slashme_> What patch do we want to include before I release ?
14:37:52 <slashme_> https://review.openstack.org/#/c/405579/
14:37:58 <slashme_> https://review.openstack.org/#/c/402170/
14:39:05 <raliev> yep
14:39:36 <zhusz1> yes
14:41:33 <slashme_> Okay. Once these are merged I request the release
14:41:51 <slashme_> #topic pending reviews.
14:41:53 <raliev> And I'll try to check all features soon
14:42:00 <raliev> in freezerclient
14:43:34 <slashme_> Good :)
14:44:12 <slashme_> I updated the pending review here:  https://etherpad.openstack.org/p/freezer_meetings
14:45:27 <slashme_> Let's try to get all these merged as soon as possible. Ocata-2 milestone is comming next week, which means release for all freezer components
14:45:42 <slashme_> #topic All the rest
14:45:53 <slashme_> Anything you want to discuss ?
14:46:40 <raliev> nothing from me :)
14:46:51 <szaher> thanks
14:47:03 <zhusz1> May I pick some BP to do from the bp list?
14:47:27 <slashme_> Yes. No problem.
14:47:35 <zhusz1> :)
14:47:35 <slashme_> Some might be outdated though.
14:47:47 <slashme_> I'll try to do some cleanup at some point
14:49:19 <zhusz1> Is is possible that use oslo.db in the freezer-agent also?
14:50:08 <slashme_> In order to do what ?
14:50:59 <zhusz1> I want to backup the all database to use oslo.db. Is It possible?
14:52:40 <neilus_> you mean for backing up relational db-s?
14:52:51 <zhusz1> yes
14:52:56 <slashme_> Well, If you plan on doing SQL backups (generating SQL files). Then I think it makes sense.
14:52:56 <slashme_> At the moment, freezer takes filesystem backups for Mysql. This is faster.
14:52:57 <slashme_> I guess it would be nice to propose multiple solutions.
14:53:11 <neilus_> I'm afraid oslo and sqlalchemy is not meant for that
14:53:22 <slashme_> https://www.percona.com/blog/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/
14:53:59 <zhusz1> neilus, yes.
14:54:15 <neilus_> I believe that we might not want to create a universal agent to sync the db-s in general what we have
14:54:16 <slashme_> neilus_: oslo does not support some kind of SQLdump action ?
14:54:38 <neilus_> maybe sqlalchemys migration toolkit/api
14:54:42 <neilus_> but i'm not  sure
14:55:10 <neilus_> but personally i don't find this a good idea...
14:55:25 <neilus_> it would be overcomplicated in my opinion
14:56:35 <slashme_> I agree it seems a bit too much dependancies to add to freezer-agent
14:56:38 <neilus_> but i can be wrong tough
14:57:06 <neilus_> and rdbms-s usually have their own backup toolchain and strategies...
14:57:32 <zhusz1> neilus, yes, you're right.
14:57:36 <neilus_> we should stick with vendor recommendations as plugins in the agent i think
14:57:59 <zhusz1> Good idea
14:58:41 <zhusz1> Maybe we can do a db engine.
14:59:35 <zhusz1> It's time to end
14:59:37 <slashme_> Okay. We are running out of time. We can continue any remaining discussions in #openstack-freezer.
14:59:37 <slashme_> Thank your for joining this week's meeting :-)
14:59:52 <zhusz1> Thanks
15:00:07 <slashme_> #endmeeting