| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-19 | |||
| 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 | bauzas | so, if the operator moves the instance to another AZ, then meh | |
| 08:38:17 | Uggla | bauzas, sure but if he unpins an instance he needs to recreate it to pin it ? | |
| 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 | No AZ | AZ but, no host | **Schedule in the AZ, keep the | | |
| 08:50:26 | Uggla | | | | reqspec.AZ as None** | |
| 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? :) | |
| 09:14:16 | bauzas | but there is one left question about the unpinned AZ | |
| 09:15:19 | gibi | do we need to consider the value of schedule_default_az during unshelve if the AZ param is not provided? | |
| 09:15:32 | bauzas | gibi: which is to continue to do what we agreed on before, but either documenting the 'unpinned can't be pinned again' thing, or provide some explicit parameter for it | |
| 09:16:21 | bauzas | gibi: you know that this option is only used by the api service and some ops use that for RR load-balancing between AZs ? | |
| 09:16:50 | bauzas | they have different value per nova-api service | |
| 09:16:52 | gibi | personally I don't want to have schedule_default_az in the picture | |
| 09:17:05 | gibi | as it is extra complication | |
| 09:17:16 | bauzas | gibi: don't disagree with this | |
| 09:17:31 | gibi | no I did not know that there are people out there abusing schedule_default_az | |
| 09:17:32 | bauzas | problem is, unshelve to AZ is end-user API | |
| 09:17:45 | bauzas | and that's a problem | |
| 09:17:48 | gibi | AZ is an end user thing | |
| 09:17:53 | gibi | during boot too | |
| 09:17:59 | gibi | (excpet for schedule_default_az ;) ) | |
| 09:18:00 | bauzas | yes I know | |
| 09:18:04 | bauzas | that ^ | |
| 09:18:12 | gibi | sure | |