| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-17 | |||
| 15:11:14 | lyarwood | mriedem: thanks, I'd like to get off of this regression merry-go-round eventually :) | |
| 15:12:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Deduplicate config/policy reference docs from main index https://review.openstack.org/564846 | |
| 15:12:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Implement granular policy rules for placement https://review.openstack.org/524425 | |
| 15:12:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add granular policy rules for /resource_classes* https://review.openstack.org/565578 | |
| 15:12:36 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add granular policy rules for resource providers inventories https://review.openstack.org/568666 | |
| 15:12:37 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add granular policy rules for usages https://review.openstack.org/568706 | |
| 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 | |