| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-05-17 | |||
| 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 | |
| 16:00:42 | zhipeng | +1 | |
| 16:01:05 | zhipeng | at least for all the LGTM specs I will merge those by the end of this week | |
| 16:01:47 | zhipeng | #agreed set June 9th for a hard cut-off date for all the remaining spec, including cyborg-nova interaction | |
| 16:01:58 | zhipeng | next up , conductor spec | |
| 16:02:14 | zhipeng | #link https://review.openstack.org/#/c/463316/ | |
| 16:02:30 | zhipeng | i think I will post some review, most on the wording | |
| 16:02:53 | zhipeng | but this should be a simple one for us to freeze this week | |
| 16:03:41 | ttk2[m] | Agreed. It's pretty much just glue code. | |
| 16:04:08 | zhipeng | #agreed after some polishing, conductor spec LGTM this week | |
| 16:04:24 | zhipeng | the last one in the queue, not a spec patch tho | |
| 16:04:34 | zhipeng | #link https://review.openstack.org/#/c/461220/ | |
| 16:04:57 | zhipeng | could folks just give a +1 so that I could merge it, it is mostly a house cleaning stuff | |
| 16:07:43 | gryf | I have mixed feelings about that | |
| 16:08:22 | zhipeng | gryf which topic ? | |
| 16:08:36 | gryf | nacsa.tgz in a repo | |
| 16:08:44 | gryf | it doesn't sound right | |
| 16:09:24 | zhipeng | we just hosted in the sandbox | |
| 16:09:37 | zhipeng | we could even move them out to an individual repo later on | |
| 16:09:46 | gryf | well, yeah | |
| 16:09:50 | zhipeng | but we did have extensive discussion on that matter | |
| 16:09:55 | zhipeng | with moshe and his team | |
| 16:09:59 | gryf | but it will affect size of the repositiory | |
| 16:10:49 | zhipeng | then I think maybe we could move the sandbox out to an individual repo, such as cyborg-sandbox | |
| 16:11:01 | zhipeng | so that it won't affect the cyborg project repo itself | |
| 16:11:19 | gryf | yes, I think that the better solution | |
| 16:11:23 | gryf | also | |
| 16:11:53 | gryf | I'd like to avoid keeping binary blobs in repository | |
| 16:12:03 | ttk2[m] | Agreed. | |
| 16:12:05 | zhipeng | that's fine for me :) | |
| 16:12:20 | zhipeng | but we do need to merge it first, and then move it out | |
| 16:12:27 | zhipeng | due process | |
| 16:12:35 | gryf | so the perfect solution would be to unpack it, and make the commmit which move entire work into its own directory. what do you think? | |
| 16:12:51 | zhipeng | nuh that won't be necessary | |
| 16:13:15 | zhipeng | i think just move to another repo just for records | |
| 16:13:30 | zhipeng | we won't do any release, for example , for the cyborg-sandbox | |
| 16:13:37 | ttk2[m] | Um if we merge it it's in the repo history forever. | |
| 16:13:40 | zhipeng | it just sits there | |
| 16:13:48 | zhipeng | no we could move it our | |
| 16:13:59 | zhipeng | and we need to move out the spec later as well | |
| 16:14:14 | zhipeng | cyborg-spec will be the standalone repo to store all the specs | |
| 16:14:19 | ttk2[m] | I don't have super strong feelings. But Id like to keep binaries out of the repo | |
| 16:14:28 | gryf | ttk2[m], +1 | |
| 16:14:39 | zhipeng | I have no problem either | |
| 16:14:58 | zhipeng | but let's just follow a procedure and get it done | |
| 16:16:44 | zhipeng | sounds reasonable for everyone ? | |