Re: RFC: Ubuntu HA resource-agents supportability

[Dan Streetman]

On Wed, Apr 29, 2020 at 11:13 PM Rafael David Tinoco
 wrote:
>
> On 29/04/2020 00:10, Rafael David Tinoco wrote:
>
> Dan, Billy, and all...
>
> part of the result from this thread is at:
>
> https://discourse.ubuntu.com/t/ubuntu-ha-pacemaker-resource-agents-supportability/
>
> And the fence agents can be found over here
>
> https://discourse.ubuntu.com/t/ubuntu-ha-pacemaker-fence-agents-supportability/15768
>
> The same (as bellow) applies to this list.

I'm +1 on the discussion there, for resource and fence agents.  I
think splitting them up makes a lot of sense to better categorize them
by supportability.


>
>
> and will at the Ubuntu Server Guide for 20.04 (Ubuntu HA session being 
> finished).
>
> I changed wording to guarantee this is seen as a community effort and to 
> differentiate from any Ubuntu Advantage offering.
>
> Categories are:
>
> Resource Agents: [main]
> Resource Agents: [universe]
> Resource Agents: [universe]-community
> Resource Agents: [non-supported]
> Resource Agents: [deprecated]
>
>
> From now on, in my head, we're 1:1 with Ubuntu Advantage in nomenclature. 
> Note that resource-agents are in [main] and fence-agents are in [universe]. 
> Despite that, the list is what defines our efforts for support - server & SEG 
> - on those, at least until I split all agents into more packages.
>
> I'm creating another discourse for fencing-agents as well, same thing.
>
> Please give me your +1 if possible, and feel free to -1 with suggestions.
>
> Cheers,
>
> -rafaeldtinoco
>
> On 07/04/2020 23:47, Rafael David Tinoco wrote:
>
> I added a few comments below, otherwise all the categories look
> reasonable to me, thanks!
>
> Thanks for the feedback Dan!
>
>

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC: Ubuntu HA resource-agents supportability

[Rafael David Tinoco]

On 29/04/2020 00:10, Rafael David Tinoco wrote:
> Dan, Billy,and all...
>
> part of the result from this thread is at:
>
> https://discourse.ubuntu.com/t/ubuntu-ha-pacemaker-resource-agents-supportability/
> 

And the fence agents can be found over here

https://discourse.ubuntu.com/t/ubuntu-ha-pacemaker-fence-agents-supportability/15768

The same (as bellow) applies to this list.

>
> and will at the Ubuntu Server Guide for 20.04 (Ubuntu HA session being
> finished).
>
> I changed wording to guarantee this is seen as a community effort and
> to differentiate from any Ubuntu Advantage offering.
>
> Categories are:
>
>   * Resource Agents: [main]
>   * Resource Agents: [universe]
>   * Resource Agents: [universe]-community
>   * Resource Agents: [non-supported]
>   * Resource Agents: [deprecated]
>
>
> From now on, in my head, we're 1:1 with Ubuntu Advantage in
> nomenclature. Note that resource-agents are in [main] and fence-agents
> are in [universe]. Despite that, the list is what defines our efforts
> for support - server & SEG - on those, at least until I split all
> agents into more packages.
>
> I'm creating another discourse for fencing-agents as well, same thing.
>
> Please give me your +1 if possible, and feel free to -1 with suggestions.
>
> Cheers,
>
> -rafaeldtinoco
>
> On 07/04/2020 23:47, Rafael David Tinoco wrote:
>>> I added a few comments below, otherwise all the categories look
>>> reasonable to me, thanks!
>> Thanks for the feedback Dan!


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC: Ubuntu HA resource-agents supportability

[Rafael David Tinoco]

Dan, Billy,and all...

part of the result from this thread is at:

https://discourse.ubuntu.com/t/ubuntu-ha-pacemaker-resource-agents-supportability/


and will at the Ubuntu Server Guide for 20.04 (Ubuntu HA session being
finished).

I changed wording to guarantee this is seen as a community effort and to
differentiate from any Ubuntu Advantage offering.

Categories are:

  * Resource Agents: [main]
  * Resource Agents: [universe]
  * Resource Agents: [universe]-community
  * Resource Agents: [non-supported]
  * Resource Agents: [deprecated]


>From now on, in my head, we're 1:1 with Ubuntu Advantage in
nomenclature. Note that resource-agents are in [main] and fence-agents
are in [universe]. Despite that, the list is what defines our efforts
for support - server & SEG - on those, at least until I split all agents
into more packages.

I'm creating another discourse for fencing-agents as well, same thing.

Please give me your +1 if possible, and feel free to -1 with suggestions.

Cheers,

-rafaeldtinoco

On 07/04/2020 23:47, Rafael David Tinoco wrote:
>> I added a few comments below, otherwise all the categories look
>> reasonable to me, thanks!
> Thanks for the feedback Dan!
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC: Ubuntu HA resource-agents supportability

[Seth Arnold]

On Tue, Apr 07, 2020 at 03:54:11PM -0400, Dan Streetman wrote:
> > Xen - xen unprivileged domains
> 
> as cpaelzer mentioned, Xen should probably move up to the 'best
> effort' section; this was just moved out of main in focal.

Xen's status before focal was awkward: the source package and libxen were
in main because libvirt depended upon them. However, the hypervisor and
related utilities were in universe and not supported.

I'm not sure where exactly this Xen resource agent should be placed on
the list -- but in practice, Xen wasn't in main, and that may influence
your thinking.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

RE: RFC: Ubuntu HA resource-agents supportability

[Rafael David Tinoco]

> > > > pgsql   - pgsql database instance
> > >
> > > shouldn't this be in fully supported?
> >
> > Pgsql is in [universe]. Unless SEG supports pgsql "by default", do you ?
> 
> We're talking about postgresql right?  It's definitely supported (it's
> in main), and from a quick look at cases, it gets quite a bit of
> support requests, especially around cluster management.

Err, you're absolutely right. Not sure what I thought here! Too many agents 
perhaps =). Postgresql + pgsql agent = fully supported then.

> >
> > > also Brett (I added to cc) brought up that resource-agents-paf might
> > > be worth considering supporting:
> > > https://launchpad.net/ubuntu/+source/resource-agents-paf
> >
> > Also in [universe]. Opened for discussions for pgsql.
> 
> Right exactly, Brett was suggesting it may be worth considering this
> for main as well.  Just wanted to let you know in case you had any
> opinions on it and FYI (and we'll be coming to you anyway if we do
> pursue an MIR ;-).

We can target a MIR for 20.10, no problem. And we can still do a "best effort" 
to it for 20.04 if there are users.

Tku!


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC: Ubuntu HA resource-agents supportability

[Dan Streetman]

On Tue, Apr 7, 2020 at 10:47 PM Rafael David Tinoco
 wrote:
>
> > I added a few comments below, otherwise all the categories look
> > reasonable to me, thanks!
>
> Thanks for the feedback Dan!
>
> > > clvm- clvmd daemon (cluster logical vol manager)
> >
> > Was clvm dropped from lvm2?
> > https://launchpad.net/ubuntu/+source/lvm2/2.03.02-2ubuntu1
> > I haven't used clustered lvm myself; maybe it was just rolled into lvm2.
>
> LVM2 can use lvmlockd (lvm2-lockd in Focal) now for VG access coordination: 
> It can use either dlm (dlm-controld) or sanlock (sanlock) as lock managers. 
> It is not a cmdline level based locking, as clvm was. AND it supports lvmetad.
>
> I believe we will continue seeing dlm as the lock manager as it uses 
> underlying corosync for messaging, same one as pacemaker, thus allowing the 
> same dlm to support gfs2, for example.
>
> > > docker  - docker container resource agent
> >
> > as cpaelzer said, docker itself shouldn't be in the fully supported list.
> >
>
> Yep, changed it already!
>
> > > lxc - allows LXC containers to be managed by the 
> > > cluster
> >
> > presumably, this includes lxc and lxd?
>
> That's actually a really good question. I flagged LXC resource here ("fully 
> supported agents - containers") and LXD resource agent in the "best effort - 
> registration agents" section.
>
> I explain:
>
> * We do have ocf_heartbeat_lxd resource:
>
> Just a service agent to tell the cluster (through CIB attributes) how many 
> containers are running in that node. Pacemaker pengine decisions can be made 
> out of that CIB attribute (to compile decision taking).
>
> For LXD, it seems it uses RAFT through its internal SQLite database for 
> clustering consensus. AND it controls all its own internal resources... so 
> not sure there would be any advantage in creating a pacemaker agent for LXD.
>
> Its quite a long discussion whether to rely on Paxos/Raft/Zab protocols or a 
> "totem single ring" protocol + fencing mechanisms like corosync & pacemaker 
> do... But I think its not worth pursuing a lxd agent if we are not managing 
> multiple resources in big resource groups and clusters.
>
> * We also have ocf_heartbeat_lxc resource: Basically manages lxc containers.
>
> Since LXD is light years in front of pacemaker + lxc I believe, IMO, the 
> strategy here should be to support users of the ocf lxc agent (if any) and 
> point them at lxd clustering.
>
> I could even move lxc agent to "best effort" as our strategy is targeted to 
> lxd.

