/srv/irclogs.ubuntu.com/2022/05/31/#ubuntu-server.txt

=== xispita_ is now known as xispita
=== not_phunyguy is now known as phunyguy
=== kostkon_ is now known as kostkon
ahasenackrbasak: hi, lp is not showing the diff on this mp, and I'm not allowed to press the button at the bottom of the page that says "update diff"12:22
ahasenackrbasak: can you click it for me please? :)12:22
rbasakahasenack: link please?12:22
ahasenackoops12:22
ahasenackrbasak: https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/crmsh/+git/crmsh/+merge/42364512:23
rbasakCliecked12:23
ahasenackrbasak: diff is showing now, thanks12:24
ahasenackathos: hi, around?12:42
ahasenackkanashiro: or you?12:43
athosahasenack: I am :)12:45
ahasenacko/12:45
athos\o12:46
ahasenackI was looking at the crmsh delta in d/t/acemaker-node-status.sh12:46
ahasenackand thought we didn't need it anymore, because the test is getting the node name already12:46
ahasenackbut turns out that it looks like when we don't specify node name in corosync.conf, and it takes the default of `uname -n`, it also doesn't fill in that name in the corosync-cmapctl nodelist output12:47
ahasenacki.e., corosync-cmapctl | grep $(uname -n) is empty12:47
ahasenackI'm trying to verify with a real cluster now, not just the one with one node12:47
ahasenackI mean this diff specifically:12:48
ahasenack-NODE="$(corosync-cmapctl -q -g nodelist.node.$POS.name)"12:48
ahasenack+NODE="$(uname -n)"12:48
ahasenackI'm tempted to email the mailing list asking why is that12:49
athosThanks, ahasenack! I did consider dropping the delta, but as you also found out, it is still needed unless we sort the corosync-cmapctl issue out12:51
athoshttps://salsa.debian.org/ha-team/crmsh/-/merge_requests/3 does not help either because the patch was introduced bach when the value was hard coded12:51
ubottuMerge 3 in ha-team/crmsh "d/t/pacemaker-node-status.sh: Use 'uname -n' instead of 'node1' as the node name" [Closed]12:51
athoss/bach/back/12:51
ahasenackthere must be a way to query the node name12:52
ahasenackI just formed a real cluster of 3 nodes, all with name unset in the conf12:53
ahasenackcrm status is happy, shows all 3 online, with their respective names12:53
ahasenackbut corosync-cmapctl doesn't have their names, just ips and ids :/12:53
ahasenackhttps://pastebin.ubuntu.com/p/f4VhhMK6sX/ this is most annoying12:54
ahasenackI'll email the list12:55
athosahasenack: thanks :)12:59
athosfwiw, our corosync delta does comment the "name: node1" bit of the example configuration file and this seems to cause the test result difference between Ubuntu and Debian, but that's probably what you meant on your first comment above :)13:01
ahasenackyes, that and the fact that the debian maintainer in that PR you posted was willing to make it generic13:06
ahasenackand I agree it should be possible13:07
ahasenackcrm_node -n could be a replacement13:23
athosCould anyone import php-cache-integration-tests into git ubuntu? :)14:00
athosutkarsh2102: do you recall the story behind the delta in that package? I am wondering why we did not changes the requirements to use our current (or any) version of the dependencies instead of dropping them14:02
athoss/changes/changed/14:02
utkarsh2102athos: yes but gimme a minute, I'll need to go thru the logs/bugs to see what's up. D'you have anything handy? Bug? Or anything?14:05
athosnot really... I got there after I realized php-doctrine-cache's delta is just adding the dependency that was removed from php-cache-integration-tests; found no bugs pointing to the matter14:10
utkarsh2102athos: ah, then very like likely because it was FTBFSing and we disabled the tests to workaround our way for circular dependency.14:14
athosack; thanks for checking that. I will re-introduce the dependencies (with no version constraints) and sync php-doctrine-cache; Then I will deal with any issues during the symfony merge14:19
athosahasenack: thanks for updating the merge. I was waiting to see if there were any developments in the email thread. I will go ahead and apply the change you suggested. Do you want to propose that to Debian or should I go ahead and do it?14:22
athosIt's not like we will be able to sync that package anytime soon due to the resource agents split, but we can at least reduce the delta a bit :)14:23
ahasenackathos: a thread started14:29
ahasenackI replied14:29
ahasenackI mean, I got replies14:29
ahasenackmostly "it's expected, why would you expect otherwise?" and so on14:29
ahasenackathos: let's wait a few hours, see if there is another suggestion14:32
ahasenackafter lunch :)14:32
athos+114:33
athosthanks for handling that btw, ahasenack :)14:33
ahasenackI need to learn this stuff, there are so many layers14:38
ahasenackand depending which layer you ask, you get different answers14:38
shubjerocoreycb or anyone, when did canonical start cherry picking an openstack release to be treated as LTS?16:58
coreycbshubjero: I'm not sure I'm following. can you give an example?17:00
shubjeroFor example Ussuri on Ubuntu 20.04 is supported by canonical until 2025 (2030 with ESM), but Victoria on Ubuntu 20.04 is already unsupported. What's the expectation for operators wanting to stay on these LTS Ubuntu/OpenStack combo's? For example whatever Canonical picks for the next OpenStack LTS what's the upgrade path? Is a huge jump in openstack releases or are we still expected to do17:00
shubjeroeverything in between?17:00
shubjeroAs an operator I very much like the idea of a specific Ubuntu release and OpenStack release being supported for a long time. We rarely benefit from these incremental / frequent openstack upgrades.. causes a lot of stress for almost no reward17:02
shubjerocoreycb: ^17:02
coreycbit's been this way for a long time. the end of life releases will remain available, so you can step upgrade through victoria even though it's end of life.17:04
shubjerocoreycb: does this mean that the canonical team will be backporting more stuff to ussuri than the in between releases like victoria/wallaby/xena/etc?17:04
shubjerocoreycb: the reason i ask is because openstack has their own release cycle which i dont think aligns with what canonical is doing17:05
coreycbshubjero: yes, but if it affects upgrades we will backport to the end of life releases as well17:05
shubjerocoreycb: oh wow you guys rock17:05
sarnoldshubjero: btw https://ubuntu.com/about/release-cycle#openstack-release-cycle17:15
shubjerosarnold: yeah i only discovered this semi recently17:16
sarnoldaha cool :)17:16
ahasenackathos: let's do the crm_node -n change then17:51
ahasenackrun a quick dep8 locally17:51
yurtesenahasenack: thanks!19:06
athosahasenack: ack, I will perform the changes before I EOD and will also submit that to debian if you are OK with it :)19:37
ahasenackjust that one liner, right?19:37
athosyes19:48
ahasenackhoho, happy mailman day is starting19:54
ahasenackgot my first reminder19:54
athosahasenack: as for the changelog, should I remove the old patch (list it in dropped changes) and add a different change for the new fix there? :)20:04
ahasenackwait, let me check, I might have mixed up the names20:04
ahasenackI meant this: - d/t/pacemaker-node-status.sh: Use the output of "uname -n" instead20:05
ahasenack+      of "node1" as the pacemaker node name.20:05
ahasenacknot a patch then20:05
ahasenackbut an existing change, you would have to change the description20:05
ahasenackor is this what you meant, drop that, and add another saying what is being done now?20:05
athos^ this; So there will be two entries: one in the "Dropped changes" and another one in the "New changes", for clarity (It's not like we are keeping an old change)20:07
ahasenackI think you can use the same commit, but change the description20:07
ahasenackwe are keeping the same idea of the change, which was to use the actual node's name instead of `node1`20:07
ahasenackjust the method changeed20:07
athosfair enough20:08
ahasenackathos: tiny nitpick20:58
athosduh! Thanks :)20:59
ahasenackathos: +1'ed21:18
athosthanks!21:39

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!