Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-13
15:38:08 mriedem dansmith: also, i wonder if some of this is why the build request stuff didn't play so nice with your new instance_list stuff + paging
15:38:10 dansmith well we have to filter them based on the json property so we kinda have to load them all right?
15:38:30 dansmith mriedem: it's because of ^ that it was less easy to add
15:38:30 mriedem we can find the marker up front but i don't know if that helps us
15:38:52 dansmith it doesn't because we still have to load them all to figure out where to start after the marker
15:38:57 mriedem sure,
15:39:03 mriedem how about this as an optimization though,
15:39:05 dansmith so could be one shortcut we could add maybe, but..
15:39:14 mriedem if we have a marker, get the build request up front and if not found, bail early
15:39:20 mriedem that would avoid the get_all())
15:39:38 mriedem chances are we aren't going to find a marker in the build request in most cases i wouldn't think
15:40:06 dansmith it's more round trips to the db, and getting the marker ahead of time doesn't really help us select a smaller get_all()
15:40:16 dansmith so I'm not sure it's really worth it, TBH, but.. if you think it's better
15:40:20 dansmith so imagine this scenario:
15:40:46 dansmith nova boot --min-instances=100, followed by a paged list of tens of instances per page
15:40:56 dansmith that could be a couple minutes where your markers are in the build requests
15:41:22 mriedem true
15:41:57 mriedem until the public cloud guys tell me in 18 months that we're spending too much time paging over build requests, i'll leave this alone :)
15:42:23 dansmith aye
15:42:39 stephenfin mriedem: OK, I know where I went wrong. Re-reviewed now
15:43:13 stephenfin dansmith: Mind reminding me why we don't do stuff like this with o.vo objects? https://review.openstack.org/#/c/523919/2/nova/objects/pci_device.py@177
15:43:24 mriedem stephenfin: cool thanks
15:43:59 stephenfin It was the reason for this whole series https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1636338
15:44:06 mriedem stephenfin: could just be laziness on the part of the consuming code,
15:44:18 mriedem i.e. instead of the calling code checking "if 'extra_info' in pci_device'"
15:44:58 dansmith stephenfin: it means that objects default to something being set that may not match what is in the database. so, if I wanted to do something like this:
15:45:38 dansmith d = objects.PciDevice(id=123, label="new_label"); d.save(), we would overwrite extra_info in the database with an empty dict
15:46:09 dansmith may not apply directly to this situation, but that's the pattern we've got elsewhere and it's super confusing to have some of them work like that, and others have silent defaults for some fields
15:46:58 mriedem stephenfin: also without that self.extra_info = {} in __init__, if you called PciDevice.create(), we'd fail here https://review.openstack.org/#/c/523919/2/nova/objects/pci_device.py@168
15:47:47 stephenfin mriedem: yeah, you'd have to harden that to include 'if 'extra_info' in self:' or the likes
15:48:00 mriedem that should really probably be something like, "if 'extra_info' in self: extra_info = self.extra_info else: extra_info = {}"
15:48:01 stephenfin I'd to do sooo much of that in aforementioned series
15:48:13 stephenfin mriedem: ++
15:50:07 stephenfin Oh, also, thanks for the re-explanation dansmith
15:50:30 dansmith np
15:52:25 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: remove cpuset_reserved from __init__ of InstanceNUMATopology https://review.openstack.org/466030
15:52:25 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: remove related pinning from __init__ of InstanceNUMATopology https://review.openstack.org/485554
15:53:23 dansmith <3
15:56:13 openstackgerrit Jay Pipes proposed openstack/nova master: handle traits with sharing providers https://review.openstack.org/517119
15:56:14 openstackgerrit Jay Pipes proposed openstack/nova master: Test alloc_cands with one RP shared between two RPs https://review.openstack.org/519617
15:56:14 openstackgerrit Jay Pipes proposed openstack/nova master: Test alloc_cands with non overlapping sharing RPs https://review.openstack.org/519380
15:56:15 openstackgerrit Jay Pipes proposed openstack/nova master: Test helper: validate provider summaries https://review.openstack.org/518982
15:56:15 openstackgerrit Jay Pipes proposed openstack/nova master: Test allocation candidates: multiple aggregates https://review.openstack.org/518633
15:56:16 openstackgerrit Jay Pipes proposed openstack/nova master: Add aggregates check in allocation candidates https://review.openstack.org/522407
15:56:16 openstackgerrit Jay Pipes proposed openstack/nova master: Fix accumulated nits in refactor series https://review.openstack.org/521189
15:56:17 openstackgerrit Jay Pipes proposed openstack/nova master: placement: func tests for multiple shared RPs https://review.openstack.org/498737
15:56:17 openstackgerrit Jay Pipes proposed openstack/nova master: Fix missing rps in allocation candidates https://review.openstack.org/522409
15:56:24 jaypipes dansmith, gibi: voila. ^
16:00:37 gibi jaypipes: looking
16:01:50 openstackgerrit Lajos Katona proposed openstack/nova master: WIP: Add nested resources to server moving tests https://review.openstack.org/527728
16:02:43 gibi jaypipes: +2 from me
16:10:36 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: vSCSI https://review.openstack.org/526094
16:14:40 dansmith jay_tampa: +W on the bottom three.. I had a question on Bottom-4 that you didn't answer
16:41:12 stephenfin moshele: Just the man I'm looking for. What's the possibility that you could take a look at https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/share-pci-between-numa-nodes ?
16:47:30 moshele stephenfin: will do, but tomorrow
16:47:40 stephenfin moshele: No problem. Thanks :)
16:50:13 klindgren un: Cell rabbitmq, nova-conductor, nova-computes (attached to the cell rmq), cell DB. Now in cellv1 we run nova-manage at both the api cell and the child cell level. I assume the same is required with cellsv2?
16:50:13 klindgren Hello, Working on setting up a new pike cloud with cellsv2 running on it. and trying to get a list of services that need to be ran at each level. I found https://docs.openstack.org/nova/latest/user/cellsv2-layout.html. But I just want to confirm. So at the Top level API cell. I need to run: nova-api, nova-consoleauth, nova-spicehtml5proxy, nova-conductor, API rabbitmq, API DB, Cell0 DB. Then in each cell I need to r
16:52:24 dansmith klindgren: ye[
16:52:28 dansmith er yup
16:52:45 klindgren So all thats need in child cells now is nova-conductor
16:53:07 dansmith and compute :)
16:53:49 mriedem scheduler is top level
16:53:52 mriedem didn't see that in your list
16:54:10 dansmith oh yeah
16:54:14 dansmith you will want a scheduler
16:54:26 klindgren and placement
16:54:48 mriedem yes
16:54:53 mriedem placement is assumed to be global
16:55:04 mriedem cern is doing it per-cell to start
16:55:21 mriedem i think for perf reasons
16:55:30 mriedem if you're not at cern scale, global is your long-term friend
16:55:34 mriedem imo
16:55:37 dansmith yup
16:56:50 cfriesen__ Is it possible to reset specific individual tenant quotas back to the default value? (by writing -1 to them, maybe?) What about specific user/tenant quotas? (The code there makes it look like you can't set the max to more than the custom tenant quota.)
16:57:15 melwitt except for console proxies, after they move (because they'll need cell database access and don't have instance uuid)
16:57:30 mriedem cfriesen__: once you start overriding default quotas for a tenant, you're stuck
16:57:39 mriedem unless you remove those entries from the db
16:57:51 melwitt cfriesen__: writing -1 will make them unlimited, so that's not what you want either
16:58:04 mriedem remember that the lookup order for quota is (1) per-project quota table (2) global quota_classes table, (3) config
16:58:14 mriedem so you'd have to remove (1)
16:58:19 klindgren do you guys have a blog post or something that explains all the nova-manage commands to run now to setup cellsv2?
16:58:22 melwitt yup, that
16:58:37 mriedem klindgren: https://docs.openstack.org/nova/latest/user/cells.html
16:59:02 mriedem klindgren: there is basic setup stuff in there and in the install guide
16:59:12 mriedem the cellsv1->v2 portion is admittedly light
16:59:34 mriedem klindgren: and you know about https://etherpad.openstack.org/p/cellsv1-to-v2-migration
17:00:18 cfriesen__ mriedem: so we have a way to remove *all* per-tenant quotas, but no way to remove individual ones?
17:00:42 klindgren yea - right now just getting a pike cloud with all the new features enabled on it (cellsv2, network aware placement, neutron routed networks, ect ect). So we can start working on the migration to that. So not currently concerned with cellsv1 -> cellv2
17:00:46 mriedem cfriesen__: this ?https://developer.openstack.org/api-ref/compute/#revert-quotas-to-defaults
17:00:59 mriedem klindgren: ack
17:01:24 cfriesen__ mriedem: yeah. so you can revert all the quotas for a tenant back to defaults, and you can override specific quotas, but you can't revert specific quotas back to defaults
17:01:26 mriedem cfriesen__: yes correct, https://developer.openstack.org/api-ref/compute/#revert-quotas-to-defaults removes all of the per-tenant quota
17:01:47 mriedem cfriesen__: you'd need like a DELETE /os-quota-sets/{tenant_id}/{quota_key} or something
17:01:49 mriedem which we don't have
17:02:16 cfriesen__ right. okay, thanks
17:02:44 klindgren mriedem, thanks for the link, I thought I looked at this, but I guess I just didn't scroll down enough :-/
17:04:04 mriedem klindgren: that reminds me of something sdague posted recently,
17:04:16 mriedem at this point, we should probably move the 'setup of cellsv2 and faqs' to the top of page
17:04:22 mriedem and the cellsv1/v2 manifesto to the bottom of page

Earlier   Later