Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-11
16:18:58 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: DNM Test https://review.opendev.org/#/c/702089/ on stable/rocky https://review.opendev.org/702090
#openstack-nova - 2020-01-13
03:09:56 openstackgerrit Brin Zhang proposed openstack/nova master: Populate 'updated_at' when aggregate is updated https://review.opendev.org/580271
05:12:05 alex_xu efried: sean-k-mooney, if we only support placement-ese, then we will get mixing case like, user specified the cpu_policy=dedicated or shared, also specified PCPU and VCPU in resources.
05:18:43 alex_xu efried: sean-k-mooney, huaqiang reminder me, we currently refuse both cpu_policy and PCPU/VPCU are specified, so it should be ok
05:19:47 alex_xu efried: sean-k-mooney i'm ok with that algo, I guess that algo will be done at API layer,not the virt layer.
05:51:10 alex_xu efried: sean-k-mooney and if the user specified PCPU and VCPU in resources, then the value of InstanceNUMACell.cpu_policy will be 'dedicated'. then we didn't introduce new policy 'mixed' anymore, does sounds make sense to you?
06:39:33 openstackgerrit Brin Zhang proposed openstack/nova master: Populate 'updated_at' when aggregate is updated https://review.opendev.org/580271
09:55:02 openstackgerrit Liang Fang proposed openstack/nova-specs master: Support volume local cache https://review.opendev.org/689070
10:04:35 openstackgerrit Balazs Gibizer proposed openstack/nova stable/stein: Mask the token used to allow access to consoles https://review.opendev.org/702181
10:25:31 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use EphemeralObject for non DB versioned objects https://review.opendev.org/702184
12:41:46 brinzhang_ Hi all, https://review.opendev.org/#/c/580271/ this patch I was resolved the functional test and python test, but there are some errors I donot know why.
12:41:59 brinzhang_ is there need some dependency packges?
12:43:28 brinzhang_ any professional python expert can give some guide? thanks ^^
12:44:37 lyarwood brinzhang_: https://storyboard.openstack.org/#!/story/2007084
12:50:26 lyarwood brinzhang: I'm not sure if you saw this, https://storyboard.openstack.org/#!/story/2007084 | http://lists.openstack.org/pipermail/openstack-discuss/2020-January/011956.html
12:51:53 brinzhang lyarwood: Oh no, see it by your send
13:25:05 brinzhang_ gibi: hi, I am not very clear what did you mean, can you give me more details about this https://review.opendev.org/#/c/699669/2/specs/ussuri/approved/action-event-fault-details.rst@128
13:25:08 brinzhang_ gibi: thanks :)
14:05:10 efried alex_xu: I don't fully have in my head all the combinations that would or would not make sense.
14:05:13 efried But somebody should
14:05:19 efried And then block the ones that don't make sense.
14:05:35 efried I don't know if cpu_policy=$anything makes sense in the mixed CPU case, because you're dedicating some and sharing some.
14:05:42 efried So perhaps those should be mutually exclusive.
14:06:07 efried but that ^ kind of decision just needs to be made, in a way that makes sense, for all the relevant options.
14:06:30 efried ...by someone who knows what makes sense, which ain't me :P
14:07:43 efried But tl;dr we're not going to freak out about combining placement-ese and other syntaxes, because dansmith beat me down. I'm now a husk of my former self.
14:40:09 gibi brinzhang_: extended my comment in https://review.opendev.org/#/c/699669/2/specs/ussuri/approved/action-event-fault-details.rst@128
14:45:48 sean-k-mooney efried: we were going to use an expcitly cpu_policy=mixed for mixed cpus if you dont set that you cant use the feature
14:46:45 efried 'mixed' is a new value?
14:46:56 sean-k-mooney yes
14:47:00 efried And why do we need it?
14:47:12 efried Is cpu_policy a required field otherwise?
14:47:28 sean-k-mooney it how you enable pinning
14:47:30 efried I would expect we could infer 'mixed' based on the fact you specified both vcpu and pcpu
14:47:38 sean-k-mooney and it need to be set for realtime
14:47:52 sean-k-mooney and we do not want to use cpu_policy=dedicated with mixed cpus
14:49:36 sean-k-mooney all the pinning code check the cpu_policy values so if stephen enabeld pinning with resouces:PCPU he is implcitly setting that internally
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

Earlier   Later