| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-06 | |||
| 13:46:50 | gibi | I will check it shortly and if I'm OK with it then I will ask for an exception on the todays meeting | |
| 13:55:16 | lyarwood | kashyap: resize | |
| 13:55:46 | lyarwood | kashyap: https://github.com/openstack/nova/blob/9ecefeb836964c52a5a2969b15c82b11c51d32ab/nova/api/openstack/compute/migrate_server.py#L76-L77 | |
| 13:57:58 | artom | lyarwood, could you revisit https://review.opendev.org/#/c/729763/11 when you get a chance? I didn't actually address any of your feedback, but hopefully my reasons make sense to you | |
| 13:58:10 | artom | stephenfin, ^^ same request, though I did fix the nit | |
| 14:01:16 | lyarwood | artom: yup was waiting for my changes to actually land before I went back to it | |
| 14:01:23 | lyarwood | artom: I'll hit it this afternoon | |
| 14:10:07 | sean-k-mooney | anyone rememebr off the top of there head when placment became required? | |
| 14:10:13 | sean-k-mooney | was it pike? | |
| 14:11:21 | lyarwood | sean-k-mooney: ocata I think | |
| 14:12:02 | sean-k-mooney | cool and prefilters were added in rocky right | |
| 14:16:29 | sean-k-mooney | yes they were. | |
| 14:40:58 | openstackgerrit | Stephen Finucane proposed openstack/os-vif master: mypy: Add type annotations https://review.opendev.org/745162 | |
| 14:40:59 | openstackgerrit | Stephen Finucane proposed openstack/os-vif master: mypy: Extend type annotations to 'vif_plug_noop' https://review.opendev.org/745163 | |
| 14:45:42 | openstackgerrit | Merged openstack/os-vif master: support pyroute2 0.5.13 https://review.opendev.org/744809 | |
| 15:12:50 | suryasingh | ERROR (Conflict): Cannot 'confirmResize' instance eaff75ba-1e16-4096-8882-33028d8b97fd while it is in vm_state active (HTTP 409) (Request-ID: req-71f53b9c-d01d-4bfe-a22c-b62401545f3c) | |
| 15:12:50 | suryasingh | When I downsize with —poll status comes out to be Finished. But confirming the the same fails with below error. | |
| 15:12:50 | suryasingh | I have a query about downsizing the nova instance. | |
| 15:12:50 | suryasingh | Sorry to interrupt in middle of your work. | |
| 15:12:50 | suryasingh | Hello Team | |
| 15:12:51 | suryasingh | So I just wanted to confirm, if it’s feasible operation from nova side and if not, is there any historical reason of it to not support downsize operation ? | |
| 15:26:33 | suryasingh | melwitt: dansmith lyarwood gmann efried would be very thankful if any of you respond to my query. | |
| 15:27:01 | gibi | suryasingh: do you try to downsize the disk in the flavor? | |
| 15:27:56 | suryasingh | @gibi whole flavor including disk. | |
| 15:28:02 | lyarwood | yeah I didn't think we supported down sizing tbh | |
| 15:28:14 | lyarwood | we can't downsize the disk at least | |
| 15:28:35 | gibi | the resize action fails if you try to decrease the disk size with 'Resize error: Unable to resize disk down.' | |
| 15:28:46 | gibi | the cpu and memory can be downsized | |
| 15:29:08 | sean-k-mooney | you can downsize the ram or cpus | |
| 15:29:11 | sean-k-mooney | but not the disk | |
| 15:29:20 | sean-k-mooney | as that would loose data potentially | |
| 15:29:39 | sean-k-mooney | oh gibi just said that | |
| 15:30:48 | suryasingh | gibi: sean-k-mooney lyarwood understood. Thanks for responding to query. | |
| 15:37:33 | stephenfin | Does anyone care to sanity check this idea for me? I end up wanting the feature every time I have to use osc-placement (along with auto-translation of RP names to UUIDs, but that's more work) https://review.opendev.org/#/c/743976/ | |
| 15:38:21 | stephenfin | As an aside, there are a quite a few patches queued up for review at https://review.opendev.org/#/q/is:open+project:openstack/osc-placement | |
| 15:50:41 | gibi | nova meeting starts in 10 minutes on #openstack-meeting-3 | |
| 15:57:48 | gibi | stephenfin: https://review.opendev.org/#/c/743976/ work for me. Also I can pay (with some review time) for the RP name -> uuid translation in the client | |
| 16:09:23 | sean-k-mooney | gibi: i the neutron docs are confusing on the ip allocation policy. i think i saw one place refecne that neutorn would do it automaticlly but i know when it was first added it needed to be set manually | |
| 16:10:08 | gibi | sean-k-mooney: I don't have my mutlisegment test env working so I cannot check right now but as far as I remember I had to set it manually | |
| 16:12:32 | sean-k-mooney | ok nova does not actully support multisegment prodier netwroks correctly | |
| 16:12:49 | sean-k-mooney | if you try to use them it will fail in at least two cases | |
| 16:12:52 | sean-k-mooney | sriov | |
| 16:13:12 | sean-k-mooney | and if one host has 2 phsynets it wont work right | |
| 16:13:41 | sean-k-mooney | also numa_aware_vswitch or anything that depens on the phsynet wont work properly | |
| 16:13:58 | sean-k-mooney | but ya that as seperate problem | |
| 16:15:32 | gibi | I guess I never tried with two physnets then | |
| 16:17:47 | sean-k-mooney | gibi: we just grap the first physnet form the list in nova | |
| 16:18:30 | sean-k-mooney | so if a network has more then one phsynet then there is no guarenttee that it will be correct. | |
| 16:19:41 | sean-k-mooney | the current hack that existsi assuem that we will have at most 1 provider network and 1 tunnel network but not multipele provider networks | |
| 16:23:40 | gibi | would it make sense to have two provide segment in the same network? | |
| 16:40:10 | sean-k-mooney | yes that is what the routed provider netwrok feature in neturon is for | |
| 16:40:19 | sean-k-mooney | it uses physnets to map hosts to segments | |
| 16:40:31 | sean-k-mooney | there is no other way to map host to segments that i have found | |
| 16:58:29 | openstackgerrit | Ghanshyam Mann proposed openstack/os-vif master: [goal] migrate testing to ubuntu focal https://review.opendev.org/738130 | |
| 16:59:25 | gmann | sean-k-mooney: ^^ need re Approved | |
| 16:59:37 | sean-k-mooney | already done | |
| 16:59:44 | gmann | thanks | |
| 17:00:43 | sean-k-mooney | gmann: also nova core technically are os-vif cores although we bacsically just ask you to use your judgement. if you feel comfortably approving you can if not then you dont have too :) | |
| 17:00:54 | sean-k-mooney | os-vif review is totally optional | |
| 17:02:06 | gmann | sean-k-mooney: sure. as long as you are on irc (which is always :p) i am ok to bother you | |
| 17:03:24 | sean-k-mooney | yep happy to be pinged about os-vif | |
| 17:05:04 | sean-k-mooney | oh i got the github "Arctic Code Vault Contributor" badge :) that is cool now in 1000 year peopel will see my terrible code and be equally stumped as we are now to how that ever worked :) | |
| 17:05:15 | sean-k-mooney | https://archiveprogram.github.com/ | |
| 17:05:55 | sean-k-mooney | i wonder what version of nova the archived | |
| 17:07:47 | sean-k-mooney | oh it was master from 02/02/2020 | |
| 17:08:17 | sean-k-mooney | huh that a pallandrome im sure they did that intentionally | |
| 17:08:48 | gibi | ohh, that was my brithday too :) | |
| 17:11:07 | sean-k-mooney | nice | |
| 17:52:54 | lyarwood | \o | |
| 17:54:43 | openstackgerrit | Merged openstack/nova-specs master: Routed network scheduling spec https://review.opendev.org/733703 | |
| 18:49:00 | lyarwood | does anyone know what the file paths for file backed memory look like in Nova? | |
| 18:49:11 | lyarwood | is it specific to the instance? | |
| 18:55:36 | sean-k-mooney | lyarwood: yes they are | |
| 18:55:44 | sean-k-mooney | they are generated by libvirt | |
| 18:55:49 | lyarwood | wonderful | |
| 18:55:53 | sean-k-mooney | with one per numa node | |
| 18:56:01 | sean-k-mooney | the are in the instance directory | |
| 18:56:17 | sean-k-mooney | why do you ask | |
| 18:56:35 | sean-k-mooney | thats one per guest numa node by the way | |
| 18:56:50 | lyarwood | oh no reason | |
| 18:57:15 | sean-k-mooney | there si a libvirt config option memory_backing_dir that you can set to chooese where to put them | |
| 19:14:38 | artom | stephenfin, so you're saying you'll edit out the typing stuff when you backport https://review.opendev.org/#/c/744958/ ? | |
| 19:14:49 | artom | I mean, I'd have done it right away by doing 2 patches, but w/e works | |
| 19:16:00 | stephenfin | artom: Yup, though only because I have to for Train (it's not Python 3-only) | |
| 19:16:39 | stephenfin | If it was, I'd leave them since they're a noop until mypy is enabled for that file (via mypy-files.txt) | |
| 19:17:13 | artom | stephenfin, ack, I'll remove my -1 then. I still don't fully get the problem/fix though :P | |
| 19:17:18 | stephenfin | a second patch is also doable, but I find the type hints help understand what's getting passed around | |
| 19:17:22 | stephenfin | I'm replying with that now | |
| 19:17:35 | artom | Yeah, I can understand that (the typing hints helping) | |
| 19:19:21 | stephenfin | artom: comments left. Let me know if that makes sense | |
| 19:20:56 | artom | stephenfin, ah, I think I get it - we don't "delta" the usage, we rebuild it from scratch every time. So if a certain migration/instance doesn't get counted as "tracked", it'll effectively unpin its PCPUs | |
| 19:21:11 | stephenfin | Yup, exactly | |
| 19:21:48 | artom | OK, great, so that's 1 hour to understand the concept. | |
| 19:21:53 | artom | Now to review the actual code :P | |
| 19:22:02 | artom | Need to pick up food first though | |
| 19:22:30 | stephenfin | TBH, that whole periodic task feels racy and generally wrong to me, but it does state that it's intention is to blow everything away and start from scratch so... | |
| 19:22:55 | stephenfin | yet another thing to add my "tech debt I really need to get back to" list, I guess | |
| 19:23:09 | artom | It's definitely not the first race in there | |
| 19:23:49 | artom | See: https://review.opendev.org/#/c/684409/ | |
| 19:23:57 | stephenfin | For sure. I decided not to start listing the related bugs of the related bugs, because it started getting ridiculous | |