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