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