| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-10 | |||
| 15:23:08 | cfriesen | sean-k-mooney: I thought from the hangout that physical TPM would be handled via a resource with inventory? | |
| 15:23:45 | sean-k-mooney | in the tpm i guess it could be as it is passthough to the vm and not subdevied | |
| 15:24:09 | sean-k-mooney | in which case COMPUTE_SECURITY_TPM should be the only trait that is needed | |
| 15:24:18 | jaypipes | sean-k-mooney: is TPM2.0 an Intel-specific thing? | |
| 15:24:21 | sean-k-mooney | moduleo adding a version | |
| 15:24:30 | sean-k-mooney | jaypipes: no its an open standard | |
| 15:24:34 | jaypipes | k. | |
| 15:24:55 | jaypipes | sean-k-mooney: I was going to suggest prefixing with X86 if it was Intel-specific. | |
| 15:25:03 | sean-k-mooney | jaypipes: https://www.iso.org/standard/66510.html | |
| 15:25:42 | cfriesen | okay, I can switch to COMPUTE_SECURITY_TPM_1_2 and COMPUTE_SECURITY_TPM_2_0 if jaypipes is cool with that | |
| 15:26:10 | jaypipes | sean-k-mooney: we have used COMPUTE_ to refer to virt-driver specific capabilities. I don't believe this is that? | |
| 15:26:18 | jaypipes | sean-k-mooney: isn't TPM a hardware thing? | |
| 15:26:30 | cfriesen | jaypipes: with the trait we're talking about an emulated TPM | |
| 15:26:42 | cfriesen | the hardware TPM would be a resource since there would be a finite number of them | |
| 15:26:49 | jaypipes | ah, right.. | |
| 15:26:55 | jaypipes | OK, good with me then. | |
| 15:27:07 | sean-k-mooney | yep what cfriesen said :) | |
| 15:27:11 | jaypipes | this is what I was confusing HPET with :) | |
| 15:27:19 | sean-k-mooney | yep | |
| 15:27:25 | cfriesen | okay, I'll respin the TPM spec with that minor change | |
| 15:27:30 | jaypipes | cfriesen: you proposing the os-trait patch? | |
| 15:27:53 | cfriesen | sure | |
| 15:28:59 | sean-k-mooney | *subdivided | |
| 15:29:19 | jaypipes | cfriesen: ok, when you do, please be sure to be crystal clear that the trait refers to the virt-driver emulated capability, not a physical resource. | |
| 15:29:28 | jaypipes | sean-k-mooney: I'm kidding with you :) | |
| 15:29:43 | cfriesen | jaypipes: right, makes sense | |
| 15:29:49 | jaypipes | ty sir | |
| 15:30:24 | sean-k-mooney | what i have realised while typeing used to massively reduce the amount of missspelling i made due to reversing or omitting letter now that i touch type entirly without thinking they are reappearing | |
| 15:31:39 | sean-k-mooney | it used to be a huge problem in school when i would hand write things and just stop writing a word half way through and start in the middle fo the next one bacially because my hand could not keep up with my brian when writing | |
| 15:32:49 | jangutter | In the past few years I've noticed that I've started to mistype things really really badly, reading back the sentence once is no longer enough for me to figure out what I messed up. | |
| 15:33:38 | jangutter | Worse, it's happening to my speech too. Pretty hilarious when you realise that your words leaving your mouth and in your brain don't match up. | |
| 15:34:50 | jangutter | but really, I try to spread that rumour so I can claim I actually meant "offloads" when I said "screwdriver". | |
| 15:48:49 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Ignore hw_vif_type for direct, direct-physical vNIC types https://review.openstack.org/609460 | |
| 15:49:04 | stephenfin | sean-k-mooney: ^ | |
| 15:57:05 | openstackgerrit | Chris Friesen proposed openstack/nova-specs master: Add support for emulated virtual TPM https://review.openstack.org/571111 | |
| 16:00:59 | openstackgerrit | Andreas Jaeger proposed openstack/nova master: Replace openSUSE experimental check with newer version https://review.openstack.org/609467 | |
| 16:03:02 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Consider nested allocations during allocation cleanup https://review.openstack.org/606050 | |
| 16:03:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject forced move with nested source allocation https://review.openstack.org/605785 | |
| 16:04:55 | gibi | jaypipes, mriedem, bauzas, efried: here is the rework of the force migration with nested allocation https://review.openstack.org/#/c/605785 | |
| 16:05:08 | gibi | and I'm leaving for today | |
| 16:05:13 | bauzas | I'm done for the day, but I'll look tomorrow | |
| 16:05:20 | bauzas | hah | |
| 16:09:07 | sean-k-mooney | stephenfin: can you take a look at https://review.openstack.org/#/c/609414/ before you leave | |
| 16:09:25 | stephenfin | sean-k-mooney: Can do | |
| 16:09:51 | sean-k-mooney | master is currently broken for hardware offloaded ovs and some other cases this will fix it and harden up the interface a little | |
| 16:26:38 | stephenfin | sean-k-mooney: Yeah, good spot | |
| 16:27:53 | sean-k-mooney | stephenfin: lennyb spotted it and pingged rodlfo and i on the neutron irc this morning | |
| 16:28:23 | sean-k-mooney | i was thinking about fixing the name spaceing of those module too but i think there is already enough in one patch | |
| 16:28:32 | sean-k-mooney | i might submit a followup later | |
| 16:28:35 | stephenfin | sean-k-mooney: I'm going to see if we can do the same thing claudiub did here to avoid that happening again https://review.openstack.org/#/c/470775/ | |
| 16:29:30 | sean-k-mooney | stephenfin: im not sure that would have help in this case but i might not under stand awhat that dose enough either | |
| 16:30:28 | stephenfin | sean-k-mooney: Yeah, it wouldn't actually. I thought https://review.openstack.org/#/c/609414/1/os_vif/tests/unit/internal/command/ip/windows/test_impl_netifaces.py was mocking the wrong stuff but it's not | |
| 16:31:02 | sean-k-mooney | this is the improtant test https://review.openstack.org/#/c/609414/1/os_vif/tests/unit/internal/command/ip/test_api.py | |
| 16:31:26 | sean-k-mooney | before we were returing an instance of the ip lib for windows and the module for linux | |
| 16:31:43 | stephenfin | sean-k-mooney: Just left a nit comment on that, actually | |
| 16:32:33 | mriedem | dansmith: on that initial allocation ratios spec, there is one place we still use the compute node fields, and that's in the scheduler https://github.com/openstack/nova/blob/6bf11e1dc14afad78b11d980c2544a3dc41579ff/nova/scheduler/host_manager.py#L256 | |
| 16:32:46 | sean-k-mooney | ya i realsied i coudl have used that too. im going to be adding more unit tests wehn ir change the module layout so ill change that then if your ok with that | |
| 16:32:51 | mriedem | so we set the values on the compute (in the RT) and then read in the scheduler | |
| 16:33:00 | dansmith | mriedem: but aren't those just for the filters? | |
| 16:33:04 | dansmith | what else cares about those? | |
| 16:33:28 | mriedem | weighers use it too i guess | |
| 16:33:46 | dansmith | to pick things that aren't set for oversubscription? | |
| 16:33:49 | dansmith | that seems weird | |
| 16:34:11 | mriedem | the numa topology filter is also using it | |
| 16:34:12 | dansmith | oh, numa filter uses it | |
| 16:34:18 | dansmith | hah | |
| 16:34:24 | dansmith | christ | |
| 16:34:37 | dansmith | so | |
| 16:34:43 | dansmith | (a) we should try to get someone to fix that | |
| 16:35:02 | stephenfin | sean-k-mooney: Yup, it's just a nit | |
| 16:35:02 | dansmith | (b) we can just update the compute node record with the same policy as we update placement | |
| 16:35:28 | mriedem | which is use config if set | |
| 16:35:35 | mriedem | that's what the spec proposed yeah | |
| 16:35:39 | dansmith | yep | |
| 16:35:44 | dansmith | okay I see the use in the weigher | |
| 16:35:48 | mriedem | the question was about upgrading from compute nodes that have 0.0 values in the db | |
| 16:36:01 | mriedem | and i said we could online data migrate those by reading config if the values are 0.0 | |
| 16:36:13 | dansmith | the 0.0 means that scheduler uses its own config, right? | |
| 16:36:26 | sean-k-mooney | regarding the numa topology filter im not sure it actully need the allocation ratiors | |
| 16:36:27 | mriedem | no | |
| 16:36:43 | dansmith | allocation_ratio of zero makes no sense otherwise right? | |
| 16:36:47 | mriedem | nothing in the scheduler reads config for allocation ratios | |
| 16:36:58 | dansmith | mriedem: it used to though yeah? | |
| 16:37:04 | mriedem | in the long long ago i guess, | |
| 16:37:07 | mriedem | oh well, | |
| 16:37:12 | mriedem | the facade would i guess yeah... | |
| 16:37:30 | dansmith | point being, 0.0 is nonsense | |
| 16:37:30 | mriedem | the ComputeNode._from_db_object would read from config if 0.0 in the db | |
| 16:37:38 | jaypipes | dansmith: ++ | |
| 16:37:55 | dansmith | so we could leave that, and only set it if they override per compute.. same logic as placement | |
| 16:38:05 | dansmith | and anything existing with 0.0 gets the same treatment as usual I guess | |
| 16:38:26 | mriedem | leave the facade in ComputeNode._from_db_object? | |
| 16:38:49 | dansmith | i imagine it won't affect compute's use if it is ignoring what is set on the object, so .. sure? | |
| 16:38:58 | sean-k-mooney | stephenfin: for https://github.com/openstack/nova/blob/0163b9bfb54aaa89b0574c86e7fd36321eebccfe/nova/scheduler/filters/numa_topology_filter.py#L91-L102 can you think of a use case wehre we actully need the allcoation ratiios here | |
| 16:39:33 | sean-k-mooney | stephenfin: we are not allowed to over subsibe against our selves wehn fitting to a host so setting them to 1.0 i think would be valid | |
| 16:42:05 | sean-k-mooney | stephenfin: i would have to go through the code to check but i think we could make the numa topolgy filter work without them. | |
| 16:42:50 | sean-k-mooney | dansmith: although it sound like we dont need to remove them if we go wtih the facade right | |
| 16:43:14 | dansmith | sean-k-mooney: it won't be right if you do | |
| 16:43:32 | dansmith | sean-k-mooney: because if people set the ratio in placement per-compute, which is what we're trying to enable with all of this work, | |
| 16:43:38 | dansmith | the filter will consider a value other than what is in placement | |