Posted	Nick	Remark
#openstack-cyborg - 2017-06-21
15:24:45	zhipeng	crushil yes understood :)
15:25:09	zhipeng	and if we got meeting minutes that'd be perfect
15:25:40	zhipeng	NokMikeR your thought on DPACC ?
15:26:37	NokMikeR	more complicated than originally thought - issue seems to be related to translating the gapi to something usefull.
15:27:02	zhipeng	okey that would be on the data plane side of things
15:27:10	NokMikeR	in summary maybe a bit before its time? lots of missing parts etc.
15:27:13	zhipeng	I would leave that to you experts :P
15:27:18	NokMikeR	lol
15:27:51	zhipeng	I think in jist Lingli said that as long as there are people willing to work on the project
15:28:05	zhipeng	she's more than willing to restart the project
15:28:26	zhipeng	so for gpai as long as there are folks actively working on it
15:28:31	NokMikeR	Thats also important eg dont bother restarting unless theres really something to address.
15:28:34	zhipeng	maybe some of the problems could be fixed
15:28:37	jkilpatr	what lead to it being stopped in the first place?
15:28:56	NokMikeR	fdio mass migration?
15:28:58	zhipeng	people sorta drift away
15:29:05	zhipeng	ah maybe that
15:30:05	zhipeng	okey any other buisness
15:30:15	zhipeng	we could wrap up quick this time
15:30:41	zhipeng	oh on top of my head
15:30:50	zhipeng	the CFP for Sydney Summit is already open
15:31:00	zhipeng	and deadline is around July 15th I guess
15:31:16	zhipeng	let's all think of possible session topics
15:31:33	zhipeng	we could each summit one cyborg related talk
15:32:03	zhipeng	SO weird CFP is this early, but we gotta play by the rules
15:32:16	crushil	Or we can submit one joint talk where we have a basic POC by the time summit rolls around
15:32:27	zhipeng	that as well :)
15:33:49	zhipeng	okey if no other business I could close the meeting early today
15:33:58	NokMikeR	nothing this side
15:34:19	zhipeng	leave a note here if you come up with anything, handles with [m] are always lurking here :)
15:34:59	zhipeng	thanks everyone
15:35:03	zhipeng	#endmeeting
15:35:05	openstack	Meeting ended Wed Jun 21 15:35:03 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:35:06	openstack	Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-06-21-15.04.html
15:35:07	openstack	Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-06-21-15.04.txt
15:35:08	openstack	Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-06-21-15.04.log.html
15:35:29	jkilpatr	if we have enough 30 minute meetings we might be able to get our average down to an hour
15:35:34	jkilpatr	by sometime in 2020
15:35:39	crushil	jkilpatr, lol
15:35:40	zhipeng	hahaha
15:35:54	crushil	Btw I don't see the CFP on the ML zhipeng
15:36:08	crushil	Btw I don't see it?
15:36:16	zhipeng	I think I saw it sometimes ago
15:36:27	zhipeng	will dig again and fwd to you guys
15:38:07	NokMikeR	bye all
#openstack-cyborg - 2017-06-22
19:59:54	jkilpatr	ok got config loading working and message passing working, next is rpc then these stubs are workable and should be merged so that we can work on a more integrated system
#openstack-cyborg - 2017-06-28
14:59:52	ttk2[m]	Morning everyone.
15:02:04	zhipeng	hey
15:05:49	zhipeng	anyone else is here ?
15:13:59	openstack	Meeting started Wed Jun 28 15:13:59 2017 UTC and is due to finish in 60 minutes. The chair is zhipeng. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:13:59	zhipeng	#startmeeting openstack-cyborg
15:14:00	openstack	Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:14:03	openstack	The meeting name has been set to 'openstack_cyborg'
15:14:33	zhipeng	#topic Roll Call
15:14:54	NokMikeR	#info Michael Rooke, Nokia
15:15:03	zhipeng	#info Howard Huang
15:16:16	NokMikeR	Must be summer :)
15:16:37	ttk2[m]	#info Justin Kilpatrick, RedHat
15:16:43	ttk2[m]	Sorry on a plane today.
15:16:57	zhipeng	wow, still wifi ?
15:17:17	ttk2[m]	Just landed.
15:17:44	zhipeng	you work too hard :)
15:18:03	zhipeng	#topic development progress
15:18:06	ttk2[m]	Anyways I'd like to get that accelerator object stub merged so that I can start setting up the db components of the conductor. Messaging and rpc is working.
15:18:27	ttk2[m]	The agent needs the dummy driver merged at least so that I can play around with integrating those two.
15:19:05	ttk2[m]	Oh also I figured out the config module it loads transport urls and works in a real cloud env.
15:19:16	zhipeng	crushil how's the driver patch going ?
15:19:32	zhipeng	ttk2[m] config module ?
15:20:02	ttk2[m]	Oslo config.
15:20:22	zhipeng	okey
15:21:22	ttk2[m]	Essentially I have all the basics worked out except the db so all the various components can talk to each other after that it's just a matter of writing business logic.
15:28:42	zhipeng	ttk2[m] so looking at the conductor patch
15:28:47	zhipeng	#link https://review.openstack.org/#/c/472662/
15:29:10	zhipeng	I think except for a need to modify the patch title, it looks good for me to merge
15:30:01	zhipeng	also the api spec could be merged at this point I guess
15:30:06	zhipeng	#link https://review.openstack.org/445814
15:34:25	ttk2[m]	API spec is good. And I'll get the db stuff into the conductor and then mark it as ready.
15:34:38	zhipeng	cool
15:35:18	NokMikeR	does the api cover listing an application running on the accelerator?
15:36:05	zhipeng	we list accelerators, but i doubt we will list applications
15:36:12	zhipeng	could you give a use case on that ?
15:36:50	NokMikeR	GPU has a running application, you list the GPU to see if its 100% free, then discover its not, hence skip to the next one.
15:37:12	NokMikeR	thats more fine grained than simply discovering / listing the accelerator itself.
15:37:23	ttk2[m]	isn't that the same as listing usage?
15:37:43	ttk2[m]	I'm planning on usage metric collection but I'm not sure if/how we expose that to the api instead of just the operator/internally
15:38:39	zhipeng	i think we could definitely have that metric for the scheduler to use, but it might be just used internally
15:38:57	zhipeng	and it would be difficult to model it in the resource provider, because it is dynamic
15:39:28	NokMikeR	so operations like deleting an accelerator only occur when there is no running applications (=anything left) on the accelerator?
15:40:57	zhipeng	i think it would be up to the users to make that judgement (check if nothing left running)
15:41:07	ttk2[m]	that's easy enough to do as we have to control scheduling based on usage anyways
15:41:15	zhipeng	cyborg will just receive a request to detach the accelerator for whatever purpose
15:41:22	NokMikeR	ok
15:41:33	ttk2[m]	on the ohter hand it would be a pretty bad user experience if an idling VM kept the accelerator from being changed.
15:42:07	NokMikeR	or updated with something else since theres a left over app using resources that should be allocated for the new app etc.
15:42:37	NokMikeR	maybe these are issues outside of cyborg, not sure.
15:51:42	ttk2[m]	so managing instances attached to the accelerators is only partly cyborgs job
15:52:54	ttk2[m]	I mean we'll list instances that are attached or running on various accelerators, but deciding if the work being done is useful is out of scope. And in the case of shared accelerators we're going to need to rely on them being able to print out who is doing what since there's probably a scheduler running below us for that.
15:55:02	zhipeng	a sched running below us ?
15:58:39	ttk2[m]	zhipeng: like if we had gpu virtualization and three vm's sharing a gpu
15:59:38	ttk2[m]	there's a scheduler at the driver level taking workloads from the 3 virutal gpu's and muxing them into the real hardware. We may be able to see how much the actual hardware is utilized, but unless the driver tells us which vm is using what percentage of the total resources we're in the dark other than "these vm's are hooked up to this physical gpu"

Earlier   Later