Posted	Nick	Remark
#openstack-cyborg - 2018-06-27
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.
14:49:49	shaohe_feng	Sundar, they develop logic on FPGA.
14:50:17	shaohe_feng	we have a gap on cyborg API design.
14:50:31	Sundar	Interesting. So, they have their own bitstreams. How are they using it -- like FPGA aaS?
14:52:13	shaohe_feng	Not sure how do they use it.
14:52:34	shaohe_feng	Sundar, will check with them about it by mail. and CC you.
14:52:42	shaohe_feng	for we need to interactive nova.
14:53:13	Sundar	shaohe: Ok
14:53:42	shaohe_feng	wangzhh, introduce the whole flow for the interaction.
14:53:55	shaohe_feng	they have do a demo for it during summit.
14:54:18	wangzhh	OK. We have a discussion offline this afternoon.
14:54:34	wangzhh	Let me introduce about it.

Earlier   Later