Conversation
|
|
||
| - name: config reload | ||
| ansible.builtin.command: config reload --yes | ||
| ansible.builtin.command: config reload --yes -f |
There was a problem hiding this comment.
Shouldn't this be an optional behavior? Maybe sometimes people do not want to force this. 😅
There was a problem hiding this comment.
One could argue that a config reload should always restart, even if the switch is broken, since it’s not a failure if the switch isn’t working anyway.
There was a problem hiding this comment.
if I recall this correctly, a force config reload might result in some network disruption.
But correct me if I'm wrong
There was a problem hiding this comment.
If I remember correctly a reload always interrupts the network. But maybe you do not want a restart if the SWSS is broken because the current state requires investigation before forcing a configuration change.
There was a problem hiding this comment.
Yes a config reload disrupts network, it disrupts it with or without the -f .
There was a problem hiding this comment.
PR is still in draft, using this for certain testing functionalities right now.
When finished I will put it out.
There was a problem hiding this comment.
If I remember correctly a reload always interrupts the network. But maybe you do not want a restart if the SWSS is broken because the current state requires investigation before forcing a configuration change.
Also the problem is I think with config reload, it "restarts" it and isn't returning an error, even if the swss is broken.
I could be wrong tho.
That's the main reason I'm adding the -f tag.
There was a problem hiding this comment.
Have you tried a force reload when the swss is down? I can't imagine a force reload fixing the situation where a regular reload is not possible. Usually it means there's something wrong with the config, which will instantly lead to a crash again after reload (and even after reboot).
Description
When the swss is broken the config reload is not being run. The -f tag skips the check for it.