Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-17
15:03:42 mriedem why non-voting?
15:03:46 mriedem i think it is stable otherwise
15:04:02 mriedem we just don't gate on it because it's not a highly deployed image backend
15:04:16 melwitt I dunno. voting then?
15:04:21 mriedem we also had a raw imagebackend job at one point
15:04:34 mriedem or maybe that was just a dnm patch i had...
15:05:24 mriedem let's see how it looks on lee's fix first
15:05:40 mriedem 1 hour and 20 minutes...
15:05:43 mriedem but it passes
15:05:50 mriedem maybe we should just run the nova-lvm job on compute api tests
15:05:53 mriedem non-voting to start
15:05:57 mriedem and only on libvirt changes
15:06:23 melwitt I think that would be helpful
15:07:38 openstackgerrit Merged openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644
15:09:27 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: test raw image live migration with vfat config drive https://review.openstack.org/567860
15:09:40 mriedem lyarwood: let's make sure we don't regress the raw + vfat config drive + live migration case :) ^
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 mriedem efried: ^
16:16:52 melwitt oh, right. okay
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

Earlier   Later