15:03:31 <m3m0> #startmeeting openstack-freezer 09-09-2015
15:03:32 <freezerBot> Meeting started Thu Sep  3 15:03:31 2015 UTC and is due to finish in 60 minutes.  The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:32 <freezerBot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:32 <freezerBot> The meeting name has been set to 'openstack_freezer_09_09_2015'
15:03:32 <openstack> Meeting started Thu Sep  3 15:03:31 2015 UTC and is due to finish in 60 minutes.  The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:36 <openstack> The meeting name has been set to 'openstack_freezer_09_09_2015'
15:03:46 <m3m0> All: meetings notes available in real time at: https://etherpad.openstack.org/p/freezer_meetings
15:04:01 <m3m0> Hello, let's start by order
15:04:09 <m3m0> daemontool_
15:04:15 <m3m0> you're first
15:04:19 <daemontool_> ok
15:04:55 <daemontool_> I've been mainly working on code review, currently I'm working in fabriziov to integration tests settings up a dsvm gate job,
15:05:28 <daemontool_> I'm planning to work
15:06:11 <daemontool_> on usability improvement (with szaher), and on the block based incremental as soon as the current storage code refactor will be merged
15:06:11 <m3m0> does the integration tests only include linux functionality?
15:06:46 <daemontool_> when we have a dsvm I think we can test both linux and windows, as it is basically a VM runnin the OS
15:07:01 <daemontool_> at first instance the tests will be done for Linux
15:07:07 <daemontool_> there are
15:07:28 <daemontool_> other tests that can be done in the hp public cloud with dsvm by creating a windows vm
15:07:53 <daemontool_> but that wouldn't be automatic, so we need to understand how we can manage the windows image in devstack as I'm not sure it is included by default
15:08:19 <daemontool_> once we know where to get the windows image, I think the tests will be done pretty strightforward
15:09:17 <m3m0> do you have a timeline for this? or a blueprint that we can review?
15:10:53 <daemontool_> for Windows yes: https://blueprints.launchpad.net/freezer/+spec/windows-testing
15:11:03 <daemontool_> for dsvm not, I'll create one
15:11:23 <m3m0> thank you
15:11:32 <m3m0> do you need help with anything?
15:12:13 <daemontool_> I'll be out starting from saturday 2 weeks, so probably fabriziov  will need a bit of help on this
15:12:23 <daemontool_> all good for now :)
15:12:59 <m3m0> ok, thank you very much
15:13:10 <m3m0> fabriziov, you're next
15:13:19 <fabriziov> so
15:13:36 <fabriziov> my main task atm is setting up devstack gate jobs for integration tests
15:14:09 <fabriziov> it'll take a few days
15:14:18 <fabriziov> I also have some reviews out:
15:14:19 <daemontool_> basic bp herr for dsvm integration: https://blueprints.launchpad.net/freezer/+spec/freezer-dsvm
15:14:59 <fabriziov> thx for the bp :)
15:15:14 <fabriziov> the reviews:
15:15:16 <fabriziov> - improved db-init script
15:15:22 <fabriziov> https://review.openstack.org/#/c/219798/
15:15:34 <fabriziov> - freezer-scheduler in no-daemon mode
15:15:40 <fabriziov> https://review.openstack.org/#/c/218933/
15:16:01 <fabriziov> - better handling of job-events (fixes an issue with inability to restart failed jobs)
15:16:08 <fabriziov> https://review.openstack.org/#/c/217324/
15:16:10 <fabriziov> and
15:16:15 <fabriziov> https://review.openstack.org/#/c/217325/
15:16:30 <fabriziov> We shoud discuss the behavior for this: https://review.openstack.org/#/c/218812/
15:17:03 <fabriziov> that is the selection of the api entpoint type
15:17:21 <fabriziov> should the freezer-scheduler stick to an explicit url of the api (public/admin/internal) ?
15:17:33 <fabriziov> or should it try all until one succeeds ?
15:17:53 <m3m0> I'll say we have to be explicit on the selection
15:18:13 <daemontool_> I think we need to support both cases
15:18:19 <m3m0> that way we can document the behaviour more easily
15:18:22 <daemontool_> if one fails, we try the other
15:18:30 <daemontool_> like the default
15:18:47 <daemontool_> but if we are explicit we have to use exactly that
15:19:12 <m3m0> in that case we need to be very carefully on the trying order
15:19:36 <m3m0> someone can have access to public, admin and internal endpoints
15:19:36 <daemontool_> in the trying order, the explicit is the first, otherwise is the default
15:20:07 <fabriziov> maybe if the user gives an explicit endpoint-type, the scheduler should use only that
15:20:16 <fabriziov> and if it fails, it fails
15:20:34 <fabriziov> if, on the other hand, the user did not specify a value
15:20:48 <fabriziov> the scheduler could try all the types
15:20:49 <daemontool_> by default try all, while if explicit try only that?
15:21:13 <daemontool_> I think make sense
15:21:29 <fabriziov> yes. if I ask for the "internal", the scheduler shoudl try only that
15:21:37 <fabriziov> not the public nor the admin
15:21:59 <fabriziov> if I dont specify a value, try all
15:22:17 <fabriziov> the order counts, of course, we should agree and document that
15:22:24 <daemontool_> m3m0, sounds good that to you?
15:22:29 <daemontool_> +1 for me
15:22:52 <daemontool_> reldan, any thought?
15:23:04 <m3m0> I would like to have further discussion, we can to this offline and document the issue on the bp
15:23:37 <reldan> I would like to have discussion as well, I have no strong opinion at the moment
15:24:27 <m3m0> so agree further dicussion?
15:24:41 <daemontool_> m3m0, OK
15:24:47 <reldan> m3mo, yes
15:25:15 <m3m0> so, fabriziov, do you have a timeline on this topics?
15:25:16 <fabriziov> sure
15:25:49 <fabriziov> the devstack gate jobs will take some days
15:25:58 <fabriziov> the rest is in review.
15:26:07 <fabriziov> as soon as we agree on the endpoint-type selection criteria
15:26:42 <fabriziov> the patchset will be out within the day
15:26:59 <fabriziov> unless we meet ad 7pm ;)
15:27:13 <daemontool_> lol
15:28:00 <fabriziov> that's pretty much all for me
15:28:05 <m3m0> hahaha talk to your admin for that :)
15:28:14 <m3m0> thanks a lot fabriziov
15:28:37 <fabriziov> u r welcome
15:28:41 <daemontool_> fabriziov,  talk to your webmaster for that
15:29:52 <m3m0> I'm next on the list
15:30:23 <m3m0> I've been working on this blueprint https://blueprints.launchpad.net/freezer/+spec/code-guidelines
15:31:03 <m3m0> still needs some uptades but is to help us to define a common code guideline to deal with multiple os and external tool calls
15:31:39 <m3m0> also to define a series of steps need it to submit new functionality or a patch
15:32:12 <m3m0> for instance if a new functionality doesn't come with a bp it's a -1
15:32:14 <m3m0> the same for bugs
15:32:50 <m3m0> this way we can keep track of bugs, new changes and define timelines more easily
15:33:45 <m3m0> at the moment I'm working on a different project but as soon as that is finished I would like to work in 2 items
15:34:57 <m3m0> finish the porting of the scheduler on windows: https://blueprints.launchpad.net/freezer/+spec/port-freezer-scheduler-windows
15:35:17 <m3m0> and increase the coverage of tests in the web-ui
15:36:01 <m3m0> that's it for me at the moment
15:36:10 <m3m0> reldan, you're next
15:36:21 <reldan> Thank you m3m0
15:37:21 <reldan> I still doing my parallel backup stuff. I have reviewed your comments on my pull request and agree with them. I am writing documentation for methods, as well as I’m trying to show correct errors in case of internal gnutar errors
15:38:20 <reldan> It is really hard to do correct output of errors in case of multithreading, because reading from pipe is bloking operation in python
15:38:45 <reldan> I understand that it already took too much time, but I hope to commit my changes today
15:39:05 <m3m0> do you need any help with that?
15:40:11 <reldan> Thank you m3m0, I believe that I finish it soon, but I really will need help during review. It will be that somebody to check everything with me. Because I’m really afraid of race conditions of any type
15:41:12 <m3m0> of course, we can set a private meeting to that, the more people involved on this the better
15:41:49 <m3m0> could you send us the review link?
15:41:50 <fabriziov> it could help to have some documentation about the implementation, diagrams, uml-style maybe
15:41:52 <reldan> Absolutely agree, thank you. I also have thoughts about using greenlets or pykka - put I suppose we should discuss it later
15:42:25 <m3m0> just let be careful on the dependencies licensing
15:42:45 <m3m0> do you have anything more to say?
15:42:49 <reldan> Yes, it the same request https://review.openstack.org/#/c/214596/ , but I’m going to update it
15:43:45 <reldan> About uml diagrams, it will be very good to find some semi-automatic way to do so. I mean it will be great to describe such diagrams in some dsl language and have tool to build it
15:44:00 <reldan> Otherwise any uml diagram very soon will become absolete
15:44:35 <m3m0> does pycharm comes with a functionality to do that?
15:45:00 <reldan> It have something like that https://confluence.jetbrains.com/display/PYH/Working+with+UML+class+diagrams+in+PyCharm
15:45:05 <reldan> But I have never tried it
15:45:50 <reldan> And I don’t know can it build time dependency diagramm
15:45:58 <reldan> or something except class hierarchy
15:46:01 <m3m0> me neither :P
15:46:10 <m3m0> but if you try it let us know
15:46:23 <reldan> Deal, thank you m3m0
15:46:37 <m3m0> do you have anything more to say?
15:46:42 <fabriziov> that's true. I was thinking more about a quick way to introduce us to the parallel backup implementation, so that we can understand quickly and review the code.
15:47:26 <reldan> Yes, yes we need a simple way to knowledge sharing
15:47:34 <reldan> No, I have nothing to add, thank you
15:47:35 <fabriziov> but automating diagrams would be very welcome too, especially when you have to draw them for the documentation :)
15:48:54 <m3m0> agree
15:49:04 <m3m0> am I missing someone? does anyone have anything to say?
15:50:43 <m3m0> ok
15:50:47 <m3m0> thanks a lot guys
15:50:55 <m3m0> #endmeeting