Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-25
14:43:07 dansmith mriedem: I didn't get an e-r report on it
14:43:20 mriedem dansmith: e-r bot has been off for weeks as far as i know
14:43:25 openstackgerrit Stephen Finucane proposed openstack/os-vif stable/stein: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655678
14:43:30 aspiers efried, sean-k-mooney: and I'll add a separate review which adds the new config option and inventory of the new resource class from it
14:43:30 mriedem dansmith: i have a couple of debug patches up to try and recreate to figure out what's causing the recursion stack dump
14:43:42 dansmith mriedem: consider me shamed
14:43:50 mriedem dansmith: https://review.opendev.org/#/q/topic:bug/1825435+status:open
14:44:10 mriedem if you have ideas on that it'd be cool because so far my recreate attempts are failing
14:44:32 mriedem it seems to have started somewhere along the lines of the cells v1 removal series
14:44:40 mriedem but looking through those changes i don't see anything obvious
14:44:54 mriedem it's in both py36 (upper-constraints) and lower-constraints so it's not some specific oslo.config version either
14:45:06 efried aspiers: I haven't reviewed that patch in forever, sorry.
14:45:14 mriedem i also didn't see any python3.6 changes recently in the bionic UCA changelog
14:45:36 dansmith mriedem: ack, I heard about the recursion thing, but this is a single output message (not a very long stack trace) so I didn't connect the two
14:45:37 aspiers efried: it's drastically simpler now
14:45:59 efried aspiers: I probably won't get a chance to review patches-that-aren't-specs until after the PTG dust settles.
14:46:07 mriedem dansmith: yeah the TestRPC ... inprogress seems to be a result of the stack dump earlier in the logs
14:46:16 aspiers efried: because kashyap persuaded me to split out most of it into https://review.opendev.org/#/c/655268/
14:46:17 mriedem the former doesn't always show up when this hits, but the latter does
14:46:25 efried aspiers: sight unseen, split is good.
14:46:30 aspiers efried: ok
14:47:17 kashyap Yeah, that split is useful -- because that split-up patch, which introduces getDomainCapabilities API, can be used by many other things
14:47:56 kashyap So it can be merged as a separate piece once we iron out any remaining wrinkles.
14:48:19 kashyap Thanks for doing the split, aspiers.
14:50:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Enable n-novnc in nova-multi-cell job https://review.opendev.org/655711
14:50:52 mriedem dansmith: btw https://review.opendev.org/#/c/655222/ is passing which is pretty exciting
14:51:26 dansmith mriedem: that's cool
14:52:41 dansmith mriedem: is that intended to be voting?
14:52:47 mriedem once that lands, i can throw a patch at the end of my cross-cell-resize series to enable resize and cold migrate across the cells
14:52:51 mriedem dansmith: yes
14:52:58 dansmith are you ready for it to go in?
14:53:12 mriedem we could recheck a few times if we care and then turn it on next week
14:53:18 mriedem i can also send a heads up to the ML
14:53:24 openstackgerrit garyk proposed openstack/nova master: VMware: populate datastore refs at init https://review.opendev.org/574688
14:53:28 mriedem if we want, we can land it as non-voting check only for now
14:53:41 mriedem but i'd really like it to be voting asap since we should have had this several releases ago
14:54:32 mriedem i'll post to the ML first
14:55:51 openstackgerrit garyk proposed openstack/nova master: Improve metadata performance https://review.opendev.org/615435
14:59:37 efried mriedem: Do we start -2ing pike patches now, unless they're security or something?
14:59:47 mriedem no
14:59:47 efried (and by "we" I mean stable folk)
15:00:06 mriedem that's pre-em process
15:00:11 mriedem because there was an eol
15:00:13 openstackgerrit Adam Spiers proposed openstack/nova-specs master: Update SEV work item to new approach based on MEM_ENCRYPTION_CONTEXT https://review.opendev.org/655717
15:00:23 mriedem with em we've done away with eol unless we can't manage the branch anymore (or don't want to)
15:00:35 aspiers efried, sean-k-mooney: ^^^ minor tweak based on discussion just now
15:00:37 efried so what does em actually mean?
15:00:56 efried how is it different from just continuing to backport changes?
15:01:41 mriedem efried: https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
15:02:00 mriedem or https://superuser.openstack.org/articles/extended-maintenance-openstack/ if you like bloggy
15:02:06 sean-k-mooney efried: extended mainatince
15:03:06 efried aspiers: not quite, commented.
15:03:50 efried mriedem: ugh, I'm totally not going to read that much text right now. I'll satisfy my curiosity later.
15:04:31 mriedem mission accomplished
15:04:42 aspiers efried: OK thanks. I was thinking it could rely on the translation from hw:mem_encryption to resource class in the request filter, but checking allocations dict also sounds fine
15:05:07 efried aspiers: Remember that translation isn't being persisted, so the flavor spawn gets to look at won't have it.
15:06:21 aspiers efried: ohhhh, you mean that only happens in the scheduler, and the resulting RequestSpec doesn't get passed through to the nova-compute service?
15:06:23 efried mriedem: I've updated the nova mtg agenda
15:06:59 efried aspiers: Yes, iiuc. I could be missing something though
15:07:27 aspiers efried: that makes sense - this stuff isn't obvious to me yet since I'm still very unfamiliar with the nova codebase, so thanks for the pointers
15:07:28 efried aspiers: But IMO looking at the allocation is a cleaner solution regardless.
15:07:44 aspiers efried: yup, sounds fine to me
15:08:24 mtreinish aspiers: unfortunately I won't be at Denver. But I save that talk to watch later, at least based on the abstract it looks like they had a similar idea to what andreaf and I were starting to do in CIML (at a high level)
15:08:39 efried aspiers: If you wanted to use hw:mem_encryption=true, you would have to check both the flavor and the image. So yeah, use the allocation.
15:08:40 mtreinish but they approched it with different ML techniques (and ones that might be better suited for the problem)
15:09:20 aspiers mtreinish: cool! very interested to hear your take on the talk. BTW I noticed earlier that elastic recheck / crm114 work seems to have made some v nice progress since last time I looked
15:09:42 aspiers efried: changing the spec tweak now
15:10:06 aspiers mtreinish: sorry to miss you this time though. we'll have to sort out those stestr issues online instead ;-)
15:11:55 mtreinish aspiers: yeah it's too bad. Luckily for you though masayukig will be there and he can help sort through those in person :P
15:12:04 aspiers mtreinish: true :)
15:12:23 mtreinish aspiers: hmm, I wasn't aware anyone had done anything with the crm114 stuff in a while. But I hadn't been watching it super closely
15:13:45 aspiers mtreinish: well it's a *long* time since I last more than glanced at http://status.openstack.org/elastic-recheck/
15:14:02 aspiers mtreinish: maybe I just never noticed some of the nice stuff before
15:20:31 bauzas efried: I wasn't originally thinking to discuss about NUMA affinity for vGPUs in the PTG https://review.opendev.org/#/c/650963/ but given gibi provided some good concerns, I wondered when we could have time for eventually discussing it at the PTG
15:21:06 bauzas this isn't technically a placement-related spec, but I'd love to see it discussed then
15:21:20 openstackgerrit Adam Spiers proposed openstack/nova-specs master: Update SEV work item to new approach based on MEM_ENCRYPTION_CONTEXT https://review.opendev.org/655717
15:22:52 bauzas efried: so I proposed it for the x-proj session between nova/placement if you are okay with
15:25:45 efried bauzas: Yup, wfm. cdent is going to be organizing that chunk of time.
15:25:54 bauzas k
15:26:23 dansmith mriedem: what's your feeling on adding (i.e. requiring) tests for the virt drivers I'm adding image type flags for?
15:26:35 dansmith if there's nothing dynamic, then it's just a test to assert that two dicts match
15:27:47 mriedem thus not a very useful test, i don't have strong feelings about that
15:27:57 mriedem i'd say make sure it's mentioned in the commit message though...
15:28:38 dansmith okay
15:28:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: handle port allocation during migration https://review.opendev.org/655112
15:28:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: func test for migrate server with ports having resource request https://review.opendev.org/655113
15:28:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114
15:28:58 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add request_spec to server move RPC calls https://review.opendev.org/655721
15:29:33 efried kashyap: secure boot topic, okay if I move it to Thursday 1400?
15:30:10 jaypipes stephenfin: +2
15:30:18 kashyap efried: Thursday is the first day, right?
15:30:21 stephenfin jaypipes: \o/
15:30:21 efried yes
15:30:38 stephenfin jaypipes: Thanks for taking the time to look through that
15:30:41 kashyap efried: I might need to be elsewhere. But we've discussed it also in Dublin, and people agreed it is something we want.
15:30:56 kashyap efried: So even if I miss it, it should be OK?
15:31:06 efried kashyap: If Saturday is better, I'll leave it there. Just had an opening.
15:31:20 jaypipes stephenfin: np, that *you* for having the energy to keep it going.
15:31:51 efried kashyap: But even better, if it's something we don't need to discuss, I can just strike it.
15:31:58 kashyap efried: You know what, maybe just put it on Thurs 14:00. I'll work it out to be there

Earlier   Later