15:02:25 <daemontool_> #startmeeting Freezer_weekly_01/10/2015
15:02:25 <freezerBot`> Meeting started Thu Oct  1 15:02:24 2015 UTC and is due to finish in 60 minutes.  The chair is daemontool_. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:25 <openstack> Meeting started Thu Oct  1 15:02:25 2015 UTC and is due to finish in 60 minutes.  The chair is daemontool_. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:25 <freezerBot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:25 <freezerBot`> The meeting name has been set to 'freezer_weekly_01_10_2015'
15:02:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:29 <openstack> The meeting name has been set to 'freezer_weekly_01_10_2015'
15:02:36 <daemontool_> Meetings notes available at: https://etherpad.openstack.org/p/freezer_meetings
15:03:18 <vannif> hello everyone
15:03:23 <daemontool_> hi
15:03:57 <reldan> Hi
15:04:27 <vannif> So, welcome back daemontool_
15:04:32 <vannif> do you want to start ?
15:04:37 <daemontool_> yes, thanks
15:04:52 <daemontool_> I've been working mainly on the integration gate tests
15:05:25 <daemontool_> the objectie of this would be to have a dsvm gate job to automatically execute integration tests on freezer-*
15:05:54 <daemontool_> also I've been working on code review
15:05:58 <daemontool_> and fixed this bug https://review.openstack.org/#/c/226435/
15:06:42 <daemontool_> ont he next week I'm planning to finish the integrate-gate jobs with vannif and improve the freezer documentation related to the scheduler with example, config json files ,etc
15:07:19 <daemontool_> another very important think I'd like to do, is to use oslo.log instead of the logging std lib module we are currently suing, that would align us more to openstackish
15:07:42 <vannif> yes, I definitely want to help on that, since I've worked on the integration tests in the source code tree
15:07:49 <daemontool_> for the integrated-data we are more or less taking barbican as example for the devstack plugins and integration
15:08:22 <daemontool_> we need also to release next week the release 1.1.3 on pypi
15:08:42 <daemontool_> and create a new branch proposed/kilo as our effort are focused to be kilo compliance
15:08:52 <daemontool_> after that we'll switch to be liberty compliance and so on
15:08:58 <daemontool_> that's all from me
15:09:27 <daemontool_> any question please let me know
15:09:46 <vannif> regarding the gate job, do you plan to have the in openstack CI ?
15:10:25 <daemontool_> I think before we'll set it up in our internal zuul deployment, and afterwards we'll do for the public openstack ci
15:10:41 <daemontool_> using our internal ci toolchain will be probably fast in terms of learning experience
15:10:59 <daemontool_> so when we'll set it up publicly we'll have less obstacles
15:11:28 <vannif> I agree
15:13:01 <vannif> how much will be the effort to switch to oslo.log ?
15:14:10 <daemontool_> I think 5 full days
15:14:20 <daemontool_> including testing
15:14:37 <daemontool_> I'd say 3-5 days
15:15:41 <vannif> if you need a hand I can help after the integration gate jobs are walking
15:16:05 <daemontool_> yes we can do that together, thanks a lot vannif : )
15:17:05 <vannif> no worries :)
15:17:21 <vannif> if that's all I can start
15:17:31 <daemontool_> sure, that's all from me
15:17:40 <vannif> ok, thanks deamontool_
15:18:01 <vannif> so, I've been working lvm code
15:18:49 <vannif> that was needed to fix a bug when the lvm volume to be snapshotted was not mounted on filesystem root
15:19:42 <vannif> the patch basically reworkad a little how the paths are managed for the lvm snapshots, and simplifies the usage
15:20:49 <vannif> the cli logic is still compatible with the former, but now the user can just request a snapshot without having to provide mount points and backup paths
15:21:00 <vannif> freezer will figure out and use some defautls
15:21:46 <daemontool_> vannif,  so that improved the usability as now much less options needs be used, is that right?
15:22:04 <vannif> yes. that's right
15:23:35 <vannif> instead of providing parameters such as lvm_auto_snap, backup_path, lvm_snapname
15:23:52 <vannif> the user can provide the path to the resource she wants to backup
15:24:06 <daemontool_> great, lvm_dirmount is still needed?
15:24:07 <vannif> and request a lvm snapshot using the cli flag --snapshot
15:24:58 <vannif> no. when lvm_dir_mount is not provided, freezer uses a default value of /var/lib/freezer
15:25:35 <vannif> BTW, I'd like to discuss further use cases and checks to this default behavior
15:25:55 <daemontool_> ah ok, wouldn't be a reasonable idea to use /var/lib/freezer-{$backup-name} ? so that would avoid conflicts for multiple backup execution?
15:25:59 <daemontool_> ok
15:26:18 <vannif> for example in case the user triggers two concurrent freezer runs which require snapshots
15:26:50 <daemontool_> ok
15:27:16 <daemontool_> one more question: do we have couple of examples in the README/doc for the simplified execution?
15:28:27 <vannif> not yet. I'll do that.
15:28:42 <daemontool_> ok
15:30:09 <vannif> besides that I've improved the integration tests while supporting Eldar in testing the parallel storage code
15:32:12 <vannif> I'm also working on a procedure to set up the testing environment on a clean devstack machine. the purpose is to use it in integration gat jobs
15:32:27 <vannif> s/gat/gate
15:33:16 <daemontool_> vannif, just an idea what do you think if we set a default also for the container?
15:34:29 <vannif> well, the temporary mount point is just that: temporary. it will be used for the snapshot, chdir into it and backup the filesystem tree
15:34:37 <vannif> no particular record of it
15:34:46 <vannif> the user does not need to remember it
15:34:55 <daemontool_> +1
15:35:04 <vannif> the container is actually a resource the user must be aware of
15:35:16 <vannif> since it's the location of his data :)
15:35:32 <daemontool_> well yes, but we can use a default
15:35:58 <daemontool_> it's worth having a discussion about it
15:36:19 <vannif> yes, sure. the default value must be reasonable, well advertised, and possibly searchable easily
15:36:37 <daemontool_> yes something like freezer_backup-name
15:36:58 <daemontool_> somethign like that
15:37:32 <vannif> this issue is somewhat linked with the api and the possibility for the user to browse and search through is backups
15:38:35 <vannif> before taking in consideration the api, though, we can think of a request to the scheduler to go into the (default) container and gather a list of backups
15:38:41 <vannif> with relative metadata
15:39:19 <daemontool_> ok
15:39:22 <vannif> more evoluted than a simple list of object contained in the object server
15:39:28 <daemontool_> yep
15:40:57 <daemontool_> I think we can probably move forward
15:41:03 <vannif> ok, I'll work on the idea to improve the lvm_dirmount default position
15:41:08 <vannif> yes
15:41:15 <vannif> any question ?
15:41:28 <vannif> ok. Eldar
15:41:36 <reldan> Thank you.
15:42:14 <reldan> I’m working on peformance improvement for ssh connection, I was trying to increase transport window, but it didn’t help. Looking for new solution.
15:42:42 <reldan> After that I’m going to iprove overall test coverage
15:42:58 <reldan> it’s all from my side
15:43:12 <vannif> yes, we need to work on coverage each patch we release
15:43:25 <vannif> otherwise untested lines stack up :)
15:43:55 <vannif> any idea about when it will be in review ?
15:43:57 <reldan> Agree, agree - I recently have did a lot of changes without proper coverage, my bad
15:44:54 <vannif> regarding the parallel storage
15:44:59 <reldan> I hope I will show it tomorrow - because I have no many ideas how to improve it. Or I will postpond it, if no on works
15:45:38 <vannif> is there a way to use such feature ?
15:46:06 <vannif> starting with using it for testing purposes
15:46:31 <reldan> Sorry, I don’t quite understand - what the feature we are talking about?
15:46:39 <vannif> parallel storage, sorry
15:47:28 <reldan> Oh, we need have a new mechanism of processing config files / cli. It requires not a major, but big enought refactoring
15:47:49 <reldan> So we decided to do it in different branch and merge after release
15:48:14 <reldan> I suppose I will start it next week
15:49:27 <vannif> ok. you need any help. we were talking about the definition of the configuration options to pass to the freezer agent.
15:49:44 <reldan> Sure, we can prepare the blueprint together
15:50:59 <vannif> ok, I'd say let's be clear upon the format of the config options and share them as first step
15:51:08 <vannif> I'll be glad to help on that
15:51:23 <vannif> anything else  to say ?
15:51:37 <reldan> Deal - let’s do it together. Because it really requres some refactoring. We are getting the dict from
15:51:46 <reldan> argparse and use it as a core object
15:51:50 <reldan> in our architecture
15:52:44 <vannif> so it's not a trivial refactoring. it's a new object with some responsibilities
15:53:36 <vannif> good. we need to consider also the switch to cliff then. so that all the code will not need to be thrown away
15:53:39 <reldan> I believe so, we also can have a lot of checking of input - like validator now
15:54:01 <reldan> We can do it in two steps, but it is a good idea as well
15:54:26 <reldan> First step - extract configuration from dictionary and work inside of our code with configuration
15:54:39 <reldan> And second - replace mechanism of getting arguments from CLI
15:55:40 <vannif> so that will be one of the major refactoring in the branch we are going to create, isn't it ?
15:56:27 <reldan> I have no idea ) We can do it in two steps - it will be better. But if we cannot pull small updates before the release - we can do a lot of changes in the branch
15:57:25 <vannif> ok. when we have a clearer idea we will discuss, as usual :)
15:57:33 <reldan> Agree )
15:57:38 <vannif> anything else ?
15:57:49 <reldan> Nope, it is all )
15:58:00 <vannif> thank you reldan
15:58:05 <reldan> Thank you
15:58:07 <vannif> szaher
15:58:15 <vannif> you turn :)
15:58:26 <szaher> Hi all
15:58:37 <szaher> actually I was working on some bugs in freezer
15:58:58 <szaher> trying to tune some error messages and enhancing freezer
15:59:33 <szaher> Also there is some bugs related to lvm, I am not reporting and not working on them because vannif is work on lvm staff
15:59:52 <szaher> vannif, you are going to rewrite it ?
16:00:41 <vannif> it's merged, feel free to submit any bug you find
16:01:38 <szaher> Okay, so If i found something I will report it and work on it
16:01:52 <vannif> yes please
16:01:56 <vannif> :)
16:02:10 <szaher> Sure :)
16:03:37 <vannif> anything else to say ?
16:04:00 <szaher> Thanks
16:04:29 <vannif> if you have any doubt, feel free to ask. freezer code base has moved quite a lot recently :)
16:05:19 <szaher> Yea I can see
16:05:31 <vannif> I think slashme is not available atm
16:05:49 <vannif> if you don't mind we can suspend for a few minutes
16:15:39 <Slashme> Hi, I still didn't do anything on the public side I think
16:16:05 <vannif> ok. you did great on the private though :)
16:16:37 <vannif> sir m3m0 is on holidays
16:16:51 <vannif> so I think that is pretty much all
16:17:01 <vannif> anyone has anything else to say ?
16:19:10 <szaher> thanks
16:20:25 <vannif> ok, thank you all.
16:20:27 <vannif> #endmeeting