| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-13 | |||
| 15:14:19 | sean-k-mooney | huaqiang: apparently yes however i have not found where in the code that works | |
| 15:14:44 | sean-k-mooney | efried: the cpu_polciy is not an internal field | |
| 15:15:12 | sean-k-mooney | if we consider resouces:* to be then users proably should not set them | |
| 15:17:00 | efried | It's probably just ignorance on my part. But it seems to me that if I say resources:PCPU, cpu_policy=pinned is implied and I shouldn't be *required* to say it. | |
| 15:17:00 | efried | Likewise if I say resources:PCPU+resources:VCPU, cpu_policy=mixed is implied and I shouldn't be required to say it. | |
| 15:17:55 | sean-k-mooney | efried: so in theory stephens PCPU in placment feature allows you to say that and make it so you don thave to set cpu_policy=dedicated | |
| 15:18:38 | sean-k-mooney | but as i argured in the spec review i think that is a regression in functionality as you have to ensure the PCPU vaule now matches the flavor.vcpus | |
| 15:19:00 | huaqiang | sean-k-mooney: in current code, each instance a policy, either 'dedicated' or 'shared', no matter you named it explicitly or implicitly. | |
| 15:19:21 | sean-k-mooney | actuuly it shared dedicated or unset | |
| 15:19:22 | efried | IMO we should bite the bullet and start allowing flavor.vcpus=0 | |
| 15:19:43 | sean-k-mooney | when its unset itst treated as shared but the image can set it | |
| 15:20:25 | sean-k-mooney | efried: i disagree unless we remove all out resouce filed form the flavor or allow them all too be 0 | |
| 15:20:30 | sean-k-mooney | also doing that will break the world | |
| 15:20:52 | sean-k-mooney | there is plenty of logic built up around search on flavor by flavor.* | |
| 15:21:29 | efried | "bite the bullet" means it will be hard and breaking but will result in a better world. | |
| 15:21:53 | sean-k-mooney | im not sold on that | |
| 15:22:01 | sean-k-mooney | e.g. that its better but sure we could | |
| 15:22:36 | sean-k-mooney | we woudl effectivly be saying that the only filed that maters in the falvor is the unversion dict of string that is the extra specs | |
| 15:22:41 | efried | The alternative is making flavor.pcpus | |
| 15:22:46 | sean-k-mooney | no | |
| 15:23:00 | sean-k-mooney | flavor.vcpu has nothing to do with if its floating or pinned or mixed | |
| 15:23:10 | sean-k-mooney | it is the number of logical guest cpus | |
| 15:23:15 | efried | okay, I can buy that. | |
| 15:23:32 | efried | Then flavor.vcpus must equal resources:VCPUS+resources:PCPUS | |
| 15:23:42 | efried | which is confusing as shit IMO | |
| 15:23:42 | sean-k-mooney | as of train yes | |
| 15:23:50 | sean-k-mooney | before train no | |
| 15:24:01 | sean-k-mooney | actully even now no | |
| 15:24:14 | sean-k-mooney | if you use emulator thread polciy = isolate | |
| 15:24:22 | huaqiang | efried: for PCPU we have to consider emulator thread | |
| 15:24:24 | efried | then it's 2x or something? | |
| 15:24:31 | sean-k-mooney | it will be resources:VCPUS+resources:PCPUS+1 | |
| 15:24:31 | huaqiang | it might be isolate emulator thread | |
| 15:24:35 | efried | right | |
| 15:24:39 | efried | But my point is, | |
| 15:24:53 | efried | flavor.vcpus and resources:VCPU are not the same thing | |
| 15:24:56 | efried | which is confusing as shit. | |
| 15:24:58 | sean-k-mooney | corrrect | |
| 15:25:13 | sean-k-mooney | well we should not have used VCPUs as the resouce class name | |
| 15:25:14 | efried | Almost like we should make a resources:SCPUS or something | |
| 15:25:16 | efried | right | |
| 15:25:18 | sean-k-mooney | it should be SCPUs | |
| 15:25:32 | efried | Perhaps we should do that. | |
| 15:25:43 | efried | And just tell people not to use the r-t releases | |
| 15:26:03 | sean-k-mooney | yep i had this argument after we had already commited the VCPUs resouce class code in plament and no one wnated to change it | |
| 15:28:58 | huaqiang | efried,sean-k-mooney: do we have conclusion on adding a new cpu policy 'mixed' or just don't naming it as policy if we don't provided a policy? | |
| 15:30:02 | huaqiang | for later case we just create an instance through PCPU&VCPU and we don't assign any policy to it internally | |
| 15:30:41 | sean-k-mooney | that will triger alot of the "shared" policy code paths and break realtime cpus | |
| 15:31:37 | sean-k-mooney | given realtime guest is one of the primary usecase it think that would be bad unless you also modify the logic so that we take into account the realtime mask | |
| 15:32:09 | sean-k-mooney | i mean we shoudl do that anyway but the more things we make implcit the more edgecase you will have to handel interanlly | |
| 15:36:34 | huaqiang | the logic for creating a mixed instance follows the code path of 'dedicated' policy mostly. | |
| 15:37:06 | sean-k-mooney | yes both most of the code check expcitly check for dedicated then assuem if that is not set that it is shared | |
| 15:37:21 | huaqiang | but we have to create a internal variable to represent of mixed instance, not a policy but works paraelly with policies. | |
| 15:37:22 | sean-k-mooney | so if you dont set a policy it will be treated as shared | |
| 15:37:41 | sean-k-mooney | i think that would be a mistake | |
| 15:37:44 | sean-k-mooney | this is a policy | |
| 15:37:58 | huaqiang | I also think that is a problem | |
| 15:38:02 | sean-k-mooney | having yet another thing to check would just make the code more complcatedd | |
| 15:39:38 | huaqiang | How about tell user, the 'dedicated' is extended with the concept that not all CPUs are pinning CPUs. | |
| 15:39:49 | huaqiang | this was denied byefore | |
| 15:39:49 | sean-k-mooney | noop | |
| 15:40:13 | sean-k-mooney | i really hate that idea | |
| 15:40:55 | huaqiang | for inconsistent behavior | |
| 15:41:17 | sean-k-mooney | yes it would have different meaning on different versions of openstack | |
| 15:43:22 | sean-k-mooney | we could add teh mixed policy and make it optional | |
| 15:43:49 | sean-k-mooney | so we have an internal value to use and the user can choose not to set it and just use the placmenet syntax | |
| 15:44:32 | sean-k-mooney | i would still always recomend setting it but if we can infer the mixed case the it woudl not be required | |
| 15:45:10 | sean-k-mooney | however that woudl allwo you to do something like flavor.vcpu=8 hw:cpu_policy=mixed resouces:vcpu:2 | |
| 15:45:29 | sean-k-mooney | and because we know its mixed we know the other 6 cpus must be pinned | |
| 15:46:03 | huaqiang | and the number of PCPU could be derived from the give information | |
| 15:46:10 | sean-k-mooney | you could also do flavor.vcpu=8 resouces:vcpu:2 resouces:PCPUS:6 | |
| 15:46:21 | sean-k-mooney | yep | |
| 15:46:43 | huaqiang | if emulator thread policy is isolate | |
| 15:46:49 | huaqiang | then another PCPU is requred | |
| 15:46:58 | sean-k-mooney | yep | |
| 15:47:09 | sean-k-mooney | but again we can derive that form the info availble | |
| 15:47:15 | huaqiang | yes | |
| 15:47:36 | huaqiang | works for me | |
| 15:47:46 | sean-k-mooney | knowing its a mixed cpu explictly makes it eairer to derive thing in my view | |
| 15:48:06 | sean-k-mooney | but makeing it optional as long as you tell us how much of each type you want keeps it clean | |
| 15:48:13 | sean-k-mooney | if that is what you prefer | |
| 15:49:22 | efried | Yeah, I really don't understand why it needs to be explicitly stated by the user. | |
| 15:49:51 | efried | "will trigger X code paths by default" <== we will be changing those code paths as part of this feature, right?? That's what code changes are for?? | |
| 15:50:14 | efried | Mixed means you have to take shared code paths in some places, dedicated in other places. | |
| 15:50:22 | efried | That's gonna happen internally regardless. | |
| 15:50:43 | sean-k-mooney | i think we only ever check for dedicated so i think you would always take the shared path | |
| 15:50:58 | sean-k-mooney | but yes it will be changed in anycase by this feature | |
| 15:51:20 | efried | I'm not refuting that we need "mixed" logic internally. | |
| 15:51:41 | sean-k-mooney | by the way im still looking for the code that allows resouce:PCPU=4 to actully give you a pinned guest | |
| 15:51:51 | efried | I'm saying, why require it to be stated by the user if it can be inferred 100% from the fact that they MIXED THEIR CPUs in the flavor? | |
| 15:52:11 | sean-k-mooney | well the field is an ovo filed and i dont like adding another seperate variable | |
| 15:52:28 | efried | an OVO field in what, the Flavor? | |
| 15:52:34 | sean-k-mooney | so if we extend the ovo filed defintion it will alther the api check implcitly to allow it | |
| 15:52:46 | sean-k-mooney | no in the image metadata | |
| 15:52:52 | sean-k-mooney | and in the numa objects | |
| 15:53:05 | efried | but it's not a required field. | |
| 15:53:29 | sean-k-mooney | yes it can be unset or set to shraed explcitly for floating instance or set to dedicated | |
| 15:53:43 | efried | Fine. | |
| 15:53:50 | efried | but don't require it. | |
| 15:54:32 | efried | I assume you can set it from either the flavor or the image? | |