| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-13 | |||
| 15:31:08 | mriedem | stephenfin: it's called from PciDevice.create() https://review.openstack.org/#/c/523919/2/nova/objects/pci_device.py@234 | |
| 15:31:13 | mriedem | which will dirty the extra_info field | |
| 15:31:20 | mriedem | so that it gets save()'d later | |
| 15:31:30 | mriedem | updates = self.obj_get_changes() | |
| 15:31:35 | mriedem | will contain extra_info | |
| 15:31:52 | mriedem | hence this note in update_device: | |
| 15:31:53 | mriedem | # NOTE(yjiang5): extra_info.update does not update | |
| 15:31:53 | mriedem | # obj_what_changed, set it explicitly | |
| 15:32:37 | openstackgerrit | Merged openstack/nova master: Stabilize test_live_migration_abort func test https://review.openstack.org/527440 | |
| 15:34:59 | mriedem | dansmith: melwitt: here is the marker not found fix for the build_requests thing that came up yesterday https://review.openstack.org/#/c/527564/ | |
| 15:35:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transform instance.exists notification https://review.openstack.org/403660 | |
| 15:35:21 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add sample test for instance audit https://review.openstack.org/480955 | |
| 15:36:01 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add regression test for bug 1735407 https://review.openstack.org/526095 | |
| 15:36:03 | openstack | bug 1735407 in OpenStack Compute (nova) "[Nova] Evacuation doesn't respect anti-affinity rules" [Medium,In progress] https://launchpad.net/bugs/1735407 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 15:36:03 | dansmith | mriedem: ack | |
| 15:36:08 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add late server group policy check to rebuild https://review.openstack.org/525242 | |
| 15:36:11 | jaypipes | dansmith: ya, lemme do that right quick. thanks for the reminder | |
| 15:37:28 | mriedem | dansmith: left a comment in there about something i was thinking about last night wrt getting the build request via the marker up front and then being smarter about getting the build requests that come *after* that marker, rather than getting all of the build requests first, filtering them and then throwing out a bunch - which seems really inefficient | |
| 15:37:40 | mriedem | but my brain hasn't quite been able to put together how that could work | |
| 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 | mriedem | we can find the marker up front but i don't know if that helps us | |
| 15:38:30 | dansmith | mriedem: it's because of ^ that it was less easy to add | |
| 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 related pinning from __init__ of InstanceNUMATopology https://review.openstack.org/485554 | |
| 15:52:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: remove cpuset_reserved from __init__ of InstanceNUMATopology https://review.openstack.org/466030 | |
| 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 non overlapping sharing RPs https://review.openstack.org/519380 | |
| 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:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: Test allocation candidates: multiple aggregates https://review.openstack.org/518633 | |
| 15:56:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: Test helper: validate provider summaries https://review.openstack.org/518982 | |
| 15:56:16 | openstackgerrit | Jay Pipes proposed openstack/nova master: Fix accumulated nits in refactor series https://review.openstack.org/521189 | |
| 15:56:16 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add aggregates check in allocation candidates https://review.openstack.org/522407 | |
| 15:56:17 | openstackgerrit | Jay Pipes proposed openstack/nova master: Fix missing rps in allocation candidates https://review.openstack.org/522409 | |
| 15:56:17 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: func tests for multiple shared RPs https://review.openstack.org/498737 | |
| 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 | 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: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: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) | |