| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-05-17 | |||
| 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 ? | |
| 16:18:23 | gryf | zhipeng, what exactly do you mean by following procedure? | |
| 16:19:02 | zhipeng | have it first in the current cyborg repo, and then move it out to a seperate one | |
| 16:19:31 | gryf | I'm against it. as ttk2[m] said - if we merge it, it stays forever. | |
| 16:19:43 | zhipeng | why ?? | |
| 16:19:51 | gryf | it's a git :> | |
| 16:19:54 | ttk2[m] | Because history | |
| 16:20:02 | zhipeng | say we couldn;t even move the specs out ? | |
| 16:20:12 | adreznec | merging it will permanently increase the repo size because the artifact will remain in the history forever | |
| 16:21:00 | zhipeng | okey understood | |
| 16:21:06 | gryf | zhipeng, we can, but they will be available, if someone would like to go back in time (in history) and nothing prevent him to do so :D | |
| 16:21:37 | zhipeng | then I will abandon the patch and directly submit it to the seperate repo instead | |
| 16:21:42 | zhipeng | this sounds reasonable ? | |
| 16:21:42 | gryf | unless, we do some rebase stuff on the repo itself, but I'm not aware if this is a good practice | |
| 16:21:55 | gryf | yup | |
| 16:22:31 | zhipeng | #agreed abandon the nacsa sandbox patch and directly submit it to a seperate repo | |
| 16:22:53 | adreznec | gryf: yeah, you basically have to use a rebase or git filter-branch to remove it, but that'll break everyone's checked out repos since you're rewriting history... so not typically good practice | |
| 16:23:03 | zhipeng | okey, we got many things settled :) | |
| 16:23:11 | zhipeng | #topic CI discussion | |