| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-22 | |||
| 12:04:10 | lyarwood | as a service | |
| 12:04:12 | lyarwood | :D | |
| 12:09:51 | bauzas | stephenfin: at lunch :) | |
| 12:10:25 | bauzas | stephenfin: ping me at 1.30pm your time and I'll look at them ;) | |
| 12:21:23 | nightmare_unreal | question : where does osc reads clouds.yaml file, can't seem to figure out :/ . | |
| 13:03:34 | openstackgerrit | Elod Illes proposed openstack/nova stable/queens: libvirt: Do not reference VIR_ERR_DEVICE_MISSING when libvirt is < v4.1.0 https://review.opendev.org/c/openstack/nova/+/747362 | |
| 13:06:57 | openstackgerrit | Elod Illes proposed openstack/nova stable/queens: libvirt: Do not reference VIR_ERR_DEVICE_MISSING when libvirt is < v4.1.0 https://review.opendev.org/c/openstack/nova/+/747362 | |
| 13:29:13 | sean-k-mooney | gmann: gibi we might want to increase the test timeout on tempest-integrated-compute form 2 hours to 3 | |
| 13:29:40 | sean-k-mooney | it timed out on https://review.opendev.org/c/openstack/nova/+/757614 during the senario tests but everything else ran fine | |
| 13:29:58 | sean-k-mooney | it does look like a potentally slow node but we should proably keep an eye on it | |
| 13:31:05 | sean-k-mooney | thats the only time out there https://zuul.opendev.org/t/openstack/builds?job_name=tempest-integrated-compute&project=openstack/nova | |
| 13:31:17 | gibi | sean-k-mooney: ack. looking at the run historyt https://zuul.opendev.org/t/openstack/builds?job_name=tempest-integrated-compute&project=openstack/nova most of the runs are areound 1.5 hours | |
| 13:31:19 | sean-k-mooney | and it normally complete in aboiut 1:20 | |
| 13:31:26 | sean-k-mooney | yep | |
| 13:31:29 | gibi | so let's keep an eye on it | |
| 13:31:37 | gibi | but right now I would not increase yet | |
| 13:31:44 | sean-k-mooney | i think in general the current time out looks right | |
| 13:33:07 | sean-k-mooney | the fact we have a normal run lenght in the next patch in the chain would seam to indicate that the time it ran fro is unrealted to the patch too | |
| 13:34:39 | gibi | yes, I think this was an extra slow node | |
| 13:34:58 | sean-k-mooney | collections.defaultdict(lambda: 0) huh thats a new one | |
| 13:36:05 | sean-k-mooney | so ret: ty.DefaultDict[str, int] = collections.defaultdict(lambda: 0) is default initallising a dictionary where the values will be 0 | |
| 13:37:55 | gibi | defaultdict takes a callable to produce the default value | |
| 13:38:07 | gibi | sometimes we use int instead of lamba: 0 | |
| 13:38:10 | gibi | both produce 0 | |
| 13:38:56 | gibi | as int() == 0 as well as lambda: 0() == 0 | |
| 13:39:32 | sean-k-mooney | ya its a cleaver solution but also suprisign if you have not seen it before | |
| 13:39:54 | sean-k-mooney | i would have expect to just pass 0 honestly | |
| 13:40:06 | sean-k-mooney | but i can see why that would not be a good patern in general | |
| 13:40:17 | gibi | you cannot pass 0 as that is not a callable | |
| 13:40:35 | sean-k-mooney | if it was a complex object instead of a literall it would be a problem to allow passing the object directly | |
| 13:40:42 | sean-k-mooney | since it would be shared not cloned | |
| 13:40:51 | sean-k-mooney | hence a callable to produce the defualt value | |
| 13:40:54 | gibi | yepp | |
| 13:41:02 | gibi | so we have to pass something that returns 0 | |
| 13:41:21 | gibi | both int, and lamba:0 is good for that, but a 0 literal is not | |
| 13:41:43 | sean-k-mooney | yep | |
| 13:42:40 | sean-k-mooney | its more a deficite of the api of the datastucture then anything else. its more flexable however then the claical default approch | |
| 13:43:10 | sean-k-mooney | its just different form how get and set_default work | |
| 13:43:43 | sean-k-mooney | but inline with how sorted or filter works where you provide a key funcion as a callable | |
| 13:52:37 | nightmare_unreal | how can i access clouds.yaml file once it's loaded. Suppose i want to read some values from it . For context i am trying to read placement_api_version | |
| 13:53:26 | sean-k-mooney | there is a lib for it but OSC will automaticlaly do it for vars in the right format | |
| 13:54:49 | sean-k-mooney | its just a yaml file however so in your own code you can jsut read it with the stardard lib | |
| 13:55:10 | sean-k-mooney | i think its in osc-lib | |
| 13:56:03 | nightmare_unreal | i am working on a bug : osc client does not read placement API version variable . variable name placement_api_version | |
| 13:56:26 | nightmare_unreal | so i am trying to figure out where in osc it reads the yaml file | |
| 13:57:04 | sean-k-mooney | its case sensitive and has to be uppercase just an fyi | |
| 13:57:11 | sean-k-mooney | i think | |
| 13:57:27 | openstackgerrit | Lee Yarwood proposed openstack/nova master: docs: Move the LibvirtDistroSupportMatrix wiki page into our docs https://review.opendev.org/c/openstack/nova/+/771981 | |
| 13:57:29 | sean-k-mooney | that would be in osc-placement | |
| 13:57:32 | nightmare_unreal | obvious solution that will not be good is to read the config file in osc_placement plugin and look for that value if it's set then good . | |
| 13:57:41 | lyarwood | stephenfin / kashyap ; ^ would you mind reviewing this, still need to add some versions and work out where it should live (if not in our reference docs) | |
| 13:58:14 | sean-k-mooney | nightmare_unreal: https://github.com/openstack/osc-placement/blob/master/osc_placement/plugin.py#L53 | |
| 13:59:05 | sean-k-mooney | it uses https://github.com/openstack/osc-lib/blob/ec1b7dda0e6dc1ec614a92e24267d058783ad27f/osc_lib/utils/__init__.py#L134-L144 | |
| 13:59:15 | sean-k-mooney | to get the values for the env | |
| 13:59:24 | nightmare_unreal | in clouds.yaml it should be defined like that ? OS_PLACEMENT_API_VERSION but i think there is a file that automatically does that | |
| 13:59:29 | sean-k-mooney | but i think cloud.yaml is expeorted to the evn | |
| 13:59:34 | nightmare_unreal | I see | |
| 13:59:58 | nightmare_unreal | in my head the env is when in cli we explicitly do export OS_BLAH_BLAH | |
| 14:00:09 | sean-k-mooney | yes it is | |
| 14:00:11 | nightmare_unreal | but if it takes clouds.yaml as env | |
| 14:00:20 | nightmare_unreal | then i have to think | |
| 14:00:29 | sean-k-mooney | but i think we extract some paramaters and add them to it | |
| 14:00:44 | sean-k-mooney | i havent looked at this closely but was how i understood it to work | |
| 14:01:16 | gmann | brinzhang_: ack, I will check those in details and see were it is wrong. basically having separate APi controller class should not cause any issue | |
| 14:02:14 | nightmare_unreal | I see. yeah trying to figure it out myself :) | |
| 14:03:12 | sean-k-mooney | so i think this is wher we read the cloud.yaml https://github.com/openstack/osc-lib/blob/ec1b7dda0e6dc1ec614a92e24267d058783ad27f/osc_lib/shell.py#L408-L413 | |
| 14:03:18 | gmann | sean-k-mooney: gibi I thikn 2 hr is even more time for that job disbale swift and does not run swift/keystone/slow tests | |
| 14:03:39 | sean-k-mooney | gmann: ya i mentioned the timeout befor ei check the build page | |
| 14:03:43 | kashyap | lyarwood: Hey, will check; sigh, missed the notif here | |
| 14:03:45 | gmann | ohk | |
| 14:03:52 | sean-k-mooney | gmann: it shoudl be fine just a slow node | |
| 14:04:01 | gmann | sean-k-mooney: yeah. | |
| 14:04:30 | gmann | except tripleo jobs almost all our gate are with max 2 hrs job run | |
| 14:04:59 | sean-k-mooney | yep | |
| 14:05:02 | kashyap | lyarwood: Thanks for moving; I think I have a half-done patch for it somewhere; but didn't update it | |
| 14:06:16 | nightmare_unreal | thanks sean-k-mooney , looking :D | |
| 14:06:32 | sean-k-mooney | that delegating to the sdk now | |
| 14:09:06 | sean-k-mooney | nightmare_unreal: this is what does the actul loading i think https://github.com/openstack/openstacksdk/blob/4ce235d36dfa3420534ad1b145cc7c5f7438e8e0/openstack/config/loader.py#L140 | |
| 14:10:58 | nightmare_unreal | yeah i think so too, looking | |
| 14:14:40 | sean-k-mooney | nightmare_unreal: regardelss of how its parsed i think this is what you are really looking for https://github.com/openstack/openstacksdk/blob/4ce235d36dfa3420534ad1b145cc7c5f7438e8e0/openstack/config/loader.py#L1057 | |
| 14:15:17 | sean-k-mooney | to lookup a value in the config | |
| 14:15:46 | nightmare_unreal | yes exactly , and also to check if the defined key:value in clouds.yaml is read or not | |
| 14:15:50 | nightmare_unreal | thanks | |
| 14:16:08 | kashyap | lyarwood: Do you havea rendered version of it? | |
| 14:18:46 | kashyap | lyarwood: sean-k-mooney: For testing w/ Secure Boot in the Gate ... none of the cloud images are built with EFI partition ... I'm wondering if are allowed to upload new images for testing? | |
| 14:19:06 | lyarwood | kashyap: http://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_8b1/771981/1/check/openstack-tox-docs/8b1d7c4/docs/reference/libvirt-distro-support-matrix.html | |
| 14:19:09 | kashyap | The short context is: you'd need a disk image with EFI partition in it | |
| 14:19:42 | kashyap | I'm thinking of making a custom template image for testing; is it allowed to upload somewhere via the infra and make use of it? | |
| 14:19:55 | lyarwood | kashyap: we shouldn't need to upload an image into CI, we can just host and reference one that does in a test job | |
| 14:20:17 | lyarwood | kashyap: assuming you're talking about the test instances and not the test hosts | |
| 14:20:19 | kashyap | lyarwood: Ah; okay. I'll find a suitable location to host it, once I prepare it | |
| 14:20:33 | kashyap | lyarwood: Test instance, indeed. I'm talking about a guest | |
| 14:20:51 | sean-k-mooney | kashyap: do you mean the guest image e.g. cirros | |
| 14:21:06 | lyarwood | kashyap: right then there's likely best practice our where we can host it, if it needs to be cached etc but we should be able to drop in a suitable image | |
| 14:21:17 | lyarwood | practice around* | |
| 14:21:22 | sean-k-mooney | we are not ment to pull arbiary blobs down in the jobs | |
| 14:21:24 | kashyap | lyarwood: E.g. this is what a guest image that can do EFI/SB should have, to start with: http://paste.openstack.org/show/801871/ | |
| 14:21:30 | kashyap | sean-k-mooney: Yes, guest images indeed. | |
| 14:21:39 | sean-k-mooney | so if we need a special test image we need to have that hostsed/cached by infra | |
| 14:21:48 | kashyap | sean-k-mooney: Okay; I'll check w/ the infra folks. | |