| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-13 | |||
| 15:07:05 | efried | sean-k-mooney: so that's not the same thing as pinning? | |
| 15:07:08 | sean-k-mooney | and when you enable that feature you have to set a mask of which cpus are realtime and which are not | |
| 15:07:23 | sean-k-mooney | efried: its seperate but can only be enabled if you are using pinning | |
| 15:07:30 | efried | What I'm getting at is: I don't mind if we have to change some internal logic/data to represent "mixed", but for the UX it seems unnecessary, because we can infer it. | |
| 15:07:42 | sean-k-mooney | huaqiang: it has been supported for several release | |
| 15:08:14 | sean-k-mooney | efried: if we have it as an internal value i think we should allow it to be set | |
| 15:08:40 | efried | But you can't set mixed unless you mix, and if you mix, you can't set it to any other value. That doesn't seem like good UX to me. | |
| 15:08:41 | sean-k-mooney | efried: but also i really reallly want to make sure that this new bevaior is only enabeld if we do it intentionally | |
| 15:09:15 | sean-k-mooney | efried: so there is a discoverabliy aspect too | |
| 15:09:27 | efried | As a user, I don't want to say VCPU=$n,PCPU=$m only to have my build rejected with a message like "if you set both VCPU and PCPU, you must say cpu_policy=mixed as well" | |
| 15:09:28 | sean-k-mooney | if we dont set mixed as teh cpu_policy | |
| 15:09:55 | sean-k-mooney | i now need to prse the Resouces:* to figure out if this flavor is mixed pinnend or floating | |
| 15:09:57 | efried | be like, "No, you can't do mixed CPUs unless you also set this option that says you really mean it" | |
| 15:10:13 | efried | sean-k-mooney: we're doing that anyway to make sure they're not f'ing up the combination. | |
| 15:10:28 | sean-k-mooney | no i mean as an end user | |
| 15:10:37 | sean-k-mooney | who is tryign to fine a flavor to use | |
| 15:10:59 | efried | mmph, I don't buy that. | |
| 15:11:24 | efried | If you really think your user can't handle realizing VCPU=$n,PCPU=$m means mixed, name the flavor "mixed_cpu_XXX" | |
| 15:11:24 | sean-k-mooney | that havign to check both cpu policy and Resocues: is a pain? | |
| 15:11:37 | efried | I just don't like the redundancy. | |
| 15:11:58 | sean-k-mooney | efried: a human can programing it is just annoying but ok | |
| 15:12:20 | efried | I don't see why programming it is annoying. | |
| 15:12:53 | sean-k-mooney | because i now instead of looking at just the cpu policy i also need to look at resouces:* | |
| 15:13:05 | sean-k-mooney | when cpu_policy is not set | |
| 15:13:22 | efried | You have to look at it anyway | |
| 15:13:24 | sean-k-mooney | also if cpu_polciy is not set it allows the image to set any cpu_policy | |
| 15:13:36 | sean-k-mooney | you didnt before stephens change | |
| 15:13:42 | huaqiang | can we create an instance through PCPU and VCPU resources without naming it 'dedicated' or 'shared'. It is just an instance? | |
| 15:13:48 | sean-k-mooney | but yes technically you would have | |
| 15:14:13 | efried | sorry, are you telling me that every internal field maps to a user input?? | |
| 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 | Likewise if I say resources:PCPU+resources:VCPU, cpu_policy=mixed is implied and I shouldn't be required to say it. | |
| 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: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 | sean-k-mooney | as of train yes | |
| 15:23:42 | efried | which is confusing as shit IMO | |
| 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 | huaqiang | it might be isolate emulator thread | |
| 15:24:31 | sean-k-mooney | it will be resources:VCPUS+resources:PCPUS+1 | |
| 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 | sean-k-mooney | noop | |
| 15:39:49 | huaqiang | this was denied byefore | |
| 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 | |