| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-18 | |||
| 22:01:07 | mnaser | im thinking running it in a vm is probably easier | |
| 22:01:18 | sean-k-mooney | by the way we ahve seen things like different version of sqlite3 break functinal test on different distors before | |
| 22:01:32 | sean-k-mooney | but not sure what would be similar for pep8 | |
| 22:01:33 | mnaser | which will reflect the state of our ci the closst oo | |
| 22:01:53 | mnaser | sean-k-mooney: im thinking it probably has to do with libvirt-python if i had to guess based on the fact its mostly having to do with libvirt | |
| 22:02:16 | mnaser | and since libvirt on macos is weird prolly | |
| 22:02:45 | sean-k-mooney | ya maybe | |
| 22:02:58 | sean-k-mooney | although we dont actully install that for our tox envs | |
| 22:03:34 | mnaser | all the errors were in "nova/virt/libvirt/driver.py" so /shrug | |
| 22:05:44 | mnaser | well it passed just fine inside multipass vm on my box soooo | |
| 22:06:53 | sean-k-mooney | ya i also cant get it to run natively on macos for other reasons | |
| 22:07:09 | sean-k-mooney | i do not have python form homebrew i have it from the nix package manager | |
| 22:07:43 | sean-k-mooney | its unhappy with 2to3 and suds-jurko | |
| 22:07:53 | sean-k-mooney | althoug i could jsut not install the vmware lib | |
| 22:11:06 | mnaser | yeah i had to manually install that with a lot of really complicated ways | |
| 22:14:20 | sean-k-mooney | im getting clan compliation errors trying to build type-ast | |
| 22:15:08 | sean-k-mooney | so looks like there are some cpython module compat issue with macos on arm | |
| 22:15:28 | sean-k-mooney | works find with linux vm or otherwise however | |
| 22:16:01 | sean-k-mooney | proably would be fine with macos and x86 for that mater but macos and arm is pushing it just a little too far | |
| 22:16:13 | sean-k-mooney | vms are still pretty quick on m1 | |
| 22:17:06 | sean-k-mooney | my base spec m1 air is technically faster at running the test in a vm them my amin work laptop is nativly | |
| #openstack-nova - 2022-05-19 | |||
| 06:06:20 | opendevreview | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Flavor Access APIs https://review.opendev.org/c/openstack/nova/+/767704 | |
| 06:46:57 | opendevreview | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Show usage APIs https://review.opendev.org/c/openstack/nova/+/768509 | |
| 06:46:58 | opendevreview | Brin Zhang proposed openstack/nova master: Replace os-simple-tenant-usage with os-simple-project-usage https://review.opendev.org/c/openstack/nova/+/842288 | |
| 06:46:58 | opendevreview | Brin Zhang proposed openstack/nova master: Replace tenants* with projects* of policies https://review.opendev.org/c/openstack/nova/+/765315 | |
| 06:46:59 | opendevreview | Brin Zhang proposed openstack/nova master: Replace tenant_id with project_id in Limits API https://review.opendev.org/c/openstack/nova/+/768862 | |
| 06:46:59 | opendevreview | Brin Zhang proposed openstack/nova master: Replace tenant_id with project_id in os-quota-sets path https://review.opendev.org/c/openstack/nova/+/768851 | |
| 07:51:38 | opendevreview | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Flavor Access APIs https://review.opendev.org/c/openstack/nova/+/767704 | |
| 07:52:56 | opendevreview | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Show usage APIs https://review.opendev.org/c/openstack/nova/+/768509 | |
| 08:11:45 | seyeongkim | hello, I have a question about lp https://bugs.launchpad.net/nova/+bug/1950186 if this can be fixed in near future or if there is any plan? Thanks in advance. | |
| 08:23:22 | Uggla | gibi, hello if you can have a look at https://review.opendev.org/c/openstack/nova-specs/+/831506 | |
| 08:25:36 | gibi | I'm looking at the manial one right now but then I can look the unshelve too | |
| 08:32:09 | Uggla | gibi, oh cool as well thx. | |
| 08:36:57 | bauzas | Uggla: IMHO we shouldn't add a specific parameter for asking to pin an AZ | |
| 08:37:23 | bauzas | if the user asked for a specific AZ, it's pinned | |
| 08:37:45 | bauzas | so if the operator wants to move the instance to another AZ, OK, but then it should be pinned again | |
| 08:38:05 | bauzas | if the user didn't ask for a specific AZ, then it's not pinned | |
| 08:38:17 | Uggla | bauzas, sure but if he unpins an instance he needs to recreate it to pin it ? | |
| 08:38:17 | bauzas | so, if the operator moves the instance to another AZ, then meh | |
| 08:38:44 | bauzas | Uggla: who "he" ? | |
| 08:38:47 | bauzas | the admin ? | |
| 08:38:51 | bauzas | or the user ? | |
| 08:39:04 | Uggla | bauzas, user | |
| 08:39:20 | bauzas | but the user only creates the instance | |
| 08:39:32 | bauzas | he doesn't have a "pinned" parameter | |
| 08:39:41 | bauzas | he doesn't know about the environment | |
| 08:40:09 | bauzas | but what he knows is that the environment has multiple AZs and he just wants his instance to be in one of them | |
| 08:40:29 | bauzas | then, he'll create the instance by asking --az AZ1 | |
| 08:40:34 | bauzas | which will be pinning the AZ | |
| 08:41:12 | Uggla | bauzas, yep, then he can shelve/unshelve with AZ=None to unpin it | |
| 08:41:29 | bauzas | then, if some operator wants to move the instance to another AZ, then he needs to explain to the user that the instance will be moved, as the user will see a different AZ for his instance after it's moved | |
| 08:42:39 | Uggla | bauzas, why operator ? user can do it as well. Am I wrong ? | |
| 08:42:45 | bauzas | Uggla: correct, but what I'm explaining is that if the operator does this (unshelve with AZ to be None), then he will explain his user that the instance could be moved to any AZ | |
| 08:43:05 | bauzas | Uggla: no, because endusers can't unshelve to an AZ, right? | |
| 08:43:19 | bauzas | you need to be admin | |
| 08:43:22 | Uggla | bauzas, user can unshelve to an AZ not to a host | |
| 08:43:34 | bauzas | oh my bad then | |
| 08:44:24 | bauzas | Uggla: well, then we need to document the fact that unshelving to AZ=None means the instance could be moved after to *any* AZ, exactly like when you create it without asking for an AZ | |
| 08:44:55 | bauzas | and if you unshelve az=AZ2, that exactly means like create with --az AZ2 | |
| 08:46:54 | Uggla | bauzas, agree but there is no way to pin the instance to an az without recreating it. | |
| 08:47:06 | bauzas | Uggla: or shelving again | |
| 08:47:18 | bauzas | right? | |
| 08:49:12 | Uggla | bauzas, no due to new behavior | |
| 08:49:56 | bauzas | Uggla: if an instance was unshelved with az=None, the ReqSpec.az field will be None, right? | |
| 08:50:05 | bauzas | oh I see | |
| 08:50:24 | Uggla | yep but not way to set it again to az=foo. | |
| 08:50:26 | Uggla | | | | reqspec.AZ as None** | |
| 08:50:26 | Uggla | No AZ | AZ but, no host | **Schedule in the AZ, keep the | | |
| 08:50:39 | bauzas | then if you pass shelve/unshelve with az=something, it will move to this new AZ without pinning it | |
| 08:50:57 | bauzas | I see | |
| 08:50:58 | Uggla | bauzas, yes | |
| 08:51:25 | bauzas | well, I'd say it's a hard choice to make | |
| 08:51:48 | bauzas | but the point is, if an instance is unpinned, you have no way to pin it | |
| 08:52:28 | bauzas | problem is, the existing behaviour pins it even if you don't want | |
| 08:52:48 | bauzas | Uggla: honestly, this is debatable | |
| 08:52:55 | Uggla | bauzas, yes it was raised by sean as a question, but playing with devstack I realized that it could be non conveniant. | |
| 08:53:29 | bauzas | Uggla: do we agree on the fact that you explicitely need to set az:none in order to unpin the instance, right? | |
| 08:53:42 | Uggla | bauzas, yep sure | |
| 08:53:54 | bauzas | this can't be done without the caller explicitely opting into it | |
| 08:54:09 | bauzas | you can unshelve without any parameter | |
| 08:54:19 | bauzas | which will leave the instance in the same AZ | |
| 08:54:28 | bauzas | you can now unshelve to a host | |
| 08:54:34 | Uggla | bauzas, yep | |
| 08:54:50 | bauzas | which will leave this instance to this AZ | |
| 08:54:58 | bauzas | (be pinned) | |
| 08:55:07 | bauzas | you can unshelve to another AZ | |
| 08:55:25 | bauzas | which will move this instance to the new wanted AZ, still pinned tho | |
| 08:55:45 | Uggla | bauzas, if it is pinned at boot time it will remain pinned | |
| 08:55:48 | bauzas | so, frankly, the caller exactly has to call "I want my instance to be unpinned" | |
| 08:56:32 | Uggla | bauzas, yep absolutely, but if you do that it will remain unpinned. With no way to pin it again without recreating it. | |
| 08:57:37 | Uggla | bauzas, I'm fine with that but take the opportunity to raise this fact as we want to review mutual exclusive stuff (which may cause an issue on the client side). | |
| 08:58:59 | bauzas | then you probably have right | |
| 08:59:03 | bauzas | s/have/are | |
| 08:59:30 | bauzas | I see your honest concern, people would want to tell "I want my instance be stuck somewhere now" | |
| 08:59:53 | Uggla | bauzas, by the way I have no real interest to change as my code is working... :) | |
| 09:00:00 | bauzas | problem is, I don't know which exact semantics to write | |
| 09:00:31 | bauzas | Uggla: man, you litterally just did put your left food in some poop, you know | |
| 09:00:46 | bauzas | this is all your honot | |
| 09:00:48 | bauzas | honor | |
| 09:01:03 | bauzas | but this is the joy of review times | |