Re: keepalived.data and keepalived.stats json output

Hi Guys,

Well, maybe designing a req/rep json protocol to request keepalived states
& related would be more futur proof instead of signal handling ?

Best regs,
Alexandre

On Mon, Jul 17, 2017 at 9:53 PM, Damien Clabaut <[email protected]
> wrote:

> Hello,
>
> I have made some progress on the matter. I did not know much about POSIX
> signals a few days ago, so I spent a lot of time figuring out how to
> manipulate them.
>
> To keep the code explicit, I defined two constants SIGDATAJS and
> SIGSTATJS. They are currently defined this way:
>
> --- configure.ac  2017-02-18 12:52:10.000000000 +0100
> +++ configure.ac  2017-07-17 21:07:37.994953146 +0200
> @@ -46,6 +46,8 @@
>    [
>  #ifndef _CONFIG_H
>  #define _CONFIG_H
> +#define SIGDATAJS ( __SIGRTMIN + 4 )
> +#define SIGSTATJS ( __SIGRTMIN + 5 )
>    ])
>  AH_BOTTOM(
>    [
>
>
> __SIGRTMIN to ( __SIGRTMIN + 3 ) are reserved on Linux so I started at +4.
>
> The file configure.ac being really long, I am not yet sure this is the
> best place to define those constants. It looks like I need them in config.h
> for the code to compile.
>
> Can you confirm this is a clean place to define those constants ?
>
> Meanwhile, I am starting to work on the functions that will actually write
> the json output (so far they create files and write one static string in
> it).
>
> Regards,
>
> On 14/07/17 01:28 PM, Damien Clabaut wrote:
>
> Hello Quentin and thank you for your answer.
>
> I believe we will add two extra signals (USR3 and USR4, or something else)
> and use them to write output to /tmp/keepalived_data.json and
> /tmp/keepalived_stats.json.
>
> This way users can keep using existing scripts with existing behaviour,
> and develop future scripts on new behaviour, at the same time.
>
> Regards,
>
> On 14/07/17 09:47 AM, Quentin Armitage wrote:
>
> On Fri, 2017-07-14 at 08:35 -0400, Damien Clabaut wrote:
>
> Hello Keepalived developers,
>
> My team and I are considering modifying the file https://github.com/acassen/keepalived/blob/master/keepalived/vrrp/vrrp_print.c
> in order to make the /tmp/keepalived.data and /tmp/keepalived.stats a
> valid json.
>
> In your opinion, what would be the best way to do this ?
>
> - Patching current functions so that kill -USR1 and kill -USR2 return
> valid json ?
>
> - Adding handlers for kill -USR3 and kill -USR4 to return valid json,
> leaving -USR1 and -USR2 in their current states ?
>
> The idea would be to port this patch to the master branch in the end.
>
> Regards,
>
>
> I don't think we can alter the current functionality - there might be
> users who have scripts that parse the output files.
>
> Of course, there are no signals USR3 and USR4, but there is no reason why
> you can't use other signals that aren't currently used.
>
> I can see three ways of doing this, each of which I would be happy with:
> 1. Use 2 new signals (this seems to offer the greatest flexibility)
> 2. Have a global configuration option, e.g. dump_json, which if set will
> make USR1 and USR2 write json output
> 3. Use 1 additional signal that each time it is invoked toggles between
> the current format and json (the default would need to be the current
> format); this probably isn't the best approach.
>
> Depending on how much overhead in terms of code size there is with the
> json output, it might be useful to make the inclusion of json output a
> compile time option enabled by a configure option --enable-json.
>
> It would be good not to duplicate the existing code, since at the moment
> when a new option is added we already have to update vrrp_print.c,
> vrrp_data.c and vrrp_snmp.c, and to have to update a fourth place in the
> code would be somewhat excessive. In fact I have in mind that at sometime
> the code in vrrp_print.c and the dump_vrrp() code in vrrp_data.c should be
> merged.
>
> I hope that helps,
>
> Quentin Armitage
>
>
>
> --
> Damien Clabaut
> R&D vRouterovh.qc.ca
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Keepalived-devel mailing [email protected]://lists.sourceforge.net/lists/listinfo/keepalived-devel
>
>
> --
> Damien Clabaut
> R&D vRouterovh.qc.ca
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Keepalived-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

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