| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 18:17:48 | sean-k-mooney | spatel: not much sorry | |
| 18:18:03 | spatel | no worry!! | |
| 18:18:12 | sean-k-mooney | dansmith: i would love to take that approch | |
| 18:20:08 | Sundar | dansmith: sean-k-mooney: OK, thanks for your time. | |
| 18:22:19 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: Re-propose numa-aware-live-migration spec https://review.openstack.org/599587 | |
| 18:23:24 | jaypipes | holy crap, I missed a bunch... :( sorry, reading back up... | |
| 18:25:12 | sean-k-mooney | mriedem: i found a relitvly simple and reliable way to repoduce https://bugs.launchpad.net/nova/+bug/1751923 by the way | |
| 18:25:12 | openstack | Launchpad bug 1751923 in OpenStack Compute (nova) "_heal_instance_info_cache periodic task bases on port list from nova db, not from neutron server" [Medium,In progress] - Assigned to Maciej Jozefczyk (maciej.jozefczyk) | |
| 18:50:57 | mriedem | sean-k-mooney: how is that? take down the neutron agent and reboot the vm or something? | |
| 18:52:53 | sean-k-mooney | mriedem: i added a scipt to the bug | |
| 18:53:16 | sean-k-mooney | you can cause it or a similar effect via the api | |
| 18:54:27 | sean-k-mooney | basically if you send the api request to detach a port to neutron and reboot the vm you end up with it broken | |
| 18:54:56 | sean-k-mooney | and you cant use openstack server add port or remove port to fix it | |
| 18:55:12 | sean-k-mooney | mriedem: https://bugs.launchpad.net/nova/+bug/1751923/comments/10 | |
| 18:55:12 | openstack | Launchpad bug 1751923 in OpenStack Compute (nova) "_heal_instance_info_cache periodic task bases on port list from nova db, not from neutron server" [Medium,In progress] - Assigned to Maciej Jozefczyk (maciej.jozefczyk) | |
| 18:55:58 | sean-k-mooney | mriedem: i was debating if i coudl make this into some kind of functional regression test but not sure how yet | |
| 18:58:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Apply DISTINCT clause to CellMapping.get_by_project_id for postgres https://review.openstack.org/619061 | |
| 19:01:40 | mriedem | slaweq: hopefully this ^ does the ojb | |
| 19:01:42 | mriedem | *job | |
| 19:02:03 | mriedem | i'm no pg expert though | |
| 19:12:41 | mriedem | my socks have officially been rocked off | |
| 19:16:13 | sean-k-mooney | find something interesting | |
| 19:31:39 | prometheanfire | I'm not one either, but do use it for openstack, pg question? | |
| 19:32:10 | prometheanfire | ok, above my head too :D | |
| 19:39:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Add recreate test for bug 1799892 https://review.openstack.org/619075 | |
| 19:39:48 | openstack | bug 1799892 in OpenStack Compute (nova) "Placement API crashes with 500s in Rocky upgrade with downed compute nodes" [Medium,In progress] https://launchpad.net/bugs/1799892 - Assigned to Eric Fried (efried) | |
| 19:39:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Consider root id is None in the database case https://review.openstack.org/619076 | |
| 19:50:31 | mriedem | upgrade issue in rocky so would be good to get that backport series moving ^ | |
| 19:53:02 | mriedem | the xenserver CI seems to be busted | |
| 19:54:21 | openstackgerrit | Jack Ding proposed openstack/nova-specs master: Flavor Extra Spec and Image Properties Validation https://review.openstack.org/618542 | |
| 19:54:52 | dansmith | mriedem: not merged in master yet right? | |
| 19:58:28 | mriedem | just rechecked it in the gate | |
| 20:00:00 | efried | mriedem: should we assign both branches of that bug back to tetsuro? | |
| 20:00:27 | efried | I at least put the master side back. | |
| 20:01:36 | mriedem | in launchpad? | |
| 20:01:36 | mriedem | yes | |
| 20:12:20 | dansmith | mriedem: so I've been half-assedly working on trying to do the manual metadata fill on single-instance-get | |
| 20:12:36 | dansmith | lots of weird things break just within db_api if we return a dict instead of a model | |
| 20:12:44 | dansmith | so I can go chase and fix all those things, | |
| 20:13:12 | dansmith | but I think jaypipes once flexed his db muscle and argued there was some way to change the way we do the joining to avoid the rowsplosion | |
| 20:13:23 | dansmith | so maybe we should challenge him on that before we get too far | |
| 20:14:06 | mriedem | you know how i get when jay flexes his muscles | |
| 20:14:12 | mriedem | i melt | |
| 20:14:26 | dansmith | yep | |
| 20:14:45 | dansmith | it's grotesque yet oddly satisfying | |
| 20:14:56 | jaypipes | ewww. | |
| 20:15:17 | jaypipes | dansmith: are you referring to the eagerload thing? | |
| 20:15:26 | dansmith | no | |
| 20:15:35 | dansmith | jaypipes: in the oldentimes, | |
| 20:15:47 | dansmith | we would load an instance, joined with metadata, system_metadata, etc | |
| 20:16:11 | dansmith | which would end up returning X*Y*Z rows for X instances, with Y rows of metadata and Z rows of sysmeta | |
| 20:16:17 | jaypipes | right. | |
| 20:16:29 | dansmith | which was the reason RAX failed to deploy icehouse after we moved flavor data to sysmeta | |
| 20:16:40 | dansmith | now we query metadata separately from the actual instance load | |
| 20:17:05 | dansmith | but I thought a convo with you a long time ago yielded you saying that we could do an inner-outer-blue-unicorn join to avoid that somehow | |
| 20:17:54 | jaypipes | yes, we can do a single query to get all instance metadata (and sysmeta) for all selected instances. | |
| 20:18:21 | dansmith | to be clear, | |
| 20:18:24 | jaypipes | a query that would just yield (instance_uuid, key, value) tuples. | |
| 20:18:33 | dansmith | no, that's not what I'm asking | |
| 20:19:18 | dansmith | the old query was returning the instance data itself, and the metadata key,value and the sysmeta key,value | |
| 20:19:31 | dansmith | so the instance data was repeated for every row in meta, sysmeta | |
| 20:19:48 | dansmith | that was a single query for the instance itself, and the metadata(s) | |
| 20:20:10 | dansmith | I know we can query the instance, and then query for the metadatas efficiently | |
| 20:20:12 | dansmith | but it's two queries | |
| 20:20:27 | dansmith | that's basically what we do now | |
| 20:20:50 | jaypipes | ok. well, that's the most efficient way to solve this particular problem. | |
| 20:20:56 | dansmith | two queries? | |
| 20:20:59 | jaypipes | yup. | |
| 20:21:03 | dansmith | okay | |
| 20:21:19 | dansmith | I'm pretty sure you called me a stupid ignoramus for doing that back in the icehouse days, | |
| 20:21:21 | jaypipes | I thought we were doing >1 query for grabbing instance metadata and system metadata | |
| 20:21:33 | dansmith | well, we are, but only for convenience | |
| 20:21:34 | jaypipes | no, I never called you anything. | |
| 20:21:38 | dansmith | YOU DID | |
| 20:22:10 | dansmith | we're doing three queries now, instance, meta, sysmeta | |
| 20:22:11 | jaypipes | if I ever said anything about performance it would have been because we were doing a query on instances, then *for each instance* issuing a query to get some instance metadata. | |
| 20:22:21 | dansmith | we're not doing that | |
| 20:22:25 | jaypipes | ok, coools. | |
| 20:22:37 | jaypipes | I can reduce the meta + sysmeta to a single query. | |
| 20:22:42 | dansmith | so I guess that means I have to keep plugging at this | |
| 20:22:52 | dansmith | jaypipes: yea, feel free, but that's separate from my other work here | |
| 20:23:08 | jaypipes | k. is there anything I can help you with on your work here? | |
| 20:23:21 | dansmith | jaypipes: you just did | |
| 20:23:24 | dansmith | thanks | |
| 20:23:25 | jaypipes | :) | |
| 20:23:40 | jaypipes | well, at least that gives me something to smile about today. | |
| 20:23:42 | jaypipes | thanks. | |
| 20:25:19 | jaypipes | FTR, on the cyborg thing, I *also* believe that cyborg should be modeling should be inventories, not RPs with tons of traits masquerading as resource classes. | |
| 20:25:38 | jaypipes | dansmith: ^ | |
| 20:25:47 | dansmith | jaypipes: yay. | |
| 20:25:59 | jaypipes | indeed. | |
| 20:26:04 | mriedem | dansmith: on top of the improved join on what you're doing, i think it's a 2-part change in that the metadata api doesn't need to be pre-loading on system_metadata - at least not anymore | |
| 20:26:42 | dansmith | mriedem: yeah, so that will address the acute issue right? | |
| 20:26:45 | mriedem | last i looked the only thing in meta-api that would use sysmeta is a vendor data provider if configured | |
| 20:26:53 | dansmith | maybe I should punt this until we have a better reason to do this work | |
| 20:27:02 | mriedem | i believe so, and i think that's what the workday ops guy said he did in the ML | |
| 20:27:06 | mriedem | heh | |
| 20:27:18 | mriedem | see, i started trying to do what you said and sparks flew immediately | |
| 20:27:19 | mriedem | and i gave up | |
| 20:27:34 | dansmith | oh did you | |