| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-16 | |||
| 19:21:46 | efried | Agreed. | |
| 19:22:01 | efried | edleafe But how would that work? | |
| 19:22:45 | efried | As currently architected, it *will* match that host. Cause it can't tell the difference between your CPU trait and your storage trait. | |
| 19:23:12 | edleafe | well, those are both storage traits, no? | |
| 19:23:19 | efried | So to make it clearer: | |
| 19:23:59 | efried | edleafe You ask for inventory(VCPU, MEMORY_MB, DISK_GB) and traits(RAID5, SSD, HW_CPU_X86_3DNOW) | |
| 19:24:40 | efried | edleafe What part of the architecture knows that it's okay for HW_CPU_X86_3DNOW to be split up from SSD, but it's not okay for RAID5 to be split up from SSD? | |
| 19:25:27 | edleafe | efried: for that you'll need jay to explain the big hairy sql | |
| 19:25:39 | edleafe | efried: fwiw, I don't know that it can | |
| 19:25:48 | efried | cdent So here's where numbered would come into play. I could ask for inventory1(VCPU, MEMORY_MB)&traits1(HW_CPU_X86_3DNOW) and inventory2(DISK_GB)&traits2(RAID5, SSD) | |
| 19:25:58 | efried | edleafe I believe it can't. There's no possible way it could. | |
| 19:26:25 | cdent | efried: I still don’t see the problem in the example you’ve given (non-numbered): | |
| 19:26:39 | efried | cdent Because it'll match that host+shared that it shouldn't. | |
| 19:26:48 | purplerbot | <efried> edleafe You ask for inventory(VCPU, MEMORY_MB, DISK_GB) and traits(RAID5, SSD, HW_CPU_X86_3DNOW) [2017-10-16 19:23:59.885269] [n NeX] | |
| 19:26:48 | cdent | [t NeX] | |
| 19:26:58 | edleafe | efried: if that's the case, then shared storage can't work, because shared storage would never have CPU traits | |
| 19:27:17 | cdent | right now that should not match, and you don’t want it to match | |
| 19:27:30 | efried | cdent Agree you don't want it to. But it *will*. | |
| 19:27:49 | cdent | efried: is that because of broken code or broken modelling, that’s what I’m trying to get at | |
| 19:28:44 | cdent | you should only get a trait if it’s resource provider is also providing inventory | |
| 19:28:50 | cdent | if that ^ statement is true | |
| 19:28:54 | efried | cdent Well, if we put a stake in the ground and say you can't possibly ever have a compute host with local storage associated ("aggregated") with a shared storage provider, then the scenario doesn't arise. | |
| 19:29:02 | cdent | and if you can’t split resource classes | |
| 19:29:05 | cdent | then no problem | |
| 19:29:50 | cdent | efried: let’s try to make this even more concrete, I’ll EOL when I’m done expressing the example | |
| 19:29:56 | cdent | two resource providers: | |
| 19:30:52 | cdent | compute_node1: inventory of VCPU 24, DISK_GB 1024, MEMORY_MB 1024, traits RAID5, HW_CPU_X86_3DNOW | |
| 19:31:36 | cdent | shared_diskA: inventory of DISK_GB 1024, traits RAID5, SSD, MISC_SHARES_VIA… | |
| 19:31:48 | efried | no, take RAID5 off of shared_diskA | |
| 19:32:03 | cdent | let me carry on as is | |
| 19:32:05 | efried | otherwise you match and it's not a problem. | |
| 19:32:06 | efried | okay. | |
| 19:32:10 | cdent | and then we’ll do that scenario | |
| 19:32:34 | cdent | those two are in an aggregate | |
| 19:33:39 | efried | GET /allocation_candidates?resources=VCPU:2,MEMORY_MB:512,DISK_GB:2&required=HW_CPU_X86_3DNOW,RAID5,SSD | |
| 19:33:50 | cdent | yes | |
| 19:34:16 | efried | You'll get { compute_node1: { VCPU: 2, MEMORY_MB: 512 }, shared_diskA: { DISK_GB: 2 } }. Cool. No problem. | |
| 19:34:31 | cdent | okay | |
| 19:34:43 | cdent | we agree that’s the design, right? | |
| 19:34:47 | efried | yup | |
| 19:34:51 | cdent | k, now | |
| 19:35:16 | cdent | shared diskA loses the RAID5 trait, but compute_node1 keeps it | |
| 19:35:23 | cdent | same request | |
| 19:35:33 | efried | Per the existing design, you will get the same result. | |
| 19:35:34 | cdent | the expected result, as designed, is nothi8ng | |
| 19:35:41 | efried | Correct. | |
| 19:35:57 | efried | sorry, "as designed" - we don't have a design point for this. | |
| 19:36:04 | efried | "as conceived", the expected result is nothing. | |
| 19:36:14 | cdent | yes, better choice of word | |
| 19:36:16 | efried | "as designed without having thought about this scenario" what you'll get is actually the same result as above. | |
| 19:36:33 | cdent | you have a test that shows that? | |
| 19:36:35 | efried | Because "as designed" we didn't think about this kind of split-trait scenario. | |
| 19:37:00 | efried | Well, no, because we haven't actually implemented traits on RPs yet. That's what alex_xu's change set is doing. | |
| 19:37:16 | efried | Which I suppose means there should be no harm in keeping that bit out of play for now? | |
| 19:37:41 | efried | ( ref: alex_xu's change set: https://review.openstack.org/#/c/479766/10/nova/objects/resource_provider.py ) | |
| 19:38:05 | cdent | a) there’s no harm keeping it out, but b) it’s the same thing I said before, we should write a test sooner than later that models the scenario you describe | |
| 19:38:29 | efried | cdent Yes, good idea. | |
| 19:38:31 | cdent | becuase as you talk about it, you make it sound like you think it expected to work. it is not | |
| 19:38:56 | cdent | if the second scenario is returing a result there is a bug | |
| 19:39:26 | efried | cdent Where should that test go? Cause without the above change, the framework isn't there. And if we keep aggregates out of the above change, same. | |
| 19:39:34 | cdent | and even if there is no code for it yet, we’ve got a test case prepared (at least mentally) for when there is | |
| 19:40:08 | cdent | isn’t there shared/aggregate code already pre-dating alex’s change? | |
| 19:40:18 | cdent | in objects/resource_provider.py | |
| 19:40:35 | efried | That's what I don't really know. | |
| 19:40:46 | efried | His change was really my first exposure to shared/aggregate code. | |
| 19:40:59 | cdent | one sec | |
| 19:42:59 | cdent | efried: https://review.openstack.org/#/c/460798/ introduced getting rps that share via misc | |
| 19:43:29 | efried | gaah, -1 for commit message width! | |
| 19:43:41 | edleafe | the horror!!! | |
| 19:44:29 | efried | cdent Aha, perfect, so yeah, this all makes total sense when traits are NOT in the picture at all. | |
| 19:44:57 | efried | And breaks down pretty handily once traits are introduced. | |
| 19:45:39 | cdent | so yeah, if a compute node is satisfy VCPU, and has a trait that is “about disk” | |
| 19:45:42 | cdent | things do get very weird | |
| 19:45:50 | efried | btw, I'm asserting that the scenario we walked through above is representative, not necessarily realistic. That is, even if we say "that'll never happen", something with the same characteristics is sure to pop up. | |
| 19:46:17 | cdent | yeah, I get that | |
| 19:46:27 | cdent | it’s better to be robust in the face of possibilities | |
| 19:46:52 | efried | One could imagine similar scenarios where network resources are provided by both the compute node and some shared RP. | |
| 19:46:53 | cdent | for a while the stake you mention above did exist, but then it went away, one option is for it to come back | |
| 19:48:11 | efried | Okay, what about when I have my ephemeral boot disk via local storage and my volumes shared (as they're likely to be) | |
| 19:48:33 | efried | Could solve it by modeling those storage types with different resource classes. But ew. | |
| 19:49:13 | efried | And in any case, there we get into a situation where we need to request separate chunks of storage inventory from separate RPs. | |
| 19:49:34 | cdent | yeah, this is not the first time that question comes up. I don’t know the answer right now. | |
| 19:50:27 | efried | But it sounds like the change set you pointed out means we do actually need an answer for this right now. | |
| 19:51:05 | cdent | efried: except that I’m not sure that code is doing anything | |
| 19:51:53 | cdent | it may very well be | |
| 19:52:08 | efried | cdent Well, it looks to me like it's letting you use aggregates. | |
| 19:52:45 | cdent | yes, but aggregates aren’t yet used in any particular way | |
| 19:53:23 | efried | Meaning there's no code that's creating aggregations yet? | |
| 19:53:29 | cdent | unless there are lots of clients of placement out there that we are not away of (which there very well may be, vmware has an entire feature set based around placement that has nothing to do with nova) | |
| 19:53:38 | efried | whee | |
| 19:53:49 | cdent | upstream, as far as I know, don’t think so, but I don’t know | |
| 19:55:49 | mriedem | wtf, why would hasattr return True on something and then immediately after that if i try to use it, i get an AttributeError? | |
| 19:56:16 | efried | mriedem Overrides? | |
| 19:56:21 | cdent | is it an ovo with a coerce? | |
| 19:56:27 | mriedem | no, fakelibvirtr | |
| 20:01:11 | mriedem | it's not even a Mock so getattr shouldn't be getting in the way | |
| 20:06:00 | cfriesen | are there any gotchas around running two instances of nova-compute one one system, one for local kvm instances and one for managing separate baremetal instances (for use with ironic)? | |
| 20:13:11 | cfriesen | I guess it might cause problems if the binary and hostname are the same for the two of them | |
| 20:22:29 | mriedem | my god, | |
| 20:22:40 | mriedem | when you find out you've been bashing your brains for an hour b/c of a copy paste error | |