Date: Thu, 29 Oct 1998 09:12:43 -0800 (PST) From: Bryan Mann <bmann@whistle.com> To: Andrzej Bialecki <abial@nask.pl> Cc: Terry Lambert <terry@whistle.com>, small@FreeBSD.ORG Subject: Re: Unified Configuration Interface Message-ID: <Pine.BSI.3.95.981029090042.13332A-100000@chaco.whistle.com> In-Reply-To: <Pine.BSF.4.02A.9810291441050.20293-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Oct 1998, Andrzej Bialecki wrote:
> On Wed, 28 Oct 1998, Bryan Mann wrote:
>
[deleted]
> > UPGRADE - perform upgrade tasks
> > DOWNGRADE- run downgrade tasks
>
> If I understand you correctly, I'd call this COMMIT and ROLLBACK. I think
> that each object should have space for two sets of its parameters: one
> currently used, and other, currently being supplied. This fits nicely to
> our transactional model, because after you supplied new values, you didn't
> change anything yet - first, you do a CHECK, and then COMMIT. If we assume
> that old parameters are copied back to the "new" buffer, we can also
> perform a ROLLBACK to restore previously used parameters.
>
Hmmm, no I really meant upgrade/downgrade as in a short list of things
that the code might be able to do if told to enter that state like
service manager/bootstrapper says enter state UPGRADE then service does:
a) listen on port 6060 for tar ball
b) after receiving tar ball and md5 checksum check package
c) deinstall old package saving away that copy
d) install and verify new package
e) enter state IDLE or READY
But you are correct we do need COMMIT and ROLLBACK as you have described.
Perhaps it doesn't make sense to think of putting a sub-system/service
in UPGRADE or DOWNGRADE state.
> > MONITOR - to connect for monitoring
> >
> > NOTIFY - out-of-band notification of state change
> > [out-of-band notification means that the client
> > opens a rendezvous point for the server to connect
> > to upon completion of the STATE/object in question]
>
> Hmmm... I wouldn't call them states - they are just one of (many)
> parameters. In this case, if I set a parameter called MONITOR, the object
> hooks up itself to some monitoring agent, but doesn't change its FSM
> state. In fact, if it were to do it, it should be highly undesirable,
> because ti would change its behaviour.
>
> Similarly, NOTIFY is just a hook-up to send events to specified party.
>
I was thinking in terms of bootstrapper/service manager
wanting to know who had MONITORs or NOTIFYs outstanding so
ok I agree. This makes more sense. Then they are attributes.
> > SHARE - actions to be performed when replicating this entry.
>
> Hmph... I dunno I understand this in terms of a "state". This is rather
> an action for specific event.
>
Yes see above. You are correct.
> >
> > EXT_{UserDefined}
> > - user defined extensions but how do you specify
> > where they go in the state machine ?
>
> It depends on how the FSM is built into the given subsystem - I've seen
> some FSM's which simply read their definition from configuration file
> (Merit Radius is such an example).
>
That would be very good.
Thanks for listening.
Bryan.
----------------------------------------------------------------------
Churchill's Commentary on Man:
Man will occasionally stumble over the truth, but most of the
time he will pick himself up and continue on.
(This signature brought to you courtesy of fortune(6) and cron(8).)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.981029090042.13332A-100000>