Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-16
15:42:24 artom No, you're right, only attach
15:42:43 mriedem i saw attach volume and then the two places where we build a config drive
15:42:43 artom But I think we rebuild the whole metadata when we attach any device
15:42:45 mriedem spawn and resize
15:43:11 mriedem yeah looks like it
15:43:17 mriedem re rebuild the whole metadata
15:45:09 artom mriedem, we're talking about https://review.openstack.org/#/c/616777/8/nova/compute/utils.py, right?
15:45:39 artom I'm still parsing it, but... does it only apply the new naming scheme to newly attached/booted-with bdms?
15:45:56 mriedem artom: yeah
15:46:09 mriedem yeah in that is the patch i'm talking about
15:46:24 mriedem i don't know about the latter, that's what i'm wondering
15:46:32 artom So then I don't think that's a problem? Because while the scheme changes, the device name will still be consistent between the libvirt XML and the bdm object in the db
15:46:37 artom Which is what we care about
15:47:07 mriedem for libvirt this is really the code that matters, not compute.utils https://review.openstack.org/#/c/616777/8/nova/virt/libvirt/blockinfo.py
15:47:14 mriedem since libvirt is special and has it's own device naming thing
15:48:47 artom mriedem, as long as that bit happen before the XML is generated, it shouldn't be a problem
15:49:31 mriedem once the bdm.device_name is originally set, i also don't think it will change. _prep_block_device in the compute manager calls _add_missing_dev_names but that noops if a bdm already has a device_name set
15:50:06 artom mriedem, well, if we want to really be sure, could we add some tagged devices to rally tests?
15:50:42 artom Or grenade? What's the thing that does upgrades in the gate?
15:51:36 dansmith heh
15:51:39 dansmith grenade
15:51:42 dansmith oopsie
15:51:59 dansmith guess I never dropped my cape
15:53:29 mriedem artom: grenade does attach a volume on the old side before the upgrade, but it doesn't tag it - and even if it did, to verify the guest can read the tag properly on the new side (via tempest) would require running a test that does that ssh into the guest, which wouldn't be a "smoke" test and those are the only kinds of tests that grenade jobs run
15:53:31 mriedem plus,
15:53:46 mriedem the chances of the device name changing when you only have one volume attached is pretty slim
15:53:55 mriedem since i think it'd just be vda or vdb in that case
15:54:30 mriedem anyway, if the root answer is "the device naming schema is unchanged, but fixed to allow more than 26 names" then i tihnk we're ok
15:54:36 mriedem i.e. consistent naming schema, but unbounded
15:54:56 mriedem i think that's what the commit message in https://review.openstack.org/#/c/573066/ is saying
15:55:01 dansmith mriedem: just ensure the first 26 are the same pattern after the change, right?
15:55:12 dansmith only the 27th should be different and then you're probably fine yeah?
15:55:30 artom mriedem, I thought the question was "does the new schema retroactively get applied to existing devices?"
15:56:10 mriedem i think the real question is, why am i worrying about this and wasting my time on it
15:56:40 artom And actually not even that - "does the new schema retroactively get applied to *only* the database or *only* the XML?"
15:57:16 artom mriedem, when experiencing bouts of existential nihilism I usually turn to alcohol
15:57:30 mriedem if anything it would be only the xml
15:57:37 mriedem pretty sure we don't change bdm device_name once set
15:57:48 mriedem b/c that hoses up some db constraints and stuff we passed to cinder during the attach
15:58:07 artom Err, then we actually might have a problem :(
15:58:45 mriedem like dan said, if the old pattern and new pattern are the same for the first 26 then we're fine
15:59:33 artom Yeah, screw those people with more than 26 disks, what were they thinking anyways
15:59:54 sean-k-mooney artom: you could not have more then 26 disks before
16:00:09 artom sean-k-mooney, ohhhh, hah!
16:00:12 artom Yeah, we're fine then
16:00:56 artom And maybe mriedem's right, fix that bug if/when it comes up
16:01:09 artom Seems like a pretty edgy case
16:01:27 artom (So maybe get dansmith to fix it </internal red hat joke>)
16:02:09 artom Not my fault you've shacked up with 1/4 U2
16:03:05 mriedem i think it's fine, i ran the old scheme and the new scheme over 26 in a loop and it's the same,
16:03:07 mriedem just a-z
16:03:51 mriedem the edge is a generational ground breaking guitarist for the greatest band out of ireland and dansmith is at no fault for following them on tour
16:04:08 dansmith oh the jokes are endless
16:04:15 mriedem https://www.youtube.com/watch?v=UJXqnYCWW7Y
16:04:32 dansmith as are the "how southpark has already modeled this bit of reality" quotes from mriedem
16:05:07 mriedem hey the show has been on a long time
16:05:41 artom Pretty soon they'll run out of reality and have to start making their own
16:05:48 artom Ooohhh, is that how the matrix started?
16:13:44 mriedem maciejjozefczyk: one question in https://review.openstack.org/#/c/591607/
16:17:30 kashyap mriedem: While linking I feel the itch to clean up necessary misinfomration, missing details
16:17:42 mriedem kashyap: scratch that itch in a separate change
16:18:16 kashyap mriedem: It's a small, one-sentence related addition in the "block migration" section.
16:18:35 maciejjozefczyk mriedem: checking
16:18:40 kashyap (But don't worry, I'm with your implicit point: "one logical change per commit".)
16:21:21 maciejjozefczyk mriedem: the same as you already noticed, could be a set and if - needs to changed globally
16:23:12 mriedem maciejjozefczyk: ack
16:32:29 mriedem stephenfin: jaypipes: looks like the max_count limit isn't being honored in this online data migration https://review.openstack.org/#/c/614167/
16:32:33 mriedem i mean it is, but per cell
16:33:23 mriedem so cern could end up migrating 1K+ instances across 70+ cells even though the default max limit is 50
16:46:20 melwitt cdent, edleafe: your API SIGgy opinions are wanted on this change where we're talking about a status code of 403 vs 409 for a TooManyDiskDevices attached error https://review.openstack.org/#/c/616777/8//COMMIT_MSG@14
16:46:42 cdent looking
16:46:43 edleafe melwitt: ack. In meeting hell today, but will get to it soon.
16:46:55 melwitt thanks y'all
16:58:24 cdent melwitt: responded, probably not super helpfully as I can't decide
16:59:11 melwitt cdent: cool, thank you
17:01:23 kashyap (Goes to make a TODO to clearly defin it, and then consistently use it across the board.)
17:01:43 openstackgerrit Merged openstack/nova master: docs: Secure live migration with QEMU-native TLS https://review.openstack.org/629627
17:04:23 yan0s Hi all, I have a question about quota classes
17:04:34 yan0s how do I associate them with a user?
17:10:30 openstackgerrit Adrian Chiris proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120
17:10:30 openstackgerrit Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
17:10:31 openstackgerrit Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
17:10:31 openstackgerrit Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
17:15:14 stephenfin melwitt: Think this is something that could be put through? https://review.openstack.org/#/c/608279/
17:18:30 stephenfin sean-k-mooney: Guess this should be looked at? https://review.openstack.org/#/c/629025/
17:19:29 sean-k-mooney we fixed that already
17:20:30 sean-k-mooney or maybe its another bug
17:20:36 sean-k-mooney ill take a look soon.
17:25:19 sean-k-mooney stephenfin: we should open a propper os-vif bug for this
17:25:38 sean-k-mooney stephenfin: also i would like to know why we are not seeing this in our ci.
17:25:53 stephenfin sean-k-mooney: Presumably because we don't have a Windows CI?
17:25:53 sean-k-mooney e.g. why is this apprently only happening with triplo
17:25:55 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: A few miscellaneous items related to "native TLS" https://review.openstack.org/630980
17:25:56 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: docs: Update references to "QEMU-native TLS" document https://review.openstack.org/631283
17:26:05 stephenfin actually, that wouldn't be it
17:26:26 sean-k-mooney right since triplo only works on centos/rhel/fedora?
17:26:38 kashyap mriedem: As promised: https://review.openstack.org/631283 ("docs: Update references to "QEMU-native TLS" document")
17:28:05 stephenfin sean-k-mooney: We're not seeing them because we don't test the privsep stuff
17:28:41 stephenfin Instead we call the function directly
17:28:56 edleafe bauzas: are you free to jump on the hangout for a few minutes?

Earlier   Later