ctdb client python bindings

Martin Schwenke martin at meltin.net
Mon May 2 01:38:00 UTC 2022


Thanks to everyone on involved in this thread.  I'm time limited, so
will just reply to this message...

On Fri, 29 Apr 2022 09:09:23 -0400, Andrew Walker via samba-technical
<samba-technical at lists.samba.org> wrote:

> Hmm... do you have a general idea of the gross functionality you want to
> have separate daemon's for. I was already breaking up functionality into
> different classes in the bindings I was writing. E.g.
> 
> ctdb.Ctdb - interacting with databases
> ctdb.Node - interacting with cluster nodes
> ctdb.IP - interacting with public IP addresses

Looks sane.  :-)

Functionality won't necessarily map straight to functions, but some
structure would be a big improvement.

It is a little complicated:

* We will have a failover component that supports public IPs, LVS, NAT
  gateway, and whatever else the use defines.  However, I'm not sure we
  want to push all of these under "ctdb failover" in the tool.  It gets
  too verbose.

  One question here is whether we should change the terminology from
  "public addresses" to "virtual IPs" (VIPs).

* Things like version, uptime, ping, runstate, ... all just
  apply to nodes, so let's say "ctdb node".

* Tunables (and perhaps) capabilities should eventually go away.  Some
  will become script variables (all of the failover stuff), some will
  become config variables, some will go away.

So, for discussion:

* ctdb

  - version
  - status

* ctdb cluster

  - list (listnodes)
  - reload (reloadnodes)
  - leader
  - lock (getreclock)
  - recover

* ctdb node
  - uptime
  - ping
  - status (nodestatus)
  - runstate
  - pnn
  - pid (getpid)
  - disable
  - enable
  - pause (stop) [please!]
  - continue
  - ban
  - unban
  - shutdown
  - capability list (getcapabilities)
  - capability get (getcapabilities, just 1)
  - capability set (setlmasterrole)
  - capability set (setleaderrole)
  - dumpmemory
  - dumpmemory recoverd (rddumpmemory)
  - checkpid (process-exists)

* ctdb tunable
  - get (getvar)
  - set (setvar)
  - list (listvars)

* ctdb ips (or ctdb vip?)

  - list (ip)
  - info (ipinfo)
  - iface list (ifaces)
  - iface set (setifacelink)
  - reload (reloadips)
  - reallocate (ipreallocate)

* ctdb db
  - list (getdbmap)
  - info (some of getdbstatus)
  - status (some of getdbstatus)
  - statistics (dbstatistics) [+ without DB name does global DB stats]
  - attach
  - detach
  - backup (backupdb)
  - restore (restoredb)
  - dumpbackup (dumpdbbackup)
  - wipe (wipedb)
  - seqnum (getdbseqnum)
  - cat (catdb)
  - key get (readkey, pfetch)
  - key set (writekey, pstore)
  - key delete (deletekey, pdelete)
  - key batch (ptrans, also extended for volatile)
  - flag set (setdbreadonly, setdbsticky)
  - flag get (some of getdbstatus)
  - tdb cat
  - tdb get
  - tdb set

I know I'm close, but I need to stop and get on with other things.
Remaining commands are:

  lvs             leader|list|status           show lvs configuration
  setdebug        ERROR|WARNING|NOTICE|INFO|DEBUG  set debug level
  getdebug                                     get debug level
  statistics                                   show ctdb statistics
  statisticsreset                              reset ctdb statistics
  stats           [count]                      show rolling statistics


  gratarp         <ip> <interface>             send a gratuitous arp
  tickle          <srcip:port> <dstip:port>    send a tcp tickle ack
  gettickles      <ip> [<port>]                get the list of tickles
  addtickle       <ip>:<port> <ip>:<port>      add a tickle
  deltickle       <ip>:<port> <ip>:<port>      delete a tickle
  moveip          <ip> <node>                  move an ip address to another node
  addip           <ip/mask> <iface>            add an ip address to a node
  delip           <ip>                         delete an ip address from a node

  event                                        event and event script commands
  scriptstatus    [init|setup|startup|monitor|takeip|releaseip|ipreallocated]  show event script status
  natgw           leader|list|status           show natgw configuration
  checktcpport    <port>                       check if a service is bound to a specific tcp port or not

If someone is really thinking about doing this, then please consider
the following.  Some aren't needed in version 1, but if they're kept in
mind then they should be easier to add later.

* Nested --help

* Interactive with only a single connect, potentially with readline +
  completions - could allow stepping down into commands to allow
  relative sub-commands, as well as allowing long commands

* JSON output - sorry, have meant to reply about this before

* Loop mode for JSON output - we don't have to support JSON on the
  wire, but keeping a connection to take commands and spit out JSON
  might be very helpful

* bash completion file

Gee... it is huge.  Perhaps we need a wiki page to keep track...

peace & happiness,
martin



More information about the samba-technical mailing list