| openstackgerrit | zhulingjie proposed openstack/python-cyborgclient master: Change openstack-dev to openstack-discuss https://review.openstack.org/622719 | 03:28 |
|---|---|---|
| *** tetsuro has joined #openstack-cyborg | 06:41 | |
| *** tetsuro has quit IRC | 06:43 | |
| *** helenafm has joined #openstack-cyborg | 08:25 | |
| *** sum12 has quit IRC | 08:55 | |
| *** sum12 has joined #openstack-cyborg | 09:23 | |
| *** yumeng has left #openstack-cyborg | 11:43 | |
| *** yumeng has joined #openstack-cyborg | 11:44 | |
| *** Sundar has joined #openstack-cyborg | 13:58 | |
| *** Li_Liu has joined #openstack-cyborg | 13:59 | |
| *** wangzhh has joined #openstack-cyborg | 14:05 | |
| Li_Liu | hi zhenghao | 14:07 |
| wangzhh | Hi Li | 14:07 |
| wangzhh | Any others? | 14:07 |
| Li_Liu | not ywt | 14:08 |
| Sundar | Hi Zhenghao and Li | 14:08 |
| Li_Liu | Hi Sundar' | 14:08 |
| Li_Liu | let's wait for few min | 14:08 |
| wangzhh | OK | 14:09 |
| *** xinran_ has joined #openstack-cyborg | 14:11 | |
| Li_Liu | #startmeeting openstack-cyborg | 14:11 |
| openstack | Meeting 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 http://wiki.debian.org/MeetBot. | 14:11 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:11 |
| *** openstack changes topic to " (Meeting topic: openstack-cyborg)" | 14:11 | |
| openstack | The meeting name has been set to 'openstack_cyborg' | 14:11 |
| Li_Liu | Let's get started | 14:11 |
| xinran_ | #info xinran_ | 14:11 |
| Li_Liu | #topic Roll Call | 14:12 |
| *** openstack changes topic to "Roll Call (Meeting topic: openstack-cyborg)" | 14:12 | |
| Li_Liu | #info Li_Liu | 14:12 |
| wangzhh | #info wangzhh | 14:13 |
| Li_Liu | #topic status updates | 14:13 |
| *** openstack changes topic to "status updates (Meeting topic: openstack-cyborg)" | 14:13 | |
| Li_Liu | Sundar, I saw your comments. Thanks a lot | 14:13 |
| Li_Liu | I will update the the patch to address your comments | 14:14 |
| Sundar | #info Sundar | 14:14 |
| Sundar | Welcome, Li | 14:14 |
| Li_Liu | guys, please review https://review.openstack.org/#/c/615462/ | 14:14 |
| Li_Liu | if you have the change | 14:15 |
| Li_Liu | chance* | 14:15 |
| Li_Liu | Sundar, anything to report on your side? | 14:17 |
| Sundar | Li_Liu: I am proceeding with the POC. Waiting for driver OVO object patch to submit the next OPAE driver patch | 14:18 |
| Li_Liu | ok, great | 14:19 |
| Sundar | We may need to start a feature branch to host the POC. I will get back to you on that. | 14:19 |
| Li_Liu | wangzhh, how's you and Coco's part? | 14:19 |
| Li_Liu | Sundar sure thing | 14:19 |
| wangzhh | I have finished my part in my local env. I'll commit it after improve UT. | 14:21 |
| wangzhh | Sorry for I'm late. I'm very busy last two weeks... | 14:21 |
| Li_Liu | Totally understand | 14:22 |
| Li_Liu | thanks a lot for the work :) | 14:22 |
| wangzhh | NP :) | 14:22 |
| Li_Liu | xinran_ I have send you my thoughts on the conductor diff thing | 14:25 |
| Li_Liu | I suggest to keep it simple for now | 14:25 |
| xinran_ | Yes, I saw it, thanks | 14:27 |
| xinran_ | So we all have agreement on do diff and update DB/placement on the conductor? | 14:28 |
| Li_Liu | Sundar, what's your thoughts on it? | 14:28 |
| Sundar | Li_Liu: Makes sense. I agree we should keep it simple to start with. | 14:29 |
| Sundar | Do any of you see issues if we have to change the implementation later, in terms of upgrade impact? | 14:29 |
| Li_Liu | Well, even if you want to change the implementation, it should be transparent to others | 14:30 |
| Li_Liu | should not be much impact | 14:30 |
| Sundar | Sounds good. | 14:31 |
| Li_Liu | xinran_ I guess we can do it that way | 14:31 |
| Li_Liu | Great, for my self, I will finalize the spec in next couple days | 14:32 |
| Sundar | Li_Liu: Thank you | 14:32 |
| xinran_ | so every time agent discover the device, agent should call conductor to do a diff | 14:32 |
| Li_Liu | right | 14:32 |
| Sundar | xinran_ It can be batched per host --all devices go together | 14:33 |
| Sundar | May be you can always investigate some easy compression with python libraries | 14:33 |
| Sundar | s/always// | 14:34 |
| xinran_ | all device info could be gathered in a list of OVO object | 14:34 |
| Sundar | https://stackoverflow.com/questions/26618864/library-to-compress-arbitrary-data-structures-in-python | 14:34 |
| Sundar | xinran_ Yes | 14:34 |
| xinran_ | Sundar: ok, I will look at it, thanks | 14:35 |
| *** yumeng has quit IRC | 14:35 | |
| Li_Liu | alright | 14:38 |
| Li_Liu | I think we all clear on what | 14:38 |
| Li_Liu | to do next | 14:38 |
| Li_Liu | let | 14:38 |
| Li_Liu | let's wrap up | 14:39 |
| Li_Liu | Thank you guys, remember the time will change for our next irc meeting.... I will send a new date btw | 14:39 |
| Li_Liu | #endmeeting | 14:40 |
| *** openstack changes topic to "Pending patches (Meeting topic: openstack-cyborg)" | 14:40 | |
| openstack | Meeting ended Wed Dec 5 14:40:56 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:40 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-12-05-14.11.html | 14:41 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-12-05-14.11.txt | 14:41 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-12-05-14.11.log.html | 14:41 |
| *** Li_Liu has quit IRC | 14:42 | |
| efried | Sundar: Would now be a good time to talk about feature branches vs. code series and whatnot? | 15:27 |
| Sundar | efried: Sure | 15:35 |
| Sundar | Thansk for pinging back | 15:35 |
| Sundar | *Thanks | 15:35 |
| efried | Sundar: I'm composing an email which is about to turn into an epic. | 15:35 |
| efried | Here's what I'm saying about "feature branches": | 15:36 |
| efried | Huh, 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 |
| efried | Having 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 |
| efried | Sundar: Are you aware of issues on either side beyond the above? (Rebasing vs. CI) | 15:36 |
| Sundar | IMHO, 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 |
| efried | Not sure how having a feature branch will help you there. | 15:38 |
| efried | If you need to try several different things, you can submit different series | 15:39 |
| efried | and then abandon whichever one(s) aren't The Chosen One. | 15:39 |
| Sundar | On the Cyborg side, there is some reluctance to commit to upstream changes when the form of the API is itself under question. | 15:40 |
| Sundar | If the Cyborg side is sitting as a proof of concept in some side branch, Nova developers may not consider the corresponding changes? | 15:41 |
| efried | Sundar: Proposing changes to gerrit isn't locking you into anything. | 15:41 |
| efried | And (this was going to be part of my epic) you can still develop with cross-project dependencies. | 15:42 |
| Sundar | To 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 |
| Sundar | Also, 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 |
| Sundar | The only downside is that, there is no good place to keep those changes visible publicly. | 15:46 |
| Sundar | Intel 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 |
| efried | Sundar: 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 |
| efried | Sundar: Does Intel restrict that process even for proposing code to openstack projects like nova?? | 15:47 |
| Sundar | No, upstream development is fine | 15:48 |
| efried | okay, phew. | 15:48 |
| Sundar | On the Cyborg side, if I push patches on database schema etc. I would be stepping on soem toes | 15:48 |
| efried | so 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 |
| efried | Sundar: Okay, but how does a feature branch help with that? | 15:49 |
| Sundar | I 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' upstream | 15:49 |
| efried | Well, the way to upstream a feature branch would be to merge it in, not repropose the same code to the master branch. | 15:50 |
| efried | Anyway, 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 |
| Sundar | I'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 |
| Sundar | For 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 |
| Sundar | Until 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 |
| efried | The 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 |
| efried | So 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 |
| efried | Anyway, 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 |
| efried | Sundar: 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 |
| Sundar | BTW, I am open to all ideas -- I am not bullheadedly pushing for feature branches, just evaluating options. | 16:05 |
| efried | Sundar: 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 |
| Sundar | I will need help with the rebasing for sure -- I am sure it can get complicated | 16:06 |
| efried | We 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 |
| efried | Sundar: Yes, I'm happy to help with that. I'm pretty good at it :) | 16:07 |
| Sundar | Looking forward to your epic email :) | 16:07 |
| Sundar | I see options for setting workflow to -1, but not -2. Is a procedural -2 something else? | 16:08 |
| efried | Sundar: only cores can -2. | 16:11 |
| efried | The 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 |
| Sundar | efried: Yes, aware of that. I thought 'procedural' referred to 'workflow', which is a different scoring | 16:19 |
| efried | Sundar: "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 IRC | 16:49 | |
| *** helenafm has quit IRC | 17:28 | |
| *** jiapei has quit IRC | 17:52 | |
| *** jiapei has joined #openstack-cyborg | 17:53 | |
| *** Sundar has quit IRC | 17:55 | |
| *** kailun has quit IRC | 18:25 | |
| *** efried is now known as efried_out_til_j | 22:17 | |
| *** efried_out_til_j is now known as efried_cya_jan | 22:17 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!