| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-31 | |||
| 16:21:05 | lbragstad | mriedem: we generate a mapping of supported hashing mechanisms and use that when dealing with things we need to hash | |
| 16:21:14 | abhi89 | Hi guys.. can someone please review https://review.openstack.org/#/c/485121/.. | |
| 16:21:35 | lbragstad | mriedem: we pulled most of the password hashing logic into a separate module https://github.com/openstack/keystone/blob/master/keystone/common/password_hashing.py] | |
| 16:23:07 | mriedem | lbragstad: cool, thanks. sounds like dansmith has an alternative that he's been keeping secret too. | |
| 16:23:26 | lbragstad | mriedem: for hashing cells mapping creds? | |
| 16:23:52 | mriedem | for not storing them in the db | |
| 16:24:39 | lbragstad | interesting | |
| 16:24:52 | lbragstad | mriedem: after they are hashed, where are they stored? | |
| 16:25:19 | mriedem | config | |
| 16:25:29 | mriedem | something, idk | |
| 16:25:30 | lbragstad | ahh | |
| 16:25:33 | mriedem | that's why it's a secret | |
| 16:25:37 | dansmith | lbragstad: there's some way of configuring access creds by host/db, like DSN-based stuff | |
| 16:25:44 | dansmith | I haven't done it myself, you should talk to zzzeek, maybe in the oslo channel or something | |
| 16:25:57 | mriedem | dansmith: do you know if tripleo has this built in yet? | |
| 16:26:07 | mriedem | because i know they were complaining at one point about storing creds in the db | |
| 16:26:14 | dansmith | mriedem: not for creds reasons, | |
| 16:26:19 | mriedem | we could copy this into devstack | |
| 16:26:22 | dansmith | but for source ip, which I think was a similar thing | |
| 16:26:59 | dansmith | s/thing/solution/ | |
| 16:27:43 | lbragstad | interesting | |
| 16:44:38 | mriedem | ugh this always drives me crazy | |
| 16:44:39 | mriedem | "remote: (W) No changes between prior commit a0be7d3 and new commit d375135" | |
| 16:44:46 | mriedem | i'm re-ordering a series of changes to split some apart | |
| 16:44:59 | mriedem | when i try to git review, it won't let me b/c the base change hasn't changed at all | |
| 16:45:27 | mriedem | anyone know a special trick here? rebase doesn't work as i'm up to date | |
| 16:46:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add recreate test for forced host evacuate not setting dest allocations https://review.openstack.org/499678 | |
| 16:46:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Create allocations against forced dest host during evacuate https://review.openstack.org/499399 | |
| 16:46:18 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor out claim_resources_on_destination into a utility https://review.openstack.org/499718 | |
| 16:46:27 | mriedem | update the commit message i guess | |
| 16:47:33 | user1124 | hello | |
| 16:47:38 | user1124 | i have a qq | |
| 16:47:59 | user1124 | does the nova policy for listing flavors actually work? | |
| 16:48:32 | user1124 | os_compute_api:flavors | |
| 16:48:37 | user1124 | os_compute_api:flavors:discoverable | |
| 16:57:36 | melwitt | kashyap: thanks for confirming that with Eric | |
| 17:06:57 | melwitt | mriedem: more swap volume fun https://review.openstack.org/#/c/407346/ swapping a bootable volume on a BFV instance for a non-bootable volume results in problems. that patch changes to deny bootable -> non-bootable in the API which seems right to me. I wanted to get more opinions | |
| 17:59:49 | openstackgerrit | Eric Fried proposed openstack/nova stable/pike: [placement] Update user doc with api-ref link https://review.openstack.org/499748 | |
| 18:00:03 | efried | Whee, stable branch bot notifications ^ | |
| 18:00:24 | cburgess | Anyone know if a resize of an instance will update the flavor extra specs stored in the instance_extra table for the instaince? | |
| 18:06:27 | dansmith | cburgess: it should yeah | |
| 18:06:32 | cburgess | Cool | |
| 18:06:35 | cburgess | Thanks | |
| 18:20:33 | mriedem | melwitt: swap from BFV to non-BFV, that's great | |
| 18:21:53 | melwitt | haha, yep | |
| 18:27:13 | efried | [resource providers] How does an individual resource get assigned an arbitrary property/value? | |
| 18:27:47 | efried | E.g. how does a PCI_DEVICE get a PCI address associated with it? | |
| 18:28:31 | efried | Perhaps the answer is, "In placement, it doesn't" ? | |
| 18:28:49 | dansmith | efried: in placement, it doesn't | |
| 18:28:57 | dansmith | efried: placement tracks resource types and quantities | |
| 18:29:03 | dansmith | it's not a k=v store | |
| 18:29:28 | openstackgerrit | Merged openstack/nova master: [placement] Update user doc with api-ref link https://review.openstack.org/499635 | |
| 18:29:37 | dansmith | placement tracks how many are present and allocated, | |
| 18:29:38 | dansmith | nova has to track *which* one is allocated | |
| 18:30:18 | efried | dansmith So placement knows how many, but not individual identifiers (UUIDs) | |
| 18:30:31 | efried | and nova knows which ones are allocated | |
| 18:30:32 | dansmith | correct, with an exception | |
| 18:30:39 | efried | where does the split occur? | |
| 18:31:06 | dansmith | if a pci device has multiple VFs, it might be modeled as a resource provider of VF_THINGY resources | |
| 18:31:17 | dansmith | but still, placement will only know that it has 16 to provide, of which 3 are used | |
| 18:31:36 | dansmith | where does what split occur? | |
| 18:32:20 | efried | Yeah, so placement can tell me "X a resource_provider providing 8 GPUs with traits(a,b,c)" | |
| 18:32:41 | efried | And nova can say "take GPU with UUID Y from resource_provider X and assign it to VM 34" | |
| 18:32:57 | efried | But where did we find out that one of the 8 GPUs was called Y? | |
| 18:33:36 | dansmith | well, none of that actually works today really, so.. nowhere :) | |
| 18:33:37 | dansmith | however, | |
| 18:33:44 | dansmith | nova has tables for pci devices reported from the compute nodes, with actual addresses and stuff | |
| 18:33:46 | dansmith | if that's what you mean | |
| 18:35:06 | efried | dansmith But those tables aren't plugged into placement/RP yet, right? | |
| 18:35:37 | dansmith | they won't be really | |
| 18:35:50 | efried | Certainly not in their current form, yeah. | |
| 18:36:02 | dansmith | there is some work to do to plug in a pci device as a provider, under the compute provider, which provides VF_THINGYs or whatever | |
| 18:36:10 | dansmith | that's the nested resource providers stuff yeah | |
| 18:36:53 | openstackgerrit | Dan Smith proposed openstack/nova master: Pre-create migration object https://review.openstack.org/498950 | |
| 18:37:24 | efried | dansmith Yeah, okay. I'm trying to synthesize ^ with stuff jaypipes has said plus functionality needed by e.g. HyperV (claudiub) and PowerVM (moi) and others (various DOA blueprints) for discussion at the PTG. | |
| 18:37:43 | dansmith | yeah, good effing luck with that :P | |
| 18:38:48 | efried | So it seems like what came out of the above is: We don't have a framework in place that knows how to identify individual resources within a RP. | |
| 18:38:52 | efried | And | |
| 18:38:58 | efried | We need that. | |
| 18:39:23 | efried | If we're going to talk about device passthrough of any sort (GPU, SR-IOV, etc.) | |
| 18:39:37 | dansmith | yes, I still have minor issues with the way you're phrasing it, | |
| 18:39:39 | dansmith | but only because RP is really a placement thing and placement won't ever know *which* one | |
| 18:39:48 | dansmith | but from nova's perspective it'll be closer to what you're saying | |
| 18:39:58 | dansmith | well, | |
| 18:40:00 | efried | dansmith Please do help me phrase things correctly. | |
| 18:40:07 | dansmith | pci passthrough of specific SRIOV devices works today, | |
| 18:40:14 | efried | via placement? | |
| 18:40:40 | dansmith | it won't ever be *via* placement, but we'll be using placement to do our accounting of *how many* of those things we have available | |
| 18:40:49 | efried | So part of what I'm driving here is total replacement of the existing PCI passthrough setup. | |
| 18:40:57 | dansmith | it won't be materially different from today, except faster, cleaner, and less racy | |
| 18:41:15 | dansmith | no, because the existing pci passthrough stuff knows *which* and placement does not and will not | |
| 18:41:37 | dansmith | in tha' future, | |
| 18:41:50 | dansmith | we'll pick a host with enough GPU_THINGs, reserve one of the eight it provides, | |
| 18:42:04 | dansmith | and then later we get to the compute mostly guaranteed that one will be available, where we'll pick the actual one | |
| 18:42:15 | dansmith | but placement will only ever know that we're using one of the eight | |
| 18:42:16 | efried | Who's that second 'we'? | |
| 18:42:24 | efried | The virt driver? | |
| 18:42:38 | efried | The resource tracker? | |
| 18:42:40 | dansmith | the we before "pick the actual one" ? | |
| 18:42:44 | efried | yeah | |