On 04/29/11 09:07 AM, Keith Mitchell wrote:
On 04/29/11 08:56 AM, Ethan Quach wrote:
Hi John, Jack,
On 04/28/11 16:31, John Fischer wrote:
Hey Jack,
Just bringing everyone up-to-speed on what we discussed on IRC and
the phone with
regards to the dmm_upgraded SMF service property.
We talked about the property not being generic enough for reuse with
other potential
new service features. The main problem being that if we have 10 new
features since
the inception of the project we could end up with 10 new SMF service
properties like
the proposed dmm_upgraded property. So we came to the conclusion
that perhaps
a better approach would be to use a version property and then
include a version
variable within service method. For the purpose of the
default-manifest upgrade it
might be called DEFAULT_MANIFEST_VERSION. Then if the SMF service
property version
is less then the DEFAULT_MANIFEST_VERSION the upgrade would commence and
at the conclusion the SMF service property version would be bumped
to being the
DEFAULT_MANIFEST_VERSION thus preventing the upgrade scenario on reboot.
We also talked about adding the new SMF service property to the
server.xml manifest
for the service.
I am wondering if we can push this one level deeper. I.e. place a
version on each installation service rather than on the smf service.
Logic in the smf service can then be agnostic to what the exact
version level actually is, and just acts as the facilitator to ensure
the version of the installadm software on the system and the version
of each service instance mesh.
FWIW, ISIM is planning on doing just that. Jack's code here is more of
a stop-gap, in that regard.
- Keith
Even though John mentioned only SMF-service level versioning, I
implemented versions for both the server (SMF service level) and the
individual AI services.
Thanks,
Jack
-ethan
Hopefully, this makes sense to everyone.
Thanks,
John
On 04/28/11 01:35 PM, Jack Schwartz wrote:
Hi everyone.
Here is a relatively simple code review for some Derived Manifest
project bugfixes.
Bugs fixed are:
7038729 <http://monaco.us.oracle.com/detail.jsf?cr=7038729> Older
default.xml manifests need to be imported
into new default manifest handling
7039251 <http://monaco.us.oracle.com/detail.jsf?cr=7039251> Unit
testing improvements for Derived Manifests
7040405 <http://monaco.us.oracle.com/detail.jsf?cr=7040405>
Manifest Input Module add() needs to always
insert new elements after other siblings with
same tag
7040451 <http://monaco.us.oracle.com/detail.jsf?cr=7040451> Make
slim_source soaktime more meaningful for
Manifest Input Module as it waits for CUD-AI
It addresses upgrade issues of default manifests, improved unit
tests, availability of modules, and a small Manifest Input module
bugfix
Code review is at:
http://cr.opensolaris.org/~schwartz/110428.1/webrev/index.html
Bug reports are all up to date. All is ready to go!
Please review sometime today or early tomorrow (before 10 AM PST)
as I would like to integrate these into 165.
Testing:
Upgrade:
- Verified on both old port-number and new
servicename /var/ai directory formats
- Restarted the system/install/server:default
service after upgrade to be sure there were no
issues.
- Verified handling when default.xml or
directory is missing.
Unit tests:
- Verified the automated ones work with
slim_test.
- Verified the manual one works.
MIM:
- Verified using test case in the bug report.
- Verified with and without differently-tagged
children following the element being added.
Other:
- Verified gate build, proto area, and packages.
Thanks,
Jack
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
