| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-13 | |||
| 14:50:06 | sean-k-mooney | i am 90% sure he did not remove all the check that were based on cpu_policy | |
| 14:51:19 | sean-k-mooney | ya we still use it https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1482-L1520 | |
| 14:51:26 | huaqiang | the internal logic need a cpu_policy, no matter it is specified by flavor/image or specified implicitly through resources:RC | |
| 14:53:25 | sean-k-mooney | this is where translation for the placement request https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L252-L298 | |
| 14:54:02 | sean-k-mooney | he would have to infer the cpu_policy before that | |
| 14:57:54 | huaqiang | sean-k-mooney: I ma not intent to object the new policy 'mixed', but if this new mixed policy is added, we have to find the CPU quantity information from resources:RC. The 'mixed' policy will not work if no CPU quantity information is found in resources:RC. This is not like the way that dedicated or shared policy works. | |
| 14:57:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/pike: Skip checking of target_dev for vhostuser https://review.opendev.org/702231 | |
| 14:58:48 | sean-k-mooney | huaqiang: well we have to find it form resouce:* or have a hw:* extra spec yes | |
| 14:58:57 | huaqiang | This is something weired if we comapring the requirements for creating 'mixed' instance and 'dedicated' or 'shared' instance. | |
| 14:59:01 | sean-k-mooney | i think it shoudl be a error to jsut set mixed on its own | |
| 14:59:32 | huaqiang | technically we can do as you said | |
| 15:00:09 | sean-k-mooney | well for realtime instance we have two thing that must be set. you must enabel it with a boolean and then provide a mask | |
| 15:00:34 | sean-k-mooney | we did that in the realtime case to allow the image to provide the mask | |
| 15:01:31 | huaqiang | this will a little different with the 'mixed' instance case | |
| 15:01:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/pike: Skip checking of target_dev for vhostuser https://review.opendev.org/702231 | |
| 15:01:44 | huaqiang | because we don't have a mask | |
| 15:02:33 | sean-k-mooney | well we either have a mask or you have to use the placement syntax unless we are goint to placement syntax only. if we do that then i think that is problematic as long as we support groups in the flavor | |
| 15:05:27 | huaqiang | efried said in his conclusion that if the plamenent-ness works, then the placement interface is the only interface I think, that is no mask for it | |
| 15:06:19 | efried | what does "realtime" mean? | |
| 15:06:46 | sean-k-mooney | we have the ablity to mark the gust cpus as executing with realtime priority | |
| 15:06:50 | huaqiang | sean-k-mooney: What kind of problem? Do we have spec for how to support placement groups in nova? | |
| 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 | |