| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-22 | |||
| 13:37:32 | sean-k-mooney | dmitriis: changing the number of PF would change ther PCI adress which would not be supported if you had existing vms | |
| 13:37:55 | sean-k-mooney | we can also update the mac in the db on agent start | |
| 13:38:11 | sean-k-mooney | althoguh that wont update the pf mac in the neutron port so maybe we shoudl detect that and cause an error | |
| 13:38:22 | sean-k-mooney | or at least a warning | |
| 13:39:04 | dmitriis | VF numbers have an offset but they should remain stable unless the number of PFs changes | |
| 13:39:05 | sean-k-mooney | in the unlikely case a nic dies we likely want to be able to replace it with another nic | |
| 13:39:22 | sean-k-mooney | dmitriis: right which we dont want to supprot | |
| 13:39:52 | dmitriis | sean-k-mooney: ok, then I agree in principle that we can store vf_num and pf_mac in extra_info | |
| 13:40:01 | dmitriis | not hard to retrieve it from there either | |
| 13:40:09 | sean-k-mooney | we are already storing them in the neutron db in the port bidnign | |
| 13:40:16 | sean-k-mooney | so we already have the requirement that they be stable | |
| 13:40:23 | dmitriis | right | |
| 13:41:53 | sean-k-mooney | if we detach a change in the mac we can warn on that in agent start if we want to and tell the operator what the old mac was and the new one so that they know they have to manually update the ports. we could also automaticaly do that i guess but i woudl proably defer that to a followup patch | |
| 13:43:16 | dmitriis | ack | |
| 13:46:50 | dmitriis | So I think that's the change gibi is working on https://review.opendev.org/c/openstack/nova/+/829248 | |
| 13:48:39 | gibi | dmitriis: yes, but note the self -1 :) I realized that I need to change direction | |
| 13:48:46 | gibi | to use the PciDevice object | |
| 13:50:25 | dmitriis | gibi: ack. I'll focus on adding the remaining func test cases in the short term but I'll be around to help with moving things to PciDevice object | |
| 13:51:02 | gibi | dmitriis: thanks | |
| 13:57:22 | opendevreview | Felix Huettner proposed openstack/nova stable/queens: Gracefull recovery when attaching volume fails https://review.opendev.org/c/openstack/nova/+/829861 | |
| 14:06:42 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/830010 | |
| 14:33:44 | opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 14:46:52 | opendevreview | Jonathan Race proposed openstack/nova master: driver/secheduler/docs for Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova/+/822053 | |
| 14:46:52 | opendevreview | Jonathan Race proposed openstack/nova master: zuul-job for Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova/+/828372 | |
| 14:53:34 | sean-k-mooney | gibi: can you respond ot https://review.opendev.org/c/openstack/placement/+/826492/8/placement/lib.py#219 i think that is the only thing im not sure about in your placement series | |
| 14:54:02 | sean-k-mooney | i have +w most of the patches before that so they should all be sitting in the ci queue and should merge up to that point later today | |
| 15:03:56 | gibi | sean-k-mooney: looking... | |
| 15:04:35 | sean-k-mooney | its pretty minor | |
| 15:04:46 | sean-k-mooney | just i dont think we are checkign for conflicts properly | |
| 15:05:14 | gibi | I have to load context... :) | |
| 15:05:25 | sean-k-mooney | like i think we bascially should be flattening the list of required traits and asserting that there is on intersection with forbidden | |
| 15:05:44 | sean-k-mooney | im not sure using all does that | |
| 15:11:08 | gibi | so the goal is to find a conflict in the request like required=T1,!T1 | |
| 15:11:18 | gibi | in the complex case | |
| 15:11:51 | gibi | required=in:T1,T2&required=!T2 | |
| 15:11:57 | gibi | !T2 is not a conflict | |
| 15:11:57 | opendevmeet | gibi: Error: "T2" is not a valid command. | |
| 15:12:37 | gibi | but | |
| 15:12:39 | sean-k-mooney | well it shoudl still be rejected | |
| 15:12:49 | gibi | it is satisfyable | |
| 15:13:00 | sean-k-mooney | only if we have t1 | |
| 15:13:02 | gibi | yes | |
| 15:13:11 | sean-k-mooney | right im not sure we shoudl allow that | |
| 15:13:15 | gibi | I think we cannot expect that the client will normalize the query | |
| 15:13:35 | sean-k-mooney | i dont think any frobiden traits should over lap with any required even if we in | |
| 15:13:45 | gibi | maybe these required triat pieces are coming form different direction in nova | |
| 15:13:47 | sean-k-mooney | since we cant make forbidne traits optional | |
| 15:14:26 | gibi | one prefilter says I need either T1 or T2 another prefilter says I don't like T2 | |
| 15:14:40 | gibi | I don't want nova to do the normalization in this case | |
| 15:14:58 | sean-k-mooney | i kind of feel like nova shoudl be preprocessing that rahter then having ot have placment fiture that out | |
| 15:15:08 | sean-k-mooney | but i see why you are trying to be more lax | |
| 15:15:32 | gibi | I think it is a lot easier to accept it than forcing the client to normalize | |
| 15:16:07 | sean-k-mooney | required=in:T1,T2&required=!T2 is logically jsut required=T1 | |
| 15:16:12 | gibi | yes | |
| 15:16:26 | sean-k-mooney | if we do accept that we shoudl really preprocess that before we generate the sql queries | |
| 15:16:34 | gibi | why? | |
| 15:16:44 | gibi | I think sql can handle this | |
| 15:17:07 | gibi | I even think sql should have the query planner to optimize this out | |
| 15:17:07 | sean-k-mooney | i mean it could but i think that will not scale well | |
| 15:17:10 | bauzas | sean-k-mooney: thanks for accepting the existing SQL query from gibi | |
| 15:17:29 | gibi | * the sql server | |
| 15:17:41 | sean-k-mooney | gibi: if that was your orginal intent i guess what you have will do that | |
| 15:17:47 | bauzas | sean-k-mooney: as I knew since 10 years, in general the subqueries use the same execution plans than in the inner joins | |
| 15:18:08 | bauzas | but we could verify it with the EXPLAIN query | |
| 15:18:22 | sean-k-mooney | bauzas: my expirnce is inner joins like that tended to result in more memory usage then subquires | |
| 15:18:57 | sean-k-mooney | im not sure that sqligte will optimise to the same degree as mysql in this regard | |
| 15:19:10 | gibi | I don't believe either | |
| 15:19:23 | gibi | but nobody runs sqlite in production (hopefully :) | |
| 15:19:46 | bauzas | sean-k-mooney: well, in general it depends on the DMBS | |
| 15:19:55 | sean-k-mooney | ya i was more worreid about our func tests but | |
| 15:20:03 | bauzas | sean-k-mooney: but with mysql 5.0 I saw that it was the same | |
| 15:20:09 | sean-k-mooney | we likely wont have db quiries that will stress it enough there to matter | |
| 15:20:19 | opendevreview | Elod Illes proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 15:21:24 | sean-k-mooney | bauzas: lets revisit this in the future when we have data one way or another | |
| 15:21:32 | bauzas | ++ | |
| 15:21:36 | bauzas | agreed | |
| 15:21:58 | gibi | I promise I get back to this and gather some performance data from a mysql env | |
| 15:22:29 | sean-k-mooney | bauzas: if you woudl not mind reviwing 826492 that is the only patch that does not have +w | |
| 15:22:47 | sean-k-mooney | bauzas: gibi and i were just discussing how we detct conflicts | |
| 15:22:48 | bauzas | sean-k-mooney: I could do this after the meeting | |
| 15:22:53 | bauzas | btw. | |
| 15:23:02 | bauzas | nova meeting in 38 mins | |
| 15:23:03 | bauzas | here | |
| 15:23:11 | sean-k-mooney | ack for now i think i can accept gibis explation of what they were trying to enable | |
| 15:23:47 | gibi | cool | |
| 15:23:47 | sean-k-mooney | we can let the db handel the extra complexity for now and we can simplyfy the query either in nova or placment in the futrue if needed | |
| 15:23:54 | kashyap | gibi: When you get a minute, do you, or anyone know what's going in this test here? - https://github.com/openstack/tempest/blob/master/tempest/api/compute/images/test_list_image_filters.py#L108 | |
| 15:23:54 | gibi | thank you | |
| 15:24:32 | sean-k-mooney | gibi: im just worried that if we say "the db query optimiser will take care of it" too much we could get some nasty surprise in large deplopyments | |
| 15:24:54 | kashyap | (I'm trying to debug an upstream TripleO bug from hell that's "critical", and it's hitting the failure at line-128) | |
| 15:24:58 | gibi | sean-k-mooney: sure, I will do some performance testing to see if it matters | |
| 15:26:20 | gibi | kashyap: looking... | |
| 15:27:21 | kashyap | (That's the Tempest bug here: https://bugs.launchpad.net/tripleo/+bug/1959014/) | |
| 15:27:28 | gibi | kashyap: boot servers, then snapshot the server and upload the image to glance | |
| 15:27:49 | kashyap | Is it _really_ a live snapshot? Where "it" == create_image_from_server() | |
| 15:27:58 | kashyap | Is it a live snapshot? /me looks | |
| 15:28:53 | kashyap | create_image_from_server() --> create_image() | |
| 15:30:19 | gibi | it depends | |
| 15:31:23 | kashyap | Hm, I'm combing through the libvirt <-> QEMU logs given that it seems to fail at "live snapshot", but need more time to dig | |
| 15:31:31 | sean-k-mooney | kashyap its not always a live snapshot there is a config option that you can enabel. | |