[Dev] [RFC] Tizen system rollback

Aliaksei Katovich a.katovich at samsung.com
Mon Dec 2 11:09:59 GMT 2013


hi;

>    On 2 December 2013 10:56, Aliaksei Katovich <[1]a.katovich at samsung.com>
>    wrote:
> 
>    >    Rather, it ought to be "what is currently flashed in the factory".
> 
>              I do not see any issues with supporting this concept in
>      proposed
>              approach.
> 
>    Me neither :-)

	Consensus! Great! \o/

>    But it was not part of the proposal, iirc. So I brought it up.
>    [...]
> 
>    >    Sorry, but I cannot agree with this.
>    >    You are somehow implying that the end user would not be able to
>    flash
>    >    the sw
>    >    on a bricked device.
> 
>              This sounds like a real statement rather than implication to
>      me: User
>              will not be able to restore malfunctioning after update
>      device being
>              away from PC or being not connected to network.
> 
>    How likely is that? Like users are advised to do upgrades with full
>    battery charge
>    and possibly charger plugged in, wouldn't it be advisable to tell them
>    to do the update
>    when they have a PC with broadband connection handy?

	Software issues can be manifested later, after update is applied but
	user is not anymore with PC at hands.

> 
>    [...]
> 
>              Again, OTA upgrades are already part of our lives - so it is
>      not just
>              nice but rather mandatory thing nowadays.
> 
>    I wasn't trying to say otherwise.

	Ok, i misinterpreted this, sorry.

>    [...]
>    >    Final few considerations:
>    >    1) given the dynamics of how testing works and the fact that
>    testing
>    >    teams
>    >    have only so many devices available, it's much more likely that
>    cold
>    >    flashing gets
>    >    significant more testing than OTA. I won't get into details, but
>    it's
>    >    obvious that they
>    >    have to test many releases and typically the testing starts with
>    >    flashing a new image.
>    >    Only a limited amount of devices are reserved to real OTA updates,
>    >    because it
>    >    requires more complex IT infrastructure.
> 
>              I do not see your point here. Are you trying to say that no
>      new features
>              should be added because testing is hard to arrange?
> 
>    C'mon ... do you really think I'd write that? :-D

	It was just first impression :)

>    No, what I mean is that, no matter how hard the QA team tries to test
>    OTA, the way the product program works is playing against them.
>    It's a fact: just think how many times OTA is attempted vs how many
>    times flashing is performed.
>    The latter wins hands down. Not to mention that typically one cannot
>    use
>    exactly the same production environment for testing OTA, so there are
>    bound
>    to be parts of the OTA process that will never be really tested until
>    it is
>    deployed for real on production servers.
>    This doesn't apply to flashing.

	That's why simple and easy way to rollback is important.

>    >    2) alternatively, one could use cloud storage to keep track of
>    user
>    >    data
>    >    and configuration (like apps installed and related keys) and just
>    >    rebuild the user's
>    >    customized setup on top of a new build.
>    >    Even with a rollback, there will be the problem that the use might
>    want
>    >    to re-install whatever
>    >    was non-offending and got installed in between the restored
>    snapshot
>    >    and the failure that needed reset.
>    >    And even re-installing, the user data might be in a non-consistent
>    >    state.
> 
>              This is far less tested than anything.
> 
>    That's
> 
>    a problem because it's far more likely that a user has to deal with a
>    broken/stolen/lost device hat needs to be reconstructed somehow.

	Snapshot based rollback will reconstruct one's device in no time.

>    >    3) how to decide to take a snapshot?
>    >    - let the user choose
>    >    - whenever some native app is installed
>    >    - before a distro upgrade, like windows does?
>    >    - a mixture of the options above
>    >    If I were to decide, probably I would either do it all the time or
>    >    misjudge and skip it when
>    >    it would really turn out to be useful. Probably I would do both
>    :-)
>    >    The rollback, to me, makes some sense only in certain corner
>    cases,
>    >    like:
> 
>              s/corner/vital/
> 
>    Of course you know your product better than me, so if it's going to
>    some
>    rural area in africa or india where connection is
>    unavailable/slow/expensive,
>    it might make sense to rely on rollback.

	The feature proposed is area/connection agnostic: it _makes_ sense
	to rely on rollback regardless whose product and where it is. IMHO.

	But I see your point.

>    >    - no access to broadband connection
>    >    - no access to a PC
>    >    - hard requirement of 99.999% availability
> 
>              those three above _are_ real! Look:
>              User received update being connected to internet. Update
>      worked just
>              fine first two hours and then something started to
>      malfunction. User
>              has no data connectivity nor PC accessibility at that point
>      of time
>              but desperately needs stable working device. Maybe it _can_
>      be called
>              a corner case but to me _possibility_ to restore device to
>      known working
>              configuration regardless of connectivity status or PC
>      availability is
>              extremely important.
> 
>    As I wrote, it depends on the product requirements.
>    If PC w/ broadband connectivity is available, then
> 
>    the requirement on rollback is not so hard.

	PC's world end is behind the corner! ;) Sorry for silly joke though
	could not resist.

>    >    So it might fit cases where you have rural users, but if we can
>    assume
>    >    that the
>    >    device is targeting city dwellers, the reconstruction seems more
>    >    attractive.
>    >    Which is btw, what Apple does.
>    >    I'm not saying that it's right just because they do it, but
>    certainly
>    >    we will all agree
>    >    that they have a large use base which is not necessarily tech
>    savvy and
>    >    yet they
>    >    manage to keep the bricking to an acceptable level.
> 
>    What do you think of what I wrote above?

	Sounds like alternative despite being very implementation specific.

>    Why not just rely on rebuilding the device configuration?
>    Is it just because of the requirement of PC/broadband or is there any
>    other reason?

	how about these:

	* complex solution (reconstruction) vs simple (thin-provisioning);
	* if I understand you correctly reconstruction implies package
	  re-installation which might become a problem due to:
	- time consumed;
	- space consumed;
	- dependencies;
	* how to rollback in case reconstructed configuration failed: files on
	system got already replaced with new ones;
	* how to recover from update if connectivity framework gets broken right
	  after.

	IMO snapshot based rollback is cheaper to make and maintain than
	rebuilding.

--
Aliaksei


>    --
>    cheers, igor
> 
> References
> 
>    1. mailto:a.katovich at samsung.com


More information about the Dev mailing list