| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 18:12:27 | Sundar | dansmith: Ok, tried my luck there. Can we talk tomorrow same time? | |
| 18:12:48 | sean-k-mooney | perhaps we should do it on the cyborge channel not to flood nova | |
| 18:13:05 | dansmith | Sundar: honestly, I'm not sure we're making progress here | |
| 18:13:35 | dansmith | Sundar: and no, I can't be involved in every discussion, I'm just saying I reserve the right to be unhappy with the next round of the spec | |
| 18:13:35 | Sundar | sean-k-mooney: Sure. Same time tomorrow? | |
| 18:13:44 | dansmith | Sundar: you need more than just sean-k-mooney in agreement on this | |
| 18:13:49 | sean-k-mooney | i would honestly love to jsut protoype something end to end that works and see what it looked like | |
| 18:14:01 | dansmith | and getting everyone into a single irc channel at the same time is just not going to happen repetitively | |
| 18:14:08 | dansmith | sean-k-mooney: ++ | |
| 18:14:35 | Sundar | dansmith: Sorry to hear that. I thought we made progress by agreeing to skip os-acc. | |
| 18:15:08 | dansmith | sean-k-mooney: I'm getting spec fatigue I think.. a series of patches on both sides that actually does something we can evaluate might be a better stepping stone | |
| 18:15:18 | Sundar | sean-k-mooney: I am with you, but Cyborg folks are reluctant to move till Nova spec converges, so I am facing a catch-22 | |
| 18:15:33 | dansmith | sean-k-mooney: it'll be trivial to look at that and evaluate how things are being done | |
| 18:15:34 | sean-k-mooney | so lets create a feature branch | |
| 18:15:38 | dansmith | Sundar: no, that's not a legit argument | |
| 18:15:53 | dansmith | Sundar: you can put up patches against nova and cyborg and test them together without merging anything | |
| 18:15:59 | dansmith | we do it all the time for big complex things like this | |
| 18:16:31 | dansmith | if there isn't already, cyborg should have a fake driver that can just pretend to offer up devices and program them, | |
| 18:17:06 | dansmith | and that should be enough to do some interaction testing between the two services, even if nothing actually gets attached at the final step to the vm | |
| 18:17:07 | dansmith | sean-k-mooney: agree with that ^ ? | |
| 18:17:18 | Sundar | A feature branch upstream? | |
| 18:17:36 | sean-k-mooney | yes | |
| 18:17:38 | spatel | sean-k-mooney: do you have experience with rabbitmq ? | |
| 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 | |