| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-05-17 | |||
| 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 | gryf | unless, we do some rebase stuff on the repo itself, but I'm not aware if this is a good practice | |
| 16:21:42 | zhipeng | this sounds reasonable ? | |
| 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 | |
| 16:23:33 | zhipeng | as I understand ttk2[m] and gryf has some discussion on the CI settings | |
| 16:23:40 | gryf | adreznec, yeah. | |
| 16:23:40 | zhipeng | do we have any perference now ? | |
| 16:24:25 | gryf | zhipeng, it was mostly very high level discussion | |
| 16:25:05 | gryf | we have to have some concrete implementation first | |
| 16:25:07 | zhipeng | will then on high level, any directions that we want to follow upon :) | |
| 16:25:14 | zhipeng | okey | |
| 16:25:32 | zhipeng | but have vendors to provide third party CI env would always be a good idea | |
| 16:25:49 | zhipeng | baremetal or vm, is it correct ? | |
| 16:25:53 | gryf | we can figure that out later | |