Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2017-05-17
15:23:00 zhipeng which I thought is already done in the current patch ?
15:23:27 cdent it would be great to see, at some point, a narration of the expected end to end flow from a user's standpoint, if it doesn't already exist. Including how various services will be touched.
15:24:17 zhipeng cdent we got a flow chart in our BOS presentation, but rather rudimentary at the moment
15:24:20 jkilpatr cdent, we have a decent idea of how we want it to work but I expect some things will change as we get into the nitty gritty of placement problems
15:24:42 cdent sure, change is the nature of this stuff :)
15:24:47 jkilpatr zhipeng, ok so if I want to attach an accelerator to an instance what do I do? Do I put to update an accelerator spec with a new instance ID to attach to?
15:24:48 zhipeng :)
15:25:18 jkilpatr cdent, I think I'll put up a user workflow spec later today, just so that we keep track of all of this better.
15:25:30 cdent \o/
15:25:48 cdent can you add me as a review on that when it is up, so I get some email to remind me to look?
15:26:23 zhipeng just as we drew for our presentation, after the user using Cyborg service to complete the discovery phase and Cyborg finishing interaction with placement to advertise the accelerator inventory
15:26:24 jkilpatr will do, whats your email?
15:26:44 cdent cdent@anticdent.org is me on gerrit
15:27:01 zhipeng then user just request to create an instance on a compute node with the corresponding accelerator trait
15:27:32 zhipeng if trait include hotplug, then maybe it will be a live attachment
15:27:45 jkilpatr I really don't think we're going to get away with one trait per accelerator, users will probably bundle them into flavors, but instead of being tied to a list of whitelisted pci devices these flavors can be much mroe general.
15:27:50 zhipeng which means user could attach the accelerator after VM creation
15:28:35 zhipeng I was told by jay today that trait are per resource provider
15:29:02 zhipeng so it would mostly be one trait per compute node
15:29:08 jkilpatr I'll have to look at it in detail, I was watching the summit presentation again today.
15:29:17 zhipeng or we got vGPUs or FPGA virtual functions
15:29:28 zhipeng then it would be nested resource provider
15:29:38 zhipeng and we could have trait on the virtual functions
15:29:53 zhipeng but anyways it does not tie to a specific accelerator
15:30:10 zhipeng just depending on you model your accelerators into resource providers
15:30:22 zhipeng cdent plz correct me if i'm wrong :P
15:30:24 jkilpatr we're going to need to be careful with that.
15:31:03 zhipeng #link https://pbs.twimg.com/media/DAAUxEWUAAAV6zA.jpg
15:31:16 cdent zhipeng: that looks mostly correct, but I'm only partially paying attention :(
15:31:27 zhipeng cdent no problemo :)
15:31:51 zhipeng as long as I don't make any extremely wrong claims :)
15:32:07 jkilpatr so implementation. What can we start and when?
15:32:24 zhipeng as soon as we freeze the specs
15:32:35 zhipeng i suppose we should all go ahead start coding
15:32:48 crushil Can we focus on closing out the specs out first though?
15:32:55 zhipeng yes
15:32:57 jkilpatr ok then that's a plan.
15:33:15 zhipeng okey, then for api spec
15:33:31 zhipeng #link https://review.openstack.org/445814
15:33:35 zhipeng any other questions ?
15:34:22 jkilpatr I just posted a comment there, otherwise I'm happy enough
15:34:31 zhipeng okey
15:34:54 jkilpatr um should we pick a database tech? what's available already sql, mongo... reddis (not sure about that one)
15:35:08 crushil MariaDB?
15:35:15 zhipeng #action jkilpatr to post a reminder comment, the api spec patch is LGTM
15:35:39 zhipeng i think we could just use mysql
15:35:54 jkilpatr MariaDB == mysql except when it doesnt
15:36:04 jkilpatr I think openstack ships with Maria right now
15:36:07 zhipeng yes
15:36:09 crushil yup
15:36:28 zhipeng next up, agent spec
15:36:33 zhipeng #link https://review.openstack.org/#/c/446091/
15:37:12 jkilpatr looks like most people are happy with it.
15:37:14 zhipeng #info Jay Pipes suggest agent could directly interact with placement api, instead of going through conductor
15:37:30 zhipeng #link https://pbs.twimg.com/media/DAAUtyoUMAAXQXI.jpg
15:37:50 jkilpatr so from the summit preso all the computes already talk to the placement api themselves
15:37:51 zhipeng but I guess we don't need to reflect that in the agent spec
15:37:54 jkilpatr so it's designed to scale well like that
15:38:30 jkilpatr I'd prefer to be explicit, I'll patch it into my spec today
15:38:48 crushil We should reflect that in the agent spec
15:39:01 zhipeng jkilpatr yes, and for implementation, Jay suggest we could directly just copy nova/scheduler/client/report.py
15:39:24 zhipeng since it is basically rest calls between agent and placement api
15:39:32 jkilpatr that's the sort of laziness I can get behind.
15:39:42 zhipeng XD
15:39:44 crushil lol
15:40:29 zhipeng #agreed jkilpatr do a quick update on agent spec to reflect jaypipes comment, then the agent spec patch LGTM
15:40:38 zhipeng okey, next up, generic driver
15:40:58 zhipeng #link https://review.openstack.org/#/c/447257/
15:41:04 zhipeng any more comments
15:41:08 zhipeng looks fine to me
15:41:52 crushil jkilpatr, Any other comments on your end? I have tried to address all of your and Roman's comments in the patch
15:41:56 jkilpatr what about detect accelerator? discovery has to be handled by someone, do we want drivers to have a discovery call?
15:42:10 jkilpatr I like the rest of the api list for it, good job
15:43:12 crushil I can add that to the list. What would be the flow though for discovery?
15:43:37 zhipeng i think discovery already part of the spec ?
15:43:44 zhipeng see line 121
15:43:55 jkilpatr ah yup just not in the other list
15:44:04 crushil It's not part of the API list
15:44:09 jkilpatr crushil, the flow (which I think you should add into your spec or maybe me in to the agent spec)
15:44:27 jkilpatr is agent on first startup says "hey I've never been started up before, lets call discover for all my drivers"
15:44:48 jkilpatr whatever returns true it lists and sends to the conductor to store in the db as possible accelerators
15:45:08 jkilpatr later on operators can call discover to do this again and add new accelerators.
15:45:42 jkilpatr as a note I think accelerators should get added in a "not ready" state with the operator having to tell cyborg to go install drivers otherwise we risk bad endings installing software on live clouds
15:45:59 jkilpatr more things to add to the agent spec
15:46:14 zhipeng agree
15:46:17 crushil +1
15:46:35 crushil Makes sense, but should we add it to the driver spec or agent spec or both?
15:47:26 zhipeng i think for both, because discovery is directly triggered by agent to run loops on drivers ,right ?
15:47:28 jkilpatr crushil, driver spec just needs "on discovery return if the accelerator exists or not" agent is the one that will call discovery then wait for the operator to call the api to move the accelrator into 'ready' before calling the install driver function.
15:48:08 zhipeng yep
15:48:27 jkilpatr um speaking of message passing
15:48:34 jkilpatr most of this should be done over message passing
15:48:41 jkilpatr rabbitmq/oslo messaging fine?
15:48:53 crushil Yup, that is the OS standard
15:48:59 zhipeng yep
15:50:13 zhipeng #agreed crushil to update the driver spec to include the discovery interface, and jkilpatr update the agent spec to reflect the related operations, otherwise it is LGTM
15:50:48 zhipeng moving along, next up, interaction https://review.openstack.org/#/c/448228/
15:50:52 zhipeng #link https://review.openstack.org/#/c/448228/
15:51:01 zhipeng I think we still need more work in this
15:51:27 zhipeng first of all thx to gryf to work this on his own time

Earlier   Later