15:01:45 <m3m0> #startmeeting Thu 08/ 10
15:01:45 <freezerBot`> Meeting started Thu Oct  8 15:01:45 2015 UTC and is due to finish in 60 minutes.  The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:45 <freezerBot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:45 <freezerBot`> The meeting name has been set to 'thu_08__10'
15:01:46 <openstack> Meeting started Thu Oct  8 15:01:45 2015 UTC and is due to finish in 60 minutes.  The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:50 <openstack> The meeting name has been set to 'thu_08__10'
15:02:06 <m3m0> as always, notes about the meeting are available here... https://etherpad.openstack.org/p/freezer_meetings
15:02:18 <m3m0> please update your information
15:03:07 <m3m0> vannif, you are first to go
15:04:27 <vannif> hi all.
15:04:37 <vannif> working on integration tests.
15:05:15 <vannif> to install freezer-api as a devstack plugin
15:05:40 <vannif> and freezer-web-ui as well as soon as the freezer-api installs flawlessly
15:06:14 <vannif> I've also to finish some more evoluted integration tests for lvm
15:06:18 <m3m0> do we have a blueprint that we can review or comment for this task?
15:06:44 <vannif> hmmm not specifically for devstack plugins, they are part of a broader effort to provide integration tests
15:06:54 <marzif> I'm late, sorry
15:07:17 <vannif> that is pretty much all for me atm
15:07:21 <m3m0> is this internal or external effort? this will be commited upstream?
15:07:39 <vannif> yes. upstream.
15:08:10 <m3m0> cool, if you need help with reviews let us know
15:08:23 <vannif> actually it's a /devstack folder in the freezer-api project tree wich contains scripts to install the api
15:08:50 <vannif> in the end the user will only need a single line in the local.conf
15:09:10 <vannif> which triggers the git clone and install scripts
15:09:17 <m3m0> I assume the README cover this procedure right?
15:09:37 <vannif> that is the "framework" for the integration tests
15:09:55 <vannif> yes, it will contain instructions for that
15:10:00 <m3m0> nice :)
15:10:12 <vannif> but htanks for the remainder ;)
15:10:21 <vannif> reminder
15:10:33 <m3m0> no problem :)
15:11:15 <m3m0> do you have anything else to say? or do you need help with anything?
15:12:15 <vannif> nothing mush to say. Fausto is giving me some help with the devstack dependencies installation
15:12:28 <vannif> s/mush/much
15:12:37 <m3m0> perfect :), thanks a lot
15:12:47 <vannif> thank you
15:12:58 <m3m0> reldan you're next
15:13:07 <reldan> Thank you
15:14:00 <reldan> Last week I mostly was improving code coverage. Cannot say that I improved it drastically, but a couple of percentages.
15:14:33 <reldan> I also should make changes in cofig - for parallel backup, but going to do it after release
15:14:34 <m3m0> that's great news
15:14:50 <m3m0> about what exactly?
15:15:33 <reldan> About 2.0 I assume
15:15:51 <reldan> That should be in couple of weeks
15:16:08 <reldan> I also would like to refactor lvm/shadow
15:16:19 <m3m0> I agree with the refactor
15:16:26 <m3m0> the interface should be the same
15:16:28 <reldan> Because now for example we cannot do windows shadow with mysql
15:16:40 <reldan> only lvm
15:16:52 <reldan> And it seems not very right
15:17:00 <m3m0> that's true, it should be decouple
15:17:29 <reldan> Also lvm is the last place that heavily uses backup_dict
15:17:36 <m3m0> but are we going to use the exec command? or do you have anything in mind for that?
15:18:00 <reldan> And not only read from this dictionary, but makes writes to dictionary and even replaces
15:18:23 <reldan> Sorry, what is exec command?
15:18:26 <m3m0> shadow code also has the same behaviour
15:18:59 <m3m0> is for pre and post script execution
15:19:01 <reldan> Yes, and let’s imagine that we would like to support postreSql
15:19:53 <reldan> Yes, we should create some classes here and decouple, making snapshot shoudn’t know anything about mysql, sqlserver, mongo or anything
15:20:40 <reldan> I was trying to refactor it - but it seems to be a very big refactor, so I just postponed it until the release
15:21:01 <m3m0> and how will we manage the release of the databases after the snapshot creation?
15:21:57 <m3m0> how is develop right now is that it blocks the db and then create a snapshot and then relase the db, is that behaviuor going to change?
15:22:08 <m3m0> or this is an early talk?
15:22:56 <reldan> let’s say we have an Application - it may by Mongo, Mysql, Postgres and it should have stop and start. And Snaphsot engine (Shadow, Lvm) with create and remove
15:23:23 <reldan> So we should have application.stop(); snapshot.create(); application.start(); snapshot.remove()
15:23:44 <m3m0> I like this kind of interface
15:23:57 <marzif> reldan,  you are referring to the object interface, but not on stopping the service itself right?
15:24:08 <marzif> I think it's good
15:24:19 <marzif> we can do something like application.flush()
15:24:24 <reldan> You, know probably it is not a good name. But as far as I know for mssql - we actually stop service
15:24:31 <reldan> marzif: +1
15:24:32 <marzif> yes
15:24:35 <m3m0> yes
15:24:45 <m3m0> until we find a better way
15:24:52 <marzif> application.stop if we stop make sense :)
15:24:59 <marzif> for mysql we can use app.flush
15:25:01 <reldan> let’s say flush
15:25:03 <reldan> and recover
15:25:07 <vannif> what about context managers ?
15:25:09 <m3m0> I have a question
15:25:26 <reldan> What is a context manager?
15:25:42 <m3m0> if a new application will be supported as a plugin, should we add an interface to extend the arguments for that application?
15:25:55 <vannif> for example:
15:25:59 <vannif> with db.lock:
15:26:17 <vannif> do things
15:26:31 <reldan> m3m0: If we have a pluggable mechanism - probably we can just search it by name
15:26:46 <vannif> well, we can discuss it in a deep dive
15:27:30 <reldan> Yes, anyway we can provide application to snapshot, if we actually need it
15:27:36 <reldan> like snapshot.create(application)
15:27:46 <reldan> snapshot.remove(application)
15:28:06 <m3m0> mmm do we actually need to pass the application?
15:28:21 <marzif> let's write a bp for this
15:28:23 <reldan> I have no idea, but if it is necessery - we can do this way
15:28:52 <reldan> Additional small comment - I suppose we should return from a job some result
15:28:55 <m3m0> +1 for the bp
15:29:01 <reldan> And don’t work with backup_dict
15:29:13 <reldan> Let’s have backup_dict at least read_only
15:29:20 <szaher> vannif that what we were discussing today ?
15:30:27 <reldan> And after the release, we should integrate rsync
15:30:32 <m3m0> but we return a result
15:30:37 <reldan> It everything I had
15:30:41 <m3m0> at least with the api isn't
15:30:42 <m3m0> ?
15:30:47 <marzif> reldan,  backup_dict I think will be removed with Cliff
15:31:13 <reldan> marzif: Yes! And it means that we should return something new instead of dict
15:31:24 <reldan> And we shouldn’t have a writes to dict
15:31:25 <marzif> after oslo.log implementation we can proceed with Cliff, yep
15:31:48 <vannif> szaher, before lunch ? no, it was configuration file support. removing the backup_opt_dict is something that we discuss about in regard to many aspects, not just because of oslo.config
15:32:02 <vannif> they are related of course
15:32:38 <szaher> vannif, no what me, you and pierrer pluggable arch. for storage and agent
15:32:51 <vannif> but I think reldan is talking about how to refactor the snapshot and db-locking code
15:33:01 <szaher> vannif, no what me, you and pierre were discussing before that
15:33:06 <reldan> Ok, let’s discuss it later - because it already takes so long
15:33:13 <szaher> Ok, sorry guys
15:33:14 <vannif> moving responsibilities to specific objects
15:33:48 <reldan> I have nothing to add now
15:33:52 <m3m0> thanks reldan
15:33:59 <reldan> Thank you m3m0
15:34:04 <m3m0> and let us know if you need reviews or help with anything
15:34:23 <reldan> https://review.openstack.org/#/c/231469/
15:34:26 <marzif> reldan,  there are two reviews that needs to be +Aed right?
15:34:26 <m3m0> marzif you're next
15:34:29 <marzif> ok
15:34:38 <reldan> https://review.openstack.org/#/c/229467/
15:34:45 <reldan> Yes
15:35:05 <marzif> I've been helping vannif  with the integrated tests, doing code review, some arch meeting
15:35:17 <marzif> nothing really concrete lol
15:35:46 <marzif> I think we should move to cliff after oslo.log
15:35:59 <m3m0> I agree with that
15:36:16 <marzif> and rethink the cli in a way that is backward compatible for a while
15:36:27 <marzif> and create the python-freezerclient module
15:36:48 <marzif> also I'm following up the move of the stackforge/freezer* repos to openstack namespace
15:36:51 <m3m0> szaher said that we should deprecate freezerc
15:36:57 <m3m0> and start using freezer
15:37:07 <marzif> we should use freezer-agent
15:37:11 <marzif> explicitally
15:37:12 <m3m0> but not get rid of freezerc until the next release
15:37:17 <marzif> and freezer for the freezer client
15:37:30 <marzif> freezerc is not a big issue, we can just create a symlink
15:37:37 <marzif> when we install the python egg
15:38:31 <marzif> anyway, we can dive deep on this after the oslo log implementation
15:38:34 <m3m0> and +2 for python-freezerclient
15:38:47 <marzif> also we need to change the way we tag the releases across our 3 repos
15:38:47 <m3m0> is oslo.log planned for 2.0?
15:38:53 <marzif> nope
15:39:02 <marzif> Saad write the code
15:39:06 <marzif> but it won't be in
15:39:26 <marzif> as soon 2.0 is released we'll merge the oslo.log stuff
15:39:38 <marzif> also we need to use a common version
15:39:57 <marzif> like 2015.10.08 for the 3 packages
15:40:03 <sc> marzif: I can help with logging but after work, it's difficult to schedule work on freezer for me other wise
15:40:23 <marzif> otherwise we don't know which freezer-api works for sure the freezer-scheduler and so on
15:40:30 <marzif> same for the web-ui
15:40:51 <sc> szaher: do you mind some after dinner sessions?
15:41:04 <m3m0> and are we going to create branches for openstack relases?
15:41:10 <m3m0> like stable/liberty?
15:41:13 <marzif> if we can yes
15:41:14 <marzif> we have to
15:41:18 <m3m0> or are we going to move differently?
15:41:33 <marzif> stable/release_name
15:41:42 <marzif> but I was referring to the release naming convention
15:41:49 <marzif> for the python eggs we upload to pypi
15:42:02 <marzif> while the repo branching/tagging is exactly as you said
15:43:21 <m3m0> and is there any difference once we move from stackforge to openstack?
15:44:04 <marzif> we probably needs less interaction with infra
15:44:08 <marzif> but it will be all the same
15:44:54 <m3m0> and do you need help with anything?
15:45:22 <marzif> not for now
15:45:25 <marzif> ty
15:45:30 <marzif> that's all from me
15:45:34 <m3m0> cool, thanks :)
15:45:51 <m3m0> szaher zsaher_ you're next
15:46:34 <reldan> I don’t see him
15:47:00 <m3m0> thanks :)
15:47:03 <m3m0> I'll go next
15:47:15 <m3m0> I've been working on the ui
15:47:34 <m3m0> some commits are merged that help with the interaction of the newer versions of the api
15:47:48 <m3m0> and fix some bugs
15:48:00 <m3m0> now I'm working on the UX part of the ui
15:48:25 <m3m0> and soon on the testing, the thing is that besides unittesting I'll need to implement selenium testing
15:48:45 <m3m0> as part as the UX enhancements
15:49:19 <m3m0> the job window will be enough for a new user to create jobs with actions and managing sessions
15:49:47 <m3m0> but if they want, they can manage those items individually in their on page
15:50:06 <m3m0> I'm also adding a CRUD page for actions
15:50:14 <m3m0> and a list of clients to interact with
15:50:46 <m3m0> and a kind of big re factoring in the code because most of the code is boilerplate and it's been repeated over and over
15:51:40 <m3m0> and I have this commit in progress https://review.openstack.org/#/c/232581/
15:51:51 <m3m0> which enable freezer dashboard on the admin panel
15:51:57 <m3m0> but I have a question marzif
15:52:14 <m3m0> do we want freezer to be on it's own panel but only visible to admins
15:52:31 <m3m0> or do we want freezer to be included on the admin panel itself
15:52:40 <m3m0> the first one is very very easy to implement
15:53:08 <m3m0> the second one is a little bit more tricky
15:53:17 <m3m0> and lastly for the ui
15:53:32 <m3m0> I'm working on a installation script to make things easier for automation
15:53:42 <m3m0> regarding windows, I haven't work on that for a while
15:53:54 <m3m0> and I need to rebase the changes for freezer-agent on windows
15:54:04 <m3m0> and complete the scheduler for windows as well
15:54:19 <m3m0> that's it for me at the moment
15:54:27 <m3m0> szaher, you're next
15:55:04 <szaher> Okay
15:55:43 <szaher> Actually I was working on bug fixing
15:55:52 <szaher> I fixed some and we need to test them on windows first
15:56:14 <szaher> not all but this one specially https://review.openstack.org/#/c/229467/
15:56:20 <szaher> plz review and If it's Okay approve
15:56:44 <szaher> m3m0 vannif we need to approve after m3m0 test on windows
15:57:18 <szaher> sorry this is the correct one https://review.openstack.org/#/c/231398/
15:58:04 <szaher> I will be working on making freezer use oslo libraries for now it will be logging
15:59:06 <szaher> that is it for me, fixing bugs and this blueprint :)
15:59:10 <szaher> thanks m3m0
16:00:29 <m3m0> nice, thanks a lot szhare
16:00:34 <m3m0> do you have anything more to say
16:00:43 <m3m0> #endmeeting