| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-12-05 | |||
| 14:11:42 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 14:11:44 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 14:11:48 | Li_Liu | Let's get started | |
| 14:11:54 | xinran_ | #info xinran_ | |
| 14:12:03 | Li_Liu | #topic Roll Call | |
| 14:12:18 | Li_Liu | #info Li_Liu | |
| 14:13:19 | wangzhh | #info wangzhh | |
| 14:13:39 | Li_Liu | #topic status updates | |
| 14:13:55 | Li_Liu | Sundar, I saw your comments. Thanks a lot | |
| 14:14:20 | Li_Liu | I will update the the patch to address your comments | |
| 14:14:22 | Sundar | #info Sundar | |
| 14:14:25 | Sundar | Welcome, Li | |
| 14:14:55 | Li_Liu | guys, please review https://review.openstack.org/#/c/615462/ | |
| 14:15:00 | Li_Liu | if you have the change | |
| 14:15:08 | Li_Liu | chance* | |
| 14:17:28 | Li_Liu | Sundar, anything to report on your side? | |
| 14:18:25 | Sundar | Li_Liu: I am proceeding with the POC. Waiting for driver OVO object patch to submit the next OPAE driver patch | |
| 14:19:06 | Li_Liu | ok, great | |
| 14:19:26 | Sundar | We may need to start a feature branch to host the POC. I will get back to you on that. | |
| 14:19:32 | Li_Liu | wangzhh, how's you and Coco's part? | |
| 14:19:46 | Li_Liu | Sundar sure thing | |
| 14:21:01 | wangzhh | I have finished my part in my local env. I'll commit it after improve UT. | |
| 14:21:55 | wangzhh | Sorry for I'm late. I'm very busy last two weeks... | |
| 14:22:08 | Li_Liu | Totally understand | |
| 14:22:18 | Li_Liu | thanks a lot for the work :) | |
| 14:22:30 | wangzhh | NP :) | |
| 14:25:41 | Li_Liu | xinran_ I have send you my thoughts on the conductor diff thing | |
| 14:25:53 | Li_Liu | I suggest to keep it simple for now | |
| 14:27:17 | xinran_ | Yes, I saw it, thanks | |
| 14:28:01 | xinran_ | So we all have agreement on do diff and update DB/placement on the conductor? | |
| 14:28:20 | Li_Liu | Sundar, what's your thoughts on it? | |
| 14:29:10 | Sundar | Li_Liu: Makes sense. I agree we should keep it simple to start with. | |
| 14:29:41 | Sundar | Do any of you see issues if we have to change the implementation later, in terms of upgrade impact? | |
| 14:30:22 | Li_Liu | Well, even if you want to change the implementation, it should be transparent to others | |
| 14:30:36 | Li_Liu | should not be much impact | |
| 14:31:14 | Sundar | Sounds good. | |
| 14:31:22 | Li_Liu | xinran_ I guess we can do it that way | |
| 14:32:19 | Li_Liu | Great, for my self, I will finalize the spec in next couple days | |
| 14:32:41 | xinran_ | so every time agent discover the device, agent should call conductor to do a diff | |
| 14:32:41 | Sundar | Li_Liu: Thank you | |
| 14:32:49 | Li_Liu | right | |
| 14:33:06 | Sundar | xinran_ It can be batched per host --all devices go together | |
| 14:33:30 | Sundar | May be you can always investigate some easy compression with python libraries | |
| 14:34:24 | Sundar | s/always// | |
| 14:34:25 | xinran_ | all device info could be gathered in a list of OVO object | |
| 14:34:27 | Sundar | https://stackoverflow.com/questions/26618864/library-to-compress-arbitrary-data-structures-in-python | |
| 14:34:47 | Sundar | xinran_ Yes | |
| 14:35:08 | xinran_ | Sundar: ok, I will look at it, thanks | |
| 14:38:26 | Li_Liu | alright | |
| 14:38:43 | Li_Liu | I think we all clear on what | |
| 14:38:46 | Li_Liu | to do next | |
| 14:38:53 | Li_Liu | let | |
| 14:39:03 | Li_Liu | let's wrap up | |
| 14:39:53 | Li_Liu | Thank you guys, remember the time will change for our next irc meeting.... I will send a new date btw | |
| 14:40:56 | Li_Liu | #endmeeting | |
| 14:40:59 | 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:41:00 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-12-05-14.11.html | |
| 14:41:01 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-12-05-14.11.txt | |
| 14:41:02 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-12-05-14.11.log.html | |
| 15:27:09 | efried | Sundar: Would now be a good time to talk about feature branches vs. code series and whatnot? | |
| 15:35:29 | Sundar | efried: Sure | |
| 15:35:39 | Sundar | Thansk for pinging back | |
| 15:35:45 | Sundar | *Thanks | |
| 15:35:54 | efried | Sundar: I'm composing an email which is about to turn into an epic. | |
| 15:36:12 | efried | Here's what I'm saying about "feature branches": | |
| 15:36:16 | 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:25 | 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:50 | efried | Sundar: Are you aware of issues on either side beyond the above? (Rebasing vs. CI) | |
| 15:38:23 | 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:46 | efried | Not sure how having a feature branch will help you there. | |
| 15:39:02 | efried | If you need to try several different things, you can submit different series | |
| 15:39:13 | efried | and then abandon whichever one(s) aren't The Chosen One. | |
| 15:40:41 | 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:41:21 | 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:45 | efried | Sundar: Proposing changes to gerrit isn't locking you into anything. | |
| 15:42:11 | efried | And (this was going to be part of my epic) you can still develop with cross-project dependencies. | |
| 15:44:48 | 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:45:34 | 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:46:11 | Sundar | The only downside is that, there is no good place to keep those changes visible publicly. | |
| 15:47:09 | 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:18 | 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:42 | efried | Sundar: Does Intel restrict that process even for proposing code to openstack projects like nova?? | |
| 15:48:00 | Sundar | No, upstream development is fine | |
| 15:48:23 | efried | okay, phew. | |
| 15:48:46 | Sundar | On the Cyborg side, if I push patches on database schema etc. I would be stepping on soem toes | |
| 15:48:49 | 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:49:03 | efried | Sundar: Okay, but how does a feature branch help with that? | |
| 15:49:52 | 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:50:58 | 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:52:37 | 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:39 | 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:53:25 | 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:55:30 | Sundar | Until we get the broad outlines agreed upon, focusing on the details will be distracting. | |
| 15:57:41 | 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:41 | 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:41 | 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:59:52 | 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). | |
| 16:00:43 | 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:03:44 | efried | Anyway, I think we've reached (probably passed) the border of explanation vs action here. Neither way is going to kill you. | |
| 16:04:31 | Sundar | "nobody is going to care about CI' -- Nova developers have given -1 on typos. Are you sure they will ignore CI results? | |