Rare project developers

[mc36 <>]

hi,

On 4/1/22 16:23, Alexander Gall wrote:
> Hi csaba
>
> As you've already seen, I have completed a first attempt at
> integrating the release manager with freerouter
> (https://bitbucket.software.geant.org/projects/RARE/repos/rare-nix/commits/dab3443cf73dd26a554f1a4a94b5f757ca2b452b)
> The service reconfiguration from within the freerouter service is a
> little bit tricky but it should be ok, I think.  Basically, the
> tna-switch-to-generation alias doesn't do the switch immediatley but
> delays it until the next restart of the service.
what about adding "alias exec tna-switch-to-generation cmd2nd reload warm" ?
(the rationale here is that once someone issued this, there is the intent...:)

> Can you please use PRs while we both work on this repo so we don't
> keep overwriting each other's changes?  I don't think we should put
> the GEANT_TESTBED profile into the default configuration since this is
> what ends up on a fresh ONIE installation and it should not be
> specific to our testbed.
feel free to change that to PE then...
but one thing, keep the sticky konb with a parameter in the startup,
that's the trigger that makes it really sticky... :)

> Is the sticky alias guaranteed to be executed before the external
> processes are started? If so, we can remove the default
> /etc/freertr/p4-profile file from the ONIE installer. If not, I guess
> we can still let the alias create the file and accept that there will
> be a couple of failed starts of the bfswd and bffwd processes until
> the file exists.
so there is a guarantee that the processes will be started before any
startup config get parsed because we're running them from the -hw.txt...
anyway we can remove the default from the onie installer because there
is a guarantee that when the startup parser reaches the aliases, it'll
execute the sticky one exactly once so the file will be regenerated
at every time freerouter boots up...

> When changing the profile, it would be enough to restart the bfswd and
> bffwd processes, but this currently fails for bfswd. That's because
> the process has several subprocesses and "reload process ... stop"
> does not kill them.  The top-level script start_bfswd.sh is the leader
> of a new process group, so it would be enough to kill that group.  Can
> you please modify the reload procedure so it either kills the group
> (but only if the process is the group leader) or kills all
> subprocesses explicitly?
okk, i'll do so...

br,
cs