| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-11-08 | |||
| 15:15:16 | zhipeng | ah ok | |
| 15:15:18 | crushil | I'll catch up with him my evening (his morning) | |
| 15:15:27 | zhipeng | sounds great :) | |
| 15:15:34 | crushil | Sydney is 15 hours ahead of EST | |
| 15:15:48 | crushil | It's like 3 hours ahead of you | |
| 15:15:49 | zhipeng | ye we have 3 hour difference | |
| 15:16:34 | zhipeng | let's try to get together in Dublin next year, for rocky ptg | |
| 15:16:50 | zhipeng | late Feb | |
| 15:17:07 | jkilpatr | I figure I'll get sent to the PTG, to be honest we get more work done there anyways | |
| 15:17:16 | zhipeng | might freeze my balls off tho, considering the weather ... | |
| 15:17:22 | zhipeng | jkilpatr for sure | |
| 15:17:53 | zhipeng | any other comments re this topic ? | |
| 15:18:29 | jkilpatr | speaking of getting work done, can we try and wrap up the interaction patch? Sorry I haven't gotten my nova hack ready been on PTO | |
| 15:19:01 | zhipeng | so on that note, moving on to the next topic | |
| 15:19:12 | zhipeng | #topic Placement-Cyborg Interaction Discussion | |
| 15:19:23 | zhipeng | so last week crushil made a really good proposal | |
| 15:19:40 | zhipeng | that before Xmas we should have like weekly video sprints | |
| 15:19:48 | zhipeng | i asked Sean about the release sched | |
| 15:20:00 | zhipeng | Feb 5th 2018 is the hard cutoff date for coding | |
| 15:20:09 | crushil | cool | |
| 15:20:12 | zhipeng | that will be when RC is released | |
| 15:20:13 | jkilpatr | I can refocus on Cyborg last week of November and into December | |
| 15:20:41 | jkilpatr | Wrapping up a lot of other projects in the next few weeks. | |
| 15:20:42 | zhipeng | so I think let's just concentrate on Nov and Dec and try to hammer everything we need out in this period | |
| 15:20:58 | zhipeng | jkilpatr no problem | |
| 15:21:18 | zhipeng | then when would be the dates works for everyone about the sprint ? | |
| 15:22:46 | zhipeng | crushil jkilpatr zhuli | |
| 15:23:55 | jkilpatr | Nov 27 - Dec 4th short break for Ansible training then Dec 8 - EOY and probably beyond. | |
| 15:24:42 | jkilpatr | I can attend meetings and maybe get some stuff done earlier in November but I' | |
| 15:25:01 | jkilpatr | I'm getting a few racks of gear for release qualification so I need to focus on that when I have it. | |
| 15:25:03 | zhipeng | how about you crushil ? | |
| 15:26:24 | crushil | I should be ok to start sprint next week. Still wrapping up one project that has been pending for months | |
| 15:28:02 | zhipeng | then I think zhuli and I could start with crushil first, starting next week | |
| 15:28:15 | zhipeng | on driver side and traits | |
| 15:28:15 | zhuli | since the summit is done, next week is ok for me too | |
| 15:28:21 | zhuli | yep | |
| 15:28:33 | zhipeng | and jkilpatr could jam in later on the agent and conductor parts | |
| 15:28:54 | zhipeng | then maybe EOY we could have some E2E stuff, hopefully | |
| 15:28:54 | jkilpatr | been looking at Nova don't see any reason why we can't add devices to the whitelist live | |
| 15:29:04 | jkilpatr | there's actually not too much going on with the whitelist at all, just gets loaded and checked | |
| 15:29:27 | zhipeng | jkilpatr I could also ping Matt if we encounter any problems at Nova side | |
| 15:29:48 | jkilpatr | easier to write code and ask for a review than ask them to do it :P | |
| 15:29:54 | jkilpatr | especially if it's short and easy to review | |
| 15:30:22 | zhipeng | yep :P | |
| 15:30:32 | zhipeng | then crushil which day of the week shall we pick ? | |
| 15:30:50 | zhipeng | I think time wise the meeting time would be ideal | |
| 15:31:58 | jkilpatr | I agree | |
| 15:32:19 | zhipeng | we could do like the same time but on Tuesday, for example | |
| 15:32:45 | jkilpatr | that's fine too but then what do we talk about during the Wednesday meetings? | |
| 15:33:33 | crushil | ya, that works | |
| 15:34:03 | zhipeng | jkilpatr to get you update :P | |
| 15:34:43 | zhipeng | or shall we just use the weekly meeting time ? | |
| 15:35:07 | jkilpatr | I think we should just use the weekly meeting time and be sure to note things in IRC don't want to turn away newcomers in the channel | |
| 15:35:32 | zhipeng | crushil that ok for you ? | |
| 15:36:49 | crushil | yup | |
| 15:37:11 | zhipeng | okey great, then I will send out ZOOM links for the video conf | |
| 15:37:15 | zhipeng | starting next week | |
| 15:37:42 | zhipeng | jkilpatr regarding your current spec, I will have another set of comment, but I think we could wrap it up this week | |
| 15:38:20 | jkilpatr | sounds good let me know | |
| 15:39:23 | jkilpatr | zhuli, these times good for you? | |
| 15:39:45 | zhuli | no problem | |
| 15:40:48 | zhipeng | jkilpatr last week meeting, don't know if you have comb through the log yet, I have thought about adding another dimension of resource provider | |
| 15:41:03 | jkilpatr | nope haven't read it, care to summarize? | |
| 15:41:12 | zhipeng | we could implement it later, but I think I should submit a spec about it | |
| 15:41:18 | zhipeng | so in a gist | |
| 15:41:33 | jkilpatr | link me when you have it up | |
| 15:41:36 | zhipeng | currently Placement uses Resource Provider to model resources | |
| 15:42:19 | zhipeng | which consists of two dimensions: traits on the quantative side of things, and resource class for the qualitive side of things | |
| 15:42:45 | zhipeng | e.g. you could use trait to define what you have and resource class for how much/many you have | |
| 15:43:00 | zhipeng | however, i think for cyborg to deal with accelerator | |
| 15:43:15 | zhipeng | purely enumeration would cause problems | |
| 15:43:26 | zhipeng | since for example for FPGAs | |
| 15:43:44 | zhipeng | you can't trait and resource class with every VF/PF combination/layout | |
| 15:43:50 | jkilpatr | where you have possible traits that consume the same resource class? | |
| 15:44:13 | jkilpatr | zhipeng, I would have a resource class fpga that was consumed by many traits which would be the VF/PF | |
| 15:44:35 | zhipeng | jkilpatr my point is that many traits would be really hard to manage | |
| 15:45:02 | zhipeng | we need a more fuzzy way to describe accelerator resource, besides traits and resource class | |
| 15:45:26 | jkilpatr | what do you propose | |
| 15:45:34 | zhipeng | so I think propably something like capability, that it could generally map to a set of resource that user would need | |
| 15:45:50 | zhipeng | instead of specifically id the resource | |
| 15:46:01 | zhipeng | for example for deep learning | |
| 15:46:25 | zhipeng | there will be cases that operators just want to run their framworks on OpenStack Infra | |
| 15:46:44 | zhipeng | doesn't really care about which GPU, FPGA, SoC solution it should use | |
| 15:47:15 | zhipeng | and then if say, the infra got some GPU good for temporalachitecture | |
| 15:47:36 | zhipeng | and some FPGA cards that good for spatial architecture | |
| 15:48:00 | jkilpatr | but we need to get more specific at some point? | |
| 15:48:03 | zhipeng | we should just label these like CAPABILITY: DL/TEM | |
| 15:48:15 | zhipeng | we will still have traits ands resource class | |
| 15:48:17 | jkilpatr | the way I see it we can just map a buncha traits to the same resource and it will be kinda ugly but work. | |
| 15:48:30 | zhipeng | ye that is what I think | |
| 15:48:56 | zhipeng | so my thought was that if we could add another dimension, to use with trait and resource class together | |
| 15:49:06 | zhipeng | so that operators could do a specific request | |
| 15:49:10 | zhipeng | or a fuzzy request | |
| 15:49:34 | zhipeng | because unlike the general computing infras, which could almost be enumerated | |
| 15:49:44 | zhipeng | accelerators just got so many types and combinations | |
| 15:50:09 | jkilpatr | so we let operators aggregate things when their workload could run on either and schedule agains that? | |
| 15:50:32 | jkilpatr | against* | |
| 15:51:06 | zhipeng | not necessarily aggreagating, but just select a (super/sub) set of resource that satisfy the fuzzy request | |
| 15:51:24 | zhipeng | if it deems to be a super set, then it is aggregation | |
| 15:51:43 | zhipeng | if it just needs a subset, say just some of the FPGA card funcationalities | |