| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-12 | |||
| 20:53:10 | efried | self.mock_create_ephemeral = \ | |
| 20:53:10 | efried | mock.create_autospec(driver.LibvirtDriver._create_ephemeral) | |
| 20:53:10 | efried | fx = self.useFixture(fixtures.MonkeyPatch( | |
| 20:53:10 | efried | 'nova.virt.libvirt.driver.LibvirtDriver._create_ephemeral', | |
| 20:53:10 | efried | self.mock_create_ephemeral)) | |
| 20:53:10 | efried | self.mriedem_mock = fx.mock | |
| 20:53:36 | mriedem | ok, well... | |
| 20:53:43 | mriedem | i'm past caring really | |
| 20:55:04 | efried | mriedem: You're right, though, that create_autospec ought to be a mock you can assert on. | |
| 20:55:28 | mriedem | i just hate the libvirt driver unit tests | |
| 20:55:31 | mriedem | but that's not news | |
| 20:55:40 | efried | mriedem: I've got +2s on the bottom nine patches in the neutron port binding series. | |
| 20:55:52 | mriedem | hot diggity dog | |
| 20:56:00 | mriedem | how many patches are there? 25? | |
| 20:56:12 | efried | mriedem: I'm going to punt on the libvirt ones, at least unless someone begs. | |
| 20:56:25 | efried | looks like 15 | |
| 20:56:26 | mriedem | https://review.openstack.org/#/q/topic:bp/neutron-new-port-binding-api+(status:open+OR+status:merged) | |
| 20:56:52 | efried | yeah, those all show up in the series | |
| 20:57:08 | mriedem | thanks for hitting those, even before it was in a runway | |
| 20:57:15 | efried | yahyoubetcha. | |
| 20:57:25 | mriedem | despite me wanting to murder you for awhile on the ksa stuff... :) | |
| 21:00:50 | efried | mriedem: If I had a shiny nickel for every time someone wanted to murder me... | |
| 21:02:17 | efried | mriedem: Here's some great news on ksa adapter, btw. Once https://review.openstack.org/#/c/574784/ is in a release, we can stop sending raise_exc=False with every request! | |
| 21:05:39 | mriedem | small victories | |
| 21:07:13 | mriedem | you know, | |
| 21:07:18 | mriedem | this trusted certs thing, | |
| 21:07:28 | mriedem | doesn't seem like something that should be plumbed through the various virt drivers at all | |
| 21:07:32 | mriedem | should/needs to be | |
| 21:07:47 | mriedem | but that's how we eventually get from compute manager to image api download() | |
| 21:07:56 | mriedem | kind of sucks though | |
| 21:08:18 | mriedem | it doesn't have anything specific to do with the virt drivers at all | |
| 21:08:20 | mriedem | nor the guest | |
| 21:10:00 | mriedem | like, could we do something like monkey patch or partial the image download api method from the compute manager flows that call driver.spawn() and pass the instance.trusted_certs right there to download()? | |
| 21:10:06 | mriedem | so the virt drivers don't need to plumb all that in | |
| 21:10:23 | mriedem | dansmith: ^? | |
| 21:10:57 | dansmith | I mean | |
| 21:10:58 | dansmith | yes? | |
| 21:11:28 | dansmith | that seems kinda gross | |
| 21:11:39 | mriedem | i'm not saying it's awesome | |
| 21:11:42 | dansmith | the virt driver is just passing instance.trusted_certs to the image download stuff right? | |
| 21:11:53 | mriedem | but neither is doing this exact same plumbing in all of the virt drivers for someting that's virt agnostic | |
| 21:12:15 | dansmith | yeah, okay, but .. we already have all those paths, | |
| 21:12:32 | dansmith | we should clean it all up and unify what we can and not just partial our way to verification right? | |
| 21:12:38 | dansmith | because we need to raise something and have it handled properly, | |
| 21:12:50 | dansmith | and just doing that when the virt driver doesn't expect it is probably not "good for security" and stuff | |
| 21:13:55 | mriedem | yeah fine, | |
| 21:13:59 | mriedem | plus i'm not at all signing up for this | |
| 21:14:15 | mriedem | i'm just really sour on this by now | |
| 21:16:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Plumb trusted_certs through the compute service https://review.openstack.org/561262 | |
| 21:16:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 21:16:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add notification support for trusted_certs https://review.openstack.org/563269 | |
| 21:16:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158 | |
| 21:16:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add trusted certs to feature support matrix docs https://review.openstack.org/574890 | |
| 21:20:20 | mriedem | melwitt: i think you should definitely get in on this hot trusted certs action since it's in a runway slot for the umpteenth time https://review.openstack.org/#/c/561262/ - is the current not-yet-approved bottom of the series | |
| 21:20:36 | mriedem | i will ruin the rest api change tomorrow | |
| 21:39:02 | melwitt | mriedem: I'll try. I reviewed some of it back before we had runways and it looked mostly fine to me... then people like yourself found all sorts of problems with it | |
| 22:27:05 | mnaser | does the placement api have type of way of listing all inventories in a single http request | |
| 22:27:22 | mnaser | like "detail" or something along those lines (context: looking for a quick way to see *real* amount of resources available) | |
| 22:29:57 | melwitt | you can get inventories for a resource provider in one request, but not for all resource providers https://developer.openstack.org/api-ref/placement/#resource-provider-inventories | |
| 22:30:29 | melwitt | there's also the usages api but that won't show available, only used https://developer.openstack.org/api-ref/placement/#usages | |
| 22:30:46 | mnaser | so i have to make N requests i guess | |
| 22:30:54 | melwitt | AFAIK | |
| 22:31:06 | melwitt | efried: ^ | |
| 22:32:03 | efried | mnaser: True story. | |
| 22:32:52 | mnaser | i wonder if i can abuse `allocation_candidates` | |
| 22:32:55 | efried | N+1 unless you already know all the providers | |
| 22:33:04 | cdent | What does "all" mean in "all inventories"? | |
| 22:33:07 | mnaser | if i provide no filters | |
| 22:33:32 | cdent | you mean from all the compute nodes? | |
| 22:33:33 | mnaser | cdent: i'm no placement expert but it is the inventories of every single "resource provider" | |
| 22:33:38 | mnaser | so yes compute nodes | |
| 22:34:19 | cdent | yeah, you can probably get a sort of summary of everything by abusing /allocation_candidates but you need to express at least one resource requirement | |
| 22:34:28 | cdent | so 1MB of RAM is probably the most reliable way | |
| 22:34:35 | mnaser | so as i'm thinking about it, my purpose behind this is something like "how many instances of N flavor can i host right now" | |
| 22:34:45 | mnaser | so i think i can ignore the report and get my answer with /allocation_candidates | |
| 22:35:50 | cdent | mnaser: if you figure out something cool it would be interesting to see your solution | |
| 22:36:02 | efried | mnaser: sort of. You can use some of the existing utils to translate the flavor into a GET /allocation_candidates querystring. | |
| 22:36:15 | efried | mnaser: But that will tell you how many permutations of that one instance you can fit. | |
| 22:36:23 | mnaser | yeah this isn't necessarily something that is super super super accurate but a general health view | |
| 22:36:30 | efried | mnaser: e.g. you may actually only have *room* for one of them on host X, but you could do it in ten different ways. | |
| 22:37:09 | cdent | the provider summaries would help refine that | |
| 22:37:20 | mnaser | i probably won't go to that complicated of level but something that assumes i will only create instances of X flavor | |
| 22:37:59 | efried | mnaser: If you only want to know how many hosts can handle the flavor, you should use the GET /resource_providers call with the `resources` qparam. | |
| 22:38:56 | efried | Using that list to limit which providers you're querying inventories for... would be more efficient than getting inventories for all of 'em. | |
| 22:38:57 | cdent | the initial query made it sound like knowing usages (which provider_summairies has) was important, thus /allocation_candidates | |
| 22:39:10 | cdent | but if it just a count of providers then /resource_providers is the quicker path | |
| 22:39:35 | mnaser | yeah ideally i'd like to have something that says "space for 300 instances of type X" | |
| 22:39:50 | efried | mnaser: We definitely don't have anything like that yet. | |
| 22:40:09 | efried | you'll have to do the 300 math on your own regardless. | |
| 22:40:12 | efried | mnaser: But you have access to the api-ref, yah? | |
| 22:40:25 | efried | mnaser: https://developer.openstack.org/api-ref/placement/ | |
| 22:40:27 | mnaser | right, so maybe i should write up a small python script that interacts with nova api and placement api and pop out a table :) | |
| 22:40:42 | efried | look forward to seeing that :) | |
| 22:40:43 | cdent | translate flavor to resource, query /resource_providers appropriately, take length | |
| 22:40:56 | mnaser | yep | |
| 22:41:07 | mnaser | not sure if we have some 'contrib' place to throw things like that | |
| 22:41:28 | cdent | not as yet | |
| 22:42:23 | efried | mnaser: Have a look at nova.scheduler.utils.resources_from_request_spec | |
| 22:42:42 | efried | This is mainly where flavor-to-querystring magic happens. | |
| 22:43:32 | mnaser | time to add nova as a depenedency to a tiny python script :p | |