Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2017-11-08
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
15:51:53 zhipeng we could also do that mitigation
15:52:07 jkilpatr still not sure I understand the usecase
15:52:26 zhipeng I think I will just writeup a spec and we could review it :P
15:52:40 jkilpatr sure, a better outline of the potential usecase would help a ton
15:52:40 zhipeng I need to elaborate more
15:52:44 zhipeng yep
15:52:50 zhipeng okey
15:53:29 zhipeng #agreed have weekly sprint video conf using team meeting timeslot starting Nov 15th
15:53:47 zhipeng #topic AoB
15:54:02 zhipeng I think we have covered the most important ones
15:54:07 zhipeng any other business ?
15:58:54 zhipeng okey let's conclude the meeting then, thanks everyone :)
15:58:59 zhipeng #endmeeting
15:59:00 openstack Meeting ended Wed Nov 8 15:58:59 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:59:01 openstack Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-11-08-15.01.html
15:59:02 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-11-08-15.01.txt
15:59:03 openstack Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-11-08-15.01.log.html
#openstack-cyborg - 2017-11-13
13:27:24 jkilpatr zhipengh[m], so the agent can't interact with placement well IMO. Each agent is on each compute and knows only about it's own local resources. If we want the agent to go and tell Nova 'hey we have N of these devices' it needs to know global state
13:27:27 jkilpatr which is the job of the conductor.
13:27:52 jkilpatr Otherwise we assume that no two computes will have the same type of accelerator, which is fatally flawed IMO

Earlier   Later