| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-16 | |||
| 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 | |
| 20:22:43 | cdent | it’s full of stars | |
| 20:27:14 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: libvirt: add check for VIR_DOMAIN_BLOCK_REBASE_COPY_DEV https://review.openstack.org/512406 | |
| 20:27:15 | mriedem | artom: ^ | |
| 20:54:35 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Enable PUT dict to /allocations/{consumer_uuid} https://review.openstack.org/510625 | |
| 20:54:36 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073 | |
| 20:54:36 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Document the changes to PUT /allocations/{consumer_uuid} https://review.openstack.org/510626 | |
| 20:54:37 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Include project_id and user_id in GET /allocations https://review.openstack.org/512421 | |
| 20:54:37 | openstackgerrit | Chris Dent proposed openstack/nova master: Include project_id and user_id in AllocationList.get_all_by_consumer_id https://review.openstack.org/512420 | |
| 20:55:08 | mriedem | dansmith: melwitt: need an opinion on a backport scenario for https://review.openstack.org/#/c/505771/ | |
| 20:55:26 | mriedem | i need to do the same fix as in ^ but generically since we also need that fix for resize, unshelve and evacuate | |
| 20:55:36 | mriedem | i don't want to rename the method and then backport | |
| 20:56:02 | mriedem | so i can either copy the same fix outside the method in the 4 different places and backport it, or move the fix into the method with a todo to rename later | |
| 20:56:11 | mriedem | the rename would be master only | |
| 20:57:16 | mriedem | i'm leaning toward the latter - fix in one place, rename later | |
| 21:05:30 | mgagne | mriedem: what's the proper channel to get a blueprint approved/reviewed? https://blueprints.launchpad.net/nova/+spec/rebuild-ironic-config-drive | |
| 21:05:58 | mriedem | mgagne: generally during the weekly nova meeting if it's a specless blueprint | |
| 21:07:17 | mriedem | i think this would be ok as a specless feature parity bp | |
| 21:08:30 | mriedem | mgagne: so the issue is you create an ironic node instance with a config drive, and then when you rebuild the instance in nova, the new instance doesn't have a config drive, correct? | |
| 21:08:32 | mgagne | will add to open discussion for next meeting | |
| 21:08:39 | mgagne | mriedem: yes | |
| 21:08:48 | mriedem | ok, really a bug fix | |
| 21:09:14 | mgagne | mriedem: looks like someone from nova team had a different opinion in the bug report | |
| 21:09:19 | mgagne | and suggested a blueprint | |
| 21:10:09 | mgagne | https://bugs.launchpad.net/ironic/+bug/1575935/comments/10 | |
| 21:10:10 | openstack | Launchpad bug 1575935 in Ironic "Rebuild should also accept a configdrive" [Wishlist,In progress] - Assigned to Mathieu Gagné (mgagne) | |