Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 2013-06-28T11:11:00, Andrew Beekhof and...@beekhof.net wrote:
Maybe you're right, maybe I should stop fighting it and go with the
firefox approach.
That certainly seemed to piss a lot of people off though...
If there's one message I've learned in 13 years of work on Linux HA,
then it is that people are *always* going to be pissed off. ;-)
Ok, so are you actually proposing we switch upstream to Pacemaker-{integer}
releases, forsake any notion of stable versions and leave that to the
enterprise distros?
I'm with you on this, except for forsake any notion of stable
versions.
My grumbling about 1.1.8 was mostly because it was an *exception* (from
where I stand); for the most part, all pacemaker versions have been
continuously progressing and regressions were rare enough, partly due
to the diligence of the developer(s), but also due to the rather
extensive regression test suites, and keeping backwards compatibility
(which is, anyway, a strong requirement due to the need of supporting
rolling upgrades).
So it was always easy enough to just upgrade, effectively following a
firefox model. (Or a Linux kernel 3.x model, more like.) As far as I
can see, 1.1.x already did that.
There's an exception: dropping commonly used external interfaces (say,
ptest) needs to be announced a few releases in advance before enacted
upstream. (And if Enterprise distributions want to keep something, they
have time to prepare for that.) And of course, if major components get
rewritten, they either need more testing or should be in place in
parallel for 1 or 2 releases.
Even though an Enterprise model pays my bills, I'm a big fan of
continuous delivery. I believe that everything else is mostly madness.
(Perpetuated by customers willing to pay for it, and because admittedly
not all components have good test suites.)
Regards,
Lars
--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG Nürnberg)
Experience is the name everyone gives to their mistakes. -- Oscar Wilde
___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 2013-06-27T14:28:19, Andrew Beekhof and...@beekhof.net wrote: I wouldn't say the 6 months between 1.1.7 and 1.1.8 was a particularly aggressive release cycle. For the amount of changes in there, I think yes. And the intrusive ones didn't show up all at the beginning of that cycle, either. That just made integration difficult - basically, we ended up skipping 1.1.8/1.1.9 and went mostly with 1.1.10-rcx. Generally though, it has always been hard/dangerous to backport specific fixes because of the complexity of the interactions - particularly in the PE. Yes, that's why we try to avoid backports ;-) Yeah, that one. If it fixes a bug, it was probably unavoidable (though the specific commit (953bedf8f7f54f91a76672aeee5f44dc465741e9) didn't mention a bugzilla id). It has always been the case that I find and fix far more bugs than people report. I don't plan to start filing bugs for myself. True, I didn't mean that was necessary. A one liner about the fix would have been helpful, though. In this case though, I made an exception because the plan is to NOT have another 1.1.x and it is still my intention not to have API changes in 2.0.x, so better before than after. True. I admit I would probably have taken that as a reason for inserting one more 1.1.x release, but I understand you have your own scheduling requirements. Granted I had completely forgotten about the plugin editions of ocfs2/dlm, but I was told you'd already deep frozen what you were planning to ship, so I don't understand the specific concern. We're already working towards the first maintenance update ;-) And it's not a specific concern (we'll delay that one until it's all settled again), but we were discussing changes and how to schedule releases for them; and from the point of view as a consumer/user, introducing such a change in what was supposed to be the last release candidate was a huge surprise. There is never a good point to make these changes, even if I make them just after a release people will just grumble when it comes time to look at the next one - just like you did above for 1.1.8. No, that's not quite it. 1.1.8 *was* special. Also look at the impact it had on our users; LRM rewrite (which implies huge logging changes), crmsh split, changes to m/s ... 1.1.8 was an exception in what otherwise is a rather impressive track record of releases. Normally, integrating new releases has always been rather straightforward. But I don't want to dwell on that. I don't really mind the API changes much, for me it's mostly a question of timing and how big the pile is at every single release. I thought you wanted longer release cycles... wouldn't that make the pile bigger? No, I generally tend to want shorter release cycles, with a more moderate flow of changes. (As far as that is concerned.) And is it not better to batch them up and have one point of incompatibility rather than a continuous stream of them? Well, that means we end up backporting the changes that can't wait. And the cliff to jump from to the next release just becomes larger and more deterring. If you consider the API from a customer point of view, the things like build or runtime dependencies on shared libraries aren't so much of an issue - hopefully, the distribution provider hides that before they release updates. Hence my Oh well, I don't care stance. Except if it affects ocf2/dlm/sbd? I don't care for the fact that the changes were made, much. The new interface looks like a win and code reduction. My comment was, as stated above, specifically about doing such a change in a late release candidate. What's more troublesome are changes to existing commands (even something minimal like crm_resource -M now generating a short location constraint, I find it confusing how an contained 10 line change to a CLI tool is troublesome Because it shows through to users. And it's then when I start having to worry about users complaining when their scripts break (that expected the tools to do something specific; though I hope that in this case it doesn't - we'll document it as an optimization). but you're prepared to wear the overhead of holding back API changes - which usually impact all sorts of code paths, sometimes across multiple projects. We don't hold them back. We'll fix the dependencies before the release. It's my intention to keep being as close to a (tested) upstream version as possible, because everything else ends up being very costly. The difference is that the latter is a cost that is internal to us as developers, and not something that users/customers would possibly care about. (Unless they've written their own add-on code, which is truly rare.) CLI output I can usually be convinced of, but log messages are most definitely not something I will consider as a valid programming interface. Agreed. It's not an API, that's for sure. Yet it's one of the interfaces to *customers* and their system
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 27/06/2013, at 5:40 PM, Lars Marowsky-Bree l...@suse.com wrote: On 2013-06-27T14:28:19, Andrew Beekhof and...@beekhof.net wrote: I wouldn't say the 6 months between 1.1.7 and 1.1.8 was a particularly aggressive release cycle. For the amount of changes in there, I think yes. And the intrusive ones didn't show up all at the beginning of that cycle, either. That just made integration difficult - basically, we ended up skipping 1.1.8/1.1.9 and went mostly with 1.1.10-rcx. Generally though, it has always been hard/dangerous to backport specific fixes because of the complexity of the interactions - particularly in the PE. Yes, that's why we try to avoid backports ;-) Yeah, that one. If it fixes a bug, it was probably unavoidable (though the specific commit (953bedf8f7f54f91a76672aeee5f44dc465741e9) didn't mention a bugzilla id). It has always been the case that I find and fix far more bugs than people report. I don't plan to start filing bugs for myself. True, I didn't mean that was necessary. A one liner about the fix would have been helpful, though. There was one :-) I merged the best bits of three parallel CPG code paths. The things that prompted the extra bits in one also applied to the others. In this case though, I made an exception because the plan is to NOT have another 1.1.x and it is still my intention not to have API changes in 2.0.x, so better before than after. True. I admit I would probably have taken that as a reason for inserting one more 1.1.x release, but I understand you have your own scheduling requirements. I'm also quite over doing releases. I've been wanting to close the door on 1.1 since 2010, every extra release just leaves more time for new features (and cleanups) to be dreamt up. Maybe you're right, maybe I should stop fighting it and go with the firefox approach. That certainly seemed to piss a lot of people off though... Granted I had completely forgotten about the plugin editions of ocfs2/dlm, but I was told you'd already deep frozen what you were planning to ship, so I don't understand the specific concern. We're already working towards the first maintenance update ;-) And it's not a specific concern (we'll delay that one until it's all settled again), but we were discussing changes and how to schedule releases for them; and from the point of view as a consumer/user, introducing such a change in what was supposed to be the last release candidate was a huge surprise. There is never a good point to make these changes, even if I make them just after a release people will just grumble when it comes time to look at the next one - just like you did above for 1.1.8. No, that's not quite it. 1.1.8 *was* special. Also look at the impact it had on our users; LRM rewrite (which implies huge logging changes), crmsh split, changes to m/s ... 1.1.8 was an exception in what otherwise is a rather impressive track record of releases. Normally, integrating new releases has always been rather straightforward. But I don't want to dwell on that. I don't really mind the API changes much, for me it's mostly a question of timing and how big the pile is at every single release. I thought you wanted longer release cycles... wouldn't that make the pile bigger? No, I generally tend to want shorter release cycles, with a more moderate flow of changes. (As far as that is concerned.) If only life were so predictable. Of course there is often a wishlist, but what _actually_ goes into a release is very much a product of how many and what types of bugs are getting reported (what code needs the most attention and how much free time I have). The amount of help I get is a big factor too. Without NTT looking after 1.0.x or David making short work of various features, I definitely wouldn't have gotten to half of these cleanups. So no master plan to make anyone's life hell, just Oh look, somehow I have a chunk of time to do something useful in or If I don't fix it now I'll have to look at it for the next decade. And is it not better to batch them up and have one point of incompatibility rather than a continuous stream of them? Well, that means we end up backporting the changes that can't wait. And the cliff to jump from to the next release just becomes larger and more deterring. If you consider the API from a customer point of view, the things like build or runtime dependencies on shared libraries aren't so much of an issue - hopefully, the distribution provider hides that before they release updates. Hence my Oh well, I don't care stance. Except if it affects ocf2/dlm/sbd? I don't care for the fact that the changes were made, much. The new interface looks like a win and code reduction. My comment was, as stated above, specifically about doing such a change in a late release candidate. What's more troublesome are changes to existing commands (even something minimal like crm_resource
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 2013-06-27T20:50:34, Andrew Beekhof and...@beekhof.net wrote: There was one :-) I merged the best bits of three parallel CPG code paths. The things that prompted the extra bits in one also applied to the others. Ah, that wasn't so obvious to me when I tried making sense of the commit. ;-) But that's cleared up now. Maybe you're right, maybe I should stop fighting it and go with the firefox approach. That certainly seemed to piss a lot of people off though... If there's one message I've learned in 13 years of work on Linux HA, then it is that people are *always* going to be pissed off. ;-) Then I guess I'm confused by what you meant by: Distributions can take care of them when they integrate them; basically they'll trickle through until the whole stack the distributions ship builds again. Didn't that relate to essentially holding back not-critical-to-you changes? Yes and no. Not in the sense of backports or selective back-outs (as long as I can avoid them), but in as only releasing the update once the downstream dependencies have also been adjusted. The day you suggest every message include a unique and immutable ID... lets just say you'd better start polishing that katana. Trying to find the time to look more into SNMP interfaces and traps. That'd probably address some more of the concerns about customers having to churn through the logs. And, of course, tools like crm shell's history explorer help a lot, because that abstracts the automatic parsing from users. Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Experience is the name everyone gives to their mistakes. -- Oscar Wilde ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 28/06/2013, at 12:52 AM, Lars Marowsky-Bree l...@suse.com wrote:
Maybe you're right, maybe I should stop fighting it and go with the
firefox approach.
That certainly seemed to piss a lot of people off though...
If there's one message I've learned in 13 years of work on Linux HA,
then it is that people are *always* going to be pissed off. ;-)
Ok, so are you actually proposing we switch upstream to Pacemaker-{integer}
releases, forsake any notion of stable versions and leave that to the
enterprise distros?
___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 2013-06-25T20:28:29, Andrew Beekhof and...@beekhof.net wrote: Perhaps a numbering scheme like the Linux kernel would fit better than a stable/unstable branch distinction. Changes that deserve the unstable term are really really rare (and I'm sure we've all learned from them), so it may be better to then just have a slightly longer test cycle for these. What about the API changes? Distributions can take care of them when they integrate them; basically they'll trickle through until the whole stack the distributions ship builds again. I *was* surprised to find one of those in -rc5, though - the merged cluster glue code was something I'd have expected significantly earlier in a release cycle (and the API to be stable during the -rc phase, barring security issues or similar disasters). ;-) Important is to of course keep the major/minor numbers of the libraries updated so one doesn't get runtime problems. Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Experience is the name everyone gives to their mistakes. -- Oscar Wilde ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 26/06/2013, at 7:30 PM, Lars Marowsky-Bree l...@suse.com wrote: On 2013-06-25T20:28:29, Andrew Beekhof and...@beekhof.net wrote: Perhaps a numbering scheme like the Linux kernel would fit better than a stable/unstable branch distinction. Changes that deserve the unstable term are really really rare (and I'm sure we've all learned from them), so it may be better to then just have a slightly longer test cycle for these. What about the API changes? Distributions can take care of them when they integrate them; basically they'll trickle through until the whole stack the distributions ship builds again. If we let 2.0.x be anything like 1.1.x, I suspect this would be rather difficult. I *was* surprised to find one of those in -rc5, though - the merged cluster glue code was something I'd have expected significantly earlier in a release cycle (and the API to be stable during the -rc phase, barring security issues or similar disasters). ;-) There was a couple, but are you talking about cluster glue or cluster-glue? The change I'm thinking of (CPG codepaths and global variables) was becoming a major support overhead and all-round headache. I hadn't planned to make that change, but it was the best way to fix a bug that was holding up the release. Plus it is still my intention not to have API changes in 2.0.x, so better before than after. Important is to of course keep the major/minor numbers of the libraries updated so one doesn't get runtime problems. I have been quite diligent running ./bumplibs.sh in preparation for releases for a while now. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 2013-06-26T21:31:14, Andrew Beekhof and...@beekhof.net wrote: Distributions can take care of them when they integrate them; basically they'll trickle through until the whole stack the distributions ship builds again. If we let 2.0.x be anything like 1.1.x, I suspect this would be rather difficult. Not sure. With the sore exception of 1.1.8, the integration effort was reasonable, even for an Enterprise distribution. Yes, for changes so large and intrusive, a temporary branch (or a longer release cycle) would probably be preferable. The change I'm thinking of (CPG codepaths and global variables) was becoming a major support overhead and all-round headache. I hadn't planned to make that change, but it was the best way to fix a bug that was holding up the release. Yeah, that one. If it fixes a bug, it was probably unavoidable (though the specific commit (953bedf8f7f54f91a76672aeee5f44dc465741e9) didn't mention a bugzilla id). But that trickles through all consumers here - OCFS2, DLM, sbd. Means we have to do more validation than a -rc should normally need - normally, during an rcX phase, I'd expect small, well-contained bugfixes for regressions only. But perhaps this was one such exception. (Which bug did it fix, by the way? Can't immediately spot it from the commit code.) Plus it is still my intention not to have API changes in 2.0.x, so better before than after. I wonder how that will go ;-) I don't really mind the API changes much, for me it's mostly a question of timing and how big the pile is at every single release. If you consider the API from a customer point of view, the things like build or runtime dependencies on shared libraries aren't so much of an issue - hopefully, the distribution provider hides that before they release updates. Hence my Oh well, I don't care stance. What's more troublesome are changes to existing commands (even something minimal like crm_resource -M now generating a short location constraint, which could potentially break scripts that interact with the CIB), or major changes to log messages (since those do break customer's scripts and monitoring environments). Important is to of course keep the major/minor numbers of the libraries updated so one doesn't get runtime problems. I have been quite diligent running ./bumplibs.sh in preparation for releases for a while now. Yes. Didn't mean to say it isn't working, just wanted to mention it. Because an update that fails to install until all dependencies are fixed is (mostly) fine, but one that installs and then breaks really annoys customers ;-) Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Experience is the name everyone gives to their mistakes. -- Oscar Wilde ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 26/06/2013, at 10:37 PM, Lars Marowsky-Bree l...@suse.com wrote: On 2013-06-26T21:31:14, Andrew Beekhof and...@beekhof.net wrote: Distributions can take care of them when they integrate them; basically they'll trickle through until the whole stack the distributions ship builds again. If we let 2.0.x be anything like 1.1.x, I suspect this would be rather difficult. Not sure. With the sore exception of 1.1.8, the integration effort was reasonable, even for an Enterprise distribution. Yes, for changes so large and intrusive, a temporary branch (or a longer release cycle) would probably be preferable. I wouldn't say the 6 months between 1.1.7 and 1.1.8 was a particularly aggressive release cycle. Generally though, it has always been hard/dangerous to backport specific fixes because of the complexity of the interactions - particularly in the PE. The change I'm thinking of (CPG codepaths and global variables) was becoming a major support overhead and all-round headache. I hadn't planned to make that change, but it was the best way to fix a bug that was holding up the release. Yeah, that one. If it fixes a bug, it was probably unavoidable (though the specific commit (953bedf8f7f54f91a76672aeee5f44dc465741e9) didn't mention a bugzilla id). It has always been the case that I find and fix far more bugs than people report. I don't plan to start filing bugs for myself. But that trickles through all consumers here - OCFS2, DLM, sbd. Means we have to do more validation than a -rc should normally need - normally, during an rcX phase, I'd expect small, well-contained bugfixes for regressions only. But perhaps this was one such exception. Normally I would have waited until after the final release, and have done so in the past for other changes. In this case though, I made an exception because the plan is to NOT have another 1.1.x and it is still my intention not to have API changes in 2.0.x, so better before than after. Granted I had completely forgotten about the plugin editions of ocfs2/dlm, but I was told you'd already deep frozen what you were planning to ship, so I don't understand the specific concern. There is never a good point to make these changes, even if I make them just after a release people will just grumble when it comes time to look at the next one - just like you did above for 1.1.8. (Which bug did it fix, by the way? Can't immediately spot it from the commit code.) Processes spinning for a few minutes while trying to send a CPG message. First for corosync 2.x, then later for cman, then again for pacemakerd. I borked at creating a third copy of that code when I noticed a bug in the second. I much preferred the old cib_ais_dispatch() method signature but to make it work with the corosync's API required all kinds of nastiness which made it very brittle. Plus it is still my intention not to have API changes in 2.0.x, so better before than after. I wonder how that will go ;-) We did pretty well with 1.0 once the line was drawn (after about .5 iirc). I don't really mind the API changes much, for me it's mostly a question of timing and how big the pile is at every single release. I thought you wanted longer release cycles... wouldn't that make the pile bigger? And is it not better to batch them up and have one point of incompatibility rather than a continuous stream of them? If you consider the API from a customer point of view, the things like build or runtime dependencies on shared libraries aren't so much of an issue - hopefully, the distribution provider hides that before they release updates. Hence my Oh well, I don't care stance. Except if it affects ocf2/dlm/sbd? What's more troublesome are changes to existing commands (even something minimal like crm_resource -M now generating a short location constraint, I find it confusing how an contained 10 line change to a CLI tool is troublesome but you're prepared to wear the overhead of holding back API changes - which usually impact all sorts of code paths, sometimes across multiple projects. Surely this would be the easiest of any possible change to hold back. which could potentially break scripts that interact with the CIB), or major changes to log messages (since those do break customer's scripts and monitoring environments). CLI output I can usually be convinced of, but log messages are most definitely not something I will consider as a valid programming interface. I have not and will not change them just to annoy people, but I must be allowed to reduce the level of noise and other improve them or rename the functions that produce them when appropriate (which changes the functionname: portion). I have been hammered for years on the amount of logs Pacemaker produces, yet the moment I try to do something about it... sigh. Important is to of course keep the major/minor numbers of the libraries updated so one doesn't get runtime problems. I have
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
25.06.2013, 09:49, Andrew Beekhof and...@beekhof.net: On 25/06/2013, at 2:33 PM, Andrey Groshev gre...@yandex.ru wrote: 25.06.2013, 04:46, Andrew Beekhof and...@beekhof.net: On 24/06/2013, at 3:44 PM, Vladislav Bogdanov bub...@hoster-ok.com wrote: 24.06.2013 04:17, Andrew Beekhof wrote: Either people have given up on testing, or rc5[1] is looking good for the final release. Is it going to be 1.1.10 or 1.2.0 (2.0.0)? First its going to be 1.1.10 and, if there is still no-one screaming, after a couple of weeks it will become 2.0[.0] What is really new in this version to change the major version? Compared to what? To 1.1.10 hopefully nothing, but that was always the point. So far there are changes in the interface and API. IMHO, a stable product should not be such. 1.1 is not a stable branch, thats the entire point of re-releasing 1.1.10 as 2.0: http://blog.clusterlabs.org/blog/2010/new-pacemaker-release-series/ Only instead of stopping development in 2010 and releasing 1.2.0, we kept going and the subsequent 4511 changesets and 3490 files changed, 410422 insertions(+), 144311 deletions(-) justify the 2.0 moniker. Ok, I recently became engaged in the PСMK, so for me it is a surprize. The more so in all the major linux distributions version 1.1.х. So just a reminder, we're particularly looking for feedback in the following areas: | plugin-based clusters, ACLs, the new –ban and –clear commands, and admin actions | (such as moving and stopping resources, calls to stonith_admin) which are hard | to test in an automated manner. | | Also any light that can be shed on possible memory leaks would be much appreciated. I would very much like to hear the observations (good or bad) of people that have taken it for a spin. -- Andrew [1] http://blog.clusterlabs.org/blog/2013/release-candidate-1-dot-1-10-rc5/ ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 2013-06-25T10:16:58, Andrey Groshev gre...@yandex.ru wrote: Ok, I recently became engaged in the PСMK, so for me it is a surprize. The more so in all the major linux distributions version 1.1.х. Pacemaker has very strong regression and system tests, and barring accidents, it is usually very safe to always deploy the latest version - even if it is unstable. Perhaps a numbering scheme like the Linux kernel would fit better than a stable/unstable branch distinction. Changes that deserve the unstable term are really really rare (and I'm sure we've all learned from them), so it may be better to then just have a slightly longer test cycle for these. Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Experience is the name everyone gives to their mistakes. -- Oscar Wilde ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 25/06/2013, at 6:32 PM, Lars Marowsky-Bree l...@suse.com wrote: On 2013-06-25T10:16:58, Andrey Groshev gre...@yandex.ru wrote: Ok, I recently became engaged in the PСMK, so for me it is a surprize. The more so in all the major linux distributions version 1.1.х. Pacemaker has very strong regression and system tests, and barring accidents, it is usually very safe to always deploy the latest version - even if it is unstable. Right, unstable for Pacemaker means APIs and feature sets. If its super buggy it doesn't get released (or even merged into the ClusterLabs repo). Perhaps a numbering scheme like the Linux kernel would fit better than a stable/unstable branch distinction. Changes that deserve the unstable term are really really rare (and I'm sure we've all learned from them), so it may be better to then just have a slightly longer test cycle for these. What about the API changes? ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 24/06/2013, at 3:44 PM, Vladislav Bogdanov bub...@hoster-ok.com wrote: 24.06.2013 04:17, Andrew Beekhof wrote: Either people have given up on testing, or rc5[1] is looking good for the final release. Is it going to be 1.1.10 or 1.2.0 (2.0.0)? First its going to be 1.1.10 and, if there is still no-one screaming, after a couple of weeks it will become 2.0[.0] So just a reminder, we're particularly looking for feedback in the following areas: | plugin-based clusters, ACLs, the new –ban and –clear commands, and admin actions | (such as moving and stopping resources, calls to stonith_admin) which are hard | to test in an automated manner. | | Also any light that can be shed on possible memory leaks would be much appreciated. I would very much like to hear the observations (good or bad) of people that have taken it for a spin. -- Andrew [1] http://blog.clusterlabs.org/blog/2013/release-candidate-1-dot-1-10-rc5/ ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
25.06.2013, 04:46, Andrew Beekhof and...@beekhof.net: On 24/06/2013, at 3:44 PM, Vladislav Bogdanov bub...@hoster-ok.com wrote: 24.06.2013 04:17, Andrew Beekhof wrote: Either people have given up on testing, or rc5[1] is looking good for the final release. Is it going to be 1.1.10 or 1.2.0 (2.0.0)? First its going to be 1.1.10 and, if there is still no-one screaming, after a couple of weeks it will become 2.0[.0] What is really new in this version to change the major version? So far there are changes in the interface and API. IMHO, a stable product should not be such. So just a reminder, we're particularly looking for feedback in the following areas: | plugin-based clusters, ACLs, the new –ban and –clear commands, and admin actions | (such as moving and stopping resources, calls to stonith_admin) which are hard | to test in an automated manner. | | Also any light that can be shed on possible memory leaks would be much appreciated. I would very much like to hear the observations (good or bad) of people that have taken it for a spin. -- Andrew [1] http://blog.clusterlabs.org/blog/2013/release-candidate-1-dot-1-10-rc5/ ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
On 25/06/2013, at 2:33 PM, Andrey Groshev gre...@yandex.ru wrote: 25.06.2013, 04:46, Andrew Beekhof and...@beekhof.net: On 24/06/2013, at 3:44 PM, Vladislav Bogdanov bub...@hoster-ok.com wrote: 24.06.2013 04:17, Andrew Beekhof wrote: Either people have given up on testing, or rc5[1] is looking good for the final release. Is it going to be 1.1.10 or 1.2.0 (2.0.0)? First its going to be 1.1.10 and, if there is still no-one screaming, after a couple of weeks it will become 2.0[.0] What is really new in this version to change the major version? Compared to what? To 1.1.10 hopefully nothing, but that was always the point. So far there are changes in the interface and API. IMHO, a stable product should not be such. 1.1 is not a stable branch, thats the entire point of re-releasing 1.1.10 as 2.0: http://blog.clusterlabs.org/blog/2010/new-pacemaker-release-series/ Only instead of stopping development in 2010 and releasing 1.2.0, we kept going and the subsequent 4511 changesets and 3490 files changed, 410422 insertions(+), 144311 deletions(-) justify the 2.0 moniker. So just a reminder, we're particularly looking for feedback in the following areas: | plugin-based clusters, ACLs, the new –ban and –clear commands, and admin actions | (such as moving and stopping resources, calls to stonith_admin) which are hard | to test in an automated manner. | | Also any light that can be shed on possible memory leaks would be much appreciated. I would very much like to hear the observations (good or bad) of people that have taken it for a spin. -- Andrew [1] http://blog.clusterlabs.org/blog/2013/release-candidate-1-dot-1-10-rc5/ ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there
24.06.2013 04:17, Andrew Beekhof wrote: Either people have given up on testing, or rc5[1] is looking good for the final release. Is it going to be 1.1.10 or 1.2.0 (2.0.0)? So just a reminder, we're particularly looking for feedback in the following areas: | plugin-based clusters, ACLs, the new –ban and –clear commands, and admin actions | (such as moving and stopping resources, calls to stonith_admin) which are hard | to test in an automated manner. | | Also any light that can be shed on possible memory leaks would be much appreciated. I would very much like to hear the observations (good or bad) of people that have taken it for a spin. -- Andrew [1] http://blog.clusterlabs.org/blog/2013/release-candidate-1-dot-1-10-rc5/ ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
