14:59:19 #startmeeting gantt 14:59:20 Meeting started Tue Mar 25 14:59:19 2014 UTC and is due to finish in 60 minutes. The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:59:23 The meeting name has been set to 'gantt' 14:59:39 anyone here to talk about the scheduler? 15:01:26 o/ 15:02:09 not a lot of people around :) 15:02:19 bauzas, might be just you & me, looks like you wore them out last week :-) 15:02:43 :-) 15:03:02 n0ano: have you read the minutes ? 15:03:29 I promise I haven't scared them :D 15:03:47 yeah, last week, I've forgotten (incipient Alzheimer's) were there any open questions? 15:04:44 one question I had, looks like you abandoned the client patch just to restart it again, any particular reason for not just updating the original patch? 15:04:55 no no no 15:05:12 I'm still continuing to work on the client 15:05:28 but after discussing with -infra guys, seems like drafts don't like rebases 15:05:40 hence I created another patch 15:05:49 WIP this time 15:06:11 well, if that's just a process thing that's fine 15:06:18 because I was unable to amend the existing one (gerrit was refusing to update master) 15:06:33 the bp whiteboard is modified accordingly 15:06:55 I removed all mentions of the previous patch 15:07:04 Aah, gerrit, it's caused me pain in the past, I understand completely (I had a linked set of patches and gerrit lost the links, I was not happy :-( 15:07:14 yey 15:07:20 was pretty weird 15:07:50 well, to be honest, anteaya told me to stop submitting drafts 15:08:02 that works, but that doesn't like rebases 15:08:12 anyway 15:08:25 maybe we can officially start ? :) 15:08:32 and discuss about the topics ? 15:08:36 the other thing you can do is create private update and send links out to interested parties, that would avoid some of those issues 15:08:52 for sure but with just the two of us it's pretty easy... 15:09:07 n0ano: outside the meeting if you continue to have difficulty with gerrit, talk to me in -infra 15:09:14 just a matter of reading minutes without looking at the detailed logs :) 15:09:15 gerrit should be losing links 15:09:19 shouldn't 15:09:51 anteaya, tnx, I'll remember that in future, I worked around the problem and hope not to run into it again 15:10:13 n0ano: it might be a workflow issue 15:10:53 anteaya, I always suspect cockpit error, I have a slightly strange setup so I blame me on first look 15:10:55 Hey guys, one question, if need to sask omething on the node so which node we follow for daily issues ?? 15:11:19 digambar: I don't understand the question :) 15:11:27 bauzas, +1 15:11:37 if need to ask osmething on the node so which node we follow for daily issues ?? 15:11:38 n0ano: so, about scheduler forklift 15:11:47 something** 15:11:52 digambar: still unclear to me, the question is :) 15:12:05 digambar, what do you mean by node and what do you mean by daily issues? 15:12:07 digambar: what do you mean about node ? 15:12:14 n0ano: this is our recommended workflow: https://wiki.openstack.org/wiki/Gerrit_Workflow 15:12:14 ^^ 15:12:44 https://review.openstack.org/#/c/82778/ 15:12:47 anteaya, I tried to follow that but I'm guessing I messed up (I had a linked set of patches so that's a little odd) 15:12:51 scheduler client patch 15:13:08 still chasing some bugs 15:13:20 n0ano: find me in -infra later and we can walk through it together 15:13:20 If I want to ask to something about the patches & bugs, so where I can connect you guys 15:14:01 digambar: you can reach us in #openstack-nova just by prefixing your question with our IRC nicknames :) 15:14:08 digambar, I think you mean `contact you guys' and the first option is the dev mailing list, that should be your first choice 15:14:18 yes 15:14:19 digambar: I don't promise to be 24x7 up there thou 15:14:34 Yeah, I understand 15:14:52 I'm always on #openstack-dev but I'll add #openstack-nova also 15:15:14 I also proposed a bp in nova-specs : 15:15:17 cool, Thank you :) 15:15:18 the not there 24x7 is why I always suggest the mailing list first 15:15:19 https://review.openstack.org/#/c/82133/ 15:15:28 anyway 15:15:34 #topic code forklist 15:15:43 yey ! 15:15:48 so, I was saying 15:15:54 good progress on it, still chasing bugs 15:16:21 I was going to ask, do you want a review or do you want to wait until after the bug hunt? 15:16:41 n0ano: I think it's worth waiting for the new patchset 15:16:54 n0ano: not that hard to fix 15:16:56 NP, procrastination is my middle name 15:17:00 :-) 15:17:41 given this is still a WIP I assume that, even after the bug hunt, this won't be ready to merge in yet, right? 15:17:46 so, again, please note that https://review.openstack.org/#/c/82778/ is the new review for the sched client 15:17:53 n0ano: we can't 15:17:58 until Juno 15:18:20 we're currently in FF 15:18:39 the idea is to quickly raise the bar on the client for discussing it at the summit 15:18:41 that's a given but after FF will this be ready, you still need some unit tests right? 15:18:49 n0ano: yup 15:19:24 we also need to have the bp validated 15:19:29 https://review.openstack.org/#/c/82133 15:19:36 you can review that one now 15:19:55 sure, I'll add that to my todo right now 15:20:00 it's flagged as WIP too because of the the current nova-specs template under change 15:20:38 I have to check status of it, and either promote it or produce a new patchset 15:21:23 btw, I spoke last week about http://summit.openstack.org/cfp/details/80 15:21:36 bauzas: just one quick question 15:21:38 this is the placeholder for discussing the BP 15:21:53 toan_tran: sure 15:22:09 Hey bauzas 15:22:11 what relation does this sch python lib have with nova? 15:22:42 for the scheduler lib, can help you on that ? 15:22:42 toan_tran: that's the necessary step before forking code to gantt 15:23:03 digambar: I need some reviews on it yes 15:23:09 yes 15:23:17 digambar: but I don't think it requires another contributor 15:23:25 ok 15:23:35 bauzas, we should probably propose a session to talk about gantt APIs also, I think that's another area people need to address 15:23:36 that's quite straightforward 15:23:54 any other work for gantt, I can look at ? 15:24:08 1. I'll review it 15:24:22 2. I am looking for ?? 15:24:32 n0ano: which APIs are you talking about ? 15:24:41 REST or RPC ? 15:24:43 digambar: try https://etherpad.openstack.org/p/icehouse-external-scheduler 15:24:50 ok 15:25:14 digambar: a little messy, but look at the end 15:25:23 but indeed, we need to speak about step #3 15:25:32 okay 15:25:33 bauzas, both, the RPC should just be a continuation of the current Nova ones but, for generalizing to support cinder & neutron & ... we should see if we need something more 15:25:50 n0ano: that's something we need to tackle at the summit yes 15:26:00 n0ano: I can propose a session 15:26:13 bauzas, if you want, go ahead 15:26:17 ok will do 15:26:36 that's because we need to make sure what will be the interfaces in the next future 15:26:37 I don't think we need a session on forklift per se, it's pretty obvious what needs to be done there, it's more mechanical 15:27:09 n0ano: can we organise some section with cinder & neutron folks? 15:27:11 n0ano: well, the client lib is quite straightforward, I agree 15:27:27 toan_tran: I don't think that's mature for Juno 15:27:35 but we can get feedback 15:27:53 bauzas: well, it's better if we have some initial though on that 15:28:01 toan_tran, I would hope that some of the the cinder & neutron people would come to the gantt session 15:28:11 toan_tran: I still persist that's a bit early :) 15:28:25 I don't want we follow it to the end and others'd say that it's too complicated for them 15:28:33 Juno will be focused on having the scheduler isolated from Nova 15:28:51 that's K where we should focus on integrating other projects 15:28:53 bauzas, a bit but getting other ideas early would be good, especially when talking about APIs 15:29:04 bauzas: of'course but to tackle RPC 15:29:38 I'm afraid that we focus too much into nova 15:29:39 so that means the discussion is about the interfaces 15:29:50 at some point we forget the generalization of gantt 15:29:54 hence what we discussed previously :) 15:30:13 I will propose a session wide enough to get cinder and neutron folks joining in 15:30:20 bauzas: +1 15:30:25 bauzas, +1 15:30:32 ok 15:30:37 we seem to be in violent agreement :-) 15:30:53 about the forklift by itself, there are some concerns about the service table and other pure technical aspects 15:31:30 that's only related to nova 15:31:35 I think those will resolve themselves, once we get the interfaces clean enough that we can split out the current code 15:31:46 that's why I think the forklift is not that trivial to miss a summit session 15:32:27 not sure what concensus we need on it though, it's more a `just do it' problem. 15:33:06 n0ano: we need to decouple DB tables that are not related to scheduler 15:33:07 but why argue over this, let's just propose a forklist session and see if it's accepted and who comes 15:33:15 n0ano: +1 :) 15:33:30 ok, I'm done with that topic 15:33:39 since you've signed up for 2 sessions, I'll propose a forklift one 15:34:09 there is already one ;) 15:34:17 http://summit.openstack.org/cfp/details/80 15:34:40 I'm constantly out of the loop (Alzheimers again), that's fine 15:34:46 the one missing is the one about future Gantt interfaces 15:35:02 bauzas, BTW the Juno summit is in Atlanta, will you be able to come? 15:35:09 n0ano: yup 15:35:18 excellent 15:35:46 n0ano: I'm moving from one company to another 15:36:00 n0ano: and the move will be done at summit time 15:36:22 anyway 15:36:30 anyway 15:36:34 :-) 15:36:43 I think we've beaten this particular dead horse 15:36:45 #opens 15:36:48 nah 15:36:49 nah 15:36:54 no-db :) 15:37:00 I have something to say :D 15:37:08 #topic no-db 15:37:11 bauzas, go for it 15:37:32 so, about no-db, I spoke with boris-42 15:37:43 this morning 15:37:54 (well, this EU TZ morning :-) ) 15:38:18 so, he will propose a session on no-db scheduler 15:38:30 we discussed on that thread last week 15:38:49 about the interest of having memcached or tooz 15:39:23 so, there will be opportunity for discussing about the implementation 15:39:35 never heard of tooz, I would have thought we just do memcached to start and then think about alternatives if needed 15:39:52 n0ano: +1 15:40:12 at the moment, there is no progress on the BP, as the resource was defocused from that BP 15:40:27 n0ano: that's what we agreed last week :-) 15:41:12 I just wanted to see progress, with patches up for review I hate to see them just get ignored 15:41:17 but that's worth discussing with tooz contributors 15:42:02 so, bottom line, don't expect any progress on no-db until after the summit 15:42:12 n0ano: I don't think there will be progress until Juno 15:42:19 +1 15:42:42 bauzas: last time I heard 15:42:52 there was a prob with no-db implementation 15:43:01 did he said what it was? 15:43:25 toan_tran: the only problem I heard of from boris-42 is resource :) 15:43:26 it's the design problem or just implementation's technical detail ? 15:43:41 toan_tran, scalability issue, they were working on debugging it, looks like they don't have to resources to fix it right nwo 15:43:42 toan_tran: there is no people working on atm 15:43:55 n0ano: +1 15:44:03 ok 15:44:08 hence the discussion is about the memcached use 15:44:24 we should have a flexible backend 15:44:41 with use of stevedore's plugins for implementation 15:45:02 so that we could either use a memcached driver or any other 15:45:06 hence the discussion around tooz 15:45:11 bauzas, no argument, which is why I'd implement memcached first and then look into other backends 15:45:24 https://github.com/stackforge/tooz 15:45:39 n0ano: that would be worth having a stevedore namespace for this 15:45:49 with proper interfaces 15:46:03 the few I saw from the bp was ok with that 15:46:25 but we just need to make sure it will still be the case in the next implementations 15:46:43 well, there'll be a session at Juno, should be a lively one 15:47:07 :D 15:47:19 anything else on no-db 15:47:21 nope 15:47:32 OK, once more 15:47:38 #topic opens 15:47:41 :-) 15:47:43 I have some question :) 15:47:45 anything new? 15:47:48 toan_tran, go for it 15:47:59 has anyone ever measured the scheduling performance? 15:47:59 yeah, I have a remark about the current gantt repo 15:48:16 toan_tran: ask boris-42 15:48:32 toan_tran: they made some benchs using Rally 15:48:48 well, they promised to have data published :) 15:48:56 but I haven't seen one :) 15:49:08 open a thread in -dev ML then :) 15:49:18 bauzas: +1 15:49:37 toan_tran, check out https://docs.google.com/document/d/1_DRv7it_mwalEZzLy5WO92TJcummpmWL4NWsWf0UWiQ/edit?pli=1#heading=h.6ixj0ctv4rwu 15:50:03 it does not have data 15:50:15 n0ano: great document, missed it, thanks 15:50:40 toan_tran, what about fig. 1? 15:51:02 n0ano: only on compute_get_all() 15:51:20 could we tackle that on -dev ? 15:51:29 bauzas: OK 15:51:31 I have something to discuss about gantt repo 15:51:37 then, as bauzas said, raise it on -dev (be sure to CC boris) 15:51:44 bauzas, go for it 15:52:01 ok, at the moment, the gantt repo is a bit confusing people 15:52:13 as it was generated a while ago 15:52:23 and as the efforts are now going to nova first 15:53:02 I'm just saying that I think we should update the README file in gantt stating that this is currently not an official repo, much likely related to a sandbox 15:53:17 I can propose a patch on it 15:53:25 and we also need to review the reviewers :D 15:53:31 bauzas, sure, that's a good idea 15:53:46 russellb raised that concern earlier in the day 15:54:11 current reviewers are the nova core team, it's easy enough to create our own team, we should probably discuss that at Juno 15:54:50 (11:06:52) russellb: i'm not sure if it can actually be removed, but at a minimum, we can push a commit that removes all code and leaves a README 15:54:59 o/ 15:55:09 russellb: o/ 15:55:19 basically just wondering what you guys want to do with the repo 15:55:24 I'm not sure we want to go that far, just changing the README would be my suggestiuon 15:55:25 russellb: we're quickly discussing on the gantt repo state 15:55:37 is there active work on the code? 15:55:55 I'm still working on it 15:55:58 btw, should we move it to stackforge ? 15:56:12 i asked about the stackforge move, -infra folks generally against it if there's any chance we'll move it back later 15:56:26 russellb: ok thanks for the heads-up 15:56:40 i don't think nova-core is looking at it 15:56:54 we'd definitely move it back so I'm good with leaving it 15:57:06 n0ano: russellb: so I will propose a patch for updating README and stating this is not active code 15:57:08 so if it stays we should just change the review team 15:57:16 russellb: +1 15:57:20 otherwise nothing will ever get approved 15:57:21 heh 15:57:46 then we should change the review team `before` we change the README 15:57:54 n0ano: agreed 15:58:15 not sure the order matters 15:58:17 but sure 15:58:19 we're running out of time 15:58:36 We need to identify the review team, I'll start a ML thread 15:58:50 for today, yes, we'll have to continue on the ML 15:58:54 ok 15:58:57 tnx everyone 15:59:01 #endmeeting