Re: enable/disable features in running configuration

On Monday 04 May 2015 09:57:19 Alexandre Cassen wrote:
> Hi Patrick,
> 
> Any option are open, as netop guy mainly I am used to play with CLI, 
that is
> the way most of us are conditioned to play around :D,

Sure thing! I have my own CLI (scripted in perl, not really shareable, 
contains too many site specific hacks) which provides monitoring (show 
commands) and in-service/out-of-service switch commands, as well as 
manual failover steering; towards keepalived itself, it operates by 
generating a new configuration file for any change needed (server 
weights, VRRP priorities), then signals keepalived to reload.

For my purposes this is sufficient, as I prefer to have a config generator 
anyway, using its own mission specific input files that reflect the 
specifics of our setup, while keeping the overall structure of our setup 
inside the generator itself. Of course, this is at the cost of being site 
specific...

> but for sure every
> options are open. Please feel free to discuss and bring idea here. But 
we
> are all on the same line of saying, current conf parser MUST be 
changed…

I would love to be able to signal the more dynamic config changes 
during operation, in addition to generating new startup config, by 
sending suitable snippets to the running daemon, with easily 
processed replies. I'm less interested in using it as a CLI all by itself - I 
already have one :)

Important aspects, from that angle, would be

1) regarding security, provide a text based unix domain socket interface, 
i.e. something usable with "netcat -U" and no fancy prompting. This is 
what I would use from my own CLI. Strive for API stability here.

2) if you want to add a nice cisco style CLI, provide it as a seperate 
executable, taking to the daemon itself using the unix domain interface; 
this CLI could optionally listen on a telnet port, or be called as a 
"command=" thing via ssh. It should offer some kind of authentication 
(for the ssh thing, this might be as easy as passing a username in the 
command= string) and authorization (accounts that can look, accounts 
that can configure, maybe accounts that can only change some things, 
like weights; there's a lot of complexity possible here...)

3) if your goal is to be able to configure and reconfigure the running 
daemon from such a CLI, I think you must get rid of the {} block syntax in 
the configuration file, and instead use a section/subsection based 
scheme, and for the more detailed inner blocks (e.g. authentication, 
virtual_ipaddress in vrrp sections, HTTP_GET etc. in real_server 
subsections), a slightly more verbose format that can "address" 
individual items. If I can't copy+paste config snippets from saved config 
files, or _remove_ stuff with a "no" in front, it won't be cisco style. 
Example of what I mean:

NOW:    virtual_server fwmark 123 {
      real_server 1.2.3.4 80 {
        HTTP_GET {
          url {            path /foo/bar            status_code 200          }        }      }    }

THEN:    virtual_server fwmark 123      real_server 1.2.3.4 80        check 
method HTTP_GET        check http url path /foo/bar        check http 
status_code 200


These are my rough ideas at the moment. Hope they are useful to you.

If you are interested, I could additionally write a bit about the day-to-day 
display and management stuff I have in our private CLI, regarding 
realserver weight switching (taking out of service), and manual failover 
control.

best regards
  Patrick

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel