[ClusterLabs Developers] Releasing crmsh version 2.3.0
Hello everyone! I am proud to present crmsh version 2.3.0, the latest stable release. I would recommend all users to upgrade to 2.3.0 if they can. For this release, I would like to begin by highlighting the new contributors to crmsh since 2.2.0 was released in January: * Marc A. Smith added the new subcommand "configure load push", which removes any configuration lines that aren't included in the cib provided when pushing. * Andrei Maruha added an optional name parameter to the "corosync add-node" command, and made the add-node command recycle old node IDs if possible. * Kai Kang fixed a build system bug when removing generated docs, causing issues with parallel make. * Daniel Hoffend contributed various fixes improving support for building crmsh for Debian and Ubuntu. * Pedro Salgado fixed a bug in the graph rendering code in crmsh, added a tox configuration file to make testing with multiple versions of Python easy, and updated the Travis CI configuration to use tox. * Nate Clark fixed a bug in the parser for fencing hierarchies. I would also like to thank all the other contributors, testers and users who have helped in making this release as stable and reliable as possible. Some of the other major features in 2.3.0 include: * Support for the new event-based alerts feature in Pacemaker 1.1.15 * Greatly improved timezone handling in crm report and the history explorer * Improvements to the cluster scripts / wizards, as well as new wizards for LVM on DRBD, and NFS on LVM and DRBD and VMware/vCenter * Better support for fencing remote nodes The source code can be downloaded from Github: * https://github.com/ClusterLabs/crmsh/releases/tag/2.3.0 Packages for several popular Linux distributions can be downloaded From the Stable repository at the OBS: * http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/ Archives of the tagged release: * https://github.com/ClusterLabs/crmsh/archive/2.3.0.tar.gz * https://github.com/ClusterLabs/crmsh/archive/2.3.0.zip For the full list of changes since version 2.3.0, see the ChangeLog, available at: * https://github.com/ClusterLabs/crmsh/blob/2.3.0/ChangeLog As usual, a huge thank you to all contributors and users of crmsh! Cheers, Kristoffer -- // Kristoffer Grönlund // kgronl...@suse.com signature.asc Description: PGP signature ___ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] HA/Clusterlabs Summit 2017 Proposal
Chris Feist <cfe...@redhat.com> writes: > On Mon, Jan 30, 2017 at 8:23 AM, Kristoffer Grönlund <kgronl...@suse.com> > wrote: > >> Hi everyone! >> >> The last time we had an HA summit was in 2015, and the intention then >> was to have SUSE arrange the next meetup in the following year. We did >> try to find a date that would be suitable for everyone, but for various >> reasons there was never a conclusion and 2016 came and went. >> >> Well, I'd like to give it another try this year! This time, I've already >> got a proposal for a place and date: September 7-8 in Nuremberg, Germany >> (SUSE main office). I've got the new event area in the SUSE office >> already reserved for these dates. >> >> My suggestion is to do a two day event similar to the one in Brno, but I >> am open to any suggestions as to format and content. The main reason for >> having the event would be for everyone to have a chance to meet and get >> to know each other, but it's also an opportunity to discuss the future >> of Clusterlabs and the direction going forward. >> >> Any thoughts or feedback are more than welcome! Let me know if you are >> interested in coming or unable to make it. >> > > Kristoffer, > > Thank you for getting some dates and providing a space for the summit. I > know myself and several cluster engineers from Red Hat are definitely > interested in attending. The only thing that I might recommend is moving > the conference one day earlier (change to Wed/Thu instead of Thu/Fri) to > make it easier for people traveling to/from the conference. Hi Chris, Sounds great! Happy to move it to September 6-7 if that works out better. Cheers, Kristoffer > > Thanks! > Chris > > >> >> Cheers, >> Kristoffer >> >> -- >> // Kristoffer Grönlund >> // kgronl...@suse.com >> >> ___ >> Developers mailing list >> Developers@clusterlabs.org >> http://lists.clusterlabs.org/mailman/listinfo/developers >> > ___ > Developers mailing list > Developers@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/developers -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
[ClusterLabs Developers] Releasing crmsh version 3.0.0
Hello everyone! I'm happy to announce the release of crmsh version 3.0.0 today. The main reason for the major version bump is because I have merged the sleha-bootstrap project with crmsh, replacing the cluster init/add/remove commands with the corresponding commands from sleha-bootstrap. At the moment, these commands are highly specific to SLE and openSUSE, unfortunately. I am working on making them as distribution agnostic as possible, but would appreciate help from users of other distributions in making them work as well on those platforms as they do on SLE/openSUSE. Briefly, the "cluster init" command configures a complete cluster from scratch, including optional configuration of fencing via SBD, shared storage using OCFS2, setting up the Hawk web interface etc. There are some other changes in this release as well, see the ChangeLog for the complete list of changes: * https://github.com/ClusterLabs/crmsh/blob/3.0.0/ChangeLog The source code can be downloaded from Github: * https://github.com/ClusterLabs/crmsh/releases/tag/3.0.0 This version of crmsh will be available in openSUSE Tumbleweed as soon as possible, and packages for several popular Linux distributions are available from the Stable repository at the OBS: * http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/ Archives of the tagged release: * https://github.com/ClusterLabs/crmsh/archive/3.0.0.tar.gz * https://github.com/ClusterLabs/crmsh/archive/3.0.0.zip As usual, a huge thank you to all contributors and users of crmsh! Cheers, Kristoffer -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
[ClusterLabs Developers] HA/Clusterlabs Summit 2017 Proposal
Hi everyone! The last time we had an HA summit was in 2015, and the intention then was to have SUSE arrange the next meetup in the following year. We did try to find a date that would be suitable for everyone, but for various reasons there was never a conclusion and 2016 came and went. Well, I'd like to give it another try this year! This time, I've already got a proposal for a place and date: September 7-8 in Nuremberg, Germany (SUSE main office). I've got the new event area in the SUSE office already reserved for these dates. My suggestion is to do a two day event similar to the one in Brno, but I am open to any suggestions as to format and content. The main reason for having the event would be for everyone to have a chance to meet and get to know each other, but it's also an opportunity to discuss the future of Clusterlabs and the direction going forward. Any thoughts or feedback are more than welcome! Let me know if you are interested in coming or unable to make it. Cheers, Kristoffer -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] Potential logo for Cluster Labs
Andrew Beekhof <and...@beekhof.net> writes: > agree completely > as ken said, we always wanted this but lacked the time Alright, I guess I've committed to doing this now ;) Cheers, Kristoffer -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] Potential logo for Cluster Labs
Klaus Wenninger <kwenn...@redhat.com> writes: > On 08/25/2016 03:13 PM, Andrew Price wrote: >> On 25/08/16 13:58, Klaus Wenninger wrote: >>> On 08/25/2016 12:49 PM, Andrew Price wrote: >>>> On 24/08/16 18:50, Ken Gaillot wrote: >>>>> Suggestions/revisions/alternatives are welcome. >>>> >>>> Here's a possible alternative theme. It's similarly greyscale and I'm >>>> not hugely happy with the font (I don't seem to have many good ones >>>> installed) but I'm happy enough with it to throw it on the pile :) Alright, if we're throwing logo design ideas on a pile, here's mine! The idea being basically a beaker with servers in it, hence.. Clusterlabs. -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] Resurrecting OCF
Jan Pokorný <jpoko...@redhat.com> writes: > Thinking about that, ClusterLabs may be considered a brand established > well enough for "clusterlabs" provider to work better than anything > general such as previously proposed "core". Also, it's not expected > there will be more RA-centered projects under this umbrella than > resource-agents (pacemaker deserves to be a provider on its own), > so it would be pretty unambiguous pointer. I like this suggestion as well. > > And for new, not well-tested agents within resource-agents, there could > also be a provider schema akin to "clusterlabs-staging" introduced. > > 1 CZK ...and this too. Here is another one: While we are moving agents into a new namespace, perhaps it is time to clean up some of the legacy agents that are no longer recommended or of questionable quality? Off the top of my head, there are * heartbeat/Evmsd * heartbeat/EvmsSCC * heartbeat/LinuxSCSI * heartbeat/pingd * heartbeat/IPaddr * heartbeat/ManageRAID * heartbeat/vmware A pet peeve of mine would also be to move heartbeat/IPaddr2 to clusterlabs/IP, to finally get rid of that weird 2 in the name... Cheers, Kristoffer -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] announcement: schedule for resource-agents release 3.9.8
Oyvind Albrigtsen <oalbr...@redhat.com> writes: > Hi, > > This is a tentative schedule for resource-agents v3.9.8: > 3.9.8-rc1: January 10. > 3.9.8: January 31. > > I modified the corresponding milestones at > https://github.com/ClusterLabs/resource-agents/milestones > > If there's anything you think should be part of the release > please open an issue, a pull request, or a bugzilla, as you see > fit. > Hi Oyvind, I think it's high time for a new release! My only suggestion would be to call it 4.0.0, since there are much bigger changes from 3.9.7 than an update to the patch release number would suggest. Cheers, Kristoffer > If there's anything that hasn't received due attention, please > let us know. > > Finally, if you can help with resolving issues consider yourself > invited to do so. There are currently 49 issues and 38 pull > requests still open. > > > Cheers, > Oyvind Albrigtsen > > ___ > Developers mailing list > Developers@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/developers > -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] sbd v1.3.0
"Gao,Yan" <y...@suse.com> writes: > Hi Klaus, > > On 03/22/2017 06:47 AM, Klaus Wenninger wrote: >> Hi sbd-developers! >> >> >> ClusterLabs / sbd - repo on github hasn't received a tag for >> >> more than 3 year now. >> >> Changes since v1.2.0 like adding the possibility to have a >> >> watchdog-only setup without shared-block-devices >> >> legitimate a bump to v1.3.0. >> >> As there hasn't been super active development most >> >> recently I guess we can spare having release-candidates ... >> >> So if there is no opposition I would go ahead and put >> >> a tag on the current state on master. > +1. Sounds good to me too! Cheers, Kristoffer > > Thanks, >Yan > >> >> >> Regards, >> >> Klaus >> >> >> ___ >> Developers mailing list >> Developers@clusterlabs.org >> http://lists.clusterlabs.org/mailman/listinfo/developers >> >> > > ___ > Developers mailing list > Developers@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/developers > -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] crmsh: Release 3.0.1 - cluster init with sbd
Valentin Vidic <valentin.vi...@carnet.hr> writes: > Trying out the cluster init functionality I can't get SBD to work: > > 1. The config file is updated with SBD_DEVICE and SBD_WATCHDOG, > but the systemd service only takes $SBD_OPTS: > >ExecStart=/usr/sbin/sbd $SBD_OPTS -p /var/run/sbd.pid watch > > Maybe a different service file is expected or this only supports the > init script? This may be an unintentional SUSE-ism that has snuck in... please create an issue on github and attach your service file for sbd, and I'll take a look! > > 2. /dev/watchdog device is by default taken by corosync, so sbd can't grab it: > > Jul 23 09:29:11 node1 sbd[1120]:error: watchdog_init: Cannot open > watchdog device '/dev/watchdog': Device or resource busy (16) > > Should the watchdog option for SBD disable the watchdog in corosync? Good point, there should probably at least be a warning issued if both are configured to use the same watchdog device. Cheers, Kristoffer > > -- > Valentin > > ___ > Developers mailing list > Developers@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/developers > -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
[ClusterLabs Developers] Clusterlabs Summit 2017: Please register!
Hi everyone, This mail is for attendees of the Clusterlabs Summit event in Nuremberg, September 6-7 2017. If it didn't arrive via the Clusterlabs mailing list and you're not going but got this mail anyway, please let me know since apparently I have you on my list of possible attendees ;) Apologies for springing this on you at such a late stage, but as we are investigating dinner options, making badges and making sure there are enough chairs for everyone at the event, it became more and more clear that it would be very useful to have a better grasp of how many people are coming to the event. URL to sign up -- https://www.eventbrite.com/e/clusterlabs-summit-2017-dinner-tickets-3689052 To make it as easy as possible, I created an event on Eventbrite for this purpose. Signing up is not a requirement! However, it would be great if you could send an email to me confirming your attendance regardless, in case you are unhappy about using Eventbrite. Also, it would be great if you could register as quickly as possible so that we can make dinner reservations early enough to hopefully be able to fit everyone into one space. Thank you, Kristoffer -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
[ClusterLabs Developers] Clusterlabs Summit 2017 (Sept. 6-7 in Nuremberg) - One month left!
Hey everyone! Here's a quick update for the upcoming Clusterlabs Summit at the SUSE office in Nuremberg in September: The time to register for the pool of hotel rooms has now expired - we have sent the final list of names to the hotel. There may still be hotel rooms available at the Sorat Saxx or other hotels in Nuremberg, so if anyone missed the deadline and still needs a room, either contact me or feel free to contact the hotel directly. The same goes for any changes, for those who have reservations: Please either contact me, or contact the hotel directly at i...@saxx-nuernberg.de. The schedule is being sorted out right now, and the planning wiki will be updated with a preliminary schedule soon. If there is anyone who would like to present on a topic or would like to discuss a topic that isn't on the wiki yet, now is the time to add it there. Other than that, I don't have any other remarks, other than to wish everyone welcome to Nuremberg in a month! Feel free to contact me with any concerns or issues related to the summit, and I'll do what I can to help out. Cheers, Kristoffer -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] New LVM resource agent name (currently LVM-activate)
Jan Pokorný <jpoko...@redhat.com> writes: > > Nobody has a patent on what's best (even hardlier a bystander like > me), that's why discourse is a vital (discuss early, discuss often). Agreed! It seems that a lot of the time, the problem boils down to naming. With clear naming that makes the differences and use cases clear, having multiple agents is less of a problem. When coming up with different names is difficult, that would seem to point to a conceptual problem. Cheers, Kristoffer > > -- > Jan (Poki) > ___ > Developers mailing list > Developers@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/developers -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] resource-agents v4.1.0 rc1
Dejan Muhamedagic <deja...@fastmail.fm> writes: > Hi, > > On Tue, Nov 14, 2017 at 03:16:04PM +0100, Oyvind Albrigtsen wrote: >> ClusterLabs is happy to announce resource-agents v4.1.0 rc1. >> Source code is available at: >> https://github.com/ClusterLabs/resource-agents/releases/tag/v4.1.0rc1 >> >> The most significant enhancements in this release are: >> - new resource agents: >> - aws-vpc-route53 >> - LVM-activate > > There was a long and, unfortunately, fruitless discussion > regarding this new version of LVM RA and whether it can be merged > with the existing LVM RA. In spite of no consensus, Kristoffer > eventually merged it. There is now a plugin like system in LVM > which should make adding new mechanisms such as lvmlockd easy, > but the contributors didn't try yet to adjust the new LVM. Yeah, my apologies for jumping the gun. I hope we can work this out before release. :/ > Furthermore, in case we agree that having two LVM versions is the > best way forward, such refactoring would also significantly > reduce code duplication. > > Thanks, > > Dejan > > P.S. Right now irrelevant, but LVM-activate doesn't seem like a > good name. If nothing else, it's in keeping with the rest of the mess of bad names ;) Maybe we should decide on a naming standard? Abbreviations or no abbreviations, CamelCase or lowercase, or lower_case? This could be enforced through the CI checks, and the Makefile could make sure to install aliases to the old names so as not to break existing installations. Maybe we could even move IPaddr2 to ip or IP, and move the now-outdated agents to a legacy provider... Cheers, Kristoffer > > > > >> - minio >> - NodeUtilization >> - oraasm >> - ovsmonitor >> - rkt >> - ZFS >> >> - bugfixes and enhancements: >> - aws*: fixes and improvements >> - CTDB: fixes for newer versions >> - CTDB: fix for --logfile being replaced with --logging >> - DB2: fix HADR support for DB2 V98+ >> - docker: add docker-native healthcheck >> - galera: fix for MariaDB 10.1.21+ >> - mysql: set correct master score after maintenance mode >> - ocf-shellfuncs: improve locking (ocf_take_lock()) >> - pgsql: add support for PostgreSQL 10 >> - pgsql: allow dynamic membership >> - rabbitmq-cluster: fix to work on Pacemaker remote nodes >> >> The full list of changes for resource-agents is available at: >> https://github.com/ClusterLabs/resource-agents/blob/v4.1.0rc1/ChangeLog >> >> Everyone is encouraged to download and test the new release candidate. >> We do many regression tests and simulations, but we can't cover all >> possible use cases, so your feedback is important and appreciated. >> >> Many thanks to all the contributors to this release. >> >> >> Best, >> The resource-agents maintainers >> >> _______ >> Developers mailing list >> Developers@clusterlabs.org >> http://lists.clusterlabs.org/mailman/listinfo/developers > > ___ > Developers mailing list > Developers@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/developers > -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] resource-agents v4.1.0 rc1
Dejan Muhamedagic <deja...@fastmail.fm> writes: >> > > P.S. Right now irrelevant, but LVM-activate doesn't seem like a >> > > good name. >> > >> > If nothing else, it's in keeping with the rest of the mess of bad names >> > ;) Maybe we should decide on a naming standard? Abbreviations or no >> > abbreviations, CamelCase or lowercase, or lower_case? This could be >> > enforced through the CI checks, and the Makefile could make sure to >> > install aliases to the old names so as not to break existing >> > installations. >> I think we should keep them as is for current agents, but new agents >> should be lowercase with an optional -'s if that clarifies their >> usage. > > My point was that it is arguably a pleonasm. The "activate" part > is superfluous. Sorry for not being clearer. > > As for bad names, we need to look no further than the LVM RA: > in volgrpname the "name" part is just as much necessary. While I agree that LVM-activate, being a verb, is not a great name, I at least am having a hard time coming up with a good one. Naming truly is the hardest part of programming... I guess my general point was that we don't have any kind of guidelines for naming that people can refer to, resulting in the amazing variety of names both in style and semantics that we're stuck with now. We had this discussion before and decided it was as much trouble as it solves to change things, but I still haven't given up on the idea ;) There's also the topic of the heartbeat provider being completely outdated and continuing to confuse newcomers, especially considering Pacemaker now dropping heartbeat support completely as of version 2. Maybe that would be the time to introduce a new provider, with a more strictly defined standard for agent and parameter naming for example. > >> > Maybe we could even move IPaddr2 to ip or IP, and move the now-outdated >> > agents to a legacy provider... > > Yeah, I hope we don't need to get into that ;-) Too late! Anyway, I'll try to let it go for now... ;) Cheers, Kristoffer > > Cheers, > > Dejan > >> > >> > Cheers, >> > Kristoffer >> > >> > > >> > > >> > > >> > > >> > > > - minio >> > > > - NodeUtilization >> > > > - oraasm >> > > > - ovsmonitor >> > > > - rkt >> > > > - ZFS >> > > > >> > > > - bugfixes and enhancements: >> > > > - aws*: fixes and improvements >> > > > - CTDB: fixes for newer versions >> > > > - CTDB: fix for --logfile being replaced with --logging >> > > > - DB2: fix HADR support for DB2 V98+ >> > > > - docker: add docker-native healthcheck >> > > > - galera: fix for MariaDB 10.1.21+ >> > > > - mysql: set correct master score after maintenance mode >> > > > - ocf-shellfuncs: improve locking (ocf_take_lock()) >> > > > - pgsql: add support for PostgreSQL 10 >> > > > - pgsql: allow dynamic membership >> > > > - rabbitmq-cluster: fix to work on Pacemaker remote nodes >> > > > >> > > > The full list of changes for resource-agents is available at: >> > > > https://github.com/ClusterLabs/resource-agents/blob/v4.1.0rc1/ChangeLog >> > > > >> > > > Everyone is encouraged to download and test the new release candidate. >> > > > We do many regression tests and simulations, but we can't cover all >> > > > possible use cases, so your feedback is important and appreciated. >> > > > >> > > > Many thanks to all the contributors to this release. >> > > > >> > > > >> > > > Best, >> > > > The resource-agents maintainers >> > > > >> > > > _______ >> > > > Developers mailing list >> > > > Developers@clusterlabs.org >> > > > http://lists.clusterlabs.org/mailman/listinfo/developers >> > > >> > > ___ >> > > Developers mailing list >> > > Developers@clusterlabs.org >> > > http://lists.clusterlabs.org/mailman/listinfo/developers >> > > >> > >> > -- >> > // Kristoffer Grönlund >> > // kgronl...@suse.com >> > >> > ___ >> > Developers mailing list >> > Developers@clusterlabs.org >> > http://lists.clusterlabs.org/mailman/listinfo/developers > > ___ > Developers mailing list > Developers@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/developers > -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?
Adam Spiers writes: > Kristoffer Gronlund wrote: >>>On 07/06/18 08:48 +0200, Kristoffer Grönlund wrote: >>>>Jan Pokorný writes: >>So GitLab has a problem that AFAIK even GitHub didn't have, where >>certain crucial features are only in the enterprise edition - > > You're portraying GitLab as worse than GitHub here, but your logic is > backwards ;-) *All* of GitHub's functionality is non-libre, whereas > only certain features of GitLab are. > Ah, I wasn't talking about license problems but feature parity. My glance through the list of features only found in the enterprise edition made me think that the open version lacks some features that github currently has. Regarding licensing, the announcement about enabling additional features for open source projects seems to conflate Free as in Libre with free as in no one is getting paid, which is a bit concerning... Anyway, I'm not *against* GitLab, I'm just not convinced it's worth moving to the hosted version due to concerns with the future of GitHub. Yet. Cheers, Kristoffer -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?
Jan Pokorný writes: > > But with the latest headlines on where that site is likely headed, > I think it's a great opportunity for us to possibly jump on the > bandwagon inclined more towards free (as in freedom) software > principles. > > Possible options off the top of my head: > - GitLab, pagure: either their authoritative sites or self-hosted > - self-hosted cgit/whatever > > It would also allow us to reconsider our workflows, e.g. using gerrit > for patch review queue (current silent force-pushes is a horrible > scheme!). > My general view is that I also feel (and have felt) a bit uneasy about free software projects depending so strongly on a proprietary service. However, unless self-hosting, I don't see how f.ex. GitLab is much of an improvement (Pagure might be a different story, but does it offer a comparable user experience?) in that regard, and anything hosted on "public" cloud is basically the same. ;) crmsh used to be hosted at GNU Savannah, which is Free with a capital F, but the admin experience, user experience and general discoverability in the world at large all left something to be desired. In regard to workflows, if everyone agrees, we should be able to improve that without moving. For example, if all changes went through pull requests, there is a "required reviews" feature in github. I don't know if that is something everyone want, though. https://help.github.com/articles/enabling-required-reviews-for-pull-requests/ Cheers, Kristoffer -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?
Jan Pokorný writes:
> On 07/06/18 08:48 +0200, Kristoffer Grönlund wrote:
>> Jan Pokorný writes:
>>> But with the latest headlines on where that site is likely headed,
>>> I think it's a great opportunity for us to possibly jump on the
>>> bandwagon inclined more towards free (as in freedom) software
>>> principles.
>>>
>>> Possible options off the top of my head:
>>> - GitLab, pagure: either their authoritative sites or self-hosted
>>> - self-hosted cgit/whatever
>>>
>>> It would also allow us to reconsider our workflows, e.g. using gerrit
>>> for patch review queue (current silent force-pushes is a horrible
>>> scheme!).
>>>
>> My general view is that I also feel (and have felt) a bit uneasy about
>> free software projects depending so strongly on a proprietary
>> service. However, unless self-hosting, I don't see how f.ex. GitLab is
>> much of an improvement
>
> Open-core business approach aside as perhaps necessary downside at
> these scales, the difference is crucial: Community Edition is open
> source, anyone can host it individually, which is what enabled
> both Debian and GNOME to consider it's usage (became a reality
> for the latter: https://gitlab.gnome.org/explore/groups,
> https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/)
>
> Feature-wise:
> https://wiki.debian.org/Alioth/GitNext/GitLab
> https://wiki.debian.org/Alioth/GitNext
> https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/FeatureMatrix
>
>> (Pagure might be a different story, but does it offer a comparable
>> user experience?) in that regard, and anything hosted on "public"
>> cloud is basically the same. ;)
>
> Pagure has the benefit you can influence it relatively easily, as
> I directly attested :-)
>
So GitLab has a problem that AFAIK even GitHub didn't have, where
certain crucial features are only in the enterprise edition - though
they did announce the special allowance for open source projects the
other day which I don't know the details of.
And of course GitLab risks being acquired not by Microsoft but whoever
else, so again, not sure how much it improves. Unless self-hosting that
is.
Pagure has the benefit of being written in Python which I'm comfortable
with so yeah, maybe we can fix any problems with it ;)
>> crmsh used to be hosted at GNU Savannah, which is Free with a capital F,
>> but the admin experience, user experience and general discoverability in
>> the world at large all left something to be desired.
>>
>> In regard to workflows, if everyone agrees, we should be able to improve
>> that without moving. For example, if all changes went through pull
>> requests, there is a "required reviews" feature in github. I don't know
>> if that is something everyone want, though.
>>
>> https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
>
> AFAIK this doesn't address the qualitative complaint I have. It makes
> for a very poor experience when there's no readily available way to
> observe evolution of particular patchsets, only to waste time of the
> reviewer or contribute to oversights ("I'll skip this part I am sure
> I reviewed already, if there was a generational diff, I'd have a look,
> but the review is quite a pain already, I'll move on").
> No, setting up a bot to gradually capture work in progress is not
> a solution. And pull-request-per-patchset-iteration sounds crazy
> considering this count sometimes goes pretty high.
>
I'll confess that I have no experience with Gerrit or the Github
required reviews, and I don't really know how they differ. :)
>
> In the short term, I'd suggest concentrating on the two points I raised:
> - good discipline regarding commit messages
> - more systemic approach to release tarballs if possible
>
Both of these are generally good suggestions, I agree that we should
make an effort regarding commit messages. On the other hand, there is a
balance between having good commit messages and lowering the threshold
of contribution from outside developers.
Cheers,
Kristoffer
> --
> Poki
> ___
> Developers mailing list
> Developers@clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/developers
--
// Kristoffer Grönlund
// kgronl...@suse.com
___
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] Impact of changing Pacemaker daemon names on other projects?
Ken Gaillot <kgail...@redhat.com> writes: > Hi all, > > As I'm sure you've seen, there is a strong sentiment on the users list > to change all the Pacemaker daemon names in Pacemaker 2.0.0, mainly to > make it easier to read the logs. > > This will obviously affect any other scripts and projects that look for > the old names. I'd like to hear more developer input on how far we > should go with this, and how much or little of a headache it will > cause. I'm interested in both the public projects that use pacemaker > (crmsh, pcs, sbd, dlm, openstack) and one-off scripts that people > commonly put together. > > In order of minimum impact to maximum impact, we could actually do this > in stages: > > 1. Log tags: This hopefully wouldn't affect anyone. For example, from > > Mar 12 12:10:49 [11120] node1 pacemakerd: info: > crm_log_init: Changed active directory to /var/lib/pacemaker/cores > > to > > Mar 12 12:10:49 [11120] node1 pcmk-launchd: info: > crm_log_init: Changed active directory to /var/lib/pacemaker/cores > Perhaps surprisingly, this is probably the part which affects crmsh the most... For the history explorer we do a lot of log scanning and have a set of regexes to match various interesting outputs from pacemaker. However, we already handle changes in this format between versions, so it's just a matter of adding another set of regexes for the new version. More details: https://github.com/ClusterLabs/crmsh/blob/master/crmsh/log_patterns.py There are some other places that have similar things, like logparser.py. > 2. Process names: what shows up in "ps". I'm hoping this would affect > very little outside code, so we can at least get this far. This will also need some updates in crmsh, but not too many. There is a list of programs to query for metadata, just adding the new names to that list should be sufficient for example. > > 3. Library names: for example, -lstonithd to -lpcmk-fencing. Other > projects would need their configure script to auto-detect which is > available. Not difficult, but it makes all older versions of other > projects incompatible with Pacemaker 2.0. This is mostly what I want > feedback on, whether this is a good idea. The only advantage is > consistency and clarity. I would just move to the new names and require 2.0 to build the newer versions.. so it would be a compatibility break both ways. > > 4. Public API symbols: for example, crm_meta_name() -> > pcmk_meta_name(). This would be a huge project with huge impact, and > will definitely not be done for 2.0.0. We would immediately start using > the new convention for new API symbols, and more slowly update existing > ones (with compatibility wrappers for the old names). Not too much opinion here but seems questionable, not sure how much benefit it would bring and there are clear downsides to doing it. Cheers, Kristoffer > -- > Ken Gaillot <kgail...@redhat.com> > _______ > Developers mailing list > Developers@clusterlabs.org > https://lists.clusterlabs.org/mailman/listinfo/developers -- // Kristoffer Grönlund // kgronl...@suse.com ___ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] [ClusterLabs] resource-agents v4.2.0
On Wed, 2018-10-24 at 10:21 +0200, Oyvind Albrigtsen wrote: > ClusterLabs is happy to announce resource-agents v4.2.0. > Source code is available at: > https://github.com/ClusterLabs/resource-agents/releases/tag/v4.2.0 > [snip] > - ocf.py: new Python library and dev guide > I just wanted to highlight the Python library since I think it can make agent development a lot easier in the future, especially as we expand the library with more utilities that are commonly needed when writing agents. Any agents written in Python should (for now at least) be compatible both with Python 2.7+ and Python 3.3+. We still need to expand the CI to actually verify that agents do support these versions, so anyone who would like to help out improving the test setup is more than welcome to do so :) The biggest example of an agent using it that we have now is the azure- events agent [1], so I would recommend anyone interested in working on new agents to take a look at that. For a more compact example, I wrote a version of the Dummy resource agent using the ocf.py library and put it in a gist [2], and then there is a small example in the document describing the library and how to use it [3]. [1]: https://github.com/ClusterLabs/resource-agents/blob/master/heartbe at/azure-events.in [2]: https://gist.github.com/krig/6676d0ae065fd852fac8b445410e1c95 [3]: https://github.com/ClusterLabs/resource-agents/blob/master/doc/dev -guides/writing-python-agents.md Cheers, Kristoffer ___ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)
On Wed, 2018-10-24 at 14:42 +0200, Valentin Vidic wrote: > On Wed, Oct 24, 2018 at 01:25:54PM +0100, Adam Spiers wrote: > > No doubt I've missed some pros and cons here. At this point > > personally I'm slightly leaning towards keeping them in the > > openstack-resource-agents - but that's assuming I can either hand > > off > > maintainership to someone with more time, or somehow find the time > > myself to do a better job. > > > > What does everyone else think? All opinions are very welcome, > > obviously. > > Well, I can just comment that with all the python agents coming in, > the resource-agents package is getting a bit heavy on the > dependencies > (at least in Debian) so we might decide to split it at some point in > the future. > Do you mean additional python module dependencies, or that the dependency on python itself seems like added weight? Because since python is a dependency of pacemaker as well as both crmsh, pcs and fence-agents already, it really shouldn't make a difference. Cheers, Kristoffer ___ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)
On Wed, 2018-10-24 at 16:35 +0200, Valentin Vidic wrote: > On Wed, Oct 24, 2018 at 04:22:52PM +0200, Kristoffer Grönlund wrote: > > Do you mean additional python module dependencies, or that the > > dependency on python itself seems like added weight? Because since > > python is a dependency of pacemaker as well as both crmsh, pcs and > > fence-agents already, it really shouldn't make a difference. > > Yes, I meant the dependencies on openstack, cloud libraries and > perhaps other things to come, not python itself. It is not too > bad now but we shall see where it takes us and reevaluate. > Makes sense, yes. Hopefully we can keep the amount of external dependencies down at least somewhat, at the same time being able to use available python libraries is clearly a motivating factor in writing the agents in python rather than shell. Cheers, Kristoffer ___ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)
On Wed, 2018-10-24 at 13:25 +0100, Adam Spiers wrote: > [cross-posting to openstack-dev] > > Oyvind Albrigtsen wrote: > [snipped] > > > - openstack-cinder-volume > > - openstack-floating-ip > > - openstack-info > > That's an interesting development. > > By popular demand from the community, in Oct 2015 the canonical > location for OpenStack-specific resource agents became: > > https://git.openstack.org/cgit/openstack/openstack-resource-agent > s/ > > as announced here: > > http://lists.openstack.org/pipermail/openstack-dev/2015-October/0 > 77601.html > Hi Adam, I guess I did know that but it didn't cross my mind to question the submission, apologies. What is the relationship of the submitter of these openstack agents to the upstream project? Are these agents copies of your openstack agents, or completely separate developments? Maybe the best solution would be if you could get in touch with the submitter of these agents and see if you can join forces in maintaining a single set of agents. I guess this is an issue with maintaining agents outside the resource- agents repository - the same goes for the two PostgreSQL agents in existence. It's possible that people don't even realise that there could be agents that are not maintained in the resource-agents repository. :/ Maybe one solution would be to add documents in place of the agents with links to their actual upstream. Cheers, Kristoffer ___ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)
On Thu, 2018-10-25 at 17:26 +0100, Adam Spiers wrote: > Kristoffer Grönlund wrote: > > On Wed, 2018-10-24 at 13:25 +0100, Adam Spiers wrote: > > > [cross-posting to openstack-dev] > > > > > Are these agents copies > > of your openstack agents, or completely separate developments? > > Completely separate developments. > > Ironically, it seems that he submitted a blueprint for this work > to openstack-resource-agents back in May, but somehow I totally > missed it: > > https://blueprints.launchpad.net/openstack-resource-agents/+spec/ > resource-agents-consuming-openstack-api > > > Maybe the best solution would be if you could get in touch with the > > submitter of these agents and see if you can join forces in > > maintaining > > a single set of agents. > > Isn't that what I just did, by cross-posting to both communities? ;-) > > Unfortunately I don't have a direct email address I can Cc. > > > I guess this is an issue with maintaining agents outside the > > resource- > > agents repository - the same goes for the two PostgreSQL agents in > > existence. It's possible that people don't even realise that there > > could be agents that are not maintained in the resource-agents > > repository. :/ Maybe one solution would be to add documents in > > place of > > the agents with links to their actual upstream. > > Right. Discoverability is key. Given the blueprint above, discoverability doesn't seem to be the issue here though. I'll ask him to contact you in his open PR at resource-agents. Cheers, Kristoffer ___ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
Re: [ClusterLabs Developers] FYI: github policy change potentially affecting ssh/app access to repositories
Ken Gaillot writes: > Hello all, > > Florian Haas and Kristoffer Grönlund noticed that the ClusterLabs > organization on github currently carries over any app access that > members have given to their own accounts. > Thank you Ken for picking this up! All the credit for noticing this should go to Florian, I simply forwarded his comments. The plan sounds good to me as well. Cheers, Kristoffer > This is not significant at the moment since we don't have any private > repositories and few accounts have write access, but to stay on the > safe side, we'd like to enable OAuth access restrictions on the > organization account. > > Going forward, this will simply mean that any apps that need access > will need to be approved individually by one of the administrators. > > But as a side effect, this will invalidate existing apps' access as > well as some individual contributors' ssh key access to the > repositories. If you are affected, you can simply re-upload your ssh > key and it will work again. > > I'll wait a couple of weeks before implementing this change in case > anyone wants to raise concerns. > -- > Ken Gaillot > > ___ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/developers > > ClusterLabs home: https://www.clusterlabs.org/ -- // Kristoffer Grönlund // kgronl...@suse.com ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs Developers] Using ClusterLabs logo
Tomas Jelinek writes: > Hi, > > Is it OK to use ClusterLabs logo as a favicon for pcs in upstream? If > so, are there any conditions to meet? Yes, this would be OK to me at least (as the creator of the logo)! > > I went through new logo threads in mailinglists but I didn't find > anything specific other than this: I don't remember the specific license we decided on back then, but at least to me, CC-BY would make sense, where a link to clusterlabs.org would be sufficient attribution I think. https://creativecommons.org/licenses/by/4.0/ Cheers, Kristoffer > > > On 09/21/2017 04:42 PM, Ken Gaillot wrote: > > > >> On Thu, 2017-09-21 at 11:56 +0200, Kai Dupke wrote: > >> - I would like to see the logo used by as many > >> people/projects/marketingers, so I propose to link the Logo to a Logo > >> page with some prepared Logos - at least with one big to download and > >> a > >> license info > > > > Another good idea > > > Thanks, > Tomas > ___ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/developers > > ClusterLabs home: https://www.clusterlabs.org/ > -- // Kristoffer Grönlund // kgronl...@suse.com ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs Developers] Using ClusterLabs logo
Jan Pokorný writes: > Seems more appropriate for the author to do this himself if it's > indeed his intention :-) https://github.com/ClusterLabs/clusterlabs-www/pull/24 Cheers, Kristoffer > > Thanks! > > -- > Jan (Poki) > ___ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/developers > > ClusterLabs home: https://www.clusterlabs.org/ -- // Kristoffer Grönlund // kgronl...@suse.com ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/