While lxc is still supported in Xenial, if we're talking only about
future direction, then I absolutely agree.

I also agree it's probably better to allow lxd to manage its
clustering itself, instead of with a pacemaker agent.

>
> > > exportfs- nfs exports (not the nfs server)
>
> That’s a nice catch, I'm supporting NFS HA so I should support this together 
> as it specifies the exported directories. We can configure one per running 
> agent and give it the same fsid for example. Moving to supported.
>
> > wouldn't this be fully supported?
> >
> > > fio - fio instance
> > > galera  - galera instance
> > > garbd   - galera arbitrator instance
> > > jboss   - JBoss application server instance
> > > jira- JIRA server instance
> > > kamailio- kamailio SIP proxy/registrar instance
> > > mariadb - MariaDB master/slave instance
> > > nagios  - nagios instance
> > > ovsmonitor  - clone resource to monitor network bonds on diff
> > > nodes
> > > pgagent - pgagent instance
> > > pgsql   - pgsql database instance
> >
> > shouldn't this be in fully supported?
>
> Pgsql is in [universe]. Unless SEG supports pgsql "by default", do you ?

We're talking about postgresql right?  It's definitely supported (it's
in main), and from a quick look at cases, it gets quite a bit of
support requests, especially around cluster management.

>
> > also Brett (I added to cc) brought up that resource-agents-paf might
> > be worth considering supporting:
> > https://launchpad.net/ubuntu/+source/resource-agents-paf
>
> Also in [universe]. Opened for discussions for pgsql.

Right exactly, Brett was suggesting it may be worth considering this
for main as well.  Just wanted to let you know in case you had any
opinions on it and FYI (and we'll be coming to you anyway if we do
pursue an MIR ;-).

>
> > >
> > > # openstack
> > >
> > > openstack-cinder-volume - attach cinder vol to an instance (os-info <->)
> > > openstack-floating-ip   - move a floating IP from an instance to another
> >
> > I would expect both these to be in the fully supported category?
>
> So, ocf_heartbeat_openstack-info gets attributes from openstack instance and 
> records into cluster CIB (openstack_flavor, openstack_ports, etc). 
> 

Re: RFC: Ubuntu HA resource-agents supportability

[Dan Streetman]

On Tue, Apr 7, 2020 at 7:24 PM Seth Arnold  wrote:
>
> On Tue, Apr 07, 2020 at 03:54:11PM -0400, Dan Streetman wrote:
> > > Xen - xen unprivileged domains
> >
> > as cpaelzer mentioned, Xen should probably move up to the 'best
> > effort' section; this was just moved out of main in focal.
>
> Xen's status before focal was awkward: the source package and libxen were
> in main because libvirt depended upon them. However, the hypervisor and
> related utilities were in universe and not supported.
>
> I'm not sure where exactly this Xen resource agent should be placed on
> the list -- but in practice, Xen wasn't in main, and that may influence
> your thinking.

From UA perspective looking back at support requests, there have been
only a small handful of cases involving Xen hypervisor itself.  There
are quite a few cases where we fixed the Xen guest code in the kernel,
but that's of course different.

So while I would still recommend putting Xen into the 'best effort'
section, in practice it's likely to make little to no difference for
UA.

>
> Thanks

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

RE: RFC: Ubuntu HA resource-agents supportability

[Rafael David Tinoco]

> I'm not sure where exactly this Xen resource agent should be placed on
> the list -- but in practice, Xen wasn't in main, and that may influence
> your thinking.

I'll follow @cpaelzer's suggestion and keep it in "best effort". No hard 
commitment as it is in [universe], but at least some commitment.

> Thanks

Thanks to u!


openpgp-digital-signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

RE: RFC: Ubuntu HA resource-agents supportability

[Rafael David Tinoco]

> I added a few comments below, otherwise all the categories look
> reasonable to me, thanks!

Thanks for the feedback Dan!

> > clvm- clvmd daemon (cluster logical vol manager)
> 
> Was clvm dropped from lvm2?
> https://launchpad.net/ubuntu/+source/lvm2/2.03.02-2ubuntu1
> I haven't used clustered lvm myself; maybe it was just rolled into lvm2.

LVM2 can use lvmlockd (lvm2-lockd in Focal) now for VG access coordination: It 
can use either dlm (dlm-controld) or sanlock (sanlock) as lock managers. It is 
not a cmdline level based locking, as clvm was. AND it supports lvmetad.

I believe we will continue seeing dlm as the lock manager as it uses underlying 
corosync for messaging, same one as pacemaker, thus allowing the same dlm to 
support gfs2, for example.

> > docker  - docker container resource agent
> 
> as cpaelzer said, docker itself shouldn't be in the fully supported list.
> 

