Analysis for updating the MA

[Marcel Offermans <ma...@luminis.nl>]

Hello devs,

On the wiki I created a document that provides an analysis of how we could design an update mechanism for the management agent, as described in ACE-342 [2]. I would love to hear your feedback on this!

Greetings, Marcel

[1] https://cwiki.apache.org/confluence/display/ACE/Analysis+and+Design+for+updating+the+Management+Agent
[2] https://issues.apache.org/jira/browse/ACE-342

Re: Analysis for updating the MA

[Bram de Kruijff <bd...@gmail.com>]

Hi Marcel,

On Thu, Aug 1, 2013 at 3:48 PM, Marcel Offermans
<ma...@luminis.nl> wrote:
> Hello devs,
>
> On the wiki I created a document that provides an analysis of how we could design an update mechanism for the management agent, as described in ACE-342 [2]. I would love to hear your feedback on this!
>

Just my 2 cents; Although I am sure solution A will work, my
preference would be to go for solution B for reasons of simplicity and
efficiency.

Simplicity because, why have two transport mechanisms if you can have
one? Obviously we can and, as you suggest, must make an effort to keep
the implementations aligned. Still I feel 1 is better then 2 :)

Efficiency because, as you state, a second mechanism requires a second
HTTP call. Leveraging keep-alive (that is what you mean with HTTP
pipelining?) reduces TCP/IP overhead so that is a good idea, but that
has several consequence. First, this requires the agent update to be
on the same schedule as the regular check for updates (which I think
that is good anyway as it limits waking up devices/connections).
Second, we can not guarantee that keep-alive works in all environment
(firewalls/proxies). Third, when using keep-alive we must ensure that
connections are being closed from the target side in a timely fashion
to prevent running out of connection slots on the server fast.

grz,
Bram

> Greetings, Marcel
>
> [1] https://cwiki.apache.org/confluence/display/ACE/Analysis+and+Design+for+updating+the+Management+Agent
> [2] https://issues.apache.org/jira/browse/ACE-342

Re: Analysis for updating the MA

[Jan Willem Janssen <ja...@luminis.eu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/1/13 3:48 PM, Marcel Offermans wrote:
> On the wiki I created a document that provides an analysis of how
> we could design an update mechanism for the management agent, as 
> described in ACE-342 [2]. I would love to hear your feedback on 
> this!

I understand the need for updating the MA, but I'm somewhat reluctant
to create a separate update mechanism for this as stated in option A.
Why should the update of the MA bundle be different than for other
bundles (assuming the MA is running as plain bundle instead of being
embedded in the OSGi framework)? Isn't the whole point of ACE that it
reliably can update bundles inside an OSGi environment using
deployment packages? Why cannot this work for the MA bundle as well?

The negative point of updating "...just the management agent trigger
an update of the target, which conceptually messes up the version
number." for options B & C does, IMO, not hold. It suggests that the
MA is not part of the installed software base on a target, which is
strange because we do want to update the MA in a similar was as the
other installed software. Yes, the deployed software is normally not
affected by an upgrade of the MA, nor is it aware that there is a MA,
but still we would like to answer the question in what version of a
deployment package runs with what version of the MA.

So, in conclusion, I would opt for option B.

- -- 
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814

/My world is revolving around PulseOn and Amdatu/

Luminis Technologies B.V.
J.C. Wilslaan 29
7313 HK   Apeldoorn
+31 88 586 46 30

http://www.luminis-technologies.com
http://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR/2A2AAoJEKF/mP2eHDc4le4P/0mGeJ6E0BJmwCxkvsU4OiZ9
r7BUlZqHk7ghI68Z9LStaV1FrA5QSZsVEdauVtSto27r5oylEXibVC+qz3YWSIxn
m5CFkA8Gr/JSSEyAsbK0OdfRDYZKsHTtuWLmokijjxsuOJteOMtuslzG0qxEgbDD
I2W/wbjwyU7bo9X9cR4HO2udvA1PI44GefaiH1KAsBbFDNld3NBpGf/krav9nXzw
U8CdJAtleMBHEO03UBGNfXvlUdxhsvDOYSkg2oUirtbaA93qr5m+eX/asYnb/AJI
joyCzNDeBFur2q7cckNmH8rYXCWJx2GWbPKTMINVvPpMCFuh5GN8vFK5CKtFFluc
ZL3ddE5e0MtaXTfJq0dGP1BQA/lup6uBEh2LVErEFnyauN2tWjXi0gxs4PrOhvT4
gJClq0U35aZddk/FwPTrlFacspvxstTgE+luGWo/qZhF6be9+SSmA9lNO7L3sBIW
sQjgDK9DOx6yjZBmp6w/FKyz33H3qfeIdDIg/iLvd2B30NHgXpBznmazbjykgNIO
/pPvwvNacBmnYn6DvXX4m1dzcB15g9ubs9A+FxNHcuS0RQ0pP0njJXccs8shykml
3nCoeAqT6VslLhoLk6/r+qqiQYHHMQwIxbwg8P9hrv6T41NjFxg5fFjZlAyrxrut
8Fv50gwRxUBtPQAB/X3S
=BhDH
-----END PGP SIGNATURE-----