| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-06-27 | |||
| 14:07:52 | Li_Liu | #topic os-acc discussion | |
| 14:08:25 | Li_Liu | HI Sundar, do you want to lead this topic? | |
| 14:08:54 | Sundar | Sure, Li Liu | |
| 14:09:27 | Sundar | The os-acc spec was updated as indicated in #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131751.html | |
| 14:09:40 | Sundar | The reasons for the update are listed there as well | |
| 14:10:12 | Sundar | The updated spec is in #link https://review.openstack.org/#/c/577438/ | |
| 14:10:50 | Sundar | efried: One comment I got was to include a sequence diagram | |
| 14:10:56 | efried | yup | |
| 14:11:17 | Sundar | When I follow https://review.openstack.org/#/c/572583/11/specs/rocky/approved/reshape-provider-tree.rst, I get an error in RST syntax | |
| 14:11:31 | Sundar | The seqdiag directive is not known to standard RST editors | |
| 14:11:53 | Sundar | What do you do to in addition to updating requirements.txt etc.? | |
| 14:11:55 | efried | Sundar: Right, you have to set up dependencies and other stuff in your env | |
| 14:12:05 | efried | hold on, let me find the patch where we added that stuff into nova-specs... | |
| 14:12:18 | Sundar | Yes, requirements.txt and doc/source/conf.py need to be updated | |
| 14:12:36 | efried | right, okay - so you did those things and it's still busted? | |
| 14:13:16 | Li_Liu | Sundar, quick question, do we still need a dedicated os-acc spec on top of this one you posted? | |
| 14:13:17 | Sundar | The standard RST editors like http://rst.ninjs.org/# wouldn't know about them. So, how do you check before a submit? | |
| 14:13:44 | efried | If you're building locally, you'll need to make sure the dep is installed into your venv. You can do that by adding -r to your tox command, or you can enter the venv and install it manually via pip | |
| 14:14:25 | Sundar | OK, how do you run the tox command? | |
| 14:14:45 | efried | Sundar: How have you been running it thus far? | |
| 14:15:00 | efried | tox -e docs ? | |
| 14:15:28 | Sundar | SO, tox -e -r docs? | |
| 14:15:31 | efried | So you would say tox -re docs instead. That will rebuild the venv from scratch. That's assuming your problem is the missing dependency. | |
| 14:15:48 | Sundar | Got it. Thanks, Eric. | |
| 14:15:55 | efried | No, -e is how you specify which testenv, so tox -r -e docs or tox -re docs | |
| 14:15:56 | Sundar | Li Liu: I don't see why. We should be able to add any additional detail here | |
| 14:16:02 | efried | ++ ^ | |
| 14:16:18 | Sundar | Sure, Eric | |
| 14:16:21 | efried | agree the goal should be to have all the necessary design detail here. | |
| 14:16:35 | Li_Liu | sure, that is what I figured | |
| 14:16:52 | efried | Sundar: This is assuming the problem was the missing dependency. If you're still having problems, let me know and I'll see if I can help out. | |
| 14:16:53 | Sundar | Li Liu: We presumably need to add a bit more detail on how we can do a plugin for x86+FPGAs. Is that what you are looking for. | |
| 14:17:27 | Sundar | Thanks, Eric. I may take up on that if things don't work out by today :) | |
| 14:17:43 | efried | we're still doing this in openstack/cyborg, huh? | |
| 14:17:48 | Li_Liu | yup | |
| 14:17:49 | efried | any plans to move to cyborg-specs? | |
| 14:18:03 | efried | would make things easier to find :) | |
| 14:18:39 | Sundar | I was told we have latitude to stick to the current location for this cycle. | |
| 14:18:57 | Li_Liu | that's sounds good, let's get the current ones merged before we start the moving | |
| 14:19:25 | Li_Liu | right | |
| 14:20:08 | Sundar | OK, next steps are to add a sequence diagram. Also, I would propose a plugin for x86 + FPGAs, and a separate one for x86 + GPUs. The main reason to stick to x86 is that that's all I know about :) | |
| 14:20:42 | Sundar | We can probably generalize to ARM if SR-IOV works the same way there. Power is an area where we need Eric's input | |
| 14:20:59 | Li_Liu | how much difference if it was arm or even power? | |
| 14:21:00 | efried | I don't think you should be proposing specific plugins via this spec. | |
| 14:21:06 | efried | just the framework. | |
| 14:21:24 | efried | The plugins themselves will ultimately be the responsibility of the vendors. | |
| 14:21:29 | efried | I would think. | |
| 14:21:58 | Sundar | For x86+FPGAs, we could have a community-supported plugin which calls into Cyborg/agent/driver for vendor-specific stuff | |
| 14:22:15 | Li_Liu | shall we provide a reference from community tho? | |
| 14:22:28 | Sundar | Li_Liu: yes ^^ | |
| 14:23:06 | Sundar | Li_Liu: "how much difference if it was arm or even power?" Power seems to be quite different IIUC. Eric can expand on that | |
| 14:23:07 | shaohe_feng | entry points for driver. | |
| 14:24:32 | efried | Yeah, e.g. if the plugin has a "plug" operation, on libvirt this entails, what, editing the domain XML and doing stuff to special files under /dev? | |
| 14:25:01 | efried | In POWER, it entails making a REST call to the NovaLink API asking for an I/O slot to be attached to a logical partition (VM) and the platform does the magic. | |
| 14:25:07 | efried | Totally, totally different model. | |
| 14:25:25 | efried | and definitely not something the cyborg team should try to become domain experts on. | |
| 14:26:31 | Sundar | efried: Agreed. The plugin model should be able to handle such differences. The return value of the plug() itself is left open for that reason. | |
| 14:26:55 | Li_Liu | sounds good | |
| 14:27:01 | efried | I would think the return value would be an Acc* object | |
| 14:27:13 | Sundar | That is why it may make sense to have a x86/ARM/libvirt section that specifies what plug(), does | |
| 14:27:33 | efried | If it needs to contain platform-specific data, that goes in the *Profile bit, or something. | |
| 14:28:01 | Sundar | The return value can be a VAN object with enough data that is hypervisor-specific | |
| 14:28:20 | efried | Sundar: sorry, yeah, I guess we're calling it VAN now. | |
| 14:28:41 | Sundar | The port profiles in Neutron may not be applicable here IMHO | |
| 14:28:52 | efried | But again, I don't think your spec should go into any detail as to what each platform's plugin actually does. You could mention it for the sake of example/understanding, but it should not be the role of this spec to lay out the details. | |
| 14:29:32 | Sundar | OK. If we agree that we will do a community-supported plugin for x86 + FPGAs, I can write a separate spec for that. Is that fine? | |
| 14:30:41 | efried | yes, that sounds like the right plan. | |
| 14:31:14 | efried | Sundar: update on the seqdiag: right now it looks like the cyborg repo isn't yet using the "new" process for doc builds. | |
| 14:31:33 | efried | So you'll want to put the requirement into test-requirements.txt instead of creating a new doc/requirements.txt | |
| 14:31:35 | Sundar | Li_Liu, shaohe, all: do we all agree on this plan? | |
| 14:31:39 | efried | or you can switch over to the new build process | |
| 14:32:02 | Sundar | Ah, I put it in cyborg/requirements.txt | |
| 14:32:35 | Sundar | That seems closest? | |
| 14:32:53 | Li_Liu | Sundar, i am fine | |
| 14:33:02 | efried | Right now your docs env is calling out test-requirements.txt | |
| 14:33:09 | efried | I don't actually see anything calling out requirements.txt, which is weird. | |
| 14:35:07 | efried | Sundar: Anyway, I'm noodling around with it locally, will let you know if I get something working. | |
| 14:35:23 | Li_Liu | let's moving on | |
| 14:35:45 | Sundar | efried: Sorry, where do you see the reference to test-requirements.txt? | |
| 14:36:48 | Sundar | I mean , I see the file but what in doc is referring to it? | |
| 14:37:02 | Li_Liu | Cyborg had a meetup in Beijing LC3 yesterday, shaohe_feng do you have anything to share? | |
| 14:38:50 | shaohe_feng | zhipengh[m], introduce some scenario about cyborg | |
| 14:39:42 | Li_Liu | #topic LC3 meetup summary | |
| 14:43:52 | Li_Liu | ok, I will gather more information from the folks who attend the meetup and share with rest of the team | |
| 14:44:09 | Li_Liu | #topc AoB | |
| 14:44:14 | Li_Liu | #topic AoB | |
| 14:44:32 | shaohe_feng | Do you know iflytek? Sundar, Li_Liu | |
| 14:44:59 | Li_Liu | I know them | |
| 14:45:18 | shaohe_feng | #link http://www.iflytek.com/en/index.html | |
| 14:45:18 | Sundar | This one? https://en.wikipedia.org/wiki/IFlytek | |
| 14:46:01 | shaohe_feng | It is a famous AI company in China. | |
| 14:46:08 | shaohe_feng | Sundar, yes. | |
| 14:47:04 | shaohe_feng | AI will be a cyborg scenario. | |
| 14:47:12 | shaohe_feng | they need accelerator | |
| 14:47:46 | shaohe_feng | then we discuss the current status of cyborg development. | |
| 14:47:47 | Sundar | GPUs? | |
| 14:48:06 | shaohe_feng | Sundar, Gpus and FPGA. | |
| 14:48:08 | wangzhh | FPGAs, also. :) | |
| 14:48:13 | Li_Liu | are they planing to put people on Cyborg? | |
| 14:48:41 | shaohe_feng | Not sure. | |