[ClusterLabs] Clusterlabs Summit 2017 is on!
This is, by far, the largest summit yet. Very stoked! Fellow attendees; Feel free to share your pictures! https://photos.app.goo.gl/vBeC83yWTZcxRgux1 -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ Users mailing list: Users@clusterlabs.org http://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
[ClusterLabs] 2017 ClusterLabs Summit -- Pacemaker 1.2.0 or 2.0 talk
I thought the first day of the 2017 ClusterLabs Summit went impressively well today. We had about 50 attendees from Alteeve, Citrix, Debian, Linbit, Red Hat, SuSE, and possibly more I've missed. The talks were packed with information and covered a wide variety of topics, from container orchestration to storage management to GUIs. I gave a talk on future directions for Pacemaker. The slides are available at: https://www.clusterlabs.org/images/Pacemaker-slides-2017-09-06.pdf The main idea is that Pacemaker 1.2.0 and/or 2.0 will be more about removing legacy code more than adding anything new. As the slides are presented, my original idea was to release 1.2.0 in the near term, with smaller changes that don't affect rolling upgrades, then 2.0 at some point further in the future, that would break rolling upgrades for a (hopefully small) subset of users. However after discussions during and after the talk, it seems more worthwhile to go straight to 2.0, with the major change being dropping support for the legacy cluster layers -- heartbeat, CMAN, and the corosync 1 pacemaker plugin. This would allow us to simplify the pacemaker code and make it easier to add new features in the future. We would keep the 1.1 branch alive for a period of time, and anyone who still uses the older stacks, but is interested in fixes or features from the 2.0 line, could submit pull requests to backport them to 1.1. I'd like to open the discussion on this list as to what changes should be in 2.0. The slides give some examples that fall into categories: * Changes in Pacemaker's defaults: a higher default stonith-timeout; defaulting record-pending to true, which will allow status displays to show when an action (such as start or stop) is currently in progress; interpreting a negative stonith-watchdog-timeout as meaning to automatically calculate a value (the default of 0 would continue to mean disabling watchdog use by Pacemaker); moving the default location of the Pacemaker detail log to /var/log/cluster/pacemaker.log (a change from the slides, based on summit discussions), and removing support for some very rarely used legacy names for various configuration values. * Changes in command-line tool behavior: We might drop old legacy synonyms for command-line options, such as "crm_resource --host-uname" for what is now "crm_resource --node"; and remove crm_mon's built-in SNMP/ESMTP support in favor of the relatively recent alerts feature. * Changes in the C API: This would affect very few people -- only users who wrote their own C code using the Pacemaker C libraries. We would coordinate these changes with the handful of public projects (such as sbd) that use the API. These changes will be discussed further on the develop...@clusterlabs.org mailing list rather than this one. * Breaking rolling upgrades for certain legacy features: We would try to keep the number of affected users to a minimum. Examples are configurations created under pre-Pacemaker-1.0 and never converted to the post-1.0 XML syntax; the undocumented "resource isolation" feature, which has been superseded by the new bundle feature; certain legacy cluster options that changed names long ago; and as mentioned, support for the heartbeat, CMAN, and corosync 1+plugin stacks. Also, dropping support for "legacy attrd" would mean that rolling upgrades from Pacemaker older than 1.1.11, even if running on corosync 2, would not work (even then, a rolling upgrade would work in two steps, first to a later 1.1 version, then to 2.0). The purpose of this email is to start a discussion about these changes. Nothing is set in stone. We do want to focus more on removing legacy usage rather than adding new features in the 2.0 release. Anyone who has an opinion or questions about the changes mentioned above, or suggestions for similar changes, is encouraged to participate. -- Ken Gaillot ___ Users mailing list: Users@clusterlabs.org http://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
[ClusterLabs] DRBD, dual-primary, Live-Migration - Cluster FS necessary ?
Hi, i just want to be sure. I created a DRBD partition in a dual primary setup. I have a VirtualDomain (KVM) resource which resides in the naked DRBD (without FS), and i can live migrate. Are there situations where in this setup a cluster fs is necessary/recommended ? I'd like to avoid it, it causes more complexity. Btw: resource level fencing is necessary. Is the setup for dual-primary the same as with single-primary ? My cluster: SLES 11 SP4, DRBD 8.4.4, pacemaker 1.12. Thanks. Bernd -- Bernd Lentes Systemadministration institute of developmental genetics Gebäude 35.34 - Raum 208 HelmholtzZentrum München bernd.len...@helmholtz-muenchen.de phone: +49 (0)89 3187 1241 fax: +49 (0)89 3187 2294 no backup - no mercy Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 ___ Users mailing list: Users@clusterlabs.org http://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] Clusterlabs Summit 2017 is on!
On 06/09/17 09:45 +0200, Digimer wrote: > This is, by far, the largest summit yet. Very stoked! > > Fellow attendees; Feel free to share your pictures! > > https://photos.app.goo.gl/vBeC83yWTZcxRgux1 "Wow! Such HA. Very cluster" :) Side question: is anyone up for the early Friday morning lake swim challenge? There's at least two contestants at this point :) -- Jan (Poki) pgpF3h1iJsMsX.pgp Description: PGP signature ___ Users mailing list: Users@clusterlabs.org http://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] [ClusterLabs Developers] [HA/ClusterLabs Summit] Key-Signing Party, 2017 Edition
On 24/07/17 16:59 +0200, Jan Pokorný wrote: > On 23/07/17 12:32 +0100, Adam Spiers wrote: >> Jan Pokorný wrote: >>> So, going to attend summit and want your key signed while reciprocally >>> spreading the web of trust? >>> Awesome, let's reuse the steps from the last time: >>> >>> Once you have a key pair (and provided that you are using GnuPG), >>> please run the following sequence: >>> >>> # figure out the key ID for the identity to be verified; >>> # IDENTITY is either your associated email address/your name >>> # if only single key ID matches, specific key otherwise >>> # (you can use "gpg -K" to select a desired ID at the "sec" line) >>> KEY=$(gpg --with-colons 'IDENTITY' | grep '^pub' | cut -d: -f5) >> >> AFAICS this has two problems: it's missing a --list-key option, > > Bummer! I've been checking the original thread(s) for responses from > others, but forgot to check my own: > http://lists.linux-ha.org/pipermail/linux-ha/2015-January/048511.html > > Thanks for spotting (and the public key already sent), Adam. > >> and it doesn't handle multiple matches for 'IDENTITY'. So to make it >> choose the newest key if there are several: >> >>read IDENTITY >>KEY=$(gpg --with-colons --list-key "$IDENTITY" | grep '^pub' | >> sort -t: -nr -k6 | head -n1 | cut -d: -f5) > > Good point. Hopefully affected persons, allegedly heavy users of GPG, > are capable to adapt on-the-fly anyway :-) > >>> # export the public key to a file that is suitable for exchange >>> gpg --export -a -- $KEY > $KEY >>> >>> # verify that you have an expected data to share >>> gpg --with-fingerprint -- $KEY Thanks to the attendants and I am sorry for not responding to the ones with on-the-edge submissions -- there was actually an active one accepted and I've refreshed the authoritative record about the event at https://people.redhat.com/jpokorny/keysigning/2017-ha/ accordingly (see '*2.*' suffixes). I'd also kindly ask the actual attendants (one person skipped the event) to do the remaining signing work within the month at latest. You can just grab the key of the other, already verified party from the linked source (or the well known key server if present), sign it, and then (IMHO) preferably send the signed key back to the original person at one of his/her listed email, again (IMHO) preferably in an encrypted form. There are various tools to help with this workflow at scale, such as PIUS (https://github.com/jaymzh/pius) to give an example, but YMMV. May the web of trust be with you. -- Jan (Poki) pgpEgIhORttyN.pgp Description: PGP signature ___ Users mailing list: Users@clusterlabs.org http://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