| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-19 | |||
| 11:31:40 | sean-k-mooney | 3440x1440@100hz | |
| 11:31:44 | stephenfin | Only thing it's lacking is Thunderbolt which would be handy since I could daisy chain a second monitor. As things stand, I'm just using my laptop screen | |
| 11:31:50 | sean-k-mooney | predates usbc however | |
| 11:32:28 | stephenfin | sean-k-mooney: sure have. This can do 100Hz if you're willing to put up with USB 2.0 speeds for the other ports, but Fedora seems not to drive 60Hz regardless | |
| 11:32:34 | stephenfin | I'm not gaming so it doesn't matter much anyway | |
| 11:32:49 | sean-k-mooney | i have been debating between going to 2 ultrawids or 1 large 4k display for a while but didnt find a cheep ultrawide | |
| 11:34:39 | sean-k-mooney | hum also curved | |
| 11:34:44 | stephenfin | This was a 479€ which seemed reasonable for what it had. I could justify more than doubling that for a 49" | |
| 11:34:44 | stephenfin | This was a 479€ which seemed reasonable for what it had. I could justify more than doubling that for a 49" | |
| 11:34:57 | sean-k-mooney | that is the one think i didnt want on this | |
| 11:35:05 | stephenfin | Also, you'd *have* to step up to Thunderbolt for that | |
| 11:35:20 | stephenfin | Don't think even USB 3.2 has the bandwidth for that | |
| 11:35:39 | sean-k-mooney | am maybe with display stream compression | |
| 11:35:43 | stephenfin | (i.e. 5120 x 1440 resolution) | |
| 11:35:46 | sean-k-mooney | but it depsn on the resolution | |
| 11:35:53 | sean-k-mooney | ya 4k ultrawid is nice | |
| 11:35:59 | sean-k-mooney | that is what i was loking at | |
| 11:36:02 | sean-k-mooney | but $$$ | |
| 11:37:34 | sean-k-mooney | i have basically been thinking about getting rid of my virtical monitor and laptop off my desk and addin a seocnd ultrawid on top of my current one for email and irc | |
| 11:38:34 | sean-k-mooney | right now my laptop (left of ultra wide) is my email screen and portait monitor (right of ultra wide) is irc | |
| 11:38:45 | sean-k-mooney | im just worried they might be two high | |
| 11:47:26 | gibi | sean-k-mooney: see the new table at https://etherpad.opendev.org/p/unshelve-to-host#L166 | |
| 11:47:34 | gibi | is this what you are after? | |
| 11:52:22 | sean-k-mooney | kind of i woudl prefer if we use null and queted strings to be explcit still reading it | |
| 11:52:55 | gibi | when I say "no AZ" it means the availability_zone field is not in the request body | |
| 11:53:07 | sean-k-mooney | yep i know | |
| 11:53:17 | sean-k-mooney | i was talkign about AZ=None | |
| 11:53:20 | gibi | so that is not the same as availability_zone = null | |
| 11:53:22 | gibi | ahh | |
| 11:53:23 | sean-k-mooney | that is ambiquious | |
| 11:53:23 | gibi | OK | |
| 11:53:32 | gibi | let me fix that | |
| 11:53:41 | sean-k-mooney | that could mean AZ="None" or AZ=null | |
| 11:54:03 | sean-k-mooney | cool | |
| 11:54:05 | gibi | done | |
| 11:55:11 | gibi | yepp thanks for the quotes | |
| 11:56:03 | sean-k-mooney | so yes that is what i was thinking | |
| 11:56:07 | gibi | cool | |
| 11:56:18 | sean-k-mooney | i was also thinking of just leaving the host->az check to the schduler | |
| 11:56:36 | sean-k-mooney | we could do it in the api if we want too | |
| 11:56:49 | gibi | Uggla, bauzas, dansmith: please check the table in https://etherpad.opendev.org/p/unshelve-to-host#L166 at least Sean and I agree on that now | |
| 11:56:55 | sean-k-mooney | but we could jsut convert the no valid host to a better error | |
| 11:57:36 | gibi | yeah, good point | |
| 11:57:49 | gibi | that will be NoValid host if we not check in the api | |
| 11:57:51 | gibi | but that is fine | |
| 11:58:34 | sean-k-mooney | im going to get coffee quickly brb | |
| 12:00:56 | gibi | sean-k-mooney: about the unbind, stephenfin's patch just shows that unbind removes the device_id from the port so we cannot bindly unbind at offload | |
| 12:05:41 | sean-k-mooney | gibi: that is not an unbind then | |
| 12:05:58 | gibi | the function is called unbind :) | |
| 12:06:00 | sean-k-mooney | at least not at the nutron api level | |
| 12:06:06 | sean-k-mooney | right its miss named | |
| 12:06:17 | sean-k-mooney | that is unbind_and_detach | |
| 12:06:18 | gibi | https://review.opendev.org/c/openstack/nova/+/842528/2/nova/network/neutron.py#616 | |
| 12:06:49 | sean-k-mooney | ya that function should be renamed | |
| 12:06:58 | sean-k-mooney | that is actully a detach | |
| 12:07:18 | sean-k-mooney | its a detach and clearing of dns_name | |
| 12:08:19 | sean-k-mooney | actully does this even do an unbind | |
| 12:08:52 | sean-k-mooney | ah i t does line644 | |
| 12:09:20 | sean-k-mooney | constants.BINDING_HOST_ID: None, | |
| 12:09:43 | sean-k-mooney | is the actual unbind | |
| 12:10:26 | sean-k-mooney | gibi: this is being used as part of instance delete which is why its doing all the other stuff | |
| 12:10:54 | gibi | yeah, this is correct during delete but it would not be corrrect during offload | |
| 12:10:57 | sean-k-mooney | its just combining the unbind with teh other operations needed to reset the port | |
| 12:11:14 | sean-k-mooney | right but that function is not only doing an unbind | |
| 12:11:24 | sean-k-mooney | i never said we shoudl use that funciton | |
| 12:12:38 | gibi | sure | |
| 12:12:52 | gibi | it is about terminology | |
| 12:12:53 | sean-k-mooney | we shoudl proably rename that "release_ports" or "reset_ports" | |
| 12:13:00 | gibi | yeah I agree | |
| 12:13:15 | sean-k-mooney | right terminology wise that function is missnamed | |
| 12:13:42 | sean-k-mooney | if i propose a patch for unshelve | |
| 12:13:50 | sean-k-mooney | ill porpsoe a clean up patch to rename this | |
| 12:14:07 | gibi | ack | |
| 12:15:02 | sean-k-mooney | speaking of patchs my spawn_n patch actully passed ci this time | |
| 12:15:07 | sean-k-mooney | well ignoreing pep8 | |
| 12:15:23 | sean-k-mooney | but it did not seam to really decrease the number of greenlets | |
| 12:15:34 | sean-k-mooney | i guess becasue when we are counting them | |
| 12:15:41 | sean-k-mooney | we count the wrapped greenlets | |
| 12:15:48 | sean-k-mooney | and the freestanding ones | |
| 12:16:03 | sean-k-mooney | so as you predicted it has no visabel effect | |
| 12:18:52 | gibi | the code should only count naked greenlets that are not wrapped | |
| 12:19:00 | gibi | in a GreenThred | |
| 12:19:14 | sean-k-mooney | hum well the number looked identical | |
| 12:19:32 | gibi | https://review.opendev.org/c/openstack/nova/+/841040/6/nova/compute/manager.py#10150 | |
| 12:19:33 | sean-k-mooney | its possible it did not work i coudl add a func test to check | |
| 12:19:59 | gibi | greenlets might be special from the GC perspective as they are implemented in a C extension | |
| 12:20:10 | gibi | so this can be a side effect of my hack to looking at the GC | |
| 12:20:50 | sean-k-mooney | maybe | |
| 12:20:53 | sean-k-mooney | not really sure | |
| 12:20:57 | gibi | me neither | |
| 12:21:06 | sean-k-mooney | will isinstance look at inheritance | |
| 12:21:11 | gibi | yepp | |
| 12:21:15 | gibi | it does | |
| 12:21:40 | sean-k-mooney | and GreenThread contains but is not a greenlet | |
| 12:22:09 | Uggla | gibi, looking at the table, line 3 we came back to the original behavior right ? Which is something we wanted to avoid. (Not break user choice to keep the instance floating.) | |
| 12:22:22 | sean-k-mooney | gibi: https://github.com/eventlet/eventlet/blob/master/eventlet/greenthread.py#L163= | |
| 12:22:30 | Uggla | gibi, although I think it is a better choice. | |
| 12:23:07 | gibi | GreenThread derives from greenlet https://github.com/eventlet/eventlet/blob/master/eventlet/greenthread.py#L163 | |
| 12:23:28 | gibi | sean-k-mooney: you were faster | |
| 12:23:42 | sean-k-mooney | gibi: yep so greenlet includes all the greenthread too | |