| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-09 | |||
| 08:13:08 | gibi | yepp, I +2d the prelude yestearday. thank you for writing it | |
| 08:19:41 | kashyap | bauzas: Then how did you discover it? If it's not the line that caused the error :-) | |
| 08:20:10 | bauzas | kashyap: I still use my eyes in general | |
| 08:20:20 | kashyap | Hehe | |
| 08:20:29 | bauzas | automated coding isn't an option yet, I'm afraid | |
| 08:20:34 | bauzas | I should ask elon to propose it | |
| 08:23:27 | kashyap | bauzas: GitHUb has some ideas with their <clears-throat> "Copilot" | |
| 08:23:34 | kashyap | bauzas: But, look - https://www.techradar.com/news/github-autopilot-highly-likely-to-introduce-bugs-and-vulnerabilities-report-claims | |
| 08:23:57 | kashyap | "researchers discover that nearly 40% of the code suggestions by GitHub’s Copilot tool are erroneous, from a security point of view" | |
| 08:24:03 | kashyap | But LOL, as if that's a surprise! | |
| 08:24:50 | bauzas | kashyap: you get the same experience with Tesla Full Self Driving which was proposed since a while | |
| 08:25:12 | bauzas | the only difference being that a car bug leads to some injury :D | |
| 08:25:25 | kashyap | I don't drive; so ignore cars altogether :D I'm more interested in long-distance electric bikes :D | |
| 08:25:57 | bauzas | I switched 70% of my drives to be full electric, I'm chasing down the last 30% bits | |
| 08:26:15 | bauzas | but that will require hardware upgrade | |
| 08:26:53 | bauzas | kashyap: excellent choice, btw. do you have government incentives for this like in France ? | |
| 08:28:40 | kashyap | bauzas: I was told there are; but I need to dig in still | |
| 08:29:15 | kashyap | bauzas: I got more energized about it after my recent hiking in the Alps. | |
| 08:31:10 | bauzas | kashyap: sure, but mountain e-bikes are way different | |
| 08:31:18 | kashyap | bauzas: Oh, sure | |
| 08:31:46 | kashyap | I was not mixing them up. Just noticing how people were doing long-distance rides there w/ e-bikes made me think about it more | |
| 08:32:24 | bauzas | kashyap: https://mobilit.belgium.be/nl/mobiliteit/personenvervoer/fiets ;) | |
| 08:33:17 | kashyap | bauzas: Hehe, thank you. Yeah, NL and FR are treated as first-class citizens on most web pages | |
| 08:33:29 | kashyap | bauzas: I knew this existed, just didn't bother to investigate | |
| 08:36:14 | bauzas | kashyap: surprinsingly, most of the incentives seem to be only for the Brussels and the Wallony regions | |
| 08:36:28 | bauzas | afaicr, Ghent is in Flanders, right? | |
| 08:36:36 | kashyap | bauzas: Yes, it is | |
| 08:36:52 | kashyap | That's very odd, though. | |
| 08:36:58 | kashyap | bauzas: LOL, no, thank you | |
| 08:37:22 | bauzas | there is a fun fact here | |
| 08:37:54 | bauzas | if you want to buy an electric car, the gov gives you a discount of 7k€ if the car is below 45k€ | |
| 08:38:17 | kashyap | Nice, that's quite a chunky amount | |
| 08:38:39 | bauzas | but, if you live in the Marseille area, the local city gov gives you an extra 5k | |
| 08:39:34 | bauzas | so, lots of people are considering some way to address their primary location as some random Marseille place | |
| 08:40:50 | kashyap | Heh | |
| 08:40:58 | gibi | those are nice summs indeed | |
| 08:43:48 | gibi | here we have ~5k€ subsidise for full electric cars (and free parking) | |
| 08:44:21 | gibi | but for cars < 35k€ | |
| 08:47:45 | kashyap | I do hope people are taking advantage of it; I guess it's a win-win | |
| 08:48:50 | bauzas | kashyap: we do | |
| 08:49:21 | bauzas | we have two cars, one is full electric (a peugeot 208) and one is plugin-hybrid (a skoda superb) | |
| 08:49:52 | bauzas | even with the hybrid which has 40km+ electric range, we try to do 100% of our drives to be electric | |
| 08:50:09 | kashyap | Nice; /me learned first time of plugin-hybrid | |
| 08:50:33 | bauzas | as a consequence, we use the 208 (which is a compact car) for one-day drives around our region | |
| 08:50:58 | bauzas | and we only take the superb for trips above 200 kms which requires lots of leg space | |
| 08:51:31 | bauzas | I hate now refuelling | |
| 08:51:37 | bauzas | this is expensive and it stinks | |
| 08:52:24 | gibi | bauzas: if you feel the power, then could you please review https://review.opendev.org/c/openstack/placement/+/807014 I think (and CI thinks) it is good and fixing the transaction issue | |
| 08:52:31 | bauzas | hopefully next year, we'll change the superb to a new electric vehicle, because we tested long-range trips with intermediary recharges, and this works | |
| 08:52:47 | bauzas | gibi: excellent point, I need to look at this one | |
| 08:52:56 | bauzas | gibi: I also need to amend the vgpu doc | |
| 08:53:56 | gibi | and if you are at placement land then https://review.opendev.org/c/openstack/placement/+/807155 is simple and fixes a bug in consumer_types | |
| 08:53:59 | bauzas | gibi: I guess melwitt addressed your excellent concern ? | |
| 08:54:06 | songwenping_ | hi,team, is any entry to delete compute node except nova service-delete? | |
| 08:54:28 | gibi | bauzas: yes, she added a independent transaction for re-reading the rp data in the retry loop, and it seems to work well | |
| 08:54:34 | bauzas | songwenping_: you shouldn't delete the compute node entries | |
| 08:54:55 | bauzas | songwenping_: either the virt driver or the service deletion can do this | |
| 08:55:19 | songwenping_ | how virt driver works? | |
| 08:57:09 | kashyap | songwenping_: The bird's-eye view is this: | |
| 08:57:42 | kashyap | nova-api (in coordination with nova-scheduler) --> nova-compute (virt driver) --> launches libvirtd --> launches QEMU | |
| 08:57:55 | kashyap | But you have to be more specific for people to answer :) | |
| 08:59:01 | songwenping_ | no, i means which scenes virt driver delete the compute node? | |
| 09:16:15 | bauzas | songwenping_: sorry, I need to jump off for 30 mins | |
| 09:16:38 | bauzas | but basically, the virt driver gives the inventories and the compute nodes to the RT which creates the necessary records | |
| 09:16:43 | bauzas | RT : ResourceTracker | |
| 09:17:13 | bauzas | as the RT is run by the nova-compute service, you need to delete the service | |
| 09:17:50 | bauzas | there is a tight relationship between an RPC service (the nova-compute manager) and the compute node record | |
| 11:15:56 | songwenping_ | hi, team, anybody knows why placement check source node resource when evacuate VM? | |
| 11:19:19 | sean-k-mooney | how do you mean | |
| 11:19:29 | sean-k-mooney | as it it can include the source host in the set of host returned | |
| 11:21:03 | sean-k-mooney | that would be because we do not currently filter host but just up hosts | |
| 11:21:08 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L241-L254 | |
| 11:21:16 | sean-k-mooney | we do filter hosts by there disabeld status however | |
| 11:21:39 | sean-k-mooney | so fi you had dissbled the host you are evacuatating form then it would not be included in the placment query | |
| 11:22:30 | sean-k-mooney | songwenping_: the source node will be elimiated by the scudler after the placment query so it does not really have a negitive impact to include it | |
| 11:34:05 | opendevreview | Merged openstack/nova master: Support Cpu Compararion on Aarch64 Platform https://review.opendev.org/c/openstack/nova/+/763928 | |
| 11:41:48 | songwenping_ | sean-k-mooney: wait for a min, i am finding the placement code. | |
| 11:44:14 | songwenping_ | when we evacuate vm, placement will check_capacity_exceeded, https://github.com/openstack/placement/blob/master/placement/objects/allocation.py#L73 | |
| 11:45:47 | songwenping_ | https://github.com/openstack/placement/blob/master/placement/objects/allocation.py#L120 contains source node provider id and dest node provider id. | |
| 12:05:33 | sean-k-mooney | yes | |
| 12:06:11 | sean-k-mooney | when we make the allocation candiate quest we do not exclude the host we are evacuating form | |
| 12:06:40 | sean-k-mooney | ah i see | |
| 12:07:45 | sean-k-mooney | this should not have any negitive effect | |
| 12:08:53 | sean-k-mooney | we are technicall checkign allocation for one addtional host that we dont need placment to condiser | |
| 12:10:00 | songwenping_ | sometimes there are some rubbish data at allocation table, this lead to evacuate failed due to this check. | |
| 12:12:05 | sean-k-mooney | that shoudl just eliminate the host as an allcoation candiate no? | |
| 12:12:20 | sean-k-mooney | have you filed a bug for this | |
| 12:12:39 | sean-k-mooney | placment should not be made aware of evuacation or other lifecycle operations explcitly | |
| 12:13:20 | songwenping_ | havenot filed bug. | |
| 12:13:25 | sean-k-mooney | so im not sure we could proceed with any apprcoh that required modifciation of placment to make it expcitly aware of evacuation | |
| 12:13:48 | sean-k-mooney | but we might be able to handel the error condition with corupt data | |
| 12:13:57 | sean-k-mooney | so that it woudl not fail | |
| 12:17:56 | gibi | songwenping_: during evacuation the source node allocation of the VM is kept and the dest node allocation is added to it | |
| 12:18:18 | gibi | so for an evacuated VM you will see allocation on the source and dest nodes _until_ the source compute is down | |
| 12:18:40 | gibi | when the source compute node is recovered it will delete the allocation on the source node for the already evacuated VMs | |
| 12:19:27 | sean-k-mooney | gibi: for evacuate should we not be using the migration uuid for the evaucation | |
| 12:19:32 | sean-k-mooney | alocaltions | |
| 12:19:36 | sean-k-mooney | like we do for rezise | |
| 12:20:24 | songwenping_ | gibi: yeah, this is right workflow, but placement check the source node capacity before evacuate. | |
| 12:21:12 | gibi | sean-k-mooney: we never switched the evac workflow to migration allocations | |