Tuesday, 2021-06-15

opendevreviewJames Kirsch proposed openstack/kolla-ansible master: Support for keystone scoped authorization  https://review.opendev.org/c/openstack/kolla-ansible/+/69217902:31
mnasiadkamgoddard: forgot about them, will do it today :)04:50
yoctozeptomorning06:00
yoctozeptopriteau: oh, oh, that explains why train started failing on python-libvirt06:02
yoctozeptoand we have a report about the same on victoria06:02
yoctozeptothough in CI i have only seen it in train06:02
yoctozeptoargh06:02
yoctozeptocentos 8 is a joke now06:03
*** rpittau|afk is now known as rpittau07:13
priteaumorning07:19
Fl1ntHi everyone! :D07:23
*** hrw is now known as Guest221107:31
parallaxMorning07:31
*** Guest2211 is now known as hrw07:32
priteauyoctozepto: I was looking at the build error in train. virDomainAuthorizedSSHKeysGet was added in libvirt-python v6.10.007:36
Fl1ntpriteau, you get build errors on train ?07:36
priteauCI does07:36
Fl1ntInterestingly weird, I did a build on yesterday evening and don't get it.07:37
Fl1ntwhich distribution?07:37
Fl1ntDEB Base I suppose?07:37
priteauCentOS 807:42
priteauOnly affects masakari-monitors07:42
opendevreviewPierre Riteau proposed openstack/kolla stable/train: Fix build of masakari-monitors image  https://review.opendev.org/c/openstack/kolla/+/79638707:43
Fl1ntAaaaaaah ok, I can see why :D07:43
Fl1ntNice catch tho ^^07:43
Fl1ntby the way, this versionning drift of a key component bring me back to a question that I had from a meeting recently.07:45
Fl1ntHow do we track dependencies versionning on kolla? From my POV we do it through the CI that will error (like this issue) on regular build, but with stream bringing daily changes, will we be able to do it that way?07:46
yoctozeptopriteau: I wonder if we shouldn't actually pin libvirt itself07:47
mgoddardmorning07:48
priteauyoctozepto: yes, maybe. I mostly wanted to check if it fixes it07:48
yoctozeptopriteau: sure, thanks for working on that; also - any idea why only train fails in CI and newer ones only for users?07:50
priteauNo idea07:51
priteauUpper constraints are different obviously07:51
Fl1ntmgoddard, let say I want to make a bug report the umbrella for few smaller patch set, how do I do that?08:02
mgoddardFl1nt: Related-Bug: #12345608:03
Fl1ntaaaah perfect ! thx08:03
Fl1ntDo I only need this Related-Bug or do I still need to put Change-Id and Bug: #1234 ?08:03
priteauChange-Id is mandatory for Gerrit08:10
priteaugit-review will add it for you if you remove it08:10
Fl1ntok, noticed, thanks ^^08:10
priteauIf you remove the Change-Id, and git-review adds another one back, you will create a duplicate change in Gerrit08:11
Fl1ntAdditional though, we use apt within our Dockerfile for DEB based distribs, I do prefer this notation, BUT it seems apt doesn't have stabilized CLI APIs shouldn't we rather use apt-get alternatives in order to avoid any weird behaviors because of that?08:11
Guest529priteau: https://bugs.launchpad.net/bugs/193181708:11
yoctozeptopriteau: yeah, they are different, but should not be different user vs CI08:13
priteauI agree08:13
priteauI have a victoria dev environment running actually, can give it a try08:13
parallaxhttps://review.opendev.org/ down?08:16
parallaxno, just slow 08:16
Fl1ntSo, I'm working on improving our images build when dealing with an offline environment. The first patch will be for dumb-init based images; We currently pin the version used to 1.2.2 from github.08:17
Fl1ntI use the CentOS/Ubuntu provided binary versions from more than a year on a fairly large platform now08:18
Fl1ntand on COS8 I'm even more advanced than the pinned version08:18
Fl1ntwithout any issue/error or outage08:18
Fl1ntin order to support multiple scenarii such as offline/online/ sources based/binary based I've two options08:19
Fl1nteither I conditionally do it on the dumb-init installation block08:19
Fl1ntOR08:19
Fl1ntI can condition the dumb-init block just for online+source based or offline+source based scenarii08:20
Fl1ntWhat do you prefer folks?08:20
mgoddardFl1nt: if every distro has a sufficient version packaged we could use that08:28
Fl1ntI know that CentOS and Debian/Ubuntu does have 1.2+ releases, do we support any other distrib?08:32
Fl1ntDebian stable (buster) use 1.2.2-1.108:32
Fl1ntUbuntu stable (21.04) use 1.2.5-108:32
Fl1ntCentOS stable (8/8Stream) use 1.2.608:33
opendevreviewMark Goddard proposed openstack/kolla master: Pin td-agent to 4.0.* to fix missing logs  https://review.opendev.org/c/openstack/kolla/+/79508608:33
Fl1nt1.2.2.6 sorry08:33
yoctozeptowe usue ubuntu focal (20.04), not 21.0408:34
yoctozeptoand now debian bullseye too08:34
yoctozeptouse*08:34
yoctozeptoanyhow, they all look good enough08:34
Fl1ntok, let's go then08:35
opendevreviewMerged openstack/kolla master: [docs] Fix Debian release name  https://review.opendev.org/c/openstack/kolla/+/79627508:35
opendevreviewRadosław Piliszek proposed openstack/kolla master: Pin td-agent to 4.0.* to fix missing logs  https://review.opendev.org/c/openstack/kolla/+/79508608:36
Fl1ntlast question, do you prefer an additional conditional test based on source for the dumb_init_installation block and then by default for rdo/binary install_type I use the packages or everything dealed on dumb_init block?08:36
yoctozeptojust install the packages and we are good08:37
mgoddard+108:37
mnasiadkamorning08:37
yoctozeptoit's an old workaround08:37
Fl1ntok ok08:38
Fl1ntperfect08:38
opendevreviewRadosław Piliszek proposed openstack/kolla stable/wallaby: [docs] Fix Debian release name  https://review.opendev.org/c/openstack/kolla/+/79622808:40
opendevreviewMark Goddard proposed openstack/kolla-ansible master: Reno follow up for docker_disable_ip_forward  https://review.opendev.org/c/openstack/kolla-ansible/+/79640608:50
hub_kalleHi, I'm running into a wierd issue when trying to deploy kayobe: on "baremetal node list" shows my nodes, everything looks fine (7 nodes, 3 controllers, 4 compute) . I do "kayobe overcloud provision" and everything looks perfect until it fails when waiting for the node to become active again08:52
hub_kalleit appears all the comute node are hung up in "wait for callback"08:53
hub_kallebut it looks like the provisioning worked08:53
hub_kalleall the node are accessible via ssh08:53
hub_kalleand they are provisioned with ubuntu 20.0408:54
hub_kalle(i'm running kayobe wallaby/stable)08:54
hub_kallenow I'm trying to figure out how to debug this08:55
hub_kallethe bifrost deploy log only tells me that it waited for callback to long08:55
opendevreviewMark Goddard proposed openstack/kolla-ansible master: Drop /sys/fs/cgroup mounts  https://review.opendev.org/c/openstack/kolla-ansible/+/79378508:55
hub_kalleQuestion: should I take this up with someone at ironic or do you guys have an idea?08:56
priteauhub_kalle: are you sure your nodes were not provisioned in an earlier attempt?09:00
jingvarHi! Which OS should I use for a-multiverse09:00
mgoddardjingvar: on a-multiverse-from-nothing-master, you can use CentOS Stream/Linux 8 or Ubuntu 20.0409:01
hub_kalleyes I'm watching the whole procedure  via console09:04
hub_kalleand I had that exact problem before when those machines where always starting into a Centos 809:05
jingvarmgoddard: thanks, what about CentOS Stream and OMVF? is it fixed, or I have to downgrade the package?09:06
hub_kalleQuestion: i'm running "kayobe overcloud deprovision" in between attempts.09:06
priteaujingvar: The issue is fixed thanks to the updated libvirt package in AppStream09:06
hub_kalleDoes this means it's possible I'm now just seeing the result of an earlier failed attempt?09:07
jingvargood news09:08
opendevreviewMerged openstack/kolla stable/wallaby: [docs] Fix Debian release name  https://review.opendev.org/c/openstack/kolla/+/79622809:09
mgoddardhub_kalle: it sounds like the machines are not PXE booting the IPA ramdisk, but booting into an existing OS09:18
mgoddardhub_kalle: are they configured to PXE boot on the correct NIC? You should be able to watch the boot on a machine to see what it's doing09:18
hub_kallepretty sure that's not the problem but i'm going to run the process again (I configures them to boot via pxe on all nics and I did auto discovery on them which only works if pxe works)09:25
mgoddardhub_kalle: you can also use tcpdump on dhcp and pxe ports to be sure09:30
hub_kallemgoddard: that will be my next step09:31
Fl1ntmgoddard, where can I put default vars value for kolla? not k-a.09:39
opendevreviewMark Goddard proposed openstack/kolla-ansible master: WIP: Log fluentd events in TSV format  https://review.opendev.org/c/openstack/kolla-ansible/+/79551209:45
opendevreviewMichal Nasiadka proposed openstack/kolla master: Switch OPENSTACK_RELEASE back to master  https://review.opendev.org/c/openstack/kolla/+/79641509:56
hub_kallemgoddard: looks like you're right :( (even though I have no clue why, on the provisioning step these node skip PXE) - sorry for the dumb question then10:00
jingvarkayobe seed hypervisor host configure -  where should I configure username ? Failed to connect to the host via ssh: centos@192.168.33.4 - my user is cloud-user , controller_bootstrap_user: cloud-user does'nt work10:10
jingvarfor a-multiverse-from-nothing-master10:11
jingvaransible/kayobe-ansible-user.yml >> ansible_user: "{{ bootstrap_user }}"10:14
priteaujingvar: seed_hypervisor_bootstrap_user10:17
jingvarthanks, i've found it10:18
opendevreviewMaksim Malchuk proposed openstack/kayobe master: Set defaults for openstack_cacert  https://review.opendev.org/c/openstack/kayobe/+/79370310:22
opendevreviewVerification of a change to openstack/kolla-ansible failed: Disable docker's ip-forward when iptables disabled  https://review.opendev.org/c/openstack/kolla-ansible/+/79622310:23
opendevreviewMaksim Malchuk proposed openstack/kayobe master: TLS certificates management sync with Kolla-Ansible  https://review.opendev.org/c/openstack/kayobe/+/79369710:24
opendevreviewMarcin Juszkiewicz proposed openstack/kolla master: drop leftovers of RHEL support  https://review.opendev.org/c/openstack/kolla/+/78556910:30
hrwmorning10:31
sean-k-mooneyo/10:39
sean-k-mooneyany ceph experts around at the moment?10:40
sean-k-mooneyhas anyone tried to get kolla-ansible working with cephadm recently10:40
sean-k-mooneyim having trouble getting the serivces to be able to auth to ceph10:41
sean-k-mooneymy admin keyring works fine for me but i cant get the client keyrings to work for the services10:41
sean-k-mooneydo we know if there is a writeup on hits10:41
hrwssh: connect to host review.openstack.org port 29418: Connection timed out10:41
sean-k-mooney*this10:41
hrwanyone has it?10:41
sean-k-mooneyhrw: you should use review.opendev.org10:41
sean-k-mooneyhrw: the redirect kind of works for http but ssh does not10:42
mnasiadkasean-k-mooney: we have a cephadm based CI in stable/wallaby10:42
sean-k-mooneyat least i have had no look usign the old domain with git-review10:42
mnasiadkahrw: I have the same, it sometimes works ;)10:43
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: Update previous_release to Victoria  https://review.opendev.org/c/openstack/kolla-ansible/+/79642210:43
hrwsean-k-mooney: time to check .git/config then10:43
sean-k-mooneyhrw: or your /etc/hosts10:43
sean-k-mooneyi used to have review.openstack.org hard coded for a time when we had dns issues in the past10:44
hrwsean-k-mooney: it was .git/config10:44
sean-k-mooneyack10:44
opendevreviewMichal Nasiadka proposed openstack/kolla master: Switch OPENSTACK_RELEASE back to master  https://review.opendev.org/c/openstack/kolla/+/79641510:44
hrwmy /etc/hosts contains only one 10.*.*.* entry10:44
mnasiadkahrw: but review.opendev.org has the same problem for me, so I don't know if it will help much :)10:46
sean-k-mooneymnasiadka: i might see what ye are doing different10:46
sean-k-mooneymnasiadka: Failed to configure store correctly: Store rbd could not be configured correctly. Reason: Error in store configuration: [errno 13] RADOS permission denied (error connecting to the cluster) Disabling add method.10:46
sean-k-mooneythat is what im seeign in glance10:47
hrwmnasiadka: ;D10:47
mnasiadkasean-k-mooney: we are doing this in CI - https://github.com/openstack/kolla-ansible/blob/3675b442c9f3e77a2a3b776c75c03fc3ce853c73/tests/run.yml#L308 + role https://github.com/openstack/kolla-ansible/blob/master/roles/cephadm/tasks/main.yml - nothing fancy10:48
sean-k-mooneysame issue in cinder10:48
sean-k-mooneythe reall issue is 2021-06-14T06:52:55.468+0000 7f827ffff700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2,1]\n[errno 13] RADOS permission denied (error connecting to the cluster)\n which shows up in nova10:48
mnasiadkasean-k-mooney: ah, that's probably due to security patch in ceph10:49
sean-k-mooneymnasiadka: do you think the service might be trying to use v110:49
mnasiadkasean-k-mooney: https://docs.ceph.com/en/latest/security/CVE-2021-20288/#cve-2021-2028810:49
sean-k-mooneyinstead of v210:49
mnasiadkasean-k-mooney: let me guess, you're using a ubuntu deployment of Kolla?10:50
sean-k-mooneyyes10:50
sean-k-mooneyubuntu source10:50
sean-k-mooneywith ceph form i guess upstream 10:50
sean-k-mooneyi assume cephadm pulls the images directly form ceph.com?10:51
sean-k-mooneywell docker but not distro ceph10:51
mnasiadkaso Ubuntu hasn't updated the client ceph packages to a version that is mention in the CVE, but your server is patched - so you need to set auth_allow_insecure_global_id_reclaim to True10:51
sean-k-mooneyah ok10:51
sean-k-mooneyim glad i asked because i was not finding any info on this with google10:52
sean-k-mooneyso as admin in need to do something like this 10:53
sean-k-mooneyceph config set mon auth_allow_insecure_global_id_reclaim true10:53
sean-k-mooneyform the cephadm shell10:53
sean-k-mooneyor just set it in my ceph.conf10:53
mnasiadkasean-k-mooney: yes, ceph config is enough10:54
sean-k-mooneymnasiadka: would it make sense to rebuild the kolla images locally with the ceph repo enabeld to get a new ceph client in the kolla containers? or just wait for ubunut to update10:54
mnasiadkasean-k-mooney: just like we do in CI - https://github.com/openstack/kolla-ansible/blob/3675b442c9f3e77a2a3b776c75c03fc3ce853c73/roles/cephadm/tasks/main.yml#L8910:55
mnasiadkasean-k-mooney: I don't think UCA has updated the ceph packages yet10:55
mnasiadkaso a rebuild won't help10:55
sean-k-mooneymnasiadka++10:55
sean-k-mooneymnasiadka: well i was going to enable the package form ceph.com if i rebuilt10:55
mnasiadkasean-k-mooney: ah, that one would help for sure ;)10:56
opendevreviewMark Goddard proposed openstack/kolla-ansible master: WIP: Log fluentd events in TSV format  https://review.opendev.org/c/openstack/kolla-ansible/+/79551211:03
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: Update previous_release to Wallaby  https://review.opendev.org/c/openstack/kolla-ansible/+/79642211:29
opendevreviewMerged openstack/kolla-ansible master: Drop /sys/fs/cgroup mounts  https://review.opendev.org/c/openstack/kolla-ansible/+/79378511:38
opendevreviewMark Goddard proposed openstack/kolla-ansible master: WIP: Log fluentd events in TSV format  https://review.opendev.org/c/openstack/kolla-ansible/+/79551211:38
hub_kallemgoddard: I debugged my problem (somehow some of my node didn't do PXE) a little more, turns out for some reason my PXE Settings get overwritten at some point: I set the Boot Sequence to PXE over Hard Drive and at sometime between restarts it resets to Hard Drive over PXE11:39
hub_kalleQuestion: is there any chance this is a kayobe issue (If yes I would take some time to figure out what happens and if neccessary write a bug report)11:39
hub_kalle(it is quite likely this is just a dell idrac issue since all of the affected machines are from one batch of very new machines)11:40
hub_kalleI'm just not sure weather kayobe telling idrac to boot via PXE or to boot via Hard Drive could be the problem11:41
opendevreviewRadosław Piliszek proposed openstack/kolla-ansible stable/wallaby: Drop /sys/fs/cgroup mounts  https://review.opendev.org/c/openstack/kolla-ansible/+/79623111:43
opendevreviewRadosław Piliszek proposed openstack/kolla-ansible stable/wallaby: Drop /sys/fs/cgroup mounts  https://review.opendev.org/c/openstack/kolla-ansible/+/79623111:43
mgoddardhub_kalle: ironic will tell the nodes to boot from disk once provisioning is complete, but will PXE boot during provisioning11:46
priteauhub_kalle: make sure you have the latest firmware and idrac versions12:21
priteaualso are you using bios or uefi boot?12:22
hub_kalleI'm using bios12:24
hub_kallepriteau: any recommendation because I'm only using Bios because I always used it (which isn't a good reason for anything)12:25
priteauif you were using UEFI I would tell you to change the boot_mode in ironic, but that's not required in your case since bios is still the default12:25
sean-k-mooneyeven today using bios tend to be a better bet for older hardware12:25
sean-k-mooneyi think there is an ironic settign for local boot12:27
hrwsean-k-mooney: s/older/x86(-64)/ in general probably12:28
sean-k-mooneyironic node-update <node-uuid> add properties/capabilities="boot_option:local"12:28
sean-k-mooneyis ^ being set anywhere12:28
hub_kallebtw firmware and idrac version should be preety up to date. But it's possible they're not the latest (maybe half a year old)12:28
sean-k-mooneyhttps://docs.openstack.org/ironic/pike/install/include/local-boot-partition-images.html12:29
sean-k-mooneyhub_kalle: you do not want local boot right?12:29
hub_kalleno I wanted to provision via kayobe so I needed PXE boot and for some reason my Boot Sequence on the new Servers seems to reset at some point between restarts.12:31
hub_kalleIt's not a big problem, now that I know it exists. But it's annoying because now I need to observe the Deployment Process to see weather PXE worked or not ...12:32
hub_kallebut before debugging this I will update all firmware and iDRAC and see if the problem still persists12:32
hub_kalleI just wanted to know weather or this is possibly a kayobe issue because then I would put in some time debugging it thouroughly12:33
sean-k-mooneyhub_kalle: while you might loose some feature if you continue have issues with idrac you could try the geneirc ipmi driver too12:33
hub_kallegood idea12:34
hub_kalleeven though I'm not convinced this is a kayobe/ironic issue at all12:35
hub_kallewouldn't be the first time Dell iDRAC is broken12:35
hub_kallea by the way, I didn't update iDRAC because, a colleague of mine just bricked a server a few weeks ago by updating iDRAC ...12:36
sean-k-mooneyoh lovely12:37
sean-k-mooneythat is always fun12:37
hub_kalle... when we called  DELL about it the technician just said: "yeah, that version is broken"12:37
sean-k-mooneyya updating the bmc is like updating the bios12:37
hub_kalle... the version that is recommended on their webpage :)12:37
sean-k-mooneyyou only do it when you have no other option12:37
hub_kalleexactly12:37
priteausean-k-mooney: if hub_kalle is using the default configuration of kayobe, he's most likely using 1) whole disk images 2) local boot (which doesn't prevent provisioning via pxe boot) 3) ipmi driver12:44
priteauDoes the internal TLS feature support encrypting database traffic too?12:49
hub_kallepriteau and sean-k-mooney: that is indeed what i do right now - all my settings in ironic where done by the bifrost auto discovery feature and so far i didn't try any iDRAC Settings in kayobe. wierdly enough the auto discovery had no PXE issue12:52
priteauhub_kalle: you can try the following: log into the bifrost_deploy container, change /etc/ironic/ironic.conf to set debug = True, restart ironic-conductor, tail the logs to check the ipmitool commands being run while provisioning12:53
priteauThen you can run the same commands manually to see what happens12:53
hub_kallecool thanks i will do that12:53
priteauAnd of course check the node's console for any messages12:53
priteauCould be that it tries to pxe boot then times out and falls back to disk?12:54
hub_kalledoesnÄ12:54
hub_kalledidn't look like it12:54
hub_kallethe real mystery still is: the boot sequence set in the bios changes by itself12:55
hub_kalleit changes from PXE->Hard Drive to Hard Drive->PXE at some point that I haven't figured out yet12:56
opendevreviewMerged openstack/kolla-ansible stable/wallaby: Disable docker's ip-forward when iptables disabled  https://review.opendev.org/c/openstack/kolla-ansible/+/79622312:57
hub_kallebut i will turn on debug in bifrost, if there really is something wrong in kayobe/ironic (which I doubt) it should be visible there12:57
priteauyoctozepto: mgoddard: latest news from c8s, upload of new advanced-virt package (which should bring libvirt 7.4.0) "should happen before wednesday cob us time .. we normally do one stream compose per week (minimally)"12:58
opendevreviewMichal Nasiadka proposed openstack/kolla master: Switch OPENSTACK_RELEASE back to master  https://review.opendev.org/c/openstack/kolla/+/79641513:07
opendevreviewGaël THEROND proposed openstack/kolla master: Fix missing templating block for kolla-toolbox.  https://review.opendev.org/c/openstack/kolla/+/79627913:15
pomacHey, we've run in to a bit of a issue when upgrading one of our couds - it is missing vxlan_sys_4789 on all sides - so all vxlan traffic is being dropped. On *all* nodes including L3 nodes... 13:22
pomacopenvswitch with vxlan on viktoria - any clues of how to add it back - it seems like it has to be a manual step now13:22
opendevreviewMark Goddard proposed openstack/kolla-ansible master: WIP: Log fluentd events in TSV format  https://review.opendev.org/c/openstack/kolla-ansible/+/79551213:23
Fl1ntpomac, vxlan_sys_4789 is supposed to be there, why do you think it's no longer "automated" ?13:26
pomacFl1nt: well, 92 nodes doesn't agree with you13:27
pomacFl1nt: as in, i know it's supposed to be there - got that long in the debugging - but it's not13:27
Fl1ntI'm not telling you it's not, I'm rather asking if you think of it because you made an upgrade and it vanished or did you saw something on k-a13:28
pomacFl1nt: upgrade and full deploy - neither has it :(13:28
Fl1ntweird, looking at neutron.13:29
Fl1ntupgrade or rolling_upgrade13:29
pomacFl1nt: What i do see is that br-tun has no interfaces and all connection attempts ends up with ICMP noshuch-port 13:29
pomacrolling is default, right - so thats what happened - but we have done full deploy on reinstalled nodes as well13:30
Fl1ntright13:30
Fl1ntok ok, OVS or Linux Bridge based?13:31
pomacOVS13:31
mnasiadkaneutron-openvswitch-agent should add it13:31
Fl1ntexactly, except if the DB is corrupted/empty.13:32
pomachumm... Nothing like that from ovsdb-server that i can see13:33
pomaconce we got this far (started with suspecting switches and all kinds of things) we also wondered why it hadn't loaded the vxlan kernel module - we're running basically the same config in two other kolla-ansible victoria installs but.... 13:34
pomacanything you'd suggest - things are basically down anyway13:36
Fl1nthold on, which distro are you using pomac 13:43
pomacbtw, python3-neutronclient 7.2.113:43
pomacuhm... no13:45
Fl1ntlooks like you've got a config drift, either on your kolla config or within your images build.13:46
Fl1ntdo you use an overrided openvswitch-agent.ini file?13:47
pomacNope, we used to have override ml2 config13:47
Fl1ntmay well be a hint, like, the bridge_mappings using improper physnet addr etc13:48
pomachumm... will look at that, but it should be the same as before 13:49
opendevreviewGaël THEROND proposed openstack/kolla master: Improve offline build scenario. * Use distribution based dumb-init package. * Add conditional test for source based build.  https://review.opendev.org/c/openstack/kolla/+/79648013:55
Fl1ntHow should I name the variable use to specify kolla where to find out packages that are not provided by distribution providers? "tarballs_internal_repo_root_url" ?14:02
yoctozeptopomac: which distro is it?14:02
hrwFl1nt: you mean packages from out-of-distro/external repos?14:09
hrwFl1nt: which names you already have?14:09
hrwbbiab14:11
yoctozeptomnasiadka: https://review.opendev.org/c/openstack/kolla-ansible/+/79640614:12
yoctozeptothx14:14
yoctozeptopriteau: I believe you can lift w-1 on https://review.opendev.org/c/openstack/kolla/+/79549014:16
priteauwhy? it's still not fixed14:18
yoctozeptopriteau: it passes in CI though14:18
yoctozeptoso must got fixed14:18
priteauwhat14:18
yoctozeptolook at the results14:18
priteaulibvirt-daemon 7.0.0-14.1.el814:19
Fl1nthrw, I mean, currently, our internal mirrors are all hosted under one URL umbrella: https://repository.domain.tld/<distro>|<brand>/ and we use two vars exemple:14:19
priteauMaybe it has a cherry-pick of the fixed merged in 7.4014:19
priteau7.4.014:19
Fl1ntdistribution_internal_repo_root_url: https://repository.domain.tld/ and then tarballs_internal_repo_root_url: https://repository.domain.tld/tarbals/14:20
Fl1ntwe splitted it on two vars because some may well have one server only serving mirrors of distribution packages14:21
priteauyoctozepto: commit message doesn't match at all what's really happening in kolla (it made sense for kayobe), I will need to update it14:21
Fl1ntand another one such as: tarballs.domain.tld14:21
yoctozeptopriteau: I stopped following what shappens in centos14:21
yoctozeptopriteau: ah, right, the commit message is wrong14:22
yoctozeptoall right, you go fix it and cherry pick again14:22
yoctozeptothen we approve :-)14:22
priteauthe short version is that things should change again by tomorrow so could wait until then to make sure it's all fine14:22
priteaubecause we will move from libvirt 7.0.0 (from c8 AV) to libvirt 7.4.0 (from c8s AV)14:23
yoctozeptooh boy14:25
* yoctozepto 's head's spinning14:25
Fl1ntRH and Openstack are kinda going crazy with all those tightned release schedules, I mean, enterprise can't just move on with a migration every 3/6 months, it's just too much.14:27
Fl1ntI mean sure, automation.14:27
Fl1ntin a perfect world14:27
Fl1ntbut in reality, oh men, there are a loooooot of company relying on shitty OS implementation, specifics and weird constraints.14:28
opendevreviewMerged openstack/kolla master: Pin td-agent to 4.0.* to fix missing logs  https://review.opendev.org/c/openstack/kolla/+/79508614:28
Fl1ntIf at least you would be guarantee to be able to to a N+3/4 upgrade even not rolling but one by one.14:29
Fl1ntbut you're not.14:29
Fl1ntGood luck people still being on Rocky or Stein to upgrade to Wallaby peacefully ^^14:29
Fl1nt</ rant>14:29
opendevreviewRadosław Piliszek proposed openstack/kolla stable/wallaby: Pin td-agent to 4.0.* to fix missing logs  https://review.opendev.org/c/openstack/kolla/+/79643814:29
*** rpittau is now known as rpittau|afk14:29
yoctozeptoFl1nt: if you get RHOSP, then you get fast forward upgrade support goodies14:32
opendevreviewMerged openstack/kolla-ansible master: Reno follow up for docker_disable_ip_forward  https://review.opendev.org/c/openstack/kolla-ansible/+/79640614:32
opendevreviewRadosław Piliszek proposed openstack/kolla stable/victoria: Pin td-agent to 4.0.* to fix missing logs  https://review.opendev.org/c/openstack/kolla/+/79643914:32
Fl1ntyoctozepto, What do you mean?14:33
yoctozeptoFl1nt: I meant you were ranting about RH, OpenStack, and upgrades14:34
yoctozeptoanswered your rant14:34
Fl1ntFrom memories, RHOSP is OoO based, which is... kinda messy and using puppet everywhere so, I'll stick with kolla :D14:34
mnasiadkayoctozepto: You haven't really ran FFU ever, right? :D14:34
yoctozeptobut that's what RH supports, it answers your rant :P14:34
yoctozeptomnasiadka: yeah, I have not; I gave up at the initial deploy :-)14:35
Fl1ntI currently have the chance to work on a brand new platform, so I implemented automation from the beginning, but gosh, even with that it can be daunting sometimes.14:35
Fl1ntwhat really annoy me with all those new stuff is: One of the fundamental of Linux is KISS and well separated concerns, but every single piece of software now a day require its own "director" node but seems like all sysadmins want to host them on the same host for whatever reason I can't stick with.14:37
yoctozeptoI guess no need to persuade us14:37
Fl1ntOh yeah, sure, was just outing my thoughts as I'm just a bit annoyed by some reading of the industry ^^14:38
Fl1ntAnyway, I need a break :D14:38
Fl1ntsee ya all on tomorrow !14:38
opendevreviewRadosław Piliszek proposed openstack/kolla-ansible stable/wallaby: Reno follow up for docker_disable_ip_forward  https://review.opendev.org/c/openstack/kolla-ansible/+/79644014:38
yoctozeptobye Fl1nt14:38
Fl1ntbye yoctozepto o/14:39
yoctozeptoo/14:39
yoctozeptopriteau: I cleaned up the whiteboard - no kayobe nor kolla ansible blocker for wallaby14:40
yoctozeptoonly waiting for kolla unpin14:40
yoctozeptocan you confirm it for kayobe?14:41
mnasiadkayoctozepto: it's something I probably won't forget until retirement :)14:42
yoctozeptolol14:42
priteauyoctozepto: I looked at the source of the libvirt 7.0.0 package and really could not understand why it doesn't have the error since it doesn't have the fix for unknown qemu feature14:43
priteauBut actually, if you look at the libvirt logs, the error is still there: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_c46/795490/1/check/kolla-ansible-centos8s-source/c46c30b/primary/logs/kolla/libvirt/libvirtd.txt14:44
yoctozeptopriteau: perhaps they lowered the actual criticality14:45
yoctozeptoinbetween14:45
yoctozeptothe releases14:45
priteaumaybe it's not a fatal error anymore, but with 7.4.0 it shouldn't produce this message at all14:47
yoctozeptothat would be better14:47
yoctozeptook, master does not seem to have any blockers14:48
priteauyoctozepto: I am leaving my W-1 for now because we don't want to release a day before libvirt changes again, with the associated potential breakage14:58
yoctozeptopriteau: agreed, that makes sense15:04
opendevreviewMerged openstack/kolla-ansible stable/wallaby: Reno follow up for docker_disable_ip_forward  https://review.opendev.org/c/openstack/kolla-ansible/+/79644015:19
* sean-k-mooney personally wishes rhosp had become kolla-ansible based in osp 13 instead of ooo but ya.15:30
sean-k-mooney oh the  amd-sev-es issue15:31
sean-k-mooneyi think we have a downstream bug for that somewhere15:31
sean-k-mooneyit was breakign the rdo/downstream ci15:31
sean-k-mooneyi suggested pinning the cpu model but i dont know if that fixed it or not15:32
sean-k-mooneyso useing cpu_mode=custom and cpu_model=nehelem or simlar15:32
sean-k-mooneyyoctozepto: are ye still hitting that15:33
sean-k-mooneyah its been fixed in libvirt good https://github.com/libvirt/libvirt/commit/61d95a1073833ec4323c1ef28e71e913c55aa7b915:35
opendevreviewMaksim Malchuk proposed openstack/kayobe master: TLS certificates management sync with Kolla-Ansible  https://review.opendev.org/c/openstack/kayobe/+/79369715:49
priteausean-k-mooney: we are on top of it ;-)15:55
jingvarHow can I stop  -- while it is in state "wait call-back". (HTTP 400)15:58
jingvara node can stay in a wait state for a long time or even never time out - funny16:01
priteaujingvar: https://bugs.launchpad.net/ironic/+bug/165538516:21
*** ricolin_ is now known as ricolin16:26
jingvarpriteau :  i can't catch the idea16:35
priteauComment #8 gives instructions to force the node out of wait call-back state16:35
jingvar<priteau> : but I don't have "ironic" command  in the container16:41
priteauthis is an old comment. you will have to translate it to `openstack baremetal` commands16:41
jingvarI tried but can't find these options, maybe I'm tired16:43
opendevreviewMerged openstack/kolla-ansible stable/wallaby: Drop /sys/fs/cgroup mounts  https://review.opendev.org/c/openstack/kolla-ansible/+/79623116:52
opendevreviewMerged openstack/kolla stable/victoria: Pin td-agent to 4.0.* to fix missing logs  https://review.opendev.org/c/openstack/kolla/+/79643917:14
*** gfidente is now known as gfidente|afk17:14
opendevreviewMerged openstack/kolla stable/wallaby: Pin td-agent to 4.0.* to fix missing logs  https://review.opendev.org/c/openstack/kolla/+/79643817:23
pomacyoctozepto: centos 8 - built from source though - we're trying different versions17:28
pomacyoctozepto: I was afk - and the containers were built from source =)17:31
*** ricolin_ is now known as ricolin17:32
*** gilou_ is now known as Gilou17:49
pomacis there a way to manually set up and add vxlan_ssy_478918:01
pomacsys even18:01
pomacturns out that turning off l2_population causes neutron to create vxlan_sys_478918:13
pomacAccording to the neutron code no interfaces should be created when it's starting - can't find any exception18:27
pomacbut then, i'm tired18:27
opendevreviewGaël THEROND proposed openstack/kolla master: Improve offline build scenario.  https://review.opendev.org/c/openstack/kolla/+/79648018:31
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: Update previous_release to Wallaby  https://review.opendev.org/c/openstack/kolla-ansible/+/79642218:59
ozzzowhere can I find a good document on openstack routers?19:43
opendevreviewPiotr Parczewski proposed openstack/kolla-ansible master: Reduce container metrics cardinality  https://review.opendev.org/c/openstack/kolla-ansible/+/78388719:44
ozzzoI read this but it doesn't explain much: https://docs.openstack.org/python-openstackclient/train/cli/command-objects/router.html19:44
parallaxozzzo: here OVN related document: https://docs.openstack.org/neutron/latest/admin/ovn/routing.html19:54
ozzzoty parallax19:55

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!