| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-11-08 | |||
| 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 | |
| 13:41:21 | zhipengh[m] | Does it have to know the global state ? | |
| 13:42:05 | zhipengh[m] | Currently for Nova, it is the Nova compute you n each node interacting with Placement, as far as I understand | |
| #openstack-cyborg - 2017-11-15 | |||
| 08:03:17 | masber | good afternoon, I just found you project, is cybord ready to be installed? | |
| 08:04:05 | masber | I would like to be able to use FPGAs on openstack, can I get some help within this channel? | |
| 08:21:59 | zhipengh[m] | Hi masber , thx for the interest ! | |
| 08:22:24 | zhipengh[m] | Could u introduce a little bit about yourself and your requirement ? | |
| 08:22:34 | masber | oh yes sorry | |
| 08:22:48 | masber | I work for a medical research intitute | |
| 08:23:09 | masber | and we are playing with openstack/ceph in order to see if it can fit out use cases | |
| 08:23:20 | masber | now we are doing a project with intel | |
| 08:23:35 | masber | and we will borrow some FPGA cards from them | |
| 08:24:16 | zhipengh[m] | That sounds interesting :) | |
| 08:24:47 | masber | I would like to see if we can make those cards to work on openstack, I mean been able to access the FPGAs from the instance | |
| 08:24:55 | masber | I did a talk in the openstack summit in sydney | |
| 08:25:13 | masber | I talk about what we do etc | |
| 08:25:49 | masber | I am not an openstack expert just, installed it and played with it a little bit | |
| 08:26:23 | masber | but now with these FPGAs coming I feel I should start getting my hands dirty | |
| 08:26:40 | zhipengh[m] | Cool ! Can you provide the title of your Sydney topic ? So that I could search on youtube :) | |
| 08:26:46 | zhipengh[m] | As for cyborg | |
| 08:27:07 | masber | so, if I am not mistaken we are receiving some nallatech 385a | |
| 08:27:16 | zhipengh[m] | Our current code base cannot function yet, and we are undergoing active development | |
| 08:27:40 | masber | the name of the talk was "building a genome future with openstack" | |
| 08:28:04 | masber | https://www.youtube.com/watch?v=HSAJpAxORAw | |
| 08:28:10 | zhipengh[m] | I will definitely check it out :) | |
| 08:28:52 | masber | it is quite basic talk | |
| 08:28:55 | zhipengh[m] | So at the moment you could run up the three main cyborg processes, but no function yet | |
| 08:29:02 | masber | I see | |
| 08:29:12 | zhipengh[m] | We are now try to define data models | |
| 08:29:24 | zhipengh[m] | And would be great to have input from you | |
| 08:29:34 | zhipengh[m] | For example on FPGA | |
| 08:29:58 | masber | ok, I am not an user with lots of expertise on these kind of things, but happy to give it a go | |
| 08:30:05 | zhipengh[m] | What is your main use case for that and what would you like to see FPGA resource represented | |
| 08:30:25 | zhipengh[m] | That'd be great ! | |
| 08:30:31 | masber | this is to run a tool called GATK4 | |
| 08:30:53 | masber | it is a best practice set of tools to run genome analysis | |
| 08:31:05 | masber | so this tool can work on HPC or in a SPARK cluster | |
| 08:31:25 | masber | our goal is to see how much efficiency we can get by running these tools on FPGAs | |
| 08:31:40 | masber | compared to running on Apache Spark | |
| 08:32:25 | masber | the thing is I am receiving the cards tomorrow from the intel guy who is coming from overseas (not sure from singapose, china or US) | |
| 08:32:32 | masber | *singapore | |
| 08:32:48 | masber | and I am not sure for how long I can keep the cards either | |
| 08:33:05 | zhipengh[m] | that is very interesting | |