Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2018-06-27
14:56:27 wangzhh b) nova-compute pass parameters to os-acc(accelerator_address, acc_type, etc.) and get xml segment
14:57:36 Sundar Why do they do "nova-compute => cyborgclient => cyborg-api" for programming? We can do it entirely in compute node
14:58:14 Sundar We need to update the db, and that requires an RPC to the conductor
14:58:34 Sundar But, otherwise, it can all be in os-acc/Cyborg-agent/driver
14:58:36 wangzhh It is for 2 reasons.
14:58:37 efried I'll just mention that there was a nova core (it might have been Dan) who said nova-compute should never have to call the cyborg API; everything should be done via os-acc.
14:58:41 efried I could be misquoting too :(
15:00:09 Sundar wangzhh: Did they modify Cyborg?
15:00:41 wangzhh 1. In Openstack, It is a common design to interact by api. 2. We have something like update quota in api.
15:02:01 Sundar wangzhh: If Nova compute has to call the REST APIs of Neutron, Cinder, Cyborg, ... it can get out of hand. The os-acc/os-vif/os-brick is supposed to solve that problem
15:03:03 wangzhh efried, if so, could we imply it by os-acc =》 cyborclient?
15:03:22 efried wangzhh: Yes, I would think so.
15:03:42 Sundar efried: How about Power? Would you have os-acc call Cyborg for that too?
15:04:09 efried Sundar: I would think any calls from os-acc to cyborg API would happen *outside* of the plugin, in the common os-acc code.
15:04:33 wangzhh Sundar, IMHO os-vif/os-brick didn't call neutron or cinder.
15:05:20 efried I probably need to punt on this issue, just wanted to bring it up so y'all didn't get miles down the road and end up surprised if someone started waving a red flag.
15:05:51 Sundar In the currently proposed flow, os-acc --> plugin, and the plugin can do whatever it wants. For FPGAs, I think it would call Cyborg agent, which in turn can call the Cyborg conductor etc.
15:06:26 Sundar For Power plugin, there could be a common os-acc function which invokes cyborg client to update the API
15:06:38 wangzhh I think API is the entry of cyborg.
15:07:12 wangzhh If we call agent directly. Some process would be complex.
15:08:07 Sundar For vendor-specific actions, we need to delegate to the drivers, which would be through the agent.
15:08:12 wangzhh We can reuse client if so.
15:08:52 wangzhh Instead of init a rpc client and do extra works.
15:09:21 Li_Liu should os-acc be calling the Cyborg API from the top instead of call Cyborg driver?
15:09:30 Sundar Sure, we can have the Cyborg agent use the cyborgclient too. Then we need to configure the REST API URL etc. but that gives a single entry point to update allocation/release
15:09:51 wangzhh It is cyborg-api =》 cyborg-agent
15:10:35 Li_Liu i mean shall if be like: os-acc --> Cyborg api --> Cyborg agent ?
15:10:49 wangzhh Yes, uncle li
15:11:22 wangzhh Sundar, client is for restful api
15:11:34 Sundar Li_Liu: There is no need for such circuitous paths, and that probably won't work for Power. Eric doesn't want Cyborg to be in the middle for Power
15:11:36 wangzhh But agent is a rpc server.
15:12:31 Sundar Folks, we need 2 things: vendor-specific actions (through Cyborg drivers for FPGAs etc.), and update the db (which can be through REST API)
15:12:46 Li_Liu why Power does not work in this case, efried?
15:12:47 efried I want code provided by cyborg to do everything that's not platform specific; and I want everything that's platform specific done by plugin code. That's all.
15:13:02 efried That needs to apply to *all* platforms, including libvirt.
15:13:17 efried There's a tendency to think of libvirt as being "common". It's not.
15:14:00 efried (It's common in the sense of "pervasive" - not common in the sense of "all code paths go through it")
15:14:07 Li_Liu I understand, I don't think going through os-acc --> Cyborg api --> Cyborg agent could be a problem for you
15:14:20 Sundar To me, that means: os-acc calls the plugin for all vendor/arch-specific actions. The os-acc or the plugin must call into Cyborg REST API to update the db.
15:14:29 efried ^ this
15:14:59 efried And I'm tending toward s/or the plugin//
15:15:16 efried but will have to see how the actual flows shake out.
15:15:21 Sundar efried: That is how the spec is written today
15:15:35 Li_Liu Sundar, that I agree, but call Cyborg Agent/Driver directly from os-acc might be a problem
15:15:36 efried still need to review
15:16:30 wangzhh Sundar,
15:16:43 Sundar Li Liu: os-acc --> plugin. The plugin possibly calls Cyborg agent, but always updates Cyborg db through REST API
15:17:10 wangzhh It 's not just update state of acc in db when attach acc.
15:17:31 wangzhh Something should be done by API
15:18:12 Sundar Why "by API"? All actions can be done by Cyborg agent/drivers or the plugin, except for updating db
15:18:18 Sundar E.g. programming
15:18:43 wangzhh Yes, but as a management service.
15:18:48 Li_Liu even the programming function is now exposed by REST api
15:18:50 efried Does programming require platform-specific code?
15:19:00 efried I would kind of expect it does.
15:19:00 Sundar efried: Yes ^^
15:19:10 wangzhh We must maintain other meta,
15:19:30 Li_Liu efried, in cyborg itself, not platform-specific code, in the driver plugin, yes
15:19:36 wangzhh Quota usage, project or user info.
15:20:05 Sundar I would use the Cyborg driver on the node to do the programming. Using the compute node --> controller --> compute node loop relies on connectivity being intact through out the operation, and has more failure modes
15:20:06 wangzhh It is in oslo_context or handled by APi
15:20:31 efried So what I would expect is that os-acc would have a 'program' method; that method would do anything generic (like maybe downloading the image? not sure) and then call into the plugin's 'program' method to do the platform-specific bits.
15:21:01 efried but I wouldn't expect the plugin to call the cyborg API for any part of that.
15:21:35 Li_Liu well, os-acc is not meant for attach/detach right now
15:21:48 Li_Liu programming is done in vendor device drivers
15:22:25 Li_Liu as programming process does not involve nova at all
15:22:38 efried "os-acc is not meant for attach/detach right now" ?
15:22:59 Li_Liu sorry
15:23:03 wangzhh efried, Yes. If nova wouldn't call client, we should have programe
15:23:16 Li_Liu typo. is meat for attach/detach right now... :(
15:23:46 Sundar The os-acc is an abstraction for Nova Compute to Cyborg, for all devices, not just FPGAs
15:24:10 Sundar It includes attach/detach and any associated actions like device-specific configuration and programming
15:24:32 Sundar The latter part is delegated to plugins, which in turn may delegate them to Cyborg drivers
15:25:03 Sundar So, os-acc does not have a 'program' primitive natively
15:25:36 Sundar That is left to any FPGA plugin. Agree with Li_Liu that it would be done via Cyborg drivers down the chain
15:26:51 Sundar One expectation seems to be that all programming has to go through REST API? If so, as I explained, that relies on connectivity and has more failure modes
15:27:07 Sundar Only bitstream fetching needs connectivity
15:28:26 Sundar Anyways, please review the spec :)
15:29:20 Li_Liu ok, I think we open up more questions in os-acc spec, we can discuss them in the code review
15:29:55 Li_Liu Let's wrap up and end the meeting for now and continuous the discussion offline
15:29:59 Li_Liu #endmeeting
15:30:02 openstack Meeting ended Wed Jun 27 15:29:59 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:30:03 openstack Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-06-27-14.04.html
15:30:04 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-06-27-14.04.txt
15:30:05 openstack Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-06-27-14.04.log.html
15:31:01 efried Sundar: Back to specs building: when y'all submit a spec to the repository, does it actually get built into an HTML file anywhere, ever?
15:31:34 Sundar Li_Liu or shaohe: do you know the answer to efried's question?
15:31:52 efried (Hint: looking at your tox.ini, I'm not sure how it could)
15:51:18 Sundar efried: I think I understand what you mean. The doc build succeeds and places the output in doc/build/html/. But the specs don't seem to be there.
15:51:36 efried Sundar: Right. I'm committing a patch right now that will cause them to be built.
15:51:54 Sundar Excellent. Thanks a lot, Eric!
15:53:17 openstackgerrit Eric Fried proposed openstack/cyborg master: Build specs https://review.openstack.org/578455
15:53:20 efried Sundar: ^
16:11:16 Sundar Thanks very much, Eric. I'll try this out.
16:12:13 openstackgerrit Eric Fried proposed openstack/cyborg master: Cyborg/Nova/Glance interaction in compute node, including os-acc. https://review.openstack.org/577438
16:12:13 openstackgerrit Eric Fried proposed openstack/cyborg master: WIP/POC: seqdiag https://review.openstack.org/578460
16:12:55 efried Sundar: I rebased your spec patch on top of the 'build specs' patch; and then threw another delta on top of it ^ which demonstrates a seqdiag being built.
16:13:24 efried Sundar: This works for me locally. Once that top patch gets through zuul we can take a look and make sure it rendered.
16:13:48 efried Sundar: If you want to build locally, you can use tox -e specs or tox -e docs which is a superset thereof.
17:45:49 openstackgerrit Eric Fried proposed openstack/cyborg master: Move specs under doc/source so they build https://review.openstack.org/578455

Earlier   Later