Assigning artifacts after successful update again #446
Comments
|
Hi @EugenWiens , There are two questions in this issue.
Cheers, |
|
On 28/02/2017 11:22, Michael Hirsch wrote:
Hi @EugenWiens <https://github.com/EugenWiens> ,
There are two questions in this issue.
1.
Yes, hawkBit is checking if the |installed-DistributionSet| is
already set to the device and won't create an update-action for it
if so. There is currently no mechanism to set a fix
|installed-DistributionSet| There is an issue which describes the
functionality that a device can tell it's installed version. See:
#242 <#242>
2.
The options |forced| and |soft| are meta-data for the device. The
interpretation is device specific actually. Use-cases are for
example in a case of a |soft| update you want to inform a user that
there is an update available, or a |soft| update can indicate that
the device can download and install the update when resources are
available. A |forced| update could indicate that critical security
updates needs to be immediately installed without user-interaction
for example. |time-forced| only means that you want to execute an
update as |soft| but e.g. in a case the update is not installed
after a period of time hawkBit switching the update automatically
into |forced|.
—
My work-around: I created two distributions in the GUI and this let me
assign them again to the device. I could also assign first the old one,
and without waiting, I assign next the new one. But I agree that it
should be handled in some way.
The Hawkbit server does not check the installed version on the device
and relies on the value in the DB. But the device can fallback to the
older for a lot of reasons (corrupted fs ? crash ? something else ?),
and it could send the installed release with the configData (I know,
this is not evaluated now by the server). Or with a new API, I do not know.
Is this an issue that can be changed in future ? A mismatch between the
DB and what is running on the devices is really a use case.
Best regards,
Stefano
…--
Meet DENX at the Embedded World Trade Show
14 Mar - 16 Mar 2017, Nuremberg Trade Fair Centre, Hall 4, Booth 581
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================
|
|
A feedback channel will be great. That the DB is out of sync with the real software version is a problem in some embedded update concepts. e.g. second way for an update ( USB-Stick ) or redundancy boot. |
|
On 28/02/2017 13:26, Eugen Wiens wrote:
A feedback channel will be great. That the DB is out of sync with the
real software version is a problem in some embedded update concepts.
e.g. second way for an update ( USB-Stick ) or redundancy boot.
IMHO this is a problem that can always happen even if we do not provide
a second update source (in that case, it is clear !).
But even with a dual-copy concept and updating only from Hawkbit, there
are cases where the board fallbacks to the previous version.
And the server cannot be absolutely sure about what is running on the
board. I do not know if a customer can replace a broken board with
another with same tenant / ID, but if this happens, it is another case.
Anyway, I think more about runtime errors, such as filesystem corruption
(due maybe to software errors), or runtime conditions that avoid the
current software to run. In such cases, a fallback is often implemented,
and then the device is not aligned with Hawkbit's database.
Regards,
Stefano
…--
Meet DENX at the Embedded World Trade Show
14 Mar - 16 Mar 2017, Nuremberg Trade Fair Centre, Hall 4, Booth 581
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================
|
|
yeah, there are use-cases where hawkBit does not know about the installed version of a device (e.g. also in a plug'n play scenario where the device first time registered at hawkBit server), the truth which software is installed is always on the device. So in general it would be good if a device could tell hawkBit which version is currently installed. Problem though is that hawkBit only knows about |
|
I think what needs to be done after #242 is that devices by DDI or DMF as well can report offline updates by identifying DS by name, version. |
Hi,
how is the right procedure when after a successful update I try to assign the artifact again.
My problem is: The system that is updated have redundancy boot mechanism. When the system detect a problem with the current software version (V2) its switch back to the last one (V1). If that happening and the update to V2 comes from hawkbit the hawkbit will never again deliver the version V2.
I tried to assign the artifact to the device again in the Deployment Management view but I get a notification that the version is already installed.
Is it possible that the device reports his software version for this decision ?
What means the options forced, Soft and time Forced
The text was updated successfully, but these errors were encountered: