Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-02-22
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.
15:31:35 gibi I will try to get to the logic nova does...
15:31:40 sean-k-mooney we also fall back to cold snapshots in some cases
15:31:50 kashyap sean-k-mooney: Yeah, I realize that
15:31:55 sean-k-mooney nova's api does not gurentee that its live
15:32:11 sean-k-mooney however if we stop it we will start the vm after the snap shot
15:32:33 sean-k-mooney so the pre and post state shoudl be the same
15:35:21 gibi kashyap: https://github.com/openstack/nova/blob/28cbcbb3737d544b7f73bd5aec55ccbd40222c95/nova/virt/libvirt/driver.py#L2893-L2922
15:35:34 gibi nova logs if it is live of cold snapshot
15:36:41 kashyap gibi: Thank you; so this path live snapshot here. (The instance isn't in SHUTDOWN state)
15:37:01 kashyap s/looks/looks at/

Earlier   Later