| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-12-05 | |||
| 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 | |
| 10:22:09 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: let conductor to update DB and placement https://review.openstack.org/624340 | |
| #openstack-cyborg - 2018-12-12 | |||
| 02:02:21 | Coco_gao | Hi all | |
| 02:04:18 | Yumeng_ | hi | |
| 02:04:45 | Coco_gao | Good morning, Yumeng | |
| 02:07:00 | Yumeng_ | morning coco, about this story https://storyboard.openstack.org/#!/story/2004248 | |
| 02:07:57 | Yumeng_ | Could you email this doc to me? https://docs.google.com/document/d/1XLQtvyGJeEgo3ztBQiufWLF-E7S7yGLaYrme8iUPtA0/edit#heading=h.dllo7olmuhb | |
| 02:10:54 | Yumeng_ | I cannot access to this in my company :((((( | |
| 02:11:54 | Coco_gao | done | |
| 02:15:07 | Yumeng_ | cool got! | |
| 02:20:15 | Yumeng_ | coco, Among all these tasks in this story https://storyboard.openstack.org/#!/story/2004248 which task do you think should be the next one to be implemented? | |
| 02:24:28 | Coco_gao | This will be implemented together. | |
| 02:25:20 | Coco_gao | If you have time, maybe you can join Sundar for the cyborg client. | |
| 02:27:11 | Coco_gao | The remaining tasks in the list may owned by zhenghao. | |
| 02:27:35 | Coco_gao | Or, you can talk with him. | |
| 02:33:01 | Yumeng_ | ok, no pb. if he was busy I can help | |
| 02:41:21 | Coco_gao | By the way, what's new time for the IRC meeting? | |
| 02:47:56 | Yumeng_ | haha 11:00 | |
| 02:49:37 | Yumeng_ | I also thought it was 10:00. | |
| 03:01:19 | Li_Liu | Hi Sundar | |
| 03:01:26 | Sundar | Hi Li | |
| 03:01:27 | Li_Liu | Let's wait for others | |
| 03:01:31 | Sundar | Sure | |
| 03:02:32 | Li_Liu | maybe wait for another 3 mins | |
| 03:02:55 | Yumeng_ | hi Sundar Li :) | |
| 03:03:11 | Li_Liu | Hi Yumeng :) | |
| 03:04:04 | jiapei | o/ | |
| 03:04:43 | xinranwang | Hi all | |
| 03:04:54 | Sundar | Hi Yumeng_ and all | |
| 03:05:38 | Li_Liu | #startmeeting openstack-cyborg | |
| 03:05:39 | openstack | Meeting started Wed Dec 12 03:05:38 2018 UTC and is due to finish in 60 minutes. The chair is Li_Liu. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 03:05:40 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 03:05:42 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 03:05:48 | Li_Liu | #topic Roll Call | |
| 03:05:56 | Li_Liu | #info Li_Liu | |
| 03:06:03 | Li_Liu | Let's get started | |
| 03:06:10 | xinranwang | #info xinranwang | |
| 03:06:14 | Sundar | #info Sundar | |
| 03:06:20 | Li_Liu | I hope the new time slot works better for most of the people | |
| 03:07:08 | Li_Liu | #topic status updates | |
| 03:07:23 | Yumeng_ | # info Yumeng_ | |
| 03:07:30 | Li_Liu | Sundar, what's new on your side? | |
| 03:08:35 | Sundar | The feature branches for CYborg and its client have been created. Will be submitting code for a prorotype that shows how Nova could call into CYborg | |
| 03:09:13 | Li_Liu | that's great. So would help push the Nova-Cyborg interaction spec right? | |
| 03:09:16 | Sundar | This is intended to show developers how the interaction in the spec will play out in practice | |
| 03:09:22 | Sundar | I hope so :) | |
| 03:10:06 | Li_Liu | Once created, let's find some time to talk with Nova folks directly | |
| 03:10:11 | Li_Liu | let's push together | |
| 03:10:42 | Li_Liu | xinrangwang, anything you wanna share? | |
| 03:10:55 | Sundar | I also need to develop and push the Nova patches that do the actual invocation | |
| 03:10:56 | Li_Liu | https://review.openstack.org/#/c/624340/ | |
| 03:11:44 | Li_Liu | xinranwang, is that one ready to be reviewed? | |
| 03:12:24 | Li_Liu | Sundar, maybe we can show them how it should work first? | |
| 03:12:26 | xinranwang | Li_Liu: nope, it depends on the DB schemas the ovo object | |
| 03:13:03 | xinranwang | it's just the initial version | |
| 03:13:31 | Li_Liu | xinranwang, the spec should be ready anytime, does it also depends on Coco/zhenghao's work? | |
| 03:14:39 | Sundar | Li_Liu: Yes, the pilot code for Cyborg and its client will be submitted first. | |
| 03:15:16 | Li_Liu | great | |
| 03:16:24 | xinranwang | yes, because the input param for conductor is ovo object | |
| 03:16:41 | Li_Liu | Sundar, I think https://review.openstack.org/#/c/615462/ can be merged | |
| 03:17:03 | Li_Liu | xinranwang, ok\ | |