Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-28
15:58:44 kashyap ["But we can render lots of crap that clutters your view"]
15:59:01 efried aspiers: Point is, Depends-On will normally build against the dep, but block your patch from merging until the dep merges. If we allowed your patch to merge once the dep merges, world breaks because nova is still building against released os-traits and your os-traits patch hasn't been released yet.
15:59:27 mriedem aspiers: this is not a new problem, this is how things have always worked for depending on library changes
15:59:49 aspiers mriedem: OK thanks
15:59:53 mriedem which is why i -1 changes that depend on the library change directly rather than the upper-constraints bump for whatever released version of the library contains that change
16:00:13 mriedem you can test the things in the gate with the required-projects hack
16:01:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: cleanup evacuated instances not on hypervisor https://review.opendev.org/512623
16:01:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Enhance service restart in functional env https://review.opendev.org/512552
16:01:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove global state from the FakeDriver https://review.opendev.org/656709
16:01:17 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add functional test coverage for bug 1724172 https://review.opendev.org/512553
16:01:18 openstack bug 1724172 in OpenStack Compute (nova) "Allocation of an evacuated instance is not cleaned on the source host if instance is not defined on the hypervisor" [Medium,In progress] https://launchpad.net/bugs/1724172 - Assigned to Balazs Gibizer (balazs-gibizer)
16:01:20 aspiers kashyap: see also https://github.com/isaacs/github/issues/587
16:01:30 mriedem bauzas: you may enjoy https://bugs.launchpad.net/nova/+bug/1830747
16:01:31 openstack Launchpad bug 1830747 in OpenStack Compute (nova) "Error 500 trying to migrate an instance after wrong request_spec" [High,In progress] - Assigned to Matt Riedemann (mriedem)
16:02:45 kashyap aspiers: Ah, thanks
16:02:55 kashyap aspiers: It is the Website Obesity problem: https://idlewords.com/talks/website_obesity.htm
16:02:57 aspiers kashyap: although that's for diffs
16:03:10 gibi lyarwood: made it backportable as we discussed https://review.opendev.org/#/c/512623
16:03:59 aspiers kashyap: "I contend that text-based websites should not exceed in size the major works of Russian literature." ROFL
16:04:18 kashyap aspiers: Indeed!
16:05:30 aspiers This page is amazing. "In a misguided attempt at cultural sensitivity, I have chosen to represent the consumer with a kangaroo."
16:05:40 kashyap aspiers: I appreciate websites like npr.org (although, I only rarely read it) that provide plain text websites, without all the bloat that is, JavaScript and the advertizing bat shit
16:06:09 kashyap aspiers: Yeah, it's a very well-written article.
16:07:03 aspiers I might have to watch the video
16:12:04 mriedem gibi: i'll re-review your spec quick if you can review this quick https://review.opendev.org/#/c/661398/
16:12:17 mriedem *not if, just pelase
16:12:18 mriedem *please
16:18:48 mriedem gibi: a few nits in your spec if you can respin quick, but you might be done already
16:18:54 mriedem if so i can address those quick and +2
16:23:46 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Server move operations with ports having resource request https://review.opendev.org/652608
16:46:24 cdent cfriesen: you might have thoughts on the discussion that starts near http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-05-28.log.html#t2019-05-28T16:20:51
16:46:40 cfriesen looking
16:47:35 cdent cfriesen: the spec in question is https://review.opendev.org/658510
16:48:15 cfriesen cdent: there is a flaw in the current handling of 4K pages which means that you can't mix numa and non-numa instances using 4k pages on the same host.
16:55:11 cdent cfriesen: if you've got a chance to dig at that spec that would be great. i've got to take off for today
16:55:12 openstackgerrit Adam Spiers proposed openstack/nova master: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680
16:56:38 cfriesen cdent: will try. I left a comment elaborating a bit on the 4k page thing
16:56:47 cdent thanks
16:57:08 aspiers efried, mriedem: https://review.opendev.org/#/c/638680/16 temporarily adds os-traits to .zuul.yaml. I've put W-1 since IIUC we don't want to merge it like that.
16:57:22 aspiers kashyap: I guess you should be aware too ^^^
16:59:16 aspiers mriedem: you want the comment inline, or in the commit message?
16:59:59 aspiers would be nice if there was a magic string in commit messages which prevented zuul from merging
17:00:31 mriedem aspiers: i have a magic -2
17:00:35 mriedem aspiers: inline
17:00:47 mriedem and prefix your commit title with WIP:
17:00:55 mriedem so -W isn't lost between rebases
17:00:59 aspiers OK
17:01:20 aspiers IIRC, -2 is sticky across patchsets and has to be explicitly removed?
17:01:34 aspiers would be good if mortals could achieve something equivalent
17:01:46 aspiers I'm suggesting it in #zuul
17:04:15 aspiers probably more of a Gerrit thing actually
17:06:05 openstackgerrit Adam Spiers proposed openstack/nova master: WIP: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680
17:19:28 openstackgerrit Adam Spiers proposed openstack/nova master: WIP: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680
17:25:20 efried aspiers: I'm pretty confused about the rebasing state of all your patches.
17:25:32 aspiers efried: how can I help with that?
17:25:45 efried are you working on rebasing all of them to be in one chain?
17:25:57 aspiers only where necessary
17:26:38 aspiers my goals, in decreasing order, are: 1) correctness, 2) ease of review, 3) minimise churn on CI resources
17:27:33 aspiers it did recently occur to me that I could (theoretically, in a parallel universe where time is unconstrained) teach git-review to automatically rebase as necessary by using my git-deps module
17:29:12 efried what I mean is, for example, https://review.opendev.org/#/c/661782/2 is based on https://review.opendev.org/#/c/661266/3 when PS4 is available (and merging). And then https://review.opendev.org/#/c/638680/18 is based on https://review.opendev.org/#/c/661782/2, but https://review.opendev.org/#/c/636334/5 is based on https://review.opendev.org/#/c/638680/14
17:30:32 aspiers efried: that's because I forgot that you submitted PS4
17:30:50 aspiers efried: I just based it on the latest PS I had locally, without thinking
17:30:52 efried okay, my fault on that one
17:30:59 aspiers haha, hardly :)
17:31:18 aspiers but I'll generously share some of the blame with you if you insist ;)
17:31:37 efried anyway, as a reviewer I'm basically too confused to jump in atm
17:31:49 aspiers looking at the other ones now
17:31:50 efried which is fine, I have lots to keep me busy, not like I'm sitting on my hands waiting for this to be ready.
17:32:15 efried just want you to be aware that I'm likely to wait until there's no orange dots or green tildes on the right before I dig in.
17:32:25 spatel sean-k-mooney: hey
17:32:38 efried aspiers: (are you aware of the meaning of the orange dots and green tildes?)
17:32:41 aspiers OK, so essentially you want me to ditch my third goal? which is totally fine by me
17:32:46 aspiers yep, I had figured that out
17:33:41 aspiers I can understand the desire to eliminate orange dots. Why do you want to avoid green tildes though?
17:34:03 efried aspiers: well, I may be telling you that you may be reversing goals 2 and 3 :) at least from my pov
17:34:27 aspiers ACK, just trying to understand the cause of the confusion
17:34:29 efried because it means that those patches are based on older versions of these
17:34:43 efried it's usually a signal that you're still in the process of rebasing and cleaning things up.
17:34:56 aspiers ... which in the third example you listed is true
17:35:10 efried which is reinforced by having just WIP'd one near the bottom
17:35:20 efried anyway, again, I'm not trying to hurry you along.
17:35:29 aspiers I don't mind being hurried :)
17:35:56 efried just wanted to confirm that you're still shuffling the paperwork, as opposed to thinking you're ready for reviews and then getting frustrated when they don't happen
17:36:21 aspiers Well, this is a very useful discussion
17:37:18 aspiers It highlights that the unavoidable impact of deciding not to review anything within a given topic until all tildes and dots are gone, is that every time I need to change something minor lower in the dependency tree, I have to rebase every single thing above it before the new patchset gets reviewed
17:37:40 aspiers To me this highlights a failure in Gerrit's UI
17:38:17 efried or a failure in my method of working.
17:38:20 aspiers Ideally reviews would only be blocked if stale stuff is *below* them, not above
17:38:28 efried "blocked" is a bit strong
17:39:11 efried It's just the typical workflow I see (and use) is, when something needs to be fixed on a lower patch, download the whole series, git restack, fix the issues below, which automatically rebases the rest of the way up, and resubmit the whole series.
17:39:17 efried Agree that consumes a lot of CI resources
17:39:37 efried but it also ensures that the top changes will legitimately work with however the lower changes have been altered.
17:39:48 aspiers Sure
17:39:57 aspiers I'm not saying I want to avoid rebasing things
17:40:25 aspiers Just wondering if the presence of WIP higher up the tree should have an impact on stuff lower in the tree
17:41:16 aspiers If I understand the Gerrit UI correctly, we're talking about whether a patch in the Related Changes list has dots or tildes *below* it, right?
17:42:07 efried I'm not sure it's possible to have tildes below or dots above.
17:42:29 efried ...unless you're looking at a PS that itself has a dot
17:42:29 efried I mean, technically possible, but you would really have to be trying.
17:42:29 aspiers Oh, good point

Earlier   Later