| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-18 | |||
| 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 | |
| 09:01:27 | bauzas | either reviewers or even you think about something new you haven't written, and then you put your code in the trash | |
| 09:02:09 | Uggla | bauzas, I know, but I think if we don't provide this, I'm pretty sure user will complain saying there is no way to unpin an instance and recreating it is painful. | |
| 09:03:12 | bauzas | I literally see this coming, indeed. | |
| 09:03:49 | bauzas | the problem is that 'AZ pinning' is something we don't explicitely mention | |
| 09:03:50 | Uggla | bauzas, btw it was the case with the old microversion. | |
| 09:04:20 | bauzas | this is more a tribal knowledge | |
| 09:04:37 | bauzas | and a lot of people are confused by the multiple config options and parameters we have | |
| 09:05:09 | Uggla | bauzas, of course it means we have to explain this very well. | |
| 09:05:29 | bauzas | (you can even pin all your instance to a specific AZ, even if not specified by the client, thanks to the very errorprone schedule_default_az option) | |
| 09:11:25 | Uggla | bauzas, to come up with what you said earlier. My previous colleagues called me "Le chat noir" if something can go wrong. Then it is for me. :) | |
| 09:13:23 | gibi | I've just read the scrollback about unshelve | |
| 09:13:29 | bauzas | Uggla: you're absolutely not alone in this situation. In the past, I don't count the number of revisions I made based on feedback and myself reconsidering a few things, sometimes even restoring an old revision as a fresh new PS because eventually we considered all the things we discussed over a couple of revisions were meaningless | |
| 09:13:38 | gibi | do we have a way forward or we are still in the open? | |
| 09:14:00 | bauzas | gibi: I think we're basically arriving to a consensus | |
| 09:14:08 | gibi | which is? :) | |