Re: [ClusterLabs] Corosync 3 release plans?
On 27/09/18 20:16, Ferenc Wágner wrote: > Christine Caulfield writes: > >> I'm also looking into high-res timestamps for logfiles too. > > Wouldn't that be a useful option for the syslog output as well? I'm > sometimes concerned by the batching effect added by the transport > between the application and the (local) log server (rsyslog or systemd). > Reliably merging messages from different channels can prove impossible > without internal timestamps (even considering a single machine only). > > Another interesting feature could be structured, direct journal output > (if you're looking for challenges). > I'm inclined to leave syslog timestamps to syslog - rsyslog has the option for hi-res timestamps (yes, I know it stamps them on receipt and all that) if you need them. Adding 'proper' journal output sounds like a good idea to me though I'm not so much looking for challenges as looking to make libqb more useful for the people using it :) Chrissie ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Christine Caulfield writes: > I'm also looking into high-res timestamps for logfiles too. Wouldn't that be a useful option for the syslog output as well? I'm sometimes concerned by the batching effect added by the transport between the application and the (local) log server (rsyslog or systemd). Reliably merging messages from different channels can prove impossible without internal timestamps (even considering a single machine only). Another interesting feature could be structured, direct journal output (if you're looking for challenges). -- Regards, Feri ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Ken Gaillot writes: > libqb would simply provide the API for reopening the log, and clients > such as pacemaker would intercept the signal and call the API. Just for posterity: you needn't restrict yourself to signals. Logrotate has nothing to do with signals. Signals are a rather limited form of IPC, which might be a good tool for some applications. Both Pacemaker and Corosync already employ much richer IPC mechanisms, which might be more natural to extend for triggering log rotation than adding a new IPC mechanism. Logrotate optionally runs scripts before and after renaming the log files; these can invoke kill, corosync-cmapctl, cibadmin and so on all the same. It's entirely your call. -- Regards, Feri ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
On Thu, 2018-09-27 at 16:09 +0100, Christine Caulfield wrote: > On 27/09/18 16:01, Ken Gaillot wrote: > > On Thu, 2018-09-27 at 09:58 -0500, Ken Gaillot wrote: > > > On Thu, 2018-09-27 at 15:32 +0200, Ferenc Wágner wrote: > > > > Christine Caulfield writes: > > > > > > > > > TBH I would be quite happy to leave this to logrotate but the > > > > > message I > > > > > was getting here is that we need additional help from libqb. > > > > > I'm > > > > > willing > > > > > to go with a consensus on this though > > > > > > > > Yes, to do a proper job logrotate has to have a way to get the > > > > log > > > > files > > > > reopened. And applications can't do that without support from > > > > libqb, > > > > if > > > > I understood Honza right. > > > > > > There are two related issues: > > > > > > * Issue #142, about automatically rotating logs once they reach a > > > certain size, can be done with logrotate already. If it's a one- > > > time > > > thing (e.g. running a test with trace), the admin can control > > > rotation > > > directly with logrotate --force /etc/logrotate.d/whatever.conf. > > > If > > > it's > > > desired permanently, a maxsize or size line can be added to the > > > logrotate config (which, now that I think about it, would be a > > > good > > > idea for the default pacemaker config). > > > > > > * Issue #239, about the possibility of losing messages with > > > copytruncate, has a widely used, easily implemented, and robust > > > solution of using a signal to indicate reopening a log. logrotate > > > is > > > then configured to rotate by moving the log to a new name, > > > sending > > > the > > > signal, then compressing the old log. > > > > Regarding implementation in libqb's case, libqb would simply > > provide > > the API for reopening the log, and clients such as pacemaker would > > intercept the signal and call the API. > > > > That sounds pretty easy to achieve. I'm also looking into high-res > timestamps for logfiles too. > > > A minor complication is that pacemaker would have to supply > > different > > logrotate configs depending on the version of libqb available. > > > > Can't you just intercept the signal anyway and not do anything if an > old > libqb is linked in? > > Chrissie Yes, but the logrotate config will need to keep the copytruncate option or not depending on whether the new API is available. It's not too difficult via the configure script, just reminding myself to do it :) -- Ken Gaillot ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
On 27/09/18 16:01, Ken Gaillot wrote: > On Thu, 2018-09-27 at 09:58 -0500, Ken Gaillot wrote: >> On Thu, 2018-09-27 at 15:32 +0200, Ferenc Wágner wrote: >>> Christine Caulfield writes: >>> TBH I would be quite happy to leave this to logrotate but the message I was getting here is that we need additional help from libqb. I'm willing to go with a consensus on this though >>> >>> Yes, to do a proper job logrotate has to have a way to get the log >>> files >>> reopened. And applications can't do that without support from >>> libqb, >>> if >>> I understood Honza right. >> >> There are two related issues: >> >> * Issue #142, about automatically rotating logs once they reach a >> certain size, can be done with logrotate already. If it's a one-time >> thing (e.g. running a test with trace), the admin can control >> rotation >> directly with logrotate --force /etc/logrotate.d/whatever.conf. If >> it's >> desired permanently, a maxsize or size line can be added to the >> logrotate config (which, now that I think about it, would be a good >> idea for the default pacemaker config). >> >> * Issue #239, about the possibility of losing messages with >> copytruncate, has a widely used, easily implemented, and robust >> solution of using a signal to indicate reopening a log. logrotate is >> then configured to rotate by moving the log to a new name, sending >> the >> signal, then compressing the old log. > > Regarding implementation in libqb's case, libqb would simply provide > the API for reopening the log, and clients such as pacemaker would > intercept the signal and call the API. > That sounds pretty easy to achieve. I'm also looking into high-res timestamps for logfiles too. > A minor complication is that pacemaker would have to supply different > logrotate configs depending on the version of libqb available. > Can't you just intercept the signal anyway and not do anything if an old libqb is linked in? Chrissie ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
On Thu, 2018-09-27 at 09:58 -0500, Ken Gaillot wrote: > On Thu, 2018-09-27 at 15:32 +0200, Ferenc Wágner wrote: > > Christine Caulfield writes: > > > > > TBH I would be quite happy to leave this to logrotate but the > > > message I > > > was getting here is that we need additional help from libqb. I'm > > > willing > > > to go with a consensus on this though > > > > Yes, to do a proper job logrotate has to have a way to get the log > > files > > reopened. And applications can't do that without support from > > libqb, > > if > > I understood Honza right. > > There are two related issues: > > * Issue #142, about automatically rotating logs once they reach a > certain size, can be done with logrotate already. If it's a one-time > thing (e.g. running a test with trace), the admin can control > rotation > directly with logrotate --force /etc/logrotate.d/whatever.conf. If > it's > desired permanently, a maxsize or size line can be added to the > logrotate config (which, now that I think about it, would be a good > idea for the default pacemaker config). > > * Issue #239, about the possibility of losing messages with > copytruncate, has a widely used, easily implemented, and robust > solution of using a signal to indicate reopening a log. logrotate is > then configured to rotate by moving the log to a new name, sending > the > signal, then compressing the old log. Regarding implementation in libqb's case, libqb would simply provide the API for reopening the log, and clients such as pacemaker would intercept the signal and call the API. A minor complication is that pacemaker would have to supply different logrotate configs depending on the version of libqb available. -- Ken Gaillot ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
On Thu, 2018-09-27 at 15:32 +0200, Ferenc Wágner wrote: > Christine Caulfield writes: > > > TBH I would be quite happy to leave this to logrotate but the > > message I > > was getting here is that we need additional help from libqb. I'm > > willing > > to go with a consensus on this though > > Yes, to do a proper job logrotate has to have a way to get the log > files > reopened. And applications can't do that without support from libqb, > if > I understood Honza right. There are two related issues: * Issue #142, about automatically rotating logs once they reach a certain size, can be done with logrotate already. If it's a one-time thing (e.g. running a test with trace), the admin can control rotation directly with logrotate --force /etc/logrotate.d/whatever.conf. If it's desired permanently, a maxsize or size line can be added to the logrotate config (which, now that I think about it, would be a good idea for the default pacemaker config). * Issue #239, about the possibility of losing messages with copytruncate, has a widely used, easily implemented, and robust solution of using a signal to indicate reopening a log. logrotate is then configured to rotate by moving the log to a new name, sending the signal, then compressing the old log. -- Ken Gaillot ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Christine Caulfield writes: > TBH I would be quite happy to leave this to logrotate but the message I > was getting here is that we need additional help from libqb. I'm willing > to go with a consensus on this though Yes, to do a proper job logrotate has to have a way to get the log files reopened. And applications can't do that without support from libqb, if I understood Honza right. -- Regards, Feri ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
On 27/09/18 12:52, Ferenc Wágner wrote: > Christine Caulfield writes: > >> I'm looking into new features for libqb and the option in >> https://github.com/ClusterLabs/libqb/issues/142#issuecomment-76206425 >> looks like a good option to me. > > It feels backwards to me: traditionally, increasing numbers signify > older rotated logs, while this proposal does the opposite. And what > happens on application restart? Do you overwrite from 0? Do you ever > jump back to 0? It also leaves the problem of cleaning up old log files > unsolved... The idea I had was to look for logs with 'old' numbers at startup and then start a new log with the next number, starting at 0 or 1. Good point about the numbers going the other way with logrotate though, I hadn't considered that > >> Though adding an API call to re-open the log file could be done too - >> I'm not averse to having both, > > Not addig log rotation policy (and implementation!) to each application > is a win in my opinion, and also unifies local administration. Syslog > is pretty good in this regard, my only gripe with it is that its time > stamps can't be quite as precise as the ones from the (realtime) > application (even nowadays, under systemd). And that it can block the > log stream... on the other hand, disk latencies can block log writes > just as well. > TBH I would be quite happy to leave this to logrotate but the message I was getting here is that we need additional help from libqb. I'm willing to go with a consensus on this though Chrissie ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Christine Caulfield writes: > I'm looking into new features for libqb and the option in > https://github.com/ClusterLabs/libqb/issues/142#issuecomment-76206425 > looks like a good option to me. It feels backwards to me: traditionally, increasing numbers signify older rotated logs, while this proposal does the opposite. And what happens on application restart? Do you overwrite from 0? Do you ever jump back to 0? It also leaves the problem of cleaning up old log files unsolved... > Though adding an API call to re-open the log file could be done too - > I'm not averse to having both, Not addig log rotation policy (and implementation!) to each application is a win in my opinion, and also unifies local administration. Syslog is pretty good in this regard, my only gripe with it is that its time stamps can't be quite as precise as the ones from the (realtime) application (even nowadays, under systemd). And that it can block the log stream... on the other hand, disk latencies can block log writes just as well. -- Regards, Feri ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
On 26/09/18 09:21, Ferenc Wágner wrote: > Jan Friesse writes: > >> wagner.fer...@kifu.gov.hu writes: >> >>> triggered by your favourite IPC mechanism (SIGHUP and SIGUSRx are common >>> choices, but logging.* cmap keys probably fit Corosync better). That >>> would enable proper log rotation. >> >> What is the reason that you find "copytruncate" as non-proper log >> rotation? I know there is a risk to loose some lines, but it should be >> pretty small. > > Yes, there's a chance of losing some messages. It may be acceptable in > some cases, but it's never desirable. The copy operation also wastes > I/O bandwidth. Reopening the log files on some external trigger is a > better solution on all accounts and also an industry standard. > >> Anyway, this again one of the feature where support from libqb would >> be nice to have (there is actually issue opened >> https://github.com/ClusterLabs/libqb/issues/239). > > That's a convoluted one for a simple reopen! But yes, if libqb does not > expose such functionality, you can't do much about it. I'll stay with > syslog for now. :) In cluster environments centralised log management is > a must anyway, and that's annoying to achieve with direct file logs. > I'm looking into new features for libqb and the option in https://github.com/ClusterLabs/libqb/issues/142#issuecomment-76206425 looks like a good option to me. Though adding an API call to re-open the log file could be done too - I'm not averse to having both, Chrissie >>> Jan Friesse writes: >>> No matter how much I still believe totemsrp as a library would be super nice to have - but current state is far away from what I would call library (= something small, without non-related things like transports/ip/..., testable (ideally with unit tests testing corner cases)) and making one fat binary looks like a better way. I'll made a patch and send PR (it should be easy). >>> >>> Sounds sensible. Somebody can still split it out later if needed. >> >> Yep (and PR send + merged already :) ) > > Great! Did you mean to keep the totem.h, totemip.h, totempg.h and > totemstats.h header files installed nevertheless? And totem_pg.pc could > go as well, I guess. > ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Ferenc, Jan Friesse writes: wagner.fer...@kifu.gov.hu writes: triggered by your favourite IPC mechanism (SIGHUP and SIGUSRx are common choices, but logging.* cmap keys probably fit Corosync better). That would enable proper log rotation. What is the reason that you find "copytruncate" as non-proper log rotation? I know there is a risk to loose some lines, but it should be pretty small. Yes, there's a chance of losing some messages. It may be acceptable in some cases, but it's never desirable. The copy operation also wastes I/O bandwidth. Reopening the log files on some external trigger is a better solution on all accounts and also an industry standard. Got it Anyway, this again one of the feature where support from libqb would be nice to have (there is actually issue opened https://github.com/ClusterLabs/libqb/issues/239). That's a convoluted one for a simple reopen! But yes, if libqb does not I'm pretty sure you've seen my 2cents comment. expose such functionality, you can't do much about it. I'll stay with I can send PR :) syslog for now. :) In cluster environments centralised log management is a must anyway, and that's annoying to achieve with direct file logs. Jan Friesse writes: No matter how much I still believe totemsrp as a library would be super nice to have - but current state is far away from what I would call library (= something small, without non-related things like transports/ip/..., testable (ideally with unit tests testing corner cases)) and making one fat binary looks like a better way. I'll made a patch and send PR (it should be easy). Sounds sensible. Somebody can still split it out later if needed. Yep (and PR send + merged already :) ) Great! Did you mean to keep the totem.h, totemip.h, totempg.h and totemstats.h header files installed nevertheless? And totem_pg.pc could Whups. No, that was just an oversight. These files shouldn't be installed. go as well, I guess. Yep. Thank you for notice (I've already opened another PR). Regards, Honza ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Jan Friesse writes: > wagner.fer...@kifu.gov.hu writes: > >> triggered by your favourite IPC mechanism (SIGHUP and SIGUSRx are common >> choices, but logging.* cmap keys probably fit Corosync better). That >> would enable proper log rotation. > > What is the reason that you find "copytruncate" as non-proper log > rotation? I know there is a risk to loose some lines, but it should be > pretty small. Yes, there's a chance of losing some messages. It may be acceptable in some cases, but it's never desirable. The copy operation also wastes I/O bandwidth. Reopening the log files on some external trigger is a better solution on all accounts and also an industry standard. > Anyway, this again one of the feature where support from libqb would > be nice to have (there is actually issue opened > https://github.com/ClusterLabs/libqb/issues/239). That's a convoluted one for a simple reopen! But yes, if libqb does not expose such functionality, you can't do much about it. I'll stay with syslog for now. :) In cluster environments centralised log management is a must anyway, and that's annoying to achieve with direct file logs. >> Jan Friesse writes: >> >>> No matter how much I still believe totemsrp as a library would be >>> super nice to have - but current state is far away from what I would >>> call library (= something small, without non-related things like >>> transports/ip/..., testable (ideally with unit tests testing corner >>> cases)) and making one fat binary looks like a better way. >>> >>> I'll made a patch and send PR (it should be easy). >> >> Sounds sensible. Somebody can still split it out later if needed. > > Yep (and PR send + merged already :) ) Great! Did you mean to keep the totem.h, totemip.h, totempg.h and totemstats.h header files installed nevertheless? And totem_pg.pc could go as well, I guess. -- Regards, Feri ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Ferenc, Jan Friesse writes: Default example config should be definitively ported to newer style of nodelist without interface section. example.udpu can probably be deleted as well as example.xml (whole idea of having XML was because of cluster config tools like pcs, but these tools never used corosync.xml). Kind of strange, because the inherently hierarchical Corosync configuration admits a very natural XML representation. Agree I was also thinking about allowing timestamp by default, because log without timestamp is useless. I recommend adding high resolution timestamps, even, but for the direct For this we would need support from libqb which (AFAIK) still doesn't support highres timestamps. file log only, not for syslog (by default). And log file reopening timestamp doesn't affect blackbox and/or syslog. triggered by your favourite IPC mechanism (SIGHUP and SIGUSRx are common choices, but logging.* cmap keys probably fit Corosync better). That would enable proper log rotation. What is the reason that you find "copytruncate" as non-proper log rotation? I know there is a risk to loose some lines, but it should be pretty small. Anyway, this again one of the feature where support from libqb would be nice to have (there is actually issue opened https://github.com/ClusterLabs/libqb/issues/239). Finally, something totally unrelated: the libtotem_pg shared object isn't standalone anymore, it has several undefined symbols (icmap_get_*, stats_knet_add_member, etc) which are defined in the corosync binary. This must be fixed. Or rather eliminated, if I read correctly below. Yep Why is it still a separate object then? Honestly, I don't have too much strong reasons. We've talked with Chrissie about it last year, and actually only reason I was able to find out was to have a code/component separation so in theory other project can use totem (what was original idea, but it never happened and I don't think it will ever happen). Anyway, conclusion was to remove the totem as a shared library and keep it as a static library only, but nobody actually implemented that yet. That doesn't buy you anything if you use it in a single binary only. No matter how much I still believe totemsrp as a library would be super nice to have - but current state is far away from what I would call library (= something small, without non-related things like transports/ip/..., testable (ideally with unit tests testing corner cases)) and making one fat binary looks like a better way. I'll made a patch and send PR (it should be easy). Sounds sensible. Somebody can still split it out later if needed. Yep (and PR send + merged already :) ) Regards, Honza Thank you for the testing and reporting problems! My pleasure, speaking about the latter. I haven't got to do any significant testing yet, unfortunately. ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Jan Friesse writes: > Default example config should be definitively ported to newer style of > nodelist without interface section. example.udpu can probably be > deleted as well as example.xml (whole idea of having XML was because > of cluster config tools like pcs, but these tools never used > corosync.xml). Kind of strange, because the inherently hierarchical Corosync configuration admits a very natural XML representation. > I was also thinking about allowing timestamp by default, because log > without timestamp is useless. I recommend adding high resolution timestamps, even, but for the direct file log only, not for syslog (by default). And log file reopening triggered by your favourite IPC mechanism (SIGHUP and SIGUSRx are common choices, but logging.* cmap keys probably fit Corosync better). That would enable proper log rotation. >> Finally, something totally unrelated: the libtotem_pg shared object >> isn't standalone anymore, it has several undefined symbols (icmap_get_*, >> stats_knet_add_member, etc) which are defined in the corosync binary. > > This must be fixed. Or rather eliminated, if I read correctly below. >> Why is it still a separate object then? > > Honestly, I don't have too much strong reasons. We've talked with > Chrissie about it last year, and actually only reason I was able to > find out was to have a code/component separation so in theory other > project can use totem (what was original idea, but it never happened > and I don't think it will ever happen). Anyway, conclusion was to > remove the totem as a shared library and keep it as a static library > only, but nobody actually implemented that yet. That doesn't buy you anything if you use it in a single binary only. > No matter how much I still believe totemsrp as a library would be > super nice to have - but current state is far away from what I would > call library (= something small, without non-related things like > transports/ip/..., testable (ideally with unit tests testing corner > cases)) and making one fat binary looks like a better way. > > I'll made a patch and send PR (it should be easy). Sounds sensible. Somebody can still split it out later if needed. > Thank you for the testing and reporting problems! My pleasure, speaking about the latter. I haven't got to do any significant testing yet, unfortunately. -- Regards, Feri ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Ferenc, Jan Friesse writes: Have you had a time to play with packaging current alpha to find out if there are no issues? I had no problems with Fedora, but Debian has a lot of patches, and I would be really grateful if we could reduce them a lot - so please let me know if there is patch which you've sent PR for and it's not merged yet. Hi Honza, Sorry for the delay. You've already merged my PR for two simple typos, no worries thanks! Beyond that, there really isn't much in our patch queue anymore. As far as I can see, current master even has a patch for error propagation in notifyd, which will let us drop one more! And we arrive at the example configs. We prefer syslog for several reasons (copytruncate rotation isn't pretty, decoupling possible I/O stalls) and we haven't got the /var/log/cluster legacy. But more importantly, the knet default transport requires a nodelist instead of interfaces, unlike mcast udp. The "ring" terminology might need a change as well, especially ring0_addr. So I'd welcome an overhaul of the (now knet) example config, but I'm not personally qualified for doing that. :) Yes, that's really good catch, because I've totally forgot this two files. Default example config should be definitively ported to newer style of nodelist without interface section. example.udpu can probably be deleted as well as example.xml (whole idea of having XML was because of cluster config tools like pcs, but these tools never used corosync.xml). I was also thinking about allowing timestamp by default, because log without timestamp is useless. Finally, something totally unrelated: the libtotem_pg shared object isn't standalone anymore, it has several undefined symbols (icmap_get_*, stats_knet_add_member, etc) which are defined in the corosync binary. This must be fixed. Why is it still a separate object then? Honestly, I don't have too much strong reasons. We've talked with Chrissie about it last year, and actually only reason I was able to find out was to have a code/component separation so in theory other project can use totem (what was original idea, but it never happened and I don't think it will ever happen). Anyway, conclusion was to remove the totem as a shared library and keep it as a static library only, but nobody actually implemented that yet. No matter how much I still believe totemsrp as a library would be super nice to have - but current state is far away from what I would call library (= something small, without non-related things like transports/ip/..., testable (ideally with unit tests testing corner cases)) and making one fat binary looks like a better way. I'll made a patch and send PR (it should be easy). Thank you for the testing and reporting problems! Regards, Honza ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
On 24/09/18 13:12, Ferenc Wágner wrote: > Jan Friesse writes: > >> Have you had a time to play with packaging current alpha to find out >> if there are no issues? I had no problems with Fedora, but Debian has >> a lot of patches, and I would be really grateful if we could reduce >> them a lot - so please let me know if there is patch which you've sent >> PR for and it's not merged yet. > > Hi Honza, > > Sorry for the delay. You've already merged my PR for two simple typos, > thanks! Beyond that, there really isn't much in our patch queue > anymore. As far as I can see, current master even has a patch for error > propagation in notifyd, which will let us drop one more! And we arrive > at the example configs. We prefer syslog for several reasons > (copytruncate rotation isn't pretty, decoupling possible I/O stalls) and > we haven't got the /var/log/cluster legacy. But more importantly, the > knet default transport requires a nodelist instead of interfaces, unlike > mcast udp. The "ring" terminology might need a change as well, > especially ring0_addr. So I'd welcome an overhaul of the (now knet) > example config, but I'm not personally qualified for doing that. :) > > Finally, something totally unrelated: the libtotem_pg shared object > isn't standalone anymore, it has several undefined symbols (icmap_get_*, > stats_knet_add_member, etc) which are defined in the corosync binary. > Why is it still a separate object then? > I argued a while back for making it a static library or just building it straight into corosync. It makes little sense to me having it as a shared library any more - if it ever did. All it really achieves (IMHO) is to make debugging more complicated than it ought to be. Chrissie ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Jan Friesse writes: > Have you had a time to play with packaging current alpha to find out > if there are no issues? I had no problems with Fedora, but Debian has > a lot of patches, and I would be really grateful if we could reduce > them a lot - so please let me know if there is patch which you've sent > PR for and it's not merged yet. Hi Honza, Sorry for the delay. You've already merged my PR for two simple typos, thanks! Beyond that, there really isn't much in our patch queue anymore. As far as I can see, current master even has a patch for error propagation in notifyd, which will let us drop one more! And we arrive at the example configs. We prefer syslog for several reasons (copytruncate rotation isn't pretty, decoupling possible I/O stalls) and we haven't got the /var/log/cluster legacy. But more importantly, the knet default transport requires a nodelist instead of interfaces, unlike mcast udp. The "ring" terminology might need a change as well, especially ring0_addr. So I'd welcome an overhaul of the (now knet) example config, but I'm not personally qualified for doing that. :) Finally, something totally unrelated: the libtotem_pg shared object isn't standalone anymore, it has several undefined symbols (icmap_get_*, stats_knet_add_member, etc) which are defined in the corosync binary. Why is it still a separate object then? -- Thanks, Feri ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Ferenc, Jan Friesse writes: Currently I'm pretty happy with current Corosync alpha stability so it would be possible to release final right now, but because I want to give us some room to break protocol/abi (only if needed and right now I don't see any strong reason for such breakage), I didn't release it yet. Great! Currently I'm planning to release 3.0.0 in the beginning of December but if it would mean to miss Debian freeze date I'm open to release it sooner. No need, we should be plenty good with this, the target date of the transition freeze is 2019-Jan-12. Perfect. Have you had a time to play with packaging current alpha to find out if there are no issues? I had no problems with Fedora, but Debian has a lot of patches, and I would be really grateful if we could reduce them a lot - so please let me know if there is patch which you've sent PR for and it's not merged yet. Thanks, Honza ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Jan Friesse writes: > Currently I'm pretty happy with current Corosync alpha stability so it > would be possible to release final right now, but because I want to > give us some room to break protocol/abi (only if needed and right now > I don't see any strong reason for such breakage), I didn't release it > yet. Great! > Currently I'm planning to release 3.0.0 in the beginning of December > but if it would mean to miss Debian freeze date I'm open to release it > sooner. No need, we should be plenty good with this, the target date of the transition freeze is 2019-Jan-12. -- Thanks, Feri ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Corosync 3 release plans?
Ferenc, Jan Friesse writes: try corosync 3.x (current Alpha4 is pretty stable [...] Hi Honza, Can you provide an estimate for the Corosync 3 release timeline? We have to plan the ABI transition in Debian anf the freeze date is drawing closer. Currently I'm pretty happy with current Corosync alpha stability so it would be possible to release final right now, but because I want to give us some room to break protocol/abi (only if needed and right now I don't see any strong reason for such breakage), I didn't release it yet. Currently I'm planning to release 3.0.0 in the beginning of December but if it would mean to miss Debian freeze date I'm open to release it sooner. Honza ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
