| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-17 | |||
| 15:12:38 | mriedem | lyarwood: job security! | |
| 15:13:39 | mriedem | per my comments in https://review.openstack.org/#/c/567860/ i'd also like to diversify the live migration tests we run | |
| 15:13:43 | mriedem | to mix up the image format | |
| 15:13:53 | mriedem | and to use config drive | |
| 15:14:39 | mriedem | we already run the nova-live-migration job and the neutron-tempest-multinode-full job runs live migration, | |
| 15:14:49 | mriedem | so we can make nova-live-migration run with force_config_drive=True, | |
| 15:15:12 | mriedem | and nova-live-migration runs with 2 image formats today, first is default (qcow2) and 2nd is rbd, we could change that first run to be raw | |
| 15:15:23 | mriedem | and then neutron-tempest-multinode-full would test qcow2 (default) with no config drive (default) | |
| 15:15:50 | mriedem | we still wouldn't have vfat config drive format testing, but i suspect we can remove the vfat config_drive_format option/workaround | |
| 15:16:06 | mriedem | i think that was for old versions of libvirt and we now require a minimum that has that fixed | |
| 15:25:04 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make nova-lvm run in check on libvirt changes and compute API tests https://review.openstack.org/569149 | |
| 15:25:06 | mriedem | melwitt: lyarwood: ^ | |
| 15:25:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make nova-lvm run in check on libvirt changes and compute API tests https://review.openstack.org/569149 | |
| 15:25:39 | lyarwood | mriedem: ack thanks! | |
| 15:34:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: Skip fetching the virtual size of block devices https://review.openstack.org/569062 | |
| 15:34:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make nova-lvm run in check on libvirt changes and compute API tests https://review.openstack.org/569149 | |
| 15:35:44 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: test raw image live migration with vfat config drive https://review.openstack.org/567860 | |
| 15:42:04 | openstackgerrit | Merged openstack/nova master: Fix auth_url example in hypervisor-hyper-v.rst https://review.openstack.org/568983 | |
| 15:47:18 | mriedem | tssurya: do you need to rebase https://review.openstack.org/#/c/567878/ on top of https://review.openstack.org/#/c/568271/ or just wait for https://review.openstack.org/569112/ ? | |
| 15:47:45 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 15:56:06 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435 | |
| 15:56:26 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857 | |
| 15:59:06 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Add PLACEMENT_DB_ENABLED=True to the nova-next job https://review.openstack.org/564067 | |
| 15:59:26 | openstackgerrit | Merged openstack/nova master: Deprecate running API services under eventlet https://review.openstack.org/549510 | |
| 16:01:02 | openstackgerrit | Merged openstack/nova master: Simplify BDM boot index checking https://review.openstack.org/564480 | |
| 16:13:35 | melwitt | mriedem: do you see any issue with us increasing the max number of allowed attached volumes per instance from 26 to 1024? I was thinking to approve this specless bp https://blueprints.launchpad.net/nova/+spec/nova-improvement-of-maximum-attach-volumes-more-than-26-vols | |
| 16:14:36 | mriedem | i am not the person to ask about that... | |
| 16:14:45 | mriedem | should ask kvm people | |
| 16:14:50 | mriedem | like kashyap re danpb | |
| 16:15:14 | melwitt | I already talked to danpb about it and he suggested 1024 as the new max | |
| 16:15:30 | mriedem | because of the default fd? | |
| 16:15:37 | melwitt | was just thinking to ask you since you've worked on the multi-attach stuff | |
| 16:15:53 | mriedem | er ulimit used to default to 1024 | |
| 16:16:16 | mriedem | multiattach volumes are >1 instance to the same volume, | |
| 16:16:20 | mriedem | not >1 volumes to the same instance | |
| 16:16:28 | mriedem | default quota on volumes is 10 anyway | |
| 16:16:40 | mriedem | so a normal tenant is going to have at most 10 volumes attached to a server | |
| 16:16:50 | mriedem | if you're using powervm, i think you get up to like 256 or something | |
| 16:16:52 | melwitt | oh, right. okay | |
| 16:16:52 | mriedem | efried: ^ | |
| 16:17:05 | mriedem | because powervm just f'ing loves volumes | |
| 16:17:11 | mriedem | also, | |
| 16:17:16 | mriedem | this reminds me, | |
| 16:17:51 | melwitt | picked 1024 arbitrarily based on the field tests described here https://rwmj.wordpress.com/2017/04/25/how-many-disks-can-you-add-to-a-virtual-linux-machine/ | |
| 16:18:00 | mriedem | Ia34d06429c1f8f0a8259616bcba0c349c4c9aa33 | |
| 16:18:07 | melwitt | danpb suggested 1000 | |
| 16:18:12 | mriedem | https://review.openstack.org/#/c/366955/ | |
| 16:18:30 | mriedem | depending on how many volumes you try to attach in a single request, you could blow out the build requests table | |
| 16:18:45 | efried | I'm asking Gerald whether 1024 is enough for us. | |
| 16:18:48 | mriedem | so would 1024 BDMs in a single bfv request get stored in MediumText? | |
| 16:18:55 | melwitt | hm | |
| 16:19:01 | mriedem | MediumText is pretty damn big so i assume yes | |
| 16:19:37 | mriedem | (11:44:41 AM) burgerk: mriedem: broke at ~ 80 volumes, want to go up to 128 | |
| 16:19:45 | mriedem | so powervm was using 128 in that case | |
| 16:20:02 | efried | okay. | |
| 16:21:04 | melwitt | okay, so increasing the max is cool, it might be that 1024 is too high | |
| 16:21:14 | mriedem | MEDIUMTEXT [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 16,777,215 (224 − 1) characters. The effective maximum length is less if the value contains multibyte characters. Each MEDIUMTEXT value is stored using a 3-byte length prefix that indicates the number of | |
| 16:21:15 | mriedem | bytes in the value. | |
| 16:21:29 | mriedem | idk | |
| 16:21:34 | mriedem | someone should test it | |
| 16:21:49 | mriedem | i don't want to guess wtf would happen if someone tries to boot from volume with 1024 volumes | |
| 16:22:05 | mriedem | Tsuyoshi Nagata should test that | |
| 16:22:11 | melwitt | I'll ask | |
| 16:22:31 | mriedem | what is even the practical application of this? | |
| 16:23:44 | openstackgerrit | Merged openstack/nova master: Skip ServerActionsTestJSON.test_rebuild_server for cells v1 job https://review.openstack.org/567256 | |
| 16:23:51 | openstackgerrit | Merged openstack/nova master: Remove mox in libvirt/test_driver.py (1) https://review.openstack.org/566555 | |
| 16:23:57 | openstackgerrit | Merged openstack/nova stable/pike: libvirt: Report the virtual size of RAW disks https://review.openstack.org/568369 | |
| 16:24:02 | dansmith | mriedem: I bet it is "because kvm can do it and nova can't" | |
| 16:24:04 | openstackgerrit | Merged openstack/nova master: Remove mox in test_live_migrate.py https://review.openstack.org/564656 | |
| 16:24:05 | dansmith | not for any real reason | |
| 16:24:12 | openstackgerrit | Merged openstack/nova master: PowerVM Driver: DiskAdapter parent class https://review.openstack.org/549053 | |
| 16:24:13 | mriedem | NFV something or other | |
| 16:24:16 | dansmith | or "because kvm can do it and nova won't let you" | |
| 16:24:38 | mriedem | in today's modern high-demand enterprise telco world, 26 volumes is for babies | |
| 16:24:52 | melwitt | I had thought it was something to do with people attaching a lot of volumes for HA or something? | |
| 16:25:02 | mriedem | that's a hell of a lot of HA :) | |
| 16:25:14 | melwitt | I remember it was mentioned in the nova/cinder session at the PTG in the context of the bulk volume create/attach discussion | |
| 16:25:17 | mriedem | this needs to be....super fucking redundant | |
| 16:25:28 | mriedem | all i took out of that discussion was, | |
| 16:25:47 | mriedem | "the storage backend allows it, so we want to make the software do it" | |
| 16:26:10 | mriedem | "because the admin can attach 500 volumes in 2 hours rather than 10, but they'll never touch this thing again after that" | |
| 16:26:34 | mriedem | so i'm kind of -1 on this blueprint just based on the "why?" | |
| 16:26:50 | dansmith | yar | |
| 16:27:50 | mriedem | where is ken'ichi when i want to praise him | |
| 16:28:08 | melwitt | okay. I thought it had been discussed in the past that some people attach a lot of volumes for an HA use case | |
| 16:28:31 | mriedem | idk maybe, that's certainly an argument for volume multiattach | |
| 16:28:42 | mriedem | but that's not attaching >1 volume to an instance | |
| 16:28:46 | melwitt | and maybe 1024 is too high but I was thinking it didn't sound unreasonable to increase it > 26 for such a use case | |
| 16:28:50 | mriedem | and i don't see how 1024 is sane HA | |
| 16:29:02 | mriedem | sure, i mean maybe 128 like the powervm thing | |
| 16:29:10 | mriedem | but need to actually justify why we should make this change | |
| 16:29:12 | mriedem | not just because we can | |
| 16:29:21 | melwitt | yeah, I think the point of the blueprint is > 26 and we were trying to find a reasonable max | |
| 16:29:42 | mriedem | sure, that's just not the first question i'd ask | |
| 16:30:06 | mriedem | i want shelve to send me an email when it's done | |
| 16:30:15 | mriedem | not because i need it, just because i can make it happen | |
| 16:30:25 | mriedem | i actually think we've had that blueprint...the email thing anyway | |
| 16:30:39 | melwitt | okay, considering we've raised it to 128 for powervm and 256 for virtio-scsi, I didn't think we needed to ask about > 26 for this case as to why. others are attaching a lot more devices than 26 | |
| 16:31:55 | dansmith | mriedem: melwitt one way to look at it is 1024 is probably more than you could expect reasonable throughput from any of them on, given the number of host threads you'd need for them | |
| 16:33:12 | melwitt | sure ... I'm sorry I picked 1024, I didn't know it would be way too high. they didn't ask for 1024, they actually started with MAX_INT and I wanted to lower it to something more reasonable | |