Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26430

Re: Dynamic upgrading/Hot-swapping a service

Show all headers | View raw

On 4/25/2017 9:19 AM, Phil Martel wrote:
>>> So, lets say you're in the middle of calculating
>>> factorial(1,000,000,000,000)
>>> with algorithm 2.  Then you find out about algorithm 1 (or maybe
>>> decide that
>>> Stirling's approximation is close enough).
>>
>> You (as an executing client who has called upon the "factorial service"
>> to perform that calculation) don't "find out about" anything!  To *you*,
>> nothing appears remiss.  That's the whole point; as long as the API
>> hasn't changed, you shouldn't care that the service has been replaced
>> with an equivalent service.
>>
>> How the *system* ensures that illusion is maintained is the problem
>> being addressed.
>>
>> The remedy that "makes most sense" will vary with the design (and
>> functionality) of the service being upgraded.  And, the approach the
>> maintainer chooses to address those "rolling updates"
>
> I used the word "you" to mean the system providing the service (including the
> programmer who implemented the new algorithm).  However, a factorial
> calculation is a poor example in that it is not persistent.

There are no conditions placed on what a service can provide.  E.g.,
my calculator is a service; in your world, it might be a library.

I use factorial as an example of a "job" that can take some "macroscopic"
amount of time -- rather than arguing about whether 10 microseconds or
200 hours is "too long" for a service to "linger" in the face of a
pending/desired upgrade.

> It may make sense
> for you (the system) to dump the work you've done and start over, or to
> continue with the old algorithm for this instance.

There are *many* possible courses of action that the developer could
apply to providing a rolling upgrade of his service.  The system can't
impose *one* -- without sharply constraining the types of services that
can be implemented as well as the "time" each takes to operate.

If a service has side-effects, then you can't (typically) start over
as you would have to consider which side effects had already taken
place.

Etc.

>> As it would be heavy-handed for the system to dictate how EVERY service
>> is coded AND the constraints placed upon their algorithms, the system
>> can only offer (prefabricated) *mechanisms* that the service designer
>> (and maintainer) can exploit to facilitate the upgrade.
>>
>> And, the system has to rely on the designer/maintainer to make best use
>> of the mechanisms that it provides -- because the designer/maintainer
>> has more intimate knowledge of the way the service is intended to work.
>>
>> A "lazy" designer may choose not to address live upgrade issues.
>> In which case, the system will resort to draconian measures when
>> an upgrade is installed:  it will KILL the running service and
>> let the clients deal with the resulting mess.  *Users* will then
>> either avoid products from that provider *or* will avoid upgrading
>> (if the consequences are too painful -- where "too" is a subjective
>> criteria defined by the user in question).
>>
>>> What *can* you do with the
>>> unfinished solution other than dump the work and restart the problem
>>> with the
>>> new algorithm or let it finish? (and next time use the new algorithm)?
>>
>> I prepare a document using /WordProcessor25/.  The document can be seen
>> as a snapshot of the "conceptual document" that I seek to prepare.
>> I upgrade to /WordProcessor29/.  Is all of the work that I did prior
>> to that upgrade lost?  (Why not?  :>  )
>
> I think the example you're trying for is that you run a word processor service
> and that I'm a client.

Yes.

> I'm typing into a document using /WordProcessor25/
> (which I think of as /WordProcessor/).  You want to upgrade to
> /WordProcessor29/ while I'm typing right here.

I want to upgrade.  *When* is a separate issue.

The point I am making is that you *can* upgrade /WordProcessor/ and
not lose the "work in progress" -- even if it has been sitting on an
offline floppy for 2 years -- BECAUSE THE NEW WORDPROCESSOR KNOWS
HOW TO UNDERSTAND THE STATE STORED BY THE OLDER VERSION.

(i.e., yet another "upgrade strategy")

> In this case, perhaps in most cases, there's some point where the system can
> save its state as a checkpoint, start the new software and continue.  If the
> system can do the change between user inputs, the change will be transparent.
> The case where the inputs come too fast is where it gets tricky and you may
> have to keep a copy of the old code running.

Again, the system can't know how the service behaves or how its clients
expect to use it.  So, you can't *impose* an upgrade strategy on the service.
Instead, you provide mechanisms that allow many approaches to be used and
count on the designer/maintainer to use their specific knowledge of the
service (THEIR service!) to decide which of them to exploit.

Part of installing the upgrade "software" is the specification of the
upgrade strategy mechanism to be used -- along with any ancillary
requirements FOR THE UPGRADE.  Make it easier for developers to
do what they "should" instead of forcing them to do ALL of the
heavy lifting (which would tend to result in more "please reboot, now"
scenarios)

What I've been doing (since Friday evening) is codifying the different
strategies and drafting guidelines for when each is "preferred" along
with when each is contraindicated.  Then, I'll sort out the consequences
of a developer incorrectly specifying the "wrong" strategy/mechanism;
or, incorrectly implementing it in their upgrade:  how might this
screw up other aspects of the system and what can I do to guard against
that.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-20 16:05 -0700
  Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-20 16:11 -0700
  Re: Dynamic upgrading/Hot-swapping a service upsidedown@downunder.com - 2017-04-21 10:45 +0300
    Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-21 10:43 -0700
      Re: Dynamic upgrading/Hot-swapping a service upsidedown@downunder.com - 2017-04-21 23:06 +0300
        Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-21 17:51 -0700
          Re: Dynamic upgrading/Hot-swapping a service upsidedown@downunder.com - 2017-04-22 14:09 +0300
            Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-22 08:55 -0700
              Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-23 13:01 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-23 10:52 -0700
                Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-24 10:48 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-24 12:33 -0700
                Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-24 22:02 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-24 21:37 -0700
                Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-25 12:19 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-25 13:54 -0700

csiph-web