Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-30
18:51:17 dansmith oh, I have something on my calendar that covers it up so I wasn't paying attention
18:51:23 dansmith so yeah, cancel if we can
18:51:26 dansmith we just talked last week anyway
18:51:48 melwitt +1
18:53:28 mriedem don't need to have a meeting, but tssurya has 2 bug fixes that i'm +2 on which you should probably look at
18:53:38 melwitt k
18:53:41 dansmith links
18:53:52 mriedem https://review.openstack.org/#/c/568271/ and https://review.openstack.org/#/c/567878/
18:54:32 dansmith I'll get the second
18:54:38 dansmith since online migration
18:54:56 melwitt k
19:05:41 mriedem dansmith: we have backported online data migrations to fix bugs before https://review.openstack.org/#/c/408725/
19:06:41 dansmith okay, probably want to do a special reno with it though right? so people (if paying attention) will know to re-run them
19:08:26 mriedem yeah i think so,
19:08:35 mriedem https://review.openstack.org/#/c/529389/ was similar but not as explicit,
19:09:01 mriedem the idea just being, if we can get the fix into the stable branches before people roll up to them, then great, else we tried
19:09:17 dansmith sure, that's a fair point
19:09:44 dansmith anyway, wasn't saying we couldn't or shouldn't, just that we should highlight it
19:09:45 mriedem should we put a simple 'fixes' reno on that patch now before backports?
19:09:57 mriedem then we don't need to make it weird on stable
19:10:26 dansmith I think a dedicated reno for the backports will make it more clear, right? "If you are applying this update after already being on the current release, you'll need to re-run online migrations" or something
19:11:21 mriedem sure that works for me as well
19:11:24 dansmith if people see that it's fixed in the stable they're running, but it's still broken for them and they don't realize they would need to re-run online migrations at a peri-release boundary they might be confused
19:12:20 mriedem i'll push the backport to queens once i get done with reviewing sahid's trusted vf series again
19:19:57 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514
19:19:58 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: add vf_trusted field for network metadata https://review.openstack.org/566343
19:19:59 openstackgerrit Matt Riedemann proposed openstack/nova master: metadata: add vf_trusted field to device metadata https://review.openstack.org/566344
19:20:00 openstackgerrit Matt Riedemann proposed openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820
19:44:29 efried jaypipes: Done. mriedem: I'm +2 on https://review.openstack.org/#/c/553597/ now.
19:46:40 mriedem artom: you might want to take a quick run through this https://review.openstack.org/#/c/566344/
19:46:47 mriedem efried: ok
19:47:38 mriedem "Snarklepuss is actually my middle name, not my surname." blows my mind
19:47:52 mriedem that's professional snark at a PhD level
19:48:25 artom mriedem, indeed, thanks for motivating me
19:48:38 artom That series has been sitting on my review list since forever
19:49:15 mriedem artom: besides that one patch i'm +2 on the rest
19:49:30 mriedem artom: if you're so inclined, you could even address my comments in that one and we could get the entire thing +2ed today
19:49:50 artom mriedem, not a bad idea, sahid's done for the day anyways
19:50:04 artom I don't think he'll mind
19:50:28 artom Will we lose all your +2s if I push/rebaes tho?
19:50:29 mriedem i've been addressing my own nits to keep it going
19:50:31 mriedem so yeah he won't mind
19:50:34 mriedem no
19:50:41 artom "rebaes"
19:50:52 mriedem if you rebase like you spell, we might have problems
19:50:53 artom When you come back to your bae
19:51:03 tssurya mriedem, dansmith: thanks for the reviews, I just got back from a (2 weeks long) vacation and also don't have anything for the meeting. Will catch up on the summit stuff from tomorrow.
19:51:16 dansmith tssurya: cool
19:51:41 mriedem tssurya: rest assured we talked you up big time to belmiro and tim in vancouver
19:51:56 tssurya mriedem: haha thanks a ton!!
19:52:42 mriedem artom: just: git review -d 458820 && git rebase -i HEAD~2
19:52:52 mriedem fix the one, then git rebase --continue && git review -R -y
19:53:29 artom Ah, yeah, rebasing on the one below it instead of master isn't a bad idea
19:53:35 artom Tiny bit patronizing tho ;)
19:54:08 mriedem right don't rebase on master
19:54:15 mriedem that makes the diffs between patches hard to follow
19:54:38 mriedem i only rebase on master if i have a merge conflict
19:54:59 artom At some point, someone somewhere will make a diff of diffs tool
19:55:08 artom I remember Diana talking about it before she left Red hat
19:55:17 dansmith git review can do that for ou
19:55:21 mriedem tonyb probably already has one
19:55:39 artom dansmith, yeah? Will need to look into that
19:55:44 dansmith git review -m XXX,4,5
19:56:03 mriedem i'm currently explaining the difference, over text message, between bratwurst, kielbasa and summer sausage
19:56:10 mriedem and can't tell if it's some cruel joke
19:56:29 dansmith git review can't do that
19:56:48 dansmith git review will do anything for love, but it won't ... doo... thaaat.
19:56:51 mriedem git review --sausage-index
19:56:54 dansmith hah
19:57:24 dansmith I think you just did
19:57:38 artom So meta
20:01:03 artom mriedem, so is 'vf_trusted' always going to show in device metadata from now on? And set to True/False?
20:01:22 artom Or it'll only appear if the VF is trusted?
20:01:31 artom (Yeah, I could read, but... :/ )
20:01:44 mriedem he's always putting it in,
20:01:50 mriedem default to False for old devices, which is correct
20:02:04 mriedem the new field shows up if the requested version on the metadata api is new enough
20:02:07 artom I'm cool with whatever, just wanted to be sure
20:02:32 mriedem i tend to like adding new fields like we do in the compute rest api, which is we add the new field always, we don't expose it conditionally based on it's value
20:02:50 dansmith definitely
20:03:10 dansmith not all languages have a __contains__ type operator, which makes checking for the presence before the value annoying
20:09:40 mriedem efried: jaypipes: +W on the mirror patch
20:09:53 efried süsse
20:18:31 openstackgerrit Matt Riedemann proposed openstack/nova master: Skip ServerShowV254Test.test_rebuild_server in cells v1 job https://review.openstack.org/569454
20:21:56 artom mriedem, https://review.openstack.org/#/c/566344/7/nova/tests/unit/test_metadata.py@244
20:22:52 artom we need to include it though, no? We're asserting that the metadata will be equal to those dicts we define, so we need to add vf_trusted=False because we expect the code to generate that
20:23:36 mriedem oh is that the thing we're asserting against in the response?
20:23:39 mriedem if so, then sure
20:23:42 mriedem it wasn't obvious
20:24:04 artom Yeah, it's giving me a headache too
20:24:26 mriedem without reading it yet, is it fair to say the ML thread on review nit picking has itself succumbed to nit picking?
20:25:11 artom Duh
20:25:28 artom Really accessible topic, easy visibility points
20:25:32 artom Even *I* contributed
20:45:05 artom mriedem, need to relocate home (via daycare) will try to finish the metadata thing tonight
20:45:14 artom You east or west coast?
20:45:21 artom (Locality-wise, not rap)
20:45:44 artom Though I guess we already have your +2, it's jaypipes or whoever else we need to care about
20:46:28 jaypipes artom: hmm?
20:47:19 artom jaypipes, oh, apologies, for some reason I was sure mriedem roped you into reviewing https://review.openstack.org/#/q/topic:bp/sriov-trusted-vfs+(status:open+OR+status:merged)

Earlier   Later