Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-28
15:53:01 efried which is a regal PITA
15:53:16 aspiers why?
15:53:26 efried but go ahead and depends-on it and we'll just get the damn thing merged and released and requirementsed
15:53:32 efried why what?
15:53:40 aspiers why would .zuul.yaml need to be hacked?
15:53:49 efried because otherwise zuul will ignore your depends-on.
15:53:56 mriedem depends-on won't pull in your os-traits change w/o changing required-projects
15:54:28 mriedem we shouldn't do that anyway imo
15:54:34 efried and we don't want to make that ^ permanent, because we generally want to test against released os-traits
15:54:36 mriedem b/c we could forget to release os-traits and bump the min required versions
15:54:39 mriedem correct
15:55:07 efried mriedem: My take is that we should be allowed to do it as long as the dep switches off as soon as it merges
15:55:45 mriedem that's putting a lot of trust into people remembering all of these knobs
15:55:46 efried that is, nova X depends on os-traits Y, so while Y is still open, X will build against it. As soon as Y merges, X goes back to testing against whatever the requirements-specified version is.
15:55:51 aspiers are the zuul folks aware of this issue?
15:55:58 mriedem aspiers: it's by design
15:56:01 efried aspiers: Yes, it's a feature, not a bug.
15:56:03 efried what mriedem said
15:56:06 mriedem it's like how LIBS_FROM_GIT worked in the old days
15:56:29 aspiers without thinking hard or having the experience of you two, it sounds like a deficiency in the design?
15:56:52 efried aspiers: I agree it would be nice if there was a (straightforward) way around it, for just this reason.
15:57:02 aspiers like mriedem says, requiring people to remember sounds like a UX bug to me
15:57:12 efried I want to make sure my nova patch will build against the os-traits I'm about to release, without having to release it first to try it.
15:57:18 efried I can test locally to some extent by hacking up my venv
15:57:26 efried but I can't e.g. test the dsvms locally.
15:57:52 efried or even run all of unit and/or functional locally without the fire department standing by.
15:58:00 aspiers is there a good reason *not* to honour Depends-On if the dependency is missing from required-projects?
15:58:05 kashyap Trying to open nova/tests/unit/virt/libvirt/test_driver.py in GitHub tells me: "(Sorry about that, but we can’t show files that are this big right now.)"
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: Remove global state from the FakeDriver https://review.opendev.org/656709
16:01:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Enhance service restart in functional env https://review.opendev.org/512552
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

Earlier   Later