| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-05-17 | |||
| 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 | |
| 15:51:53 | ttk2[m] | I think this is where most of the workflow stuff is hidden right now. | |
| 15:52:04 | ttk2[m] | Oh this is jkilpatr moved to my phone. | |
| 15:53:00 | zhipeng | yes | |
| 15:53:32 | zhipeng | we should continue to work on the spec, but I don't think it will block our implementation | |
| 15:54:32 | zhipeng | any thoughts ? | |
| 15:56:18 | zhipeng | and tttk2[m] I think you could just work with Roman on this patch to illustrate the workflow | |
| 15:56:25 | zhipeng | and also have cdent for review | |
| 15:56:37 | crushil | Ya, makes sense. But, we need to have a cutoff date to finish the spec | |
| 15:57:40 | zhipeng | we slip the Apr 15th one rather quickly lol, but ya I agree we need another cutoff date | |
| 15:57:55 | zhipeng | what is the m2 deadline for Pike ? | |
| 15:58:40 | crushil | June 9 | |
| 15:59:05 | zhipeng | i think we could just use that for all the non-LGTM specs per today's meeting | |
| 15:59:23 | ttk2[m] | Ok then. Can we comment on the specs with that deadline. | |
| 15:59:41 | crushil | We should close out all the other specs sooner though | |
| 15:59:51 | ttk2[m] | I feel like we should make a point of moving info out of meetings and into specs so we don't lose them in the back hole or IRC logs. | |
| 15:59:58 | crushil | +1 | |