Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-12
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
22:43:36 mnaser but that's useful
22:44:46 efried mnaser: The returned ResourceRequest is converted to querystring in nova.scheduler.client.report.SchedulerReportClient.get_allocation_candidates
22:45:00 efried mnaser: No, I figured you would copy/adapt the code you needed :P
22:45:23 efried I'm outta here, y'all.
22:47:24 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove max_size parameter from fake_libvirt_utils.fetch_*image methods https://review.openstack.org/574911
23:00:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Add enhanced KVM storage QoS quotas https://review.openstack.org/558530
23:00:37 mriedem pretty easy +W if someone wants to get this ^
23:10:45 openstackgerrit Matt Riedemann proposed openstack/nova master: api-ref: expand on various bdm parameters https://review.openstack.org/574805
23:21:02 mriedem http://logs.openstack.org/82/574482/2/check/nova-live-migration/9241290/logs/screen-n-cpu.txt.gz#_Jun_12_16_50_46_682790
23:21:02 mriedem dansmith: huzzah
23:22:02 tasker renewing timeout timer?
23:22:22 tasker or am I sticking my nose in something without understanding anything?
23:26:03 mriedem yup
23:26:17 melwitt tasker: context https://review.openstack.org/566696 and https://review.openstack.org/#/q/topic:heartbeat-active-calls+(status:open+OR+status:merged)
23:26:20 mriedem tasker: https://review.openstack.org/#/c/566696/9
23:30:19 tasker that's a neat idea!
#openstack-nova - 2018-06-13
00:39:02 openstackgerrit Merged openstack/nova master: fix tox python3 overrides https://review.openstack.org/572974
00:39:10 openstackgerrit Merged openstack/nova master: doc follow https://review.openstack.org/#/c/572195 https://review.openstack.org/573091
01:10:38 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Return all nested providers in tree https://review.openstack.org/559480
01:10:39 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Add microversion for nested allocation candidate https://review.openstack.org/565487
01:10:40 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Fix nits in placement-return-all-resources series https://review.openstack.org/573604
01:22:55 openstackgerrit gaofei proposed openstack/nova master: Fix typos https://review.openstack.org/574931
01:35:17 openstackgerrit jiang wei proposed openstack/nova master: Add action initiator attribute to the payload https://review.openstack.org/536243
01:59:08 openstackgerrit Naichuan Sun proposed openstack/nova master: XenAPI: define a new image handler to use vdi streaming https://review.openstack.org/486475
02:00:32 openstackgerrit Naichuan Sun proposed openstack/nova master: XenAPI: update the document related to vdi streaming https://review.openstack.org/568444

Earlier   Later