Re: keepalived.data and keepalived.stats json output

Hello,

To be clear, we are talking about opening a AF_UNIX socket at keepalived 
startup, and be able to ask for json through it ?

The Bird router has something similar, I will check how it is 
implemented and how long it would take to implement it for Keepalived.

However, since the work with POSIX signals is already quite advanced, in 
case this is too long / complicated to implement, can we consider 
keeping the signal handling solution for now ?

I am doing this on my work time and will be expected to provide results 
soon.

Regards,


On 17/07/17 04:39 PM, Alexandre Cassen wrote:
> 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] <mailto:[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 <http://configure.ac>  2017-02-18
>     12:52:10.000000000 +0100
>     +++ configure.ac <http://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 <http://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
>>>>     <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 vRouter
>>     ovh.qc.ca <http://ovh.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]
>>     <mailto:[email protected]>
>>     https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>>     <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
>
>     -- 
>     Damien Clabaut
>     R&D vRouter
>     ovh.qc.ca <http://ovh.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]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>     <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
>
>

-- 
Damien Clabaut
R&D vRouter
ovh.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