Closed epruesse closed 5 years ago
:wave: Thanks for opening your first issue here! If you're reporting a :bug: bug, please make sure you include steps to reproduce it. Also, logs, error messages and information about your hardware might be usefull.
Hass.io relies on specific version tags, hence the latest tag is obsolete.
But to be honest, I think you confuse some things here... this is the AppDaemon add-on for Hass.io, not AppDaemon (manual Docker) itself?
The versions numbers you are talking about, again, are AppDaemon's version numbers. The documentation you are referring to, is for the add-on version numbering. You are barking against the wrong tree there.
I'm running Hass.io on Linux and updated the AppDaemon docker to it's latest state. The docker image installed was the one tagged 1.6.0
I believe, which has the 3.0.1
of AppDaemon inside, not the 3.0.2
. If I understand you correctly, you'd have to tag another release to push the updated containers to the Hassio installations?
(Locally, I fixed it for me by just creating a tag :latest
pointing to the latest docker container built from here - that made hassio's supervisor start the right version)
But I'm happy to be educated re versions. I do understand that the hassio-addon has a different version than the contained software (1.6.0 vs 3.0.2). I'm not certain why Hassio logs tell me something about starting the container "with version 1.1.1" though.
Curiously, after pulling the 1.6.0 docker container explicitly, it has the 3.0.2 inside. My hassio didn't install that docker though, even though it had an update recently for the appdaemon add-on.
Well.... I can't reproduce the problem any more. Closing this for now (insights appreciated though).
Ok, here we go.
I'm running Hass.io on Linux and updated the AppDaemon docker to it's latest state. The docker image installed was the one tagged
1.6.0
I believe, which has the3.0.1
of AppDaemon inside, not the3.0.2
. If I understand you correctly.
I'm not sure, but this sentence somehow makes me think, you've used the docker
command line on Linux to update the add-on? If so.... DON'T. Hass.io is a Docker manager, bypassing it, will cause issues.
You see, Hass.io is more than just Docker, it also contains all kinds of additional layers (e.g, configuration management, bridging to HA, networking, ..., ...). For example, the latest
tag in Hass.io means: "Last pulled version on update from the Hass.io panel". so latest
on your Hass.io machine, is created by Hass.io and has nothing to do with the one on Dockerhub.
Hass.io gets its tag/update/configuration information from here: https://github.com/hassio-addons/repository/blob/master/appdaemon3/config.json
The version is also specified in there, THAT is how it determines what is latest (and thus, not Docker).
I do understand that the hassio-addon has a different version than the contained software (1.6.0 vs 3.0.2)
Because the add-on does not consist of only AppDaemon. It contains the following software:
So which version should the add-on follow? AppDaemon? Interesting... What is there is a CVE in curl, that needs updating? The add-on will not wait until the next AppDaemon update, but I will ship an update.
Hence, the add-ons having their own version numbers.
I'm not certain why Hassio logs tell me something about starting the container "with version 1.1.1" though.
I was not able to reproduce that, here is my log: https://hastebin.com/axefufizar.coffeescript
even though it had an update recently for the appdaemon add-on.
Recently? November 1 2018 was the last add-on release. I desperately needs an update (which is on my shortlist).
I'm not sure, but this sentence somehow makes me think, you've used the
docker
command line on Linux to update the add-on? If so.... DON'T. Hass.io is a Docker manager, bypassing it, will cause issues.
Well - only this once to get a container with AppDaemon 3.0.2 (because I had been writing an App that needed some new APIs). The point of using the docker containers and using hassio to manage them is exactly so I don't have to mess with all the dependencies, the necessary updates, and don't have to do the integration work, getting the various things to work with HA properly (SSL setup, etc).
Because the add-on does not consist of only AppDaemon. It contains the following software: [...] (and I'm sure I'm forgetting a lot)
Yes - all the stuff I don't have to mess with :+1: :)
So which version should the add-on follow? AppDaemon? Interesting... What is there is a CVE in curl, that needs updating? The add-on will not wait until the next AppDaemon update, but I will ship an update.
Agreed, a versioning scheme for the container separate from AppDaemon is appropriate. It's effectively a distro of its own. If you are asking for a good scheme, I might have chosen 2019.01.3.0.2 or 3.0.2.2019.01 or just 2019.01 - just to make it easier later on to know what people where using when they file bugs, and perhaps give them an indication of what's in the container.
I'm not certain why Hassio logs tell me something about starting the container "with version 1.1.1" though.
I was not able to reproduce that, here is my log: https://hastebin.com/axefufizar.coffeescript
I meant the hassio-supervisor log. It says
INFO (SyncWorker_15) [hassio.docker.addon] Start Docker add-on hassioaddons/appdaemon3-amd64 with version 1.1.1
Other add-ons also mention versions that are lower than the add-on version displayed in the UI (I didn't check the version of the primary contained software).
even though it had an update recently for the appdaemon add-on.
Recently? November 1 2018 was the last add-on release. I desperately needs an update (which is on my shortlist).
Well... I didn't have it on auto, and may have overlooked it for a couple of months. So that's probably on me.
I meant the hassio-supervisor log. It says
Unfortunately, that is not in my or the add-ons control. Maybe ask that question on the Hassio repository.
Agreed, a versioning scheme for the container separate from AppDaemon is appropriate. It's effectively a distro of its own. If you are asking for a good scheme, I might have chosen 2019.01.3.0.2 or 3.0.2.2019.01 or just 2019.01 - just to make it easier later on to know what people where using when they file bugs, and perhaps give them an indication of what's in the container.
In this case, yes. In the case of a lot of other add-ons.... Nope. E.g, InfluxDB, Chronograph as shipped together in one single add-on... versioning becomes an issue with that scheme. I've decided in early stages to break it loose and pick a single scheme acros the whole project. You don't have to agree though 😉 As a result, the changelogs always have been clear and detailed on the exact software changes.
I certainly dont. Have to agree, that is. ;-) I do, though. I'm actually happy about anything that has a version at all, and doesn't do stuff like 1.1
-> 1.10
-> 1.2
-> 1.2.1
-> 1.3
-> 20172705
-> 1.4
(day job pains).
This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.
The
:latest
tag still points to the image with version 3.0.1. Possibly because the pipeline failed for the commit bumping to 3.0.2?The 3.0.2 should really have been 3.1.0, at least if you subscribe to SemVer - it brings MQTT support for apps, which I'd consider a pretty significant addition.