Hi there, I have a requirement to move a device from the resin.io (live) to resinstaging.io (dev) environment.
I’ve mounted the boot partition of the device I’d like to move and replaced values is config.json to match those in resinstaging.io
Unfortunately after the reboot, the device does not establish the connection to the staging/dev environment and continues running with the current code, albeit completely disconnected from any Resin VPN.
Is there something I am missing?
Cheers!
You will have to reprovision the device in staging as far as I can tell. Is that fine for you?
This is what I am trying to avoid, because I don’t have physical access to the device. If that’s the only way, then so be it.
Cheers!
What I meant is that you can force the device to reprovision to staging. I haven’t testing this myself but it should work. Will require though ssh access to the host because the supervisor needs to be stopped and it’s sqlite databased erased.
I don’t think I have access to do this from the container, or is there a way through dbus?
I will try to raise this internally. I’m not sure how this would work from a user’s container. Will come back as soon as I have additional information.
OK, the device in question is apps/273906/devices/468569 and on its boot partition there is a config.json.staging, in un-provisioned state, which I already tried. I guess it the device gets its state removed, then it will go and re-provision itself based on the values in the config (after renaming to config.json).
What exactly is your usecase? Why do you actually need to do this?
Mainly to cut costs by moving 5 devices to the staging environment where they won’t get billed.
It also gives me an option to test new OS versions before they are promoted to the live environment.
Hello,
I managed to have a talk with the team and have more information about your request.
First of all the staging server is not rarely unstable. And it’s not only about the OS but as well all the other components might change and behave unexpectedly because of the fact that they all trace the head of the development branches. In this way we can’t guarantee anything about this environment. Given this we don’t support any migration from production to staging and if customers decide to use this environment by provisioning device there, they do it assuming this risk.
Andrei
OK, sounds like what I was planning to do is a bad idea.
I’ll just keep my dev. devices in the same place (i.e. resin.io) and pay a few extra dollars for them.
Cheers!
It would be hard to use that environment even in testing because a misbehaviour would not say anything about what generated it. It might be the state of the staging server or the user app. So this instability would not help at all. So yes, keeping everything in the production server would be advisable.