Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-09
18:20:00 dansmith anyway, this'll require an ovo release before we can use either of these, and I don't even know how that happens these days, but I think we'll be able to reparent things like your new request classes,
18:20:07 dansmith and get them the default behavior you want
18:21:29 efried dansmith: I'm not sure I understand how this differs from using the existing syntax, considering the deepcopy we've identified previously. It looks like it might let you do extra things during the initialization that a deepcopy wouldn't account for; but afaict nobody is asking for that?
18:21:53 dansmith efried: which are you talking about?
18:22:02 dansmith the default_fn one?
18:22:43 efried Oh, you said "below", I was waiting for another link in IRC. Looking at the other patch now....
18:22:43 efried default_fn, yes.
18:23:07 dansmith the reason I actually wrote that one is more so you can provide a class than a function
18:23:13 ralonsoh efried, ^^
18:23:13 openstack bug 1844568 in tempest "[compute] "create_test_server" if networks is undefined and more than one network is present" [Medium,In progress] https://launchpad.net/bugs/1844568 - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
18:23:13 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: DNM: Test global tempest changes for bug 1844568 https://review.opendev.org/701799
18:23:33 efried ralonsoh: ack
18:24:13 dansmith yes, it'll still get deepcopy'd for compat, but not knowing that detail, it's more intuitive for just providing a callable thing like a class and having it instantiated
18:24:36 dansmith you know, I actually might be able to eliminate the deepcopy if you provide a _fn,
18:24:48 dansmith if I make the default wrapper do the deepcopy
18:25:51 efried as long as that wouldn't break anyone already relying on the deepcopy...
18:26:12 dansmith yeah, that's what we need to avoid, so I was just going to punt on it
18:26:31 dansmith but I'm not sure it'd be legit to be relying on that subtle of a detail
18:26:43 sean-k-mooney ralonsoh: is that to deal with the fact that somethins there are multile network and in somecase we race there creation if we change concurancy > 2
18:26:56 ralonsoh sean-k-mooney, yes
18:27:44 efried sean-k-mooney: trying to tackle the "Multiple networks found" CI errors that are making 80% of our CI runs fail.
18:27:45 sean-k-mooney ok in some cases where you are using tempest without floating ip we still need to be able to specify a network for the tempset clietn to be abel to ssh in on
18:27:52 sean-k-mooney i assume that will still work
18:28:16 ralonsoh sean-k-mooney, yeah, from the neutron channel
18:28:17 ralonsoh http://paste.openstack.org/show/788211/
18:28:18 efried I think that's what we're trying to find out
18:28:31 efried possibly "can be made to work"
18:30:06 sean-k-mooney well its more we support using tempest on real clouds for interop testing in that case we suppro specify a public network where you vm can directly create ports instead of using fip
18:30:30 sean-k-mooney im jsut making sure that if we create network for the compute test we can still support that when we need too
18:30:46 sean-k-mooney i can move to the neuton channel by the way if that makes more sense
18:31:50 sean-k-mooney i dont in prinsipal see an issue with createing a network for each trest although i know that some clould like rackspace used to have neutron but not allow tenant to call the api
18:35:07 efried See, I don't understand any of that, and don't especially want to take the time to learn it. I just want to make our CI not fail for reasons unrelated to the code being tested.
18:35:21 sean-k-mooney https://github.com/openstack/tempest/blob/97052fae121174b9d6daa51684c03f730dc74683/tempest/config.py#L303-L309
18:35:32 sean-k-mooney im refering to this config option by the way
18:36:21 efried I like where this is going, thank you.
18:36:21 efried dansmith: added a comment in https://review.opendev.org/#/c/701795/
18:36:26 sean-k-mooney and there is also a seperate config for ssh verification
18:36:28 sean-k-mooney https://github.com/openstack/tempest/blob/97052fae121174b9d6daa51684c03f730dc74683/tempest/config.py#L831-L834
18:36:32 dansmith efried: yep, replying
18:37:51 efried sean-k-mooney: I did notice that we're doing this explicit network setup in a different method, prepare_instance_network, based on some other conf options.
18:38:38 efried but understanding what those conf options mean, and why certain tests would want to do that but others wouldn't... again, deeper than I want to go.
18:39:57 sean-k-mooney well to be clear i have not fully groked what ralonsoh is change yet
18:40:23 ralonsoh groked?
18:40:26 sean-k-mooney i just know that there are some case where always createing neutron network might be an issue
18:40:45 sean-k-mooney ralonsoh: formed a complete understanding of
18:40:58 sean-k-mooney https://en.wikipedia.org/wiki/Grok
18:42:19 ralonsoh sean-k-mooney, maybe we can do the opposite: in those cases where the network creation is an issue, we can disable it
18:43:37 sean-k-mooney well the idea fo the fixed network was so you could execute test in an enve where the network were precreated. in that case you wont have the multiple network isue anyway
18:43:56 sean-k-mooney so if that config is defiend you would be able to jsut not create teh network and use the one set in the config
18:44:14 ralonsoh agree
18:45:40 sean-k-mooney for the ssh verificaiton im also wondering if you need to create a router too? instead of an isolated network?
19:00:03 sean-k-mooney efried: ralonsoh i left a comment on the review. i think in general this would make sense just would need someone more familar to check this wont break things
19:01:10 sean-k-mooney another example of when you need to use fixed netowrkisn is usign tempest with ironic and flat netorkign. so its not just for rackspace.
19:01:43 sean-k-mooney that said you can deploy ironic with neutron netorks too but i still dont know how common that is
19:16:07 dustinc dansmith: Is there a chance that you can check this out and maybe wf+1? It is just a small update to the Provider Config File spec. https://review.opendev.org/#/c/693414/
20:14:37 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: Ensure source service is up before resizing/migrating https://review.opendev.org/701757
20:14:37 openstack bug 1855927 in OpenStack Compute (nova) "_poll_unconfirmed_resizes may not retry later if confirm_resize fails in API" [Low,In progress] https://launchpad.net/bugs/1855927 - Assigned to Matt Riedemann (mriedem)
20:14:37 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: Add recreate test for bug 1855927 https://review.opendev.org/701756
20:41:29 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-agents policies https://review.opendev.org/701648
20:42:53 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-agents policy https://review.opendev.org/701649
20:51:18 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-assisted_volume_snapshots policies https://review.opendev.org/701835
20:58:52 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-assisted_volume_snapshots policy https://review.opendev.org/701837
21:02:47 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-assisted_volume_snapshots policies https://review.opendev.org/701840
21:08:38 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-assisted_volume_snapshots policy https://review.opendev.org/701841
21:40:02 dansmith efried: still around?
21:40:07 efried yes
21:41:01 dansmith efried: I think you're missing my point on the defaulting stuff, and mashing together the default_fn thing with the object mix-in
21:41:24 dansmith they're not really related, as you'll note the mixin has nothing to do with the default_fn thing
21:41:51 efried yeah, I get that they could be separate. I'm just not sure there's a reason to do that.
21:41:54 dansmith the latter is just syntactic sugar in most cases, aside from the fact that the latest patch avoids copying everything all the time
21:42:09 dansmith they're wholly separate
21:42:29 dansmith default_fn has nothing to do with whether or not it's applied implicitly at init time
21:42:39 efried I understand that
21:43:00 dansmith okay
21:43:13 efried but still think there's value in smashing them together.
21:43:37 dansmith do you understand that I don't want to mix default-on-init into objects that are representative of row-based data structures on the other side of an rpc pipe?
21:43:55 efried Yes.
21:44:07 efried um, I think I do
21:44:12 efried I don't think I'm suggesting otherwise.
21:44:20 dansmith your latest reply seems to disagree
21:44:55 efried as long as we're talking about object as opposed to class
21:45:47 efried I don't think a class def of a field needs to be tied to every case where an instance of that class is used in a parent object
21:46:23 efried like with nullable, where we're saying a particular instance of that class is tied to a db column that's either nullable or not.
21:46:47 efried (I get that that's not all it says, but that was its impetus)
21:47:02 dansmith um
21:47:30 dansmith maybe you're focusing on objects that are included as fields on another object specifically?
21:47:41 efried yes, that's exactly what I'm doing.
21:48:16 dansmith hang on, ups
21:49:30 dansmith so, I the inner object getting the behavior we want is cool, but not if it breaks the outer objects or the whole system
21:49:58 dansmith and making a single field default-on-init is what I don't want to do
21:50:21 dansmith which is why keying the default-on-init on the default_fn=<callable> isn't okay, IMHO
21:51:56 efried I thought "making a single field default-on-init" is exactly what we *did* want to do. It indicates that we know that field isn't backed by a db column, among other things, and we want the convenience of being able to count on it being set without having to default it explicitly or have it autovivify.
21:53:17 dansmith no, it's precisely what I don't want
21:54:02 dansmith I just finished reading your reply and replied, that we definitely don't need a subclass-per-type like you surmised
21:54:11 efried I'm playing with it now, and I think it's helping me understand the distinction you're making.
21:54:19 efried gimme a couple minutes...
21:56:44 dansmith right, so RequestSpec could become fully ephemeral IMHO
21:57:27 efried okay, so really what the bottom patch does is make __init__(): obj_set_defaults() sanctioned behavior
21:57:35 dansmith which means RequestSpec(NovaObject) becomes RequestSpec(EphemeralObject), and your default request_level_params gets applied at start
21:57:38 dansmith yes

Earlier   Later