Wednesday, 2018-12-05

openstackgerritzhulingjie proposed openstack/python-cyborgclient master: Change openstack-dev to openstack-discuss
*** tetsuro has joined #openstack-cyborg06:41
*** tetsuro has quit IRC06:43
*** helenafm has joined #openstack-cyborg08:25
*** sum12 has quit IRC08:55
*** sum12 has joined #openstack-cyborg09:23
*** yumeng has left #openstack-cyborg11:43
*** yumeng has joined #openstack-cyborg11:44
*** Sundar has joined #openstack-cyborg13:58
*** Li_Liu has joined #openstack-cyborg13:59
*** wangzhh has joined #openstack-cyborg14:05
Li_Liuhi zhenghao14:07
wangzhhHi Li14:07
wangzhhAny others?14:07
Li_Liunot ywt14:08
SundarHi Zhenghao and Li14:08
Li_LiuHi Sundar'14:08
Li_Liulet's wait for few min14:08
*** xinran_ has joined #openstack-cyborg14:11
Li_Liu#startmeeting openstack-cyborg14:11
openstackMeeting started Wed Dec  5 14:11:40 2018 UTC and is due to finish in 60 minutes.  The chair is Li_Liu. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:11
*** openstack changes topic to " (Meeting topic: openstack-cyborg)"14:11
openstackThe meeting name has been set to 'openstack_cyborg'14:11
Li_LiuLet's get started14:11
xinran_#info xinran_14:11
Li_Liu#topic Roll Call14:12
*** openstack changes topic to "Roll Call (Meeting topic: openstack-cyborg)"14:12
Li_Liu#info Li_Liu14:12
wangzhh#info wangzhh14:13
Li_Liu#topic status updates14:13
*** openstack changes topic to "status updates (Meeting topic: openstack-cyborg)"14:13
Li_LiuSundar, I saw your comments. Thanks a lot14:13
Li_LiuI will update the the patch to address your comments14:14
Sundar#info Sundar14:14
SundarWelcome, Li14:14
Li_Liuguys, please review
Li_Liuif you have the change14:15
Li_LiuSundar, anything to report on your side?14:17
SundarLi_Liu: I am proceeding with the POC. Waiting for driver OVO object patch to submit the next OPAE driver patch14:18
Li_Liuok, great14:19
SundarWe may need to start a feature branch to host the POC. I will get back to you on that.14:19
Li_Liuwangzhh, how's you and Coco's part?14:19
Li_LiuSundar sure thing14:19
wangzhhI have finished my part in my local env. I'll commit it after improve UT.14:21
wangzhhSorry  for I'm late. I'm very busy last two weeks...14:21
Li_LiuTotally understand14:22
Li_Liuthanks a lot for the work :)14:22
wangzhhNP :)14:22
Li_Liuxinran_ I have send you my thoughts on the conductor diff thing14:25
Li_LiuI suggest to keep it simple for now14:25
xinran_Yes, I saw it, thanks14:27
xinran_So we all have agreement on do diff and update DB/placement on the conductor?14:28
Li_LiuSundar, what's your thoughts on it?14:28
SundarLi_Liu: Makes sense. I agree we should keep it simple to start with.14:29
SundarDo any of you see issues if we have to change the implementation later, in terms of upgrade impact?14:29
Li_LiuWell, even if you want to change the implementation, it should be transparent to others14:30
Li_Liushould not be much impact14:30
SundarSounds good.14:31
Li_Liuxinran_ I guess we can do it that way14:31
Li_LiuGreat, for my self, I will finalize the spec in next couple days14:32
SundarLi_Liu: Thank you14:32
xinran_so every time agent discover the device, agent should call conductor to do a diff14:32
Sundarxinran_ It can be batched per host --all devices go together14:33
SundarMay be you can always investigate some easy compression with python libraries14:33
xinran_all device info could be gathered in a list of OVO object14:34
Sundarxinran_ Yes14:34
xinran_Sundar:  ok, I will look at it, thanks14:35
*** yumeng has quit IRC14:35
Li_LiuI think we all clear on what14:38
Li_Liuto do next14:38
Li_Liulet's wrap up14:39
Li_LiuThank you guys, remember the time will change for our next irc meeting.... I will send a new date btw14:39
*** openstack changes topic to "Pending patches (Meeting topic: openstack-cyborg)"14:40
openstackMeeting ended Wed Dec  5 14:40:56 2018 UTC.  Information about MeetBot at . (v 0.1.4)14:40
openstackMinutes (text):
*** Li_Liu has quit IRC14:42
efriedSundar: Would now be a good time to talk about feature branches vs. code series and whatnot?15:27
Sundarefried: Sure15:35
SundarThansk for pinging back15:35
efriedSundar: I'm composing an email which is about to turn into an epic.15:35
efriedHere's what I'm saying about "feature branches":15:36
efriedHuh, I never knew that was a thing. I will say that, in the ~3.5y I've been working in OpenStack, I've never seen this done. Even for large and complex features involving literally a dozen change sets or more, I've always seen them submitted to the master branch.15:36
efriedHaving read the link you sent, perhaps we should talk about the pros and cons before you commit (heh) yourself to using a feature branch. IMO the possibility of needing to rebase several times is the lesser evil as compared to not having CI (or needing to go through the extra work to set up CI jobs).15:36
efriedSundar: Are you aware of issues on either side beyond the above? (Rebasing vs. CI)15:36
SundarIMHO, the biggest risk is that there are differing inputs from different developers, and I wind up trying different directions. That is why this aspect will not get upstreamed right away in Cyborg either.15:38
efriedNot sure how having a feature branch will help you there.15:38
efriedIf you need to try several different things, you can submit different series15:39
efriedand then abandon whichever one(s) aren't The Chosen One.15:39
SundarOn the Cyborg side, there is some reluctance to commit to upstream changes when the form of the API is itself under question.15:40
SundarIf the Cyborg side is sitting as a proof of concept in some side branch, Nova developers may not consider the corresponding changes?15:41
efriedSundar: Proposing changes to gerrit isn't locking you into anything.15:41
efriedAnd (this was going to be part of my epic) you can still develop with cross-project dependencies.15:42
SundarTo be honest, another factor is the speed of development. It is *much* faster to develop Cyborg APIs, db schemas etc. in my own repo (which is what I am doing now) than try to get each patch out separately.15:44
SundarAlso, some developers want to 'own' parts of the code, so it is tough to put out patches in those areas. Calling it a POC sidesteps those issues.15:45
SundarThe only downside is that, there is no good place to keep those changes visible publicly.15:46
SundarIntel has a heavyweight process to disclose code in github. I got  a list of 30 tasks to do for security lifecycle alone. Feature branches seemed more attractive after looking at those 30 :)15:47
efriedSundar: Still not seeing how a feature branch helps any of that. In order to collaborate among multiple developers and/or repositories, you're still going to have to upload the code to gerrit. And it's standard procedure to proposed WIP/PoC patches all over the place and either polish them until they're ready for primetime or abandon them.15:47
efriedSundar: Does Intel restrict that process even for proposing code to openstack projects like nova??15:47
SundarNo, upstream development is fine15:48
efriedokay, phew.15:48
SundarOn the Cyborg side, if I push patches on database schema etc. I would be stepping on soem toes15:48
efriedso if the code we're talking about is going to be in openstack/cyborg, openstack/nova, openstack/os-acc, openstack/cyborgclient, or whatever, ...15:48
efriedSundar: Okay, but how does a feature branch help with that?15:49
SundarI push code to a side branch, which is a proof of concept. Somebody else can take that (or ignore it) and propose the 'real patch' upstream15:49
efriedWell, the way to upstream a feature branch would be to merge it in, not repropose the same code to the master branch.15:50
efriedAnyway, some of the benefits of using master may be enough to convince the resistant folks on the cyborg side that it's okay.15:52
SundarI'll leave that part to Cyborg folks. :) A possibility is that the API parts get merged once we settle upon that, whereas db layer is developed by itself.15:52
SundarFor Nova, the main issue is I don't want to face CI, bikeshedding on test cases and repeated rebasing. A feature branch should help there?15:53
SundarUntil we get the broad outlines agreed upon, focusing on the details will be distracting.15:55
efried- Bikeshedding on test cases would need to happen at some point anyway. But you don't need to worry too much about test cases if you're just looking to PoC several possibilities and figure out which one to go with. I don't see that being more or less of an issue either way.15:57
efried- Repeated rebasing I agree is a pain, but a relatively minor one. And as I said before, IMO it's outweighed by the benefits (more in a bit on that).15:57
efried- "don't want to face the CI" -- say what? This is definitely something you *want* to do. Again, in the PoC stage, nobody's going to care about the CI results, but once you get to a point where you're trying to polish something up and get it ready for primetime, you definitely need the CI involved.15:57
efriedThe problem with doing all the PoC in a feature branch is, once you've decided on a direction and want to move to master, you're going to *want* the advantages of the CI and the cross-project dependency automation that zuul gives you. And you don't get that with feature branches (I think, at least without extra work).15:59
efriedSo at that point you would have to *propose* (not merge) your patches back into the master branch, whereupon you would lose all your patch set and comment history, etc. Never mind the additional paperwork involved to do that.16:00
efriedAnyway, I think we've reached (probably passed) the border of explanation vs action here. Neither way is going to kill you.16:03
Sundar"nobody is going to care about CI' -- Nova developers have given -1 on typos. Are you sure they will ignore CI results?16:04
efriedSundar: I'm still working on writing up an explanation of the gerrit workflow for stacking commits into series - which you'll have to do regardless of your branching strategy.16:04
SundarBTW, I am open to all ideas -- I am not bullheadedly pushing for feature branches, just evaluating options.16:05
efriedSundar: You'll get -1s (or at least no positive votes) in the PoC stage anyway. Once you've picked a direction and are ready to go primetime, yes you'll need to have perfect spelling and CI results and and and ...16:05
SundarI will need help with the rebasing for sure -- I am sure it can get complicated16:06
efriedWe could head off some of that by putting procedural -2s on the bottom-most changes in your various series to make it clear that they're not ready to go yet.16:06
efriedSundar: Yes, I'm happy to help with that. I'm pretty good at it :)16:07
SundarLooking forward to your epic email :)16:07
SundarI see options for setting workflow to -1, but not -2. Is a procedural -2 something else?16:08
efriedSundar: only cores can -2.16:11
efriedThe special thing about code review -2 is that it sticks with the change through subsequent patch sets. Code review and workflow -1 get cleared each time a new patch set is uploaded.16:13
efried(except rebases)16:13
Sundarefried: Yes, aware of that. I thought 'procedural' referred to 'workflow', which is a different scoring16:19
efriedSundar: "procedural" isn't a real gerrit keyword, it's just what we (humans) use to distinguish, "We're holding this series until it's ready, or until the bp is approved, or whatever," versus, "We're never going to merge this, ever, and you should abandon it."16:26
*** wangzhh has quit IRC16:49
*** helenafm has quit IRC17:28
*** jiapei has quit IRC17:52
*** jiapei has joined #openstack-cyborg17:53
*** Sundar has quit IRC17:55
*** kailun has quit IRC18:25
*** efried is now known as efried_out_til_j22:17
*** efried_out_til_j is now known as efried_cya_jan22:17

Generated by 2.15.3 by Marius Gedminas - find it at!