| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-13 | |||
| 20:50:40 | dansmith | efried: default=set() isn't going to work anyway | |
| 20:50:55 | efried | it's what RequestGroup is doing | |
| 20:51:03 | efried | so, in what way not work? | |
| 20:51:31 | dansmith | efried: IIRC, that will result in every object getting the same set(), potentially cross-polluting between requests | |
| 20:51:41 | dansmith | because the field is once per definition, and done at import time | |
| 20:51:47 | efried | oh, neat. | |
| 20:52:19 | dansmith | I don't see request group doing that | |
| 20:52:46 | dansmith | er, maybe I'm looking in the wrong place | |
| 20:53:22 | dansmith | ah yeah I see | |
| 20:54:09 | dansmith | oh, hmm, maybe we copy the field's definition in obj_set_defaults, hang on | |
| 20:54:17 | dansmith | ISTR that coming up and we hacked around it that way | |
| 20:54:44 | dansmith | yeah https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L588 | |
| 20:54:57 | dansmith | alright, so ignore me I guess | |
| 20:55:31 | dansmith | a little dangerous but probably not in practice | |
| 20:55:47 | efried | then back to the original question, how should I manage this field? | |
| 20:55:48 | dansmith | but no, it doesn't help you not have to check for setted-ness | |
| 20:56:01 | dansmith | efried: you should always set it, or call obj_set_defaults() after you create it | |
| 20:56:11 | efried | but not via __init__ | |
| 20:56:22 | dansmith | I think you know the answer to that :) | |
| 20:56:35 | efried | would this be a thing for __new__ somehow? | |
| 20:56:55 | dansmith | it's less of a problem for a transient rpc-only object, but we really shouldn't create more examples for people to copy, not knowing the problems | |
| 20:56:56 | dansmith | efried: no | |
| 20:57:18 | mriedem | RequestGroup just sets defaults if it lazy-loads a field and i think all fields have defaults | |
| 20:57:24 | mriedem | is how it works around have to check set-ness | |
| 20:57:29 | mriedem | *having to | |
| 20:57:34 | dansmith | sure, you can do that if you want | |
| 20:59:20 | efried | So RequestSpec.from_components does obj_set_defaults(), meaning that if I define the field with a default, any code path that starts with from_components I can count on that field being set. | |
| 20:59:46 | dansmith | is that a question? | |
| 20:59:58 | efried | an assertion for you to refute if it's wrong | |
| 21:00:10 | dansmith | if what you say is true, then yes | |
| 21:00:33 | dansmith | however, I thought from_components is supposed to go away in the Z release when bauzas finally cleans it up | |
| 21:00:51 | dansmith | so, not sure that's the best assumption to make, although the way things are going, it'll never happen :) | |
| 21:01:27 | dansmith | I'll also note that in the G days, Z sounded like "forever", but that's becoming less true | |
| 21:06:25 | efried | is obj_set_defaults recursive into an ObjectField? | |
| 21:06:41 | mriedem | zzzeek: if/when you're around, it'd be nice if you could sniff out this simple join/filter query being proposed https://review.opendev.org/#/c/694462/2/nova/db/sqlalchemy/api.py@2005 just from an efficiency standpoint | |
| 21:06:56 | mriedem | low priority though | |
| 21:06:56 | efried | i.e. will RequestSpec.obj_set_defaults percolate into my new RequestSpec.placement_shit ObjectField and set the defaults inside that guy? | |
| 21:07:22 | dansmith | no | |
| 21:07:25 | mriedem | do not rely on from_components | |
| 21:07:39 | dansmith | I gotta run out for a bit, and likely I won't be back | |
| 21:07:41 | mriedem | i've been trying to burn all of that crap out the last several releases while sylvain is skiing | |
| 21:07:52 | dansmith | mriedem: lol | |
| 21:08:08 | dansmith | mriedem: as "a french" I believe it's his actual right to ski while others work :) | |
| 21:08:15 | mriedem | https://review.opendev.org/#/q/project:openstack/nova+branch:master+topic:bp/request-spec-use-by-compute | |
| 21:08:46 | mriedem | oh btw, as my parting shot on all of that https://review.opendev.org/#/c/697697/, | |
| 21:08:58 | mriedem | likely a lot of that crap can't be removed until we bump the major on the conductor rpc | |
| 21:09:01 | mriedem | and by we i mean dadn | |
| 21:09:03 | mriedem | *dan | |
| 21:09:09 | efried | freudian | |
| 21:09:10 | mriedem | i left details in https://review.opendev.org/#/c/697697/ | |
| 21:09:29 | dansmith | lervely | |
| 21:09:42 | dansmith | so, efried sounds like I'll review that in Jan | |
| 21:09:54 | efried | ack, enjoy your time off | |
| 21:10:00 | dansmith | o/ | |
| 21:10:29 | mriedem | talk to you monday | |
| 21:10:36 | mriedem | o-) | |
| 21:10:52 | zzzeek | mriedem: ugh jaypipes is gone? | |
| 21:11:02 | mriedem | he's been gone | |
| 21:12:41 | zzzeek | mriedem: so..."manual joins" means, list of things we load in a separate query and merge in Python ? | |
| 21:14:52 | mriedem | yeah | |
| 21:17:06 | mriedem | i've never really been sure why we distinguish honestly | |
| 21:17:34 | zzzeek | mriedem: if BlockDeviceMapping.instance_uuid is a foreign key to Instance, that would mean you don't actually have to include the Instance table in this query, right? | |
| 21:18:28 | zzzeek | mriedem: unless the "model query" aspect of this makes that more complicated | |
| 21:18:49 | mriedem | bdm.instance_uuid is a fkey to instances.uuid, i can confirm that - as for your question, idk | |
| 21:19:00 | mriedem | but... | |
| 21:19:06 | mriedem | yeah we shouldn't need the join | |
| 21:19:16 | zzzeek | mriedem: OK ill put it in the comment, if model+_query needs to look at other cols on Instance that might be the issue | |
| 21:19:38 | mriedem | select bdm.instance_uuid from bdms where instance_uuid in (instance_uuids) and boot_index=0 and destination_type=volume; | |
| 21:19:40 | mriedem | yeah? | |
| 21:19:56 | mriedem | the join seemed overly complicated to me for this | |
| 21:20:01 | mriedem | but needed other eyes | |
| 21:20:02 | zzzeek | mriedem: yes, but that's as long as model_Qeury is notlike "and instance.user_token_whatever == admin" or something | |
| 21:21:05 | mriedem | i think in this case the query isn't scoped to a project | |
| 21:21:07 | mriedem | so we should be ok | |
| 21:21:46 | mriedem | project_only=False by default and read_deleted='yes' means we don't modify the query to filter on deleted | |
| 21:21:55 | mriedem | so hell we likely don't even need model_query with this | |
| 21:22:00 | mriedem | just normal sqla orm | |
| 21:22:14 | zzzeek | woop | |
| 21:24:09 | mriedem | thanks mike | |
| 21:30:27 | mriedem | re nova-network removal series, bottom 2 are pretty easy and +2ed https://review.opendev.org/#/c/697151/ | |
| 21:30:48 | mriedem | just removing dead code | |
| 21:38:11 | gibi | mriedem: kicked the deads | |
| 21:43:46 | mriedem | pulling an all-nighter! | |
| 21:47:24 | openstackgerrit | Sundar Nadathur proposed openstack/os-traits master: Add a trait that compute manager can handle accelerator requests. https://review.opendev.org/698961 | |
| 21:48:01 | gibi | mriedem: baby sitting | |
| 21:48:34 | gibi | mriedem: but not for long | |
| 21:50:35 | mriedem | back to the future 3 huh | |
| 21:52:27 | gibi | it worked like a charm | |
| 21:54:26 | mriedem | how old? | |
| 21:55:35 | gibi | 7. I think he liked the first two too | |
| 21:56:19 | gibi | he asked for the third so I complied | |
| 21:56:23 | mriedem | heh | |
| 21:56:35 | mriedem | is it time for star wars? you could keep him busy for an entire weekend | |
| 21:57:11 | gibi | he has already consumed half (the better half) of star wars | |
| 21:57:38 | gibi | and I'm not a star wars fan. I grew up on star trek instead | |
| 21:57:59 | mriedem | then i will hold my tongue | |
| 21:59:40 | gibi | but I accept that the general public does not agree with me :) | |
| 22:01:33 | gibi | I think I stopped star wars when jar jar binks appeared | |
| 22:07:38 | gibi | now the parents are back so I'm dropping. Have a nice evening | |
| 22:21:15 | openstackgerrit | Merged openstack/nova stable/pike: Fix listing deleted servers with a marker https://review.opendev.org/690735 | |