Earlier  
Posted Nick Remark
#openstack-cyborg - 2017-05-17
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
16:23:33 zhipeng as I understand ttk2[m] and gryf has some discussion on the CI settings
16:23:40 zhipeng do we have any perference now ?
16:23:40 gryf adreznec, yeah.
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
16:26:00 zhipeng sure
16:26:09 zhipeng #topic AoB
16:26:21 zhipeng any other topics ?
16:26:36 ttk2[m] Keep up the good work guys.
16:27:00 zhipeng that would be a good note our meeting ends on :)

Earlier   Later