| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-19 | |||
| 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 | |
| 09:18:22 | bauzas | we're mixing wishes of the enduser with operator toughts | |
| 09:18:27 | gibi | yepp | |
| 09:18:45 | gibi | and most of the time operator > end user | |
| 09:18:51 | gibi | except for schedule_default_az | |
| 09:18:56 | bauzas | but this is clear that user choice supersedes the schedule_default_az thing | |
| 09:19:00 | gibi | as that is just a default that can be overridden by the end user | |
| 09:19:03 | bauzas | so this is bikeshed | |
| 09:19:11 | bauzas | yeah | |
| 09:19:37 | bauzas | let's put schedule_default_az out of the picture :) | |
| 09:20:14 | gibi | pretty please document this decision that schedule_default_az will not be used during unshelve | |
| 09:20:40 | gibi | we seriously need to beef up our doc around this | |
| 09:20:56 | gibi | to have something to point at when bugs appeare | |
| 09:21:07 | bauzas | possibly | |
| 09:21:26 | bauzas | that's what I said, AZs are tribal knowledge atm | |
| 09:30:20 | gibi | Uggla: I'm not sure I get the meaning of the colums of the table in your comment https://review.opendev.org/c/openstack/nova-specs/+/831506/4#message-7d59a1d14206c958ad82d974af5f2a2c00ad255c | |
| 09:36:06 | Uggla | gibi, I just introduced a new param "az constraint". That would be used to choose if you want to pin/unpin the az of an instance. | |
| 09:36:26 | gibi | ahh so that would be a new API param | |
| 09:36:42 | Uggla | gibi, yes sorry if it is not clear. | |
| 09:36:43 | gibi | and above bauzas suggested that we don't add that, isn't it? | |
| 09:36:50 | gibi | no worries | |
| 09:36:55 | Uggla | gibi, yes | |
| 09:36:58 | gibi | ack | |
| 09:37:24 | gibi | I will try to summarise my current understanding about the agreement from above in the review | |
| 09:37:24 | Uggla | gibi, but bauzas said that before the discussion about pin/unpin of AZ. | |
| 09:37:44 | gibi | /o\ ETOOCOMPLEX | |
| 09:38:15 | gibi | anyhow | |