| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-13 | |||
| 20:33:03 | dansmith | no | |
| 20:33:29 | dansmith | reqspec.PlacementShit = ObjectField('PlacementShit'), | |
| 20:33:48 | dansmith | then in the PlacementShit object, whatever fields you need | |
| 20:33:52 | dansmith | root_required is what, a boolean? | |
| 20:33:58 | efried | set of traits | |
| 20:33:59 | dansmith | or a list of traits | |
| 20:34:08 | efried | prefer a set if poss, to squash dups | |
| 20:34:10 | dansmith | so root_required = ListOfStringsField() | |
| 20:34:26 | efried | We have a SetOfStringsField, any reason to avoid it? | |
| 20:34:28 | mriedem | we do have a set of strings field, RequestGroup uses it | |
| 20:34:34 | dansmith | not sure we have one of those, but seriously we don't have to use sets everywhere, just run it through a set somewhere | |
| 20:34:43 | dansmith | no, if we have one that's fine | |
| 20:34:43 | mriedem | sets or bust! | |
| 20:34:48 | efried | cool | |
| 20:34:52 | dansmith | it's silly, IMHO, but... :) | |
| 20:34:53 | efried | thanks. | |
| 20:34:56 | mriedem | BagODicts | |
| 20:41:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Func test for qos live migration reschedule https://review.opendev.org/699015 | |
| 20:43:42 | efried | dansmith: and what's the accepted way to use default on a field? | |
| 20:44:15 | efried | e.g. default=set(), does that help me not have to check if present => check if None => check if empty? | |
| 20:46:07 | openstackgerrit | Merged openstack/nova-specs master: [ussuri][goal] Drop python 2.7 support https://review.opendev.org/698988 | |
| 20:48:07 | openstackgerrit | Merged openstack/nova stable/pike: Add functional regression test for bug 1849409 https://review.opendev.org/690734 | |
| 20:48:08 | openstack | bug 1849409 in OpenStack Compute (nova) pike "openstack server list --deleted --limit -1 hangs" [High,In progress] https://launchpad.net/bugs/1849409 - Assigned to Matt Riedemann (mriedem) | |
| 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 | efried | i.e. will RequestSpec.obj_set_defaults percolate into my new RequestSpec.placement_shit ObjectField and set the defaults inside that guy? | |
| 21:06:56 | mriedem | low priority though | |
| 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 | |