| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-10-16 | |||
| 17:51:04 | sean-k-mooney | dansmith: for what its worth i dont see any packages being installed | |
| 17:51:17 | dansmith | sean-k-mooney: bindep packages you mean? | |
| 17:51:30 | dansmith | I didn't see it try lxml that's for sure | |
| 17:51:48 | sean-k-mooney | ya bindep is installed bu ti dont see ay execution of setup_package that actully installs anything | |
| 17:52:16 | sean-k-mooney | so that might have silently been broken at some point | |
| 17:52:38 | sean-k-mooney | im sing things like inc/python:_setup_package_with_constraints_edit:387 : [[ /opt/stack/neutron == -bindep* ]] | |
| 17:53:06 | dansmith | I'd have expected more breakage in that case | |
| 17:54:01 | sean-k-mooney | ah so reading the code | |
| 17:54:08 | sean-k-mooney | https://github.com/openstack/devstack/blob/master/inc/python#L385 | |
| 17:54:20 | sean-k-mooney | the fintion is checkign if it was invoked with -bindep | |
| 17:54:23 | sean-k-mooney | as a flag | |
| 17:54:33 | sean-k-mooney | and poping it | |
| 17:54:39 | sean-k-mooney | and we are not doign that | |
| 17:55:04 | sean-k-mooney | we do not pass -bindep when seting up nova | |
| 17:55:22 | dansmith | probably need to get gmann to consult here I think | |
| 17:55:35 | sean-k-mooney | https://github.com/openstack/devstack/blob/ca4d5132e63752878620c4e4f374d98d433b3f52/lib/nova#L971 | |
| 17:55:53 | sean-k-mooney | i dont see any usage of this in tree so maybe this was added for out of tree plugins to call | |
| 17:56:22 | sean-k-mooney | https://github.com/openstack/devstack/commit/58243f6203f3385039fe7124b037d5abf7e1d59e | |
| 17:58:59 | sean-k-mooney | we can always follow up in #openstack-qa but my read on this is the infra is in place but not hooked up to be called | |
| 17:59:34 | sean-k-mooney | this seams to be the only? usage https://github.com/openstack/devstack/commit/dd3731c86a13334125715e44880491042526227c | |
| 18:00:06 | sean-k-mooney | so it be used if we use libs_from_git=nova i guess but that shoudl be the case in teh ci job | |
| 18:01:39 | sean-k-mooney | am not quite its still only takign that path for specific lib | |
| 18:02:01 | sean-k-mooney | not anything listed in libs form git so ya it is not hooked up for nova/service proejcts | |
| 18:02:49 | sean-k-mooney | it shoudl be simple enough to hook up but we shoudl check with gmann et al first to see if there is a reason to only do this for libs | |
| 18:03:09 | dansmith | yeah seems like there must be something missing | |
| 18:05:31 | sean-k-mooney | i think to really do this properly and get the most use out of it we woudl want to modify lib/nova and the nova hypervisor plugsin to pass a diffetn tag (the virt driver) and on the nova side group driver deps by tag .e.g libvirt or ironic in the bindeps file | |
| 18:06:03 | sean-k-mooney | it would be a nice enhancement but a lot of work to fully get right. | |
| 18:06:09 | sean-k-mooney | im honestly fine with your first patch | |
| 18:06:51 | sean-k-mooney | i would only look at hooking up bindep in devstack if we find ourselve needing to do this more hten once or twice a cycle | |
| 18:08:32 | gmann | dansmith: sean-k-mooney hi | |
| 18:08:46 | sean-k-mooney | o/ | |
| 18:09:15 | gmann | bindeps can be installed two way, via flag while installing nova or have file in devstack/file/bindep.txt itself which will be indalled by default | |
| 18:09:19 | gmann | installed | |
| 18:09:54 | gmann | but nova needs to have that in-tree under devstack directory with plugin setup | |
| 18:10:13 | sean-k-mooney | gmann: yep so in this case its a dep for an ansible module we are using in one specific ci job post playbook | |
| 18:10:15 | gmann | I mean here - https://github.com/openstack/nova/tree/master/devstack | |
| 18:10:28 | sean-k-mooney | the dep also happens to be a dep nova has | |
| 18:11:01 | sean-k-mooney | we are assumign that until last week lxml was insallsed transitivly via a weak dep somewhere | |
| 18:11:07 | sean-k-mooney | so the ci playbook worked | |
| 18:11:18 | sean-k-mooney | and that weak dep got lost over the weekend | |
| 18:11:43 | gmann | ohk so we want to have explicit in nova bindep right? | |
| 18:12:21 | sean-k-mooney | well for now we jsut installed it in the job. but then i mentioned bindep to dansmith but that dint work becasue we dont install nova's bindep currently | |
| 18:12:35 | sean-k-mooney | gmann: i was wondering if there was a reason we only do it for specific libs | |
| 18:12:48 | sean-k-mooney | i.e. if we passed the flag for nova would it break things? | |
| 18:13:17 | dansmith | gmann: not sure what changed between last week and today, but this must have been on the system before | |
| 18:13:40 | dansmith | gmann: but yeah, it's really an ansible module requirement, so not sure it should be in nova's bindep to be honest | |
| 18:14:20 | gmann | ohk | |
| 18:16:05 | gmann | not sure if changed in opendev side, I cannot remember/see anything devstack removed on this | |
| 18:16:25 | sean-k-mooney | looking at the commit history i dont see anything obvious on the devstack side | |
| 18:16:40 | gmann | yeah | |
| 18:16:44 | sean-k-mooney | perhaps a chagn ein tempet or shared job config but i think its not realted to the devstack repo | |
| 18:17:37 | gmann | which one? | |
| 18:20:05 | sean-k-mooney | the partent of the job that failed was tempest-multinode-full-py3 so i was wondering if it was in anyway related to https://github.com/openstack/tempest/commit/5c64e3913a1a5a061a6b04b212ce35aaa84f2184 | |
| 18:20:08 | sean-k-mooney | but i dont think so | |
| 18:20:47 | gmann | yeah, that is not related | |
| 18:21:07 | gmann | it is just adding stable/2023.2 jobs | |
| 18:21:17 | sean-k-mooney | there is nothing else really that lins up | |
| 18:21:28 | sean-k-mooney | for now we have a solution just isntalling the dep in teh job | |
| 18:21:32 | sean-k-mooney | so we are unblocked | |
| 18:21:54 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/898435 | |
| 18:22:00 | sean-k-mooney | why it broke is less imporant | |
| 18:22:37 | gmann | someone at door. will be back in 10-15 min | |
| 18:22:43 | sean-k-mooney | am im going to drop in a few mins o/ | |
| 21:47:33 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/884439 | |
| #openstack-nova - 2023-10-17 | |||
| 02:14:19 | opendevreview | HanGuangyu proposed openstack/nova master: Unify ServersController._flavor_id_from_req_data param to server_dict https://review.opendev.org/c/openstack/nova/+/898315 | |
| 05:19:42 | opendevreview | HanGuangyu proposed openstack/nova master: Unify ServersController._flavor_id_from_req_data param to server_dict https://review.opendev.org/c/openstack/nova/+/898315 | |
| 05:40:51 | opendevreview | HanGuangyu proposed openstack/nova master: Unify ServersController._flavor_id_from_req_data param to server_dict https://review.opendev.org/c/openstack/nova/+/898315 | |
| 08:34:50 | opendevreview | HanGuangyu proposed openstack/nova master: Unify ServersController._flavor_id_from_req_data param to server_dict https://review.opendev.org/c/openstack/nova/+/898315 | |
| 08:44:26 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Forbid use_cow_images together with flat images_type https://review.opendev.org/c/openstack/nova/+/898229 | |
| 13:28:52 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/884439 | |
| 13:30:10 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/884439 | |
| 13:31:05 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/884439 | |
| 13:40:38 | opendevreview | Tobias Urdin proposed openstack/nova master: [WIP] Handle scaling of cputune.shares https://review.opendev.org/c/openstack/nova/+/898326 | |
| 13:41:22 | sean-k-mooney | tobias-urdin: thisis not something we can do in nova | |
| 13:41:54 | sean-k-mooney | tobias-urdin: we can discuss it again but we considerd that option and rejected it before | |
| 13:42:41 | sean-k-mooney | tobias-urdin: its not jsut eh cpu_shares that woudl need to be adjusted | |
| 14:00:59 | opendevreview | Tobias Urdin proposed openstack/nova master: [WIP] Handle scaling of cputune.shares https://review.opendev.org/c/openstack/nova/+/898326 | |
| 14:01:40 | tobias-urdin | sean-k-mooney: are you thinking about quota:cpu_shares flavor extra spec as well? | |
| 14:02:24 | sean-k-mooney | tobias-urdin: yes | |
| 14:02:40 | tobias-urdin | i don't understand the reasoning for "libvirt broke us let's remove the default completely" | |
| 14:02:43 | sean-k-mooney | so on master (since zed) we nolonger genreate cpu_shares implictly | |
| 14:02:52 | sean-k-mooney | tobias-urdin: it was nto libvirt | |
| 14:03:04 | sean-k-mooney | this was cause by your kernel being compiled with cgroups_v2 | |
| 14:03:24 | sean-k-mooney | it was broken by the kernel team changeing the allowed ranges between api versions | |
| 14:05:45 | sean-k-mooney | tobias-urdin: neither nova nor libvirt provided any normalistaion of values menaing the admin is responsible for selecting values that are allowed by there kernel cgroup version | |
| 14:09:22 | tobias-urdin | while that is true and libvirt never normalized the values, i don't agree, libvirt is an abstraction and should've handled it | |
| 14:09:50 | sean-k-mooney | tobias-urdin: we made that argument to the libvirt maintainer and they disagreed | |
| 14:12:14 | sean-k-mooney | tobias-urdin: https://bugs.launchpad.net/nova/+bug/1960840 is related | |
| 14:12:33 | sean-k-mooney | we considerd extneding the flavor validation https://review.opendev.org/c/openstack/nova/+/829064 | |
| 14:13:00 | sean-k-mooney | however part of the problem is the range depend on the virtdriver in use and the cgroup version in the libvirt case | |
| 14:14:36 | sean-k-mooney | in that case actully the limit is a tc one rather the cgroup but we considerd deprecting and removing these as a result | |
| 14:15:07 | sean-k-mooney | that simpler to do with the vif quotas since they generally nolonger fucntion | |
| 14:15:18 | sean-k-mooney | and have a neutron replacemnt that does | |
| 14:17:24 | tobias-urdin | as an operator i basically have two options 1) apply patch https://review.opendev.org/c/openstack/nova/+/824048 and just live with the behaviour change and larger instances does not get favored for oversubscription and i have to manually update cpu_shares or backport that patch to yoga to move to zed with live migration or 2) scale the value and | |
| 14:17:24 | tobias-urdin | set correct on all current instances and live migrate them over and make sure new instances also gets a scaled value | |
| 14:17:52 | tobias-urdin | for an operator where touching the code is an issue this might be very messy | |
| 14:18:28 | tobias-urdin | i opted for adding it as a workaround and upon nova-compute startup fix the values, exactly because of the upgrade issue | |
| 14:18:39 | sean-k-mooney | so im not against backporting the disabling of the implict cpu_share request for what its worht | |
| 14:18:59 | sean-k-mooney | tobias-urdin: we have dont this back to wallaby downstream because we considerd it a release blocker for our product | |
| 14:19:31 | sean-k-mooney | tobias-urdin: we dont have any other code that modifes a guest on startup like that and im not sure hta tis a patten we should follow in general | |