Virtual OpenWrt on master branch

Hello,

I am planning on switching from an embedded OpenWRT based router to a LXD contained virtual x86_64 OpenWRT.
Rather than using a release, I was keen on trying to stay on the bleeding edge. I know about some risks of the bleeding edge like changing ABI/API and daily hickups. Leveraging snapshots and smoke tests should allow me to prevent unusable or unstable situations. I was however wondering if there are other reasons that I am missing, and that will fail with the following pseudo process

snapshot currentRouter testRouter
opkg full-upgrade on testRouter
if smoketestOK(testRouter) opkg full-upgrade on currentRouter
else wait a few days (and potentially report...) before retrying 

Thank you

@Arduous, welcome to the community!

The pseudo code you pasted makes no sense. There's no method to do a full-upgrade - also it's not advised to upgrade packages generally. If you intent is to upgrade the snapshot, you should re-image or sysupgrade the [x86_64] machine.

Not clear what this means. If you install a snapshot it's installed.

Personally, I’d get an A/B setup in place so you can just rollback quickly. That should reduce your risk to close to zero.

I also find an upgrade cadence faster than a few times a year to bring little tangible benefit.

Thank you!

opkg full-upgrade was a shortcut for some unrecommanded snippets that can be found over the internet to uprade with a oneliner. Given that (soft-)bricking a device is not a concern in my virtualized context, I thought it meaningful.

As suggested however, I will re-image a container with a newer OpenWrt snapshot, reinstall the needed packages and copy over the configuration with the help of something like:

sysupgrade -b -k myconf   on the current virtual router
sysupgrade -r myconf      on the new to be tested virtual router

I tried to sysupgrade in place, even with -F option, but I think that it is not designed to handle the generic-rootfs image that I am using to image the container.

Having both old and new images running at the same time will be difficult, so some specific cases may not be testable in production condition before the switch over. The almost instant rollback will then mitigate the risks.
Quarterly sounds like a relevant frequency.