Hi Sue.
On 06/25/12 04:27 PM, Sue Sohn wrote:
Jack,
The changes look ok.
Did you run unit tests?
Yes. No regressions from slim_source. (I skipped the module that
deletes the stuff from /system/volatile.)
You should add a comment to the original bug to indicate that the fix
was removed and mention that it will be handled by the new bug (or
alternatively write another bug similar to 7091202) and cross reference.
I added comments to 7091202.
I filed bug ID
7179350 Cleanup AI manifest criteria validation
to fix this in the next release.
Thanks,
Jack
Sue
On 06/24/12 02:38 PM, Jack Schwartz wrote:
Hi everyone.
Here is a code review for:
7178811 installadm create-manifest fails when mac criteria is specified
http://monaco.us.oracle.com/detail.jsf?cr=7178811
Please review:
https://cr.opensolaris.org/action/browse/caiman/schwartz/7178811_1
Testing is listed in the bug report. Also checked pep8 and pylint.
This bug manifests a larger problem, for which there is not enough
time to solve correctly right
now, but restores previously working functionality. Read on for the
gory details...
=====================
AI manifest criteria validation pandoras box was opened when I pushed
a change for:
7091202 installadm create-profile needs better messages for
invalid criteria
Currently criteria is validated against the only RelaxNG schema we
have in our gate. It is then massaged into the form it is stored in
an AI database. This is redundant; perhaps data can be validated as
it is massaged. It is inconsistent with the rest of the install
tools, which do not use RelaxNG schemas. Many of the values just
pass through the schema as strings with a kind of no-op validation.
IMO this can and should be cleaned up.
... but not now. We are in the last non-stopper build. There is
lots of testing needed, since we need to account for criteria
manifests as well as criteria specified on the command-line. There
isn't enough time to do it right, right now.
I have opened bug:
7179350 Cleanup AI manifest criteria validation
to do this in update 2.
7178811 was caused by the fix for 7091202. The breakage was due to a
switch in the order of processing criteria: I switched massaging the
data before doing validation. (My testing missed a case which
7178811 brought out.) For now, I'll recommend restoring the original
order as it is low risk. Messages will largely be as they have been
(memory still gets more checking), but all else should work as it did.
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
