search

balena-os / balena-supervisor

Balena Supervisor: balena's agent on devices.
https://balena.io
Other
150 stars 63 forks source link

applicationName, applicationId not changed on device move #123

Open lorenzo-stoakes opened 8 years ago

lorenzo-stoakes commented 8 years ago

When moving a device from one application to another, the applicationId and applicationName fields in config.json remain the same. Either we should remove these fields, rename them to 'originalXXX', or update them on move, the current case is confusing at best, and at worst maybe some code relies on this (I'm not sure.)

cywang117 commented 3 years ago

Can confirm that applicationId is still not changed in config.json on device move, even when the target state reports the app under a different id. In the code, applicationId is set as an immutable data field.

jellyfish-bot commented 3 years ago

[pdcastro] This issue has attached support thread https://jel.ly.fish/d530e774-0d99-4a90-9c6a-d8646495246b

pipex commented 3 years ago

I'm for removing it from config.json, is not compatible with multi app, and I'm pretty sure is not used within the supervisor.

pipex commented 3 years ago

I would check with the rest of the OS team to see if they use it and remove it definitely if they don't

pipex commented 3 years ago

The field is also not documented so we should be able to remove it without problems

https://www.balena.io/docs/reference/OS/configuration/#sample-configjson

pdcastro commented 3 years ago

The fact that a field is not documented does not mean that balena users aren't relying on it in their applications. Documentation about config.json hardly existed until a year or two ago, while user apps have been parsing config.json for 5+ years based on whatever could be found in there.

balenaOS v3 is coming soon though, right? Semver major = breaking changes. It might be an opportunity or excuse :-) for making this kind of change.

pipex commented 3 years ago

I see your point @pdcastro , but I think this is another case of explicit vs implicit interfaces. If we try to consider all possible ways users are relying on observable behavior before making a change, we wouldn't be able to do anything.

Other way to see it is that, if someone is relying on a private variable on your library, I'm not sure is not your fault if their code breaks with a new version.

If the common agreement is that config.json is an explicit interface for user apps, then we definitely will have to wait until balenaOS v3