=== xispita_ is now known as xispita === not_phunyguy is now known as phunyguy === kostkon_ is now known as kostkon [12:22] rbasak: 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] rbasak: can you click it for me please? :) [12:22] ahasenack: link please? [12:22] oops [12:23] rbasak: https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/crmsh/+git/crmsh/+merge/423645 [12:23] Cliecked [12:24] rbasak: diff is showing now, thanks [12:42] athos: hi, around? [12:43] kanashiro: or you? [12:45] ahasenack: I am :) [12:45] o/ [12:46] \o [12:46] I was looking at the crmsh delta in d/t/acemaker-node-status.sh [12:46] and thought we didn't need it anymore, because the test is getting the node name already [12:47] but 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 output [12:47] i.e., corosync-cmapctl | grep $(uname -n) is empty [12:47] I'm trying to verify with a real cluster now, not just the one with one node [12:48] I mean this diff specifically: [12:48] -NODE="$(corosync-cmapctl -q -g nodelist.node.$POS.name)" [12:48] +NODE="$(uname -n)" [12:49] I'm tempted to email the mailing list asking why is that [12:51] Thanks, ahasenack! I did consider dropping the delta, but as you also found out, it is still needed unless we sort the corosync-cmapctl issue out [12:51] https://salsa.debian.org/ha-team/crmsh/-/merge_requests/3 does not help either because the patch was introduced bach when the value was hard coded [12:51] Merge 3 in ha-team/crmsh "d/t/pacemaker-node-status.sh: Use 'uname -n' instead of 'node1' as the node name" [Closed] [12:51] s/bach/back/ [12:52] there must be a way to query the node name [12:53] I just formed a real cluster of 3 nodes, all with name unset in the conf [12:53] crm status is happy, shows all 3 online, with their respective names [12:53] but corosync-cmapctl doesn't have their names, just ips and ids :/ [12:54] https://pastebin.ubuntu.com/p/f4VhhMK6sX/ this is most annoying [12:55] I'll email the list [12:59] ahasenack: thanks :) [13:01] fwiw, 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:06] yes, that and the fact that the debian maintainer in that PR you posted was willing to make it generic [13:07] and I agree it should be possible [13:23] crm_node -n could be a replacement [14:00] Could anyone import php-cache-integration-tests into git ubuntu? :) [14:02] utkarsh2102: 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 them [14:02] s/changes/changed/ [14:05] athos: 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:10] not 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 matter [14:14] athos: ah, then very like likely because it was FTBFSing and we disabled the tests to workaround our way for circular dependency. [14:19] ack; 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 merge [14:22] ahasenack: 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:23] It'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:29] athos: a thread started [14:29] I replied [14:29] I mean, I got replies [14:29] mostly "it's expected, why would you expect otherwise?" and so on [14:32] athos: let's wait a few hours, see if there is another suggestion [14:32] after lunch :) [14:33] +1 [14:33] thanks for handling that btw, ahasenack :) [14:38] I need to learn this stuff, there are so many layers [14:38] and depending which layer you ask, you get different answers [16:58] coreycb or anyone, when did canonical start cherry picking an openstack release to be treated as LTS? [17:00] shubjero: I'm not sure I'm following. can you give an example? [17:00] For 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 do [17:00] everything in between? [17:02] As 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 reward [17:02] coreycb: ^ [17:04] it'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] coreycb: 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:05] coreycb: the reason i ask is because openstack has their own release cycle which i dont think aligns with what canonical is doing [17:05] shubjero: yes, but if it affects upgrades we will backport to the end of life releases as well [17:05] coreycb: oh wow you guys rock [17:15] shubjero: btw https://ubuntu.com/about/release-cycle#openstack-release-cycle [17:16] sarnold: yeah i only discovered this semi recently [17:16] aha cool :) [17:51] athos: let's do the crm_node -n change then [17:51] run a quick dep8 locally [19:06] ahasenack: thanks! [19:37] ahasenack: ack, I will perform the changes before I EOD and will also submit that to debian if you are OK with it :) [19:37] just that one liner, right? [19:48] yes [19:54] hoho, happy mailman day is starting [19:54] got my first reminder [20:04] ahasenack: 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] wait, let me check, I might have mixed up the names [20:05] I meant this: - d/t/pacemaker-node-status.sh: Use the output of "uname -n" instead [20:05] + of "node1" as the pacemaker node name. [20:05] not a patch then [20:05] but an existing change, you would have to change the description [20:05] or is this what you meant, drop that, and add another saying what is being done now? [20:07] ^ 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] I think you can use the same commit, but change the description [20:07] we are keeping the same idea of the change, which was to use the actual node's name instead of `node1` [20:07] just the method changeed [20:08] fair enough [20:58] athos: tiny nitpick [20:59] duh! Thanks :) [21:18] athos: +1'ed [21:39] thanks!