"Reload in" feature (Cisco)

[CheckPointerXL]

Hello Team

what do you think about the chance to implement the "reload" feature like cisco's devices do it?

I mean, especially for changes in gaia clish (i guess for DB revisions is a little bit complicated, but it could be useful too)...

Sometimes it happens that, working remotely (especially during changes on ISP side), I would feel safer if I could configure reload paramater. 

[_Val_]

Can you please elaborate on a use case?

[Chris_Atkinson]

You mean the ability to schedule or delay it? E.g.

router#reload in 5

[CheckPointerXL]

exact

@_Val_  lot of use cases, change to static/dynamic routes is of course the most common; sometimes for some reasons not related to your config, you need to roll back, and it could happen that it is too late for you to reach the fws again.

i'm pretty sure that list is longer but is the first use case that come to my mind

[Gojira · Accepted solution]

changes in clish don't get automatically saved.

So you could execute "shutdown -r +10" (10 minutes)

And cancel with "shutdown -c"

If its a cloning group it'd be a bit more difficult because it's automatically saved.. Might need to script something to restore previous config before reboot

[CheckPointerXL]

That's a great trick! Thank you

[Gojira]

I'm not correct about cloning group in clish, you still need to save config looks like.

So if it's a cloning group you can still do that.

[_Val_]

Save config to a file, load from a file - these functionalities are already available for you. Or do you mean, automatic reload with some delay? I am still missing the use case.

[Bob_Zimmerman]

The idea is to save you from a situation where you make a CLI config change which breaks your ability to access the box. With the "shutdown -r +10" trick, if you make the change and the change prevents you from issuing the "shutdown -c" command, the box reboots itself automatically and undoes the change you made which broke your access. It's good for remote sites without people on-hand who are allowed to work on the systems in question.

I personally prefer Juniper's CLI config system, which can commit many changes all as one atomic operation, and which can roll them back as one atomic operation. You stage a bunch of changes, issue "commit confirmed", and if you don't issue another "commit" within ten minutes, the changes applied with "commit confirmed" are rolled back. No reboot involved.