15:12:18 <m3m0> #startmeeting 2015-09-17
15:12:18 <freezerBot`> Meeting started Thu Sep 17 15:12:18 2015 UTC and is due to finish in 60 minutes.  The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:12:18 <freezerBot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:12:18 <freezerBot`> The meeting name has been set to '2015_09_17'
15:12:19 <openstack> Meeting started Thu Sep 17 15:12:18 2015 UTC and is due to finish in 60 minutes.  The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:12:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:12:23 <openstack> The meeting name has been set to '2015_09_17'
15:12:41 <m3m0> Hello everyone, sorry for the delay
15:12:57 <m3m0> all: notes available in https://etherpad.openstack.org/p/freezer_meetings
15:13:18 <m3m0> let's do a quick round on the project
15:13:28 <m3m0> fabriziov you are first
15:14:28 <fabriziov> ok
15:14:53 <fabriziov> I'm working on the lvm options
15:15:33 <fabriziov> small change to make the agent more "smart" in identifying the mount point and the directory to "cd" into
15:16:04 <fabriziov> that would result also in less options required from the user in case of lvm snapshots
15:16:08 <fabriziov> so better usability
15:16:13 <fabriziov> also
15:16:45 <fabriziov> should be ready by tomorrow at last
15:18:08 <m3m0> the lvm change, is a bug? or just an enhancement?
15:18:28 <fabriziov> kind of a bug actually.
15:19:00 <fabriziov> if the mount point of the directory to backup is not /
15:19:35 <m3m0> do we have a bug assigned to this in launchpad?
15:19:35 <fabriziov> the  path-to-backup option will not contain the whole path
15:19:51 <fabriziov> hmmm dont think so
15:20:01 <fabriziov> I will create a bug in launchpad
15:21:06 <m3m0> thanks :)
15:21:14 <m3m0> do you have anything more to add?
15:22:03 <fabriziov> there is a blueprint to improve usability which seems relative to this issue
15:22:12 <fabriziov> https://blueprints.launchpad.net/freezer/+spec/improve-freezer-usability
15:22:40 <fabriziov> Saad just told me he was working on this. I'll check with him
15:23:00 <fabriziov> We
15:23:10 <fabriziov> We'll make sure this will solve the problem
15:23:21 <m3m0> but if we are planning to send that patch as a bug fix, we should document the bug separately
15:23:46 <fabriziov> yes. I think filing the bug makes sense anyway
15:25:07 <fabriziov> Besides that I'm still reading about the openstack and gozer ci toolchain for integration tests
15:25:23 <m3m0> do you need any help with that?
15:28:39 <fabriziov> well, I can definitely use some help with that.
15:29:34 <m3m0> we should prioritize the current tasks
15:29:46 <fabriziov> if anyone has relevant docs or links or some spare mental resources :)
15:30:10 <fabriziov> yep. atm I want to close the lvm stuff.
15:30:34 <fabriziov> Since Saad has already taken a look into it, it should be fairly quick to fix it
15:32:57 <fabriziov> there's also a minor issue about the frequency of keystone requests made from the keystonemiddleware
15:33:11 <fabriziov> on behalf of the freezer-api
15:33:19 <m3m0> what's the situation there?
15:34:24 <fabriziov> maybe just enabling some caching solves
15:35:26 <m3m0> do we have timeouts?
15:35:34 <fabriziov> from what I've got, it seems that the keystonemiddleware queries keystone too often to validate the user credentials.
15:35:46 <m3m0> or tokens not valid?
15:36:26 <fabriziov> it's not a timeout problem, I think it's just that keystone receives many requests and this might be a concern
15:36:42 <m3m0> we should look in the docs if we can query once per token "life"
15:37:00 <fabriziov> in other words, the keystonemiddleware is not a "good citizen" and might stress the keystone server too much :)
15:38:32 <fabriziov> my idea is go for memcached and check the token timeout parameters
15:39:03 <m3m0> is that something that we want to do for HLM?
15:40:00 <szaher> I think the cache will solve the problem
15:40:07 <szaher> token is valid for 24 hours only
15:40:27 <fabriziov> HLM, yes
15:40:54 <szaher> http://docs.openstack.org/developer/keystone/configuration.html
15:41:02 <szaher> here you will find enabling cache will solve the problem
15:41:07 <m3m0> we can use this
15:41:07 <m3m0> #token_cache_time=300
15:41:16 <m3m0> http://docs.openstack.org/developer/keystonemiddleware/middlewarearchitecture.html
15:41:50 <fabriziov> yes memo, that's precisely the documentation I was looking into.
15:41:57 <m3m0> perfecto :)
15:42:57 <fabriziov> Saad, the problem seems to be that the keystonemiddleware queries keystone when it does not need to.
15:43:13 <fabriziov> not a keystone problem, but rather a keystonemiddleware one
15:43:57 <szaher> Okay
15:45:07 <fabriziov> the fact that there are more than one apis behind a HAProxy reduces the gain of using the cache, but not so much I think
15:49:05 <m3m0> do you have anything more to add fabriziov?
15:51:07 <fabriziov> no. thanks memo
15:51:38 <m3m0> thanks :)
15:51:44 <m3m0> reldan, you're next
15:51:55 <reldan> Thank you, m3m0!
15:52:38 <reldan> My code with first iteration of parallel backup is in master! And it works. So my next step is changing our config file
15:52:49 <m3m0> congratulations :)
15:52:58 <reldan> It should accept OS credentials as well as multiple storages
15:53:01 <reldan> Thank you!
15:53:17 <reldan> Today I did a small fix to my ssh storage - I have added SSH_PORT
15:54:10 <reldan> So I’m going to work on config files for storages. I would like to ask Fabrizio Vanni to help me
15:54:24 <reldan> It’s all from my side
15:54:29 <m3m0> you should have a small meeting to discuss this offline then :)
15:54:30 <m3m0> thanks a lot
15:54:37 <m3m0> szaher, you're next
15:54:56 <szaher> Thank you, m3m0
15:55:32 <szaher> I was working on throttling bandwidth bug, because it's not working for https
15:56:02 <szaher> I used a 3rd party app called trickle to limit bandwidth on linux and will search for something suitable for windows
15:56:17 <szaher> the code for limiting bandwidth on linux is in master now
15:56:26 <m3m0> perfect, those are great news
15:56:28 <m3m0> thanks a lot
15:56:38 <szaher> also I've been working on another task
15:56:39 <szaher> https://blueprints.launchpad.net/freezer/+spec/improve-freezer-usability
15:56:49 <m3m0> are you planning on working on usability next ?
15:56:54 <szaher> this blueprint I created to improve freezer usability
15:56:56 <m3m0> perfect
15:57:18 <m3m0> are we planning to move to cliff?
15:57:21 <szaher> container, there is a default value for container
15:57:35 <m3m0> https://github.com/openstack/cliff
15:57:39 <m3m0> for the arguments?
15:57:52 <szaher> Okay, this is another issue
15:58:00 <szaher> we need to be aligned with openstack standards
15:58:24 <szaher> but for the time being we need to fix some usability issues to make user life easier
15:58:31 <szaher> * lvm_dirmount
15:58:31 <szaher> * container
15:58:31 <szaher> * path_to_backup with lvm snapshots
15:58:42 <szaher> We need to provide default value for those 3 parameters
15:59:05 <szaher> the first two are done now, I'm working on the third one and once I finish I'll commit
15:59:11 <m3m0> why container?
15:59:16 <szaher> we can plan for using cliff to rearrange our arguments
15:59:50 <szaher> container it's already in, If the user didn't provide a container name freezer will use freezer_backups
16:00:10 <m3m0> and for local and ssh?
16:00:31 <szaher> for storage reldan is using default value as swift
16:01:04 <m3m0> but the container default value will be freezer_backups when storing on swift
16:01:18 <m3m0> but what will be the default value for ssh and local?
16:01:41 <reldan> There are no default for ssh and local
16:02:28 <szaher> for ssh and local not done yet
16:02:43 <szaher> I'll work on it
16:02:45 <reldan> I just have no idea what we can use as default for ssh and local
16:03:07 <reldan> /tmp ?  )
16:03:14 <m3m0> mmm
16:03:22 <szaher> may be the home directory of the user
16:03:27 <m3m0> i don't think that should be the correct behaviour
16:03:32 <szaher> and we use a folder called freezer_backups
16:03:33 <szaher> ?
16:03:39 <reldan> But it may be windows as well
16:03:51 <reldan> yes - and it’s fails
16:04:00 <m3m0> because if you set 2 different backups without defining a container
16:04:15 <m3m0> those 2 could get corrupted isn't it
16:04:15 <m3m0> ?
16:04:52 <reldan> I would prefer don’t have any default value
16:04:57 <reldan> It’s strange actually
16:05:12 <m3m0> yeah kind of, to have only a default value for swift
16:05:17 <reldan> And for me it is strange that we adding “freezer” prefix for swift
16:05:43 <reldan> freezerc —path-to-backup … container = my-backups
16:05:53 <fabriziov> yeah ... what about "frozen" ?
16:05:55 <reldan> but actually it will store data in freezer_my-backups
16:06:05 <reldan> Why?
16:06:28 <reldan> I have no possibility to store my data in container without “freezer” prefix at all
16:06:43 <m3m0> #agree with that
16:07:03 <m3m0> we should find a better behaviour for that
16:07:20 <reldan> Agree
16:07:47 * fabriziov agrees
16:08:11 <szaher> Okay, decision ?
16:08:13 <m3m0> so we agree that we should put a default value in containers?
16:08:25 <reldan> I
16:08:27 <m3m0> shouldn't*
16:08:32 <reldan> I’m not sure )
16:08:32 <m3m0> me too
16:08:44 <m3m0> i think we shouldn't do that
16:09:33 <fabriziov> default ok, forced value no
16:09:55 <reldan> Default is strange for me )
16:10:07 <reldan> For swift we can imagine some funny name
16:10:13 <reldan> But for other storages
16:10:18 <szaher> container is a term used only for swift and not for ssh and local
16:10:42 <reldan> But I actually don’t think that it is a major problem
16:10:50 <szaher> so we will provide default value for container for swift only ? or we will make it mandatory for the user to enter a container name ?
16:10:51 <reldan> It’s nice to discuss problem
16:10:54 <fabriziov> default for ssh could be a folder in ssh_user's home
16:11:20 <szaher> I suggested that before, but what about local ?
16:12:15 <m3m0> can we discuss this offline?
16:12:33 <reldan> Yes, sure. I’m not sure that it has any significant priority
16:12:57 <szaher> Sure
16:13:04 <m3m0> agree with that :)
16:14:01 <m3m0> so, szaher, you should go on with that
16:14:21 <szaher> Okay, finally for containers I'll leave it as it's ?
16:14:30 <m3m0> with the default value
16:14:34 <szaher> Yea
16:15:13 <m3m0> does anyone have anything more to add?
16:16:37 <szaher> nope
16:16:43 <m3m0> nice :)
16:16:47 <m3m0> thanks to everyone
16:16:52 <m3m0> #endmeeting