Yep, changed it already!

> > lxc - allows LXC containers to be managed by the cluster
> 
> presumably, this includes lxc and lxd?

That's actually a really good question. I flagged LXC resource here ("fully 
supported agents - containers") and LXD resource agent in the "best effort - 
registration agents" section.

I explain:

* We do have ocf_heartbeat_lxd resource:

Just a service agent to tell the cluster (through CIB attributes) how many 
containers are running in that node. Pacemaker pengine decisions can be made 
out of that CIB attribute (to compile decision taking).

For LXD, it seems it uses RAFT through its internal SQLite database for 
clustering consensus. AND it controls all its own internal resources... so not 
sure there would be any advantage in creating a pacemaker agent for LXD.

Its quite a long discussion whether to rely on Paxos/Raft/Zab protocols or a 
"totem single ring" protocol + fencing mechanisms like corosync & pacemaker 
do... But I think its not worth pursuing a lxd agent if we are not managing 
multiple resources in big resource groups and clusters.

* We also have ocf_heartbeat_lxc resource: Basically manages lxc containers.

Since LXD is light years in front of pacemaker + lxc I believe, IMO, the 
strategy here should be to support users of the ocf lxc agent (if any) and 
point them at lxd clustering.

I could even move lxc agent to "best effort" as our strategy is targeted to lxd.

> > exportfs- nfs exports (not the nfs server)

That’s a nice catch, I'm supporting NFS HA so I should support this together as 
it specifies the exported directories. We can configure one per running agent 
and give it the same fsid for example. Moving to supported.
 
> wouldn't this be fully supported?
> 
> > fio - fio instance
> > galera  - galera instance
> > garbd   - galera arbitrator instance
> > jboss   - JBoss application server instance
> > jira- JIRA server instance
> > kamailio- kamailio SIP proxy/registrar instance
> > mariadb - MariaDB master/slave instance
> > nagios  - nagios instance
> > ovsmonitor  - clone resource to monitor network bonds on diff
> > nodes
> > pgagent - pgagent instance
> > pgsql   - pgsql database instance
> 
> shouldn't this be in fully supported?

Pgsql is in [universe]. Unless SEG supports pgsql "by default", do you ?
 
> also Brett (I added to cc) brought up that resource-agents-paf might
> be worth considering supporting:
> https://launchpad.net/ubuntu/+source/resource-agents-paf

Also in [universe]. Opened for discussions for pgsql.

> >
> > # openstack
> >
> > openstack-cinder-volume - attach cinder vol to an instance (os-info <->)
> > openstack-floating-ip   - move a floating IP from an instance to another
> 
> I would expect both these to be in the fully supported category?

So, ocf_heartbeat_openstack-info gets attributes from openstack instance and 
records into cluster CIB (openstack_flavor, openstack_ports, etc). 
ocf_heartbeat_openstack-cinder-volume uses those attributes to take actions 
attaching or removing cinder volumes from a instance.

I have no knowhow in this and judging by the descripting it felt fragile to say 
"fully supported". I thought making no hard commitment was "safer". What's your 
opinion ?

> > Xen - xen unprivileged domains
> 
> as cpaelzer mentioned, Xen should probably move up to the 'best
> effort' section; this was just moved out of main in focal.

