Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2018-12-05
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?
16:04:43 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:05:11 Sundar BTW, I am open to all ideas -- I am not bullheadedly pushing for feature branches, just evaluating options.
16:05:36 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:06:47 Sundar I will need help with the rebasing for sure -- I am sure it can get complicated
16:06:51 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:07:02 efried Sundar: Yes, I'm happy to help with that. I'm pretty good at it :)
16:07:26 Sundar Looking forward to your epic email :)
16:08:55 Sundar I see options for setting workflow to -1, but not -2. Is a procedural -2 something else?
16:11:01 efried Sundar: only cores can -2.
16:13:30 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:38 efried (except rebases)
16:19:06 Sundar efried: Yes, aware of that. I thought 'procedural' referred to 'workflow', which is a different scoring
16:26:37 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."
#openstack-cyborg - 2018-12-06
05:06:38 openstackgerrit Li Liu proposed openstack/cyborg-specs master: Added initial draft for new DB model https://review.openstack.org/615462
#openstack-cyborg - 2018-12-07
10:11:09 openstackgerrit Xinran WANG proposed openstack/cyborg master: agent report resources status and attributes https://review.openstack.org/623437
10:11:10 openstackgerrit Xinran WANG proposed openstack/cyborg master: support lookup afu name by id and support afu id config https://review.openstack.org/623439
10:11:10 openstackgerrit Xinran WANG proposed openstack/cyborg master: api support allocation https://review.openstack.org/623438
10:11:11 openstackgerrit Xinran WANG proposed openstack/cyborg master: Add nova part patch which allow Nova to interact with Cyborg https://review.openstack.org/623441
10:11:11 openstackgerrit Xinran WANG proposed openstack/cyborg master: do not report pf is not assignable https://review.openstack.org/623440
#openstack-cyborg - 2018-12-10
09:34:59 openstackgerrit wangzhh proposed openstack/cyborg master: Add "Report device data to cyborg" https://review.openstack.org/596691
17:34:46 openstackgerrit coco-Gao proposed openstack/cyborg master: Add New Driver OVO Driver OVO is used for drivers to report to agent. It contains the layered objects as well as the functions in order to operate the DB. The design of driver OVO is reference to: https://docs.google.com/document/d/1XLQtvyGJeEgo3ztBQiufWL https://review.openstack.org/624138
17:35:55 openstackgerrit coco-Gao proposed openstack/cyborg master: Add New Driver OVO Driver OVO is used for drivers to report to agent. It contains the layered objects as well as the functions in order to operate the DB. The design of driver OVO is reference to: https://docs.google.com/document/d/1XLQtvyGJeEgo3ztBQiufWL https://review.openstack.org/624138
17:36:39 openstackgerrit coco-Gao proposed openstack/cyborg master: Add New Driver OVO. https://review.openstack.org/624138
#openstack-cyborg - 2018-12-11
02:09:30 openstackgerrit wangzhh proposed openstack/cyborg master: Add "Report device data to cyborg" https://review.openstack.org/596691
03:54:01 openstackgerrit Li Liu proposed openstack/cyborg-specs master: Added initial draft for new DB model https://review.openstack.org/615462

Earlier   Later