Hi Ethan.
On 04/29/11 10:09 AM, Ethan Quach wrote:
On 04/29/11 09:16, Jack Schwartz wrote:
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.
Where is the latter being introduced? I would have expected to see a
per-service property somewhere stored for each instance of a service
if it was the case.
See svc-install-server lines 204-208.
Here's one service's worth of svccfg listprop output:
AIai_dmm_test3 application
AIai_dmm_test3/boot_file astring ai_dmm_test3
AIai_dmm_test3/service_name astring ai_dmm_test3
AIai_dmm_test3/image_path astring
/home/jack/ai_services/ai_dmm_test3
AIai_dmm_test3/txt_record astring aiwebserver=solaris:5555
AIai_dmm_test3/status astring on
*AIai_dmm_test3/version astring 1*
AIai_dmm_test3/default-manifest astring orig_default
Thanks,
Jack
-ethan
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