Yep =(. Will do.

Thanks a lot for all the input, very helpful!

-rafaeldtinoco


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC: Ubuntu HA resource-agents supportability

[Dan Streetman]

On Tue, Mar 31, 2020 at 1:09 AM Rafael David Tinoco
 wrote:
>
> Hello,
>
> As many as you know I'm currently revamping Ubuntu High Availability
> Packages
>
> For 20.04, considered HA (or HA related) packages are:
>
> - Core packages:
>
>   - libqb
>   - kronosnet
>   - corosync
>   - pacemaker
>   - resource-agents
>   - fence-agents
>   - crmsh
>   - cluster-glue
>   - drbd-utils
>   - dlm
>   - gfs2-utils
>
> - "Deprecated" packages:
>
>   - heartbeat
>   - keepalived
>   - ocfs2-tools
>
> - Not in "main" packages:
>
>   - pcs (will likely replace crmsh in near future)
>   - csync2
>   - corosync-qdevice
>   - fence-virt
>   - sbd
>   - booth
>
> - Related packages:
>
>   - multipath-tools
>   - open-iscsi
>   - sg3-utils
>   - targetcli-fb
>   - tgt (we're trying to deprecate in favor of LIO)
>   - lvm2
>
> For now, until Beta Freeze, we've been trying to catch up with upstream
> latest
> releases and, from now on, I'm going through existing opened bugs and
> addressing
> them with latest fixes (from upstream) + any needed fix to address the bugs
> (done to kronosnet, with FFE opened, and corosync, about to merge fixes to
> it).
>
> Next step is to document in Server Guide all supported scenarios for HA
> related
> packages. The intention here is to describe exact set of scenarios that we
> know
> are good for the perfect behavior of clustering software AND which scenarios
> we
> cannot support.
>
> OBS: This includes the need, or not, to have odd number of nodes/votes, to
> have
> or not proper fencing mechanisms (and which fencing mechanisms to support)
> AND,
> finally, what *resource agents* to support.
>
> I'll probably ask other feedback soon, but, for this moment, I'm asking
> comments
> for the list of resource agents bellow. I tried to split and explain what
> the
> resources are used for and if they are supported in Ubuntu or not (or if the
> related managed service is in [main] or in [universe]).
>
> So please, take some time to provide feedback about this list, whether we
> should
> move resources from one category to the other. *NOTE* that I'm not giving
> the
> "fence agents" list yet. That will be another list.
>
> I'm particularly interested in feedback from @jamespage and @ddstreet as
> they
> probably have good intel about resources usage BUT anyone is welcome to
> provide
> comments!
>
> Thank you very much in advance!

I added a few comments below, otherwise all the categories look
reasonable to me, thanks!

>
>  RFC: Ubuntu HA resource-agents supportability
>
> #
> ## FULLY SUPPORTED (managed service is likely in main or is important
> enough)
> #
>
> # trivial agents
>
> Delay   - test resource for introducing delay
> MailTo  - sends email to a sysadmin whenever a takeover
> occurs
> ClusterMon  - runs crm_mon to a html page from time to time
> HealthCPU   - measures CPU idling and updates #health-cpu attr
> HealthIOWait- measures CPU idling and updates #health-iowait
> attr
> HealthSMART - measures CPU idling and updates #health-smart attr
>
> # services
>
> apache  - apache web server instance
> dovecot - dovecot IMAP/POP3 server instance
> dhcpd   - chrooted ISC dhcp server instance
> mysql   - MySQL database instance
> mysql-proxy - MySQL proxy instance
> named   - bind/named server instance
> nfsnotify   - nfs sm-notify reboot notifications daemon
> nfsserver   - nfs server resource
> nginx   - Nginx web/proxy server instance
> postfix - postfix mail server instance
> rabbitmq-cluster- cloned rabbitmq cluster instance
> remote  - pacemaker remote resource agent
> rsyncd  - rsyncd instance
> rsyslog - rsyslogd instance
> slapd   - stand-alone LDAP daemon instance
> Squid   - squid proxy server instance
> vsftpd  - vsftpd server instance
>
> # storage
>
> Raid1   - software RAID (MD) devices on shared storage
> iscsi   - local iscsi initiator and its conns to targets
> iSCSILogicalUnit- iSCSI logical units
> iSCSITarget - iSCSI target export agent (implementation: tgt,
> lio)
> LVM - LVM volume as an HA resource
> LVM-activate- LVM activation/deact work for a given VG
>   (lvmlockd+LVM-activate OR clvm+LVM-activate)
> Filesystem  - filesystem on a shared storage medium
> symlink - symbolic link
> ZFS - ZFS pools import/export
>
> # locking & reservations
>
> controld- distributed lock manager for clustered FSs
> clvm- clvmd daemon (cluster logical vol manager)

Was clvm dropped from lvm2?

RE: RFC: Ubuntu HA resource-agents supportability

[Rafael David Tinoco]

> I added a few comments below but I must admit that I didn't completely
> get what you want.

I'm sorry then, let me try to explain better...

> The list includes so many things, what are you expecting:
> - if they are important overall?
> - if they are important for HA cases?
> - if they should be promoted/demoted in their support level?

The list includes (1) HA packages and (2) HA related packages. This initial 
package list was informative only and supposed to get feedback about missing HA 
packages (like haproxy, for example) OR HA packages that should be fully 
supported (in [main]) instead. 

In that sense I got feedback from @freyes and @sabdfl about keepalived being 
considered as "deprecated": Felipe told me there is a important dependency for 
openstack, Mark suggested me to check on the snap coming directly from upstream 
after he started an initial snap (I'll check this for 20.10).

For the other half of the e-mail.. it listed "so many things" because it listed 
"all resource agents" pacemaker supports (yes, it is a *lot*). And it is even 
more.. since it supports all "sysv services" and "systemd units" you have 
installed (but then agents are *generic*, without specialization for particular 
service, or supporting multiple instances).

In the resource agents list... I used some terms that are mostly used by 
support organization, specially to get feedback from them about this (I had CC 
Dan before).

What I had in mind was:



1) FULLY SUPPORTED - Pacemaker Resource Agents that depend on packages in 
[main]. The resource agents should be *fully supported* like the packages are: 
they are fully supported by Ubuntu Advantage & have higher importance to us in 
LP (server team is subscribed to all server seeded pkgs, for example).

2) BEST EFFORT SUPPORT - Pacemaker Resource Agents that depend on packages in 
[universe]. The resource agents should be supported as *best effort attempt* 
like the packages in [universe] are: They are supported as "best effort 
attempt" by Ubuntu Advantage & have less importance to LP (mostly driven by 
MOTU or specific bugs impacting too many people).

3) COMMUNITY SUPPORT - In this category I placed Pacemaker Resource Agents done 
by 3rd party for their specific products or solutions. We, as community, could 
forward any bug opened against these agents to upstream project and sync LP if 
needed... or even check if "resource-agents" upstream has a fix for it.. but it 
could be difficult to debug without upstream involvement.

4) UNSUPPORTED - Pacemaker Resource Agents done for products that aren't 
supported in Ubuntu Linux (Oracle, Sybase, SAP, ...)

5) DEPRECATED - Pacemaker Agents that are deprecated and should not be used.



> - are you asking that for the packages/features themself or only for
> their HA support?

I'm adapting "resource-agents" resource to its core package (or dependency) and 
not the opposite. Example: If resource agent was made for *squid* and *squid* 
is in [main], then I should consider the *squid resource agent* as being fully 
supported. 

>   (e.g. does LVM being listed mean "is LVM important" or "do we need
> an HA resource agent for LVM")

It only means that for the "HA related packages" I'll probably be helping to 
solve bugs because they are important to HA. But nothing to do with my original 
email intent, so you can skip that list.

> To be clear I love and appreciate all the things you already fixed up
> in the HA space for Ubuntu 20.04.
> And I'd want to help going forward, but myself and probably others
> might be lost here.

I hope it was clarified now.

> Could you break these community questions into smaller chunks
> and clearly outline the questions that you ask the people to answer?
> 
> Maybe this is worth an entire discourse sub-category where multiple
> entries would help to split things?
> If you'd like that you could prep it there and test-run with a few
> people to comment there.
> Edit/Improve the topic/questions based on that and then send a mail
> again to the list here with a TL;DR and a list of link-per-topic.
> 
> What do you think?

The *discourse* part was going to be a second phase in my head... to document 
whatever we have discussed here, but maybe my long e-mail scared people =).

If discourse is the way to go, then I think I prefer finishing up the HA 
documentation for 20.04 with all my pre-concepts and then do what you suggest: 
I don't think there will be much feedback either way.

> >
> > # containers
> >
> > docker  - docker container resource agent
> 
> Umm, this one is a bit more complex.
> There is runc/containerd which provide the same but are supported.
> You should punt docket down to community support and replace this
> entry here with runc/containerd.

Perfect.

> > Xen - xen unprivileged domains
> 
> Xen is on community support level, so you likely want to move this one
> category up.

Ok.

Thanks a lot for the careful review!

Re: RFC: Ubuntu HA resource-agents supportability

[Felipe Reyes]

On Tue, 2020-03-31 at 02:09 -0300, Rafael David Tinoco wrote:
> Hello, 
> 
> As many as you know I'm currently revamping Ubuntu High Availability
> Packages
> 
> For 20.04, considered HA (or HA related) packages are:
> 
> - Core packages:
> 
>   - libqb
>   - kronosnet
>   - corosync
>   - pacemaker
>   - resource-agents
>   - fence-agents
>   - crmsh
>   - cluster-glue
>   - drbd-utils
>   - dlm
>   - gfs2-utils
> 
> - "Deprecated" packages:
> 
>   - heartbeat
>   - keepalived

keepalived is used by OpenStack Neutron. In this context what would
"deprecated" mean?.

apt-rdepends -r keepalived
Reading package lists... Done
Building dependency tree   
Reading state information... Done
keepalived
  Reverse Depends: neutron-l3-agent
(2:16.0.0~b3~git2020032420.a0e1b5804e-0ubuntu3)
neutron-l3-agent

>   - ocfs2-tools
> 
> - Not in "main" packages:
> 
>   - pcs (will likely replace crmsh in near future)
>   - csync2
>   - corosync-qdevice
>   - fence-virt
>   - sbd
>   - booth
> 
> - Related packages:
> 
>   - multipath-tools
>   - open-iscsi
>   - sg3-utils
>   - targetcli-fb
>   - tgt (we're trying to deprecate in favor of LIO)
>   - lvm2
> 
> For now, until Beta Freeze, we've been trying to catch up with
> upstream
> latest
> releases and, from now on, I'm going through existing opened bugs and
> addressing
> them with latest fixes (from upstream) + any needed fix to address
> the bugs
> (done to kronosnet, with FFE opened, and corosync, about to merge
> fixes to
> it).
> 
> Next step is to document in Server Guide all supported scenarios for
> HA
> related
> packages. The intention here is to describe exact set of scenarios
> that we
> know
> are good for the perfect behavior of clustering software AND which
> scenarios
> we
> cannot support.
> 
> OBS: This includes the need, or not, to have odd number of
> nodes/votes, to
> have
> or not proper fencing mechanisms (and which fencing mechanisms to
> support)
> AND,
> finally, what *resource agents* to support.
> 
> I'll probably ask other feedback soon, but, for this moment, I'm
> asking
> comments
> for the list of resource agents bellow. I tried to split and explain
> what
> the
> resources are used for and if they are supported in Ubuntu or not (or
> if the
> related managed service is in [main] or in [universe]).
> 
> So please, take some time to provide feedback about this list,
> whether we
> should
> move resources from one category to the other. *NOTE* that I'm not
> giving
> the
> "fence agents" list yet. That will be another list.
> 
> I'm particularly interested in feedback from @jamespage and @ddstreet
> as
> they
> probably have good intel about resources usage BUT anyone is welcome
> to
> provide
> comments!
> 
> Thank you very much in advance!
> 
>  RFC: Ubuntu HA resource-agents supportability
> 
> #
> ## FULLY SUPPORTED (managed service is likely in main or is important
> enough)
> #
> 
> # trivial agents
> 
> Delay   - test resource for introducing delay
> MailTo  - sends email to a sysadmin whenever a
> takeover
> occurs
> ClusterMon  - runs crm_mon to a html page from time to
> time
> HealthCPU   - measures CPU idling and updates #health-cpu 
> attr
> HealthIOWait- measures CPU idling and updates #health-
> iowait
> attr
> HealthSMART - measures CPU idling and updates #health-
> smart attr
> 
> # services
> 
> apache  - apache web server instance
> dovecot - dovecot IMAP/POP3 server instance
> dhcpd   - chrooted ISC dhcp server instance
> mysql   - MySQL database instance
> mysql-proxy - MySQL proxy instance
> named   - bind/named server instance
> nfsnotify   - nfs sm-notify reboot notifications daemon
> nfsserver   - nfs server resource
> nginx   - Nginx web/proxy server instance
> postfix - postfix mail server instance
> rabbitmq-cluster- cloned rabbitmq cluster instance
> remote  - pacemaker remote resource agent
> rsyncd  - rsyncd instance
> rsyslog - rsyslogd instance
> slapd   - stand-alone LDAP daemon instance
> Squid   - squid proxy server instance
> vsftpd  - vsftpd server instance
> 
> # storage
> 
> Raid1   - software RAID (MD) devices on shared
> storage
> iscsi   - local iscsi initiator and its conns to
> targets
> iSCSILogicalUnit- iSCSI logical units
> iSCSITarget - iSCSI target export agent (implementation:
> tgt,
> lio)
> LVM - LVM volume as an HA resource
> LVM-activate- LVM activation/deact work for a given VG
>   (lvmlockd+LVM-activate OR clvm+LVM-
> activate)
> Filesystem  - filesystem on a shared storage medium
> symlink - symbolic link
> 

Re: RFC: Ubuntu HA resource-agents supportability

[Christian Ehrhardt]

On Tue, Mar 31, 2020 at 7:09 AM Rafael David Tinoco
 wrote:
>
> Hello,
>
> As many as you know I'm currently revamping Ubuntu High Availability
> Packages
>
> For 20.04, considered HA (or HA related) packages are:
>
> - Core packages:
>
>   - libqb
>   - kronosnet
>   - corosync
>   - pacemaker
>   - resource-agents
>   - fence-agents
>   - crmsh
>   - cluster-glue
>   - drbd-utils
>   - dlm
>   - gfs2-utils
>
> - "Deprecated" packages:
>
>   - heartbeat
>   - keepalived
>   - ocfs2-tools
>
> - Not in "main" packages:
>
>   - pcs (will likely replace crmsh in near future)
>   - csync2
>   - corosync-qdevice
>   - fence-virt
>   - sbd
>   - booth
>
> - Related packages:
>
>   - multipath-tools
>   - open-iscsi
>   - sg3-utils
>   - targetcli-fb
>   - tgt (we're trying to deprecate in favor of LIO)
>   - lvm2
>
> For now, until Beta Freeze, we've been trying to catch up with upstream
> latest
> releases and, from now on, I'm going through existing opened bugs and
> addressing
> them with latest fixes (from upstream) + any needed fix to address the bugs
> (done to kronosnet, with FFE opened, and corosync, about to merge fixes to
> it).
>
> Next step is to document in Server Guide all supported scenarios for HA
> related
> packages. The intention here is to describe exact set of scenarios that we
> know
> are good for the perfect behavior of clustering software AND which scenarios
> we
> cannot support.
>
> OBS: This includes the need, or not, to have odd number of nodes/votes, to
> have
> or not proper fencing mechanisms (and which fencing mechanisms to support)
> AND,
> finally, what *resource agents* to support.
>
> I'll probably ask other feedback soon, but, for this moment, I'm asking
> comments
> for the list of resource agents bellow. I tried to split and explain what
> the
> resources are used for and if they are supported in Ubuntu or not (or if the
> related managed service is in [main] or in [universe]).

Hi,
I added a few comments below but I must admit that I didn't completely
get what you want.
The list includes so many things, what are you expecting:
- if they are important overall?
- if they are important for HA cases?
- if they should be promoted/demoted in their support level?
- are you asking that for the packages/features themself or only for
their HA support?
  (e.g. does LVM being listed mean "is LVM important" or "do we need
an HA resource agent for LVM")

To be clear I love and appreciate all the things you already fixed up
in the HA space for Ubuntu 20.04.
And I'd want to help going forward, but myself and probably others
might be lost here.

Could you break these community questions into smaller chunks
and clearly outline the questions that you ask the people to answer?

Maybe this is worth an entire discourse sub-category where multiple
entries would help to split things?
If you'd like that you could prep it there and test-run with a few
people to comment there.
Edit/Improve the topic/questions based on that and then send a mail
again to the list here with a TL;DR and a list of link-per-topic.

What do you think?

> So please, take some time to provide feedback about this list, whether we
> should
> move resources from one category to the other. *NOTE* that I'm not giving
> the
> "fence agents" list yet. That will be another list.
>
> I'm particularly interested in feedback from @jamespage and @ddstreet as
> they
> probably have good intel about resources usage BUT anyone is welcome to
> provide
> comments!
>
> Thank you very much in advance!
>
>  RFC: Ubuntu HA resource-agents supportability
>
> #
> ## FULLY SUPPORTED (managed service is likely in main or is important
> enough)
> #
>
> # trivial agents
>
> Delay   - test resource for introducing delay
> MailTo  - sends email to a sysadmin whenever a takeover
> occurs
> ClusterMon  - runs crm_mon to a html page from time to time
> HealthCPU   - measures CPU idling and updates #health-cpu attr
> HealthIOWait- measures CPU idling and updates #health-iowait
> attr
> HealthSMART - measures CPU idling and updates #health-smart attr
>
> # services
>
> apache  - apache web server instance
> dovecot - dovecot IMAP/POP3 server instance
> dhcpd   - chrooted ISC dhcp server instance
> mysql   - MySQL database instance
> mysql-proxy - MySQL proxy instance
> named   - bind/named server instance
> nfsnotify   - nfs sm-notify reboot notifications daemon
> nfsserver   - nfs server resource
> nginx   - Nginx web/proxy server instance
> postfix - postfix mail server instance
> rabbitmq-cluster- cloned rabbitmq cluster instance
> remote  - pacemaker remote resource agent
> rsyncd  - rsyncd instance
> rsyslog - rsyslogd instance
> slapd   - 

RE: RFC: Ubuntu HA resource-agents supportability

[Rafael David Tinoco]

> -Original Message-
> From: Felipe Reyes 
> 
> >
> > - "Deprecated" packages:
> >
> >   - heartbeat
> >   - keepalived
> 
> keepalived is used by OpenStack Neutron. In this context what would
> "deprecated" mean?.
> 
> apt-rdepends -r keepalived
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> keepalived
>   Reverse Depends: neutron-l3-agent
> (2:16.0.0~b3~git2020032420.a0e1b5804e-0ubuntu3)
> neutron-l3-agent

It means I'm (or was) considering demoting the package to [universe] and giving 
focus to other ones that might do similar things. We are trying to focus in 
single pkgs / functionality in [main] and I thought about considering 
keepalived "deprecated" in favor of a single tool to control active/passive 
virtual Ips (pacemaker in this case).

For active/active load balancing we already have haproxy & nginx in [main] (and 
pound in [universe]) and, even being L7 balancing, and not L4 + VRRP like 
keepalived, somehow I thought IPVS was already "deprecated". In a deeper look 
now seems that keepalived is well maintained and updated so I'll probably just 
mark keepalived as a "core" HA package.

Thanks for the feedback! That’s exactly the reason of my e-mails =).







-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel