| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-17 | |||
| 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 | |
| 16:34:32 | dansmith | tbh, I don't think it matters that much.. if it's not a big change, then whatever, but the justification can't be "because this is a legit real-world use case" | |
| 16:38:36 | melwitt | okay, I'll ask them to lower the proposed max and re-ask how many volumes they need to attach for their use case | |
| 16:41:57 | edleafe | dansmith: your change https://review.openstack.org/#/c/569127/ is failing unit tests due to the one-off change. Want me to fix it? | |
| 16:42:26 | dansmith | edleafe: ah, I figured it would.. I can do it | |
| 16:42:51 | edleafe | dansmith: ok | |
| 16:42:51 | dansmith | glad we have coverage on that | |
| 16:45:57 | belmorei_ | dansmith: me and tssurya were debugging the scheduler time. It's related with https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L772 | |
| 16:46:20 | belmorei_ | creating a dict with all instances info per host | |
| 16:48:01 | dansmith | per host we're considering each time we run through yeah? | |
| 16:48:14 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: Localdisk https://review.openstack.org/549300 | |
| 16:48:20 | belmorei_ | yeah | |
| 16:49:21 | dansmith | belmorei_: what is the slow part exactly? it looks like it's hitting a cell db once per host instead of grabbing a bunch at a time maybe? | |
| 16:49:46 | melwitt | I've actually seen that complaint before and I don't understand how compute isn't sending updates to the scheduler. or does that not happen anymore because of placement? | |
| 16:49:56 | mriedem | it does | |
| 16:49:58 | dansmith | melwitt: that would be an upcall | |
| 16:49:59 | mriedem | if configured to do so | |
| 16:50:04 | dansmith | right | |
| 16:50:05 | melwitt | I see | |
| 16:50:09 | mriedem | it's an rpc cast from all computes to the scheduler topic | |
| 16:50:14 | mriedem | it's only used for the affinity filters | |
| 16:50:29 | mriedem | track_instance_changes or something like that | |
| 16:50:44 | dansmith | yeah, and what I'm not getting is why this would be different for them in the new arrangement,m | |
| 16:50:47 | mriedem | https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.track_instance_changes | |
| 16:50:55 | dansmith | because they're only considering hosts from one cell at this point anyway | |
| 16:50:56 | mriedem | dansmith: i'm wondering the same | |
| 16:51:01 | melwitt | yeah. lemme see if I can find the bug I'm thinking of | |
| 16:51:51 | bauzas | is someone able to tell me how to simply just associate an instance and a floating IP, without going thru the list of ports ? | |
| 16:52:07 | bauzas | we had that in the past, but we removed that here | |
| 16:52:12 | melwitt | this one https://bugs.launchpad.net/nova/+bug/1737465 | |
| 16:52:13 | openstack | Launchpad bug 1737465 in OpenStack Compute (nova) "[cellv2] the performance issue of cellv2 when creating 500 instances concurrently" [Undecided,Confirmed] - Assigned to Jiang (jiangpf) | |
| 16:52:20 | belmorei_ | dansmith not following... hosts from one cell? | |
| 16:52:28 | mriedem | bauzas: I CAN | |
| 16:52:39 | mriedem | bauzas: https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/floating-ip.html#floating-ip-set | |
| 16:52:45 | mriedem | get the port id from the instance | |
| 16:52:51 | mriedem | then associate the port to hte floating ip | |
| 16:52:55 | bauzas | mriedem: port is required | |
| 16:52:55 | mriedem | or create the floating ip with the port | |
| 16:52:57 | dansmith | belmorei_: that code should be building a dict of host info, but only from the list of uuids that we got back from placement, which should be only one cell, and only the subset of those that are candidates | |
| 16:53:05 | mriedem | bauzas: yes the port is what links the instance to the floating ip | |
| 16:53:07 | bauzas | mriedem: so I need to openstack port list before | |
| 16:53:23 | bauzas | I was thinking we could somehow magically avoid one roundtrip | |
| 16:53:33 | bauzas | with openstack CLI doing that in secret for me | |
| 16:53:38 | mriedem | you can do it on a single command line if you want... | |
| 16:53:46 | bauzas | awk my love | |
| 16:53:50 | mriedem | no | |
| 16:53:51 | mriedem | NO | |
| 16:54:01 | mriedem | PORT1=$(openstack port list --device-id $SERVER1 -c ID -f value) | |
| 16:54:07 | mriedem | FLOATINGIP1=$(openstack floating ip create --port $PORT1 public -c floating_ip_address -f value) | |
| 16:54:13 | mriedem | do that in a single line | |
| 16:54:22 | bauzas | meh | |
| 16:54:23 | belmorei_ | dansmith: yes, but takes a lot of time even for 200 nodes | |
| 16:54:24 | mriedem | then $$$ me | |
| 16:54:34 | mriedem | bauzas: meh? | |