http://defect.opensolaris.org/bz/show_bug.cgi?id=11385
amaguire <alan.maguire at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ACCEPTED |CAUSEKNOWN
--- Comment #2 from amaguire <alan.maguire at sun.com> 2009-09-16 08:10:14 UTC
---
(In reply to comment #1)
> This is due to the fact you switched from a conditional activation mode (where
> no enabled property is used) to manual (where an enabled property is used).
> Problem is, even if you tried to set the "enabled" property, you can't IIRC,
> since it's viewed as special, and can only be set by the netadm user. The same
> problem occurs when switching a prioritized NCU to a manual one. It doesn't
> happen for locations since we always create the enabled value for them, even
> in
> conditional/system activation cases.
>
> A possible solution would be, on ncu/enm creation, to always create the
> "enabled" property, setting it by default to "false" (as we currently do for
> manual ENMs) for all activation modes. The property would be ignored for
> conditional/prioritized activation when those activation modes are in effect.
My mistake, the problem is actually in nwamcfg:
2545 /* Rules for ENMs */
2546 static prop_display_entry_t enm_prop_display_entry_table[] = {
2547 /* show conditions if activation-mode == conditional-{all,any} */
2548 { NWAM_ENM_PROP_CONDITIONS, NWAM_ENM_PROP_ACTIVATION_MODE,
2549 { NWAM_ACTIVATION_MODE_CONDITIONAL_ALL,
2550 NWAM_ACTIVATION_MODE_CONDITIONAL_ANY, -1} },
2551 /*
2552 * enabled is a read-only property that goes with activation ==
manual.
2553 * and cannot be set by nwamcfg. However, it is listed here so
2554 * that if the activation-mode is changed from manual to something
2555 * else, the enabled property is deleted.
2556 */
2557 { NWAM_ENM_PROP_ENABLED, NWAM_ENM_PROP_ACTIVATION_MODE,
2558 { NWAM_ACTIVATION_MODE_MANUAL, -1 } },
2559 { NULL, NULL, { -1 } }
2560 };
2561
(...and the enabled prop is treated similarly for ncus).
When we switch to conditional activation mode, the enabled property is deleted
via delete_skipped_props(). Then when we switch back to manual activation mode,
validation fails since this required property is missing.
I suspect a similar issue applies for activation-mode prioritized and the
priority-group/priority-mode properties - if we start with a prioritized NCU,
switch it to manual and back to prioritized we're going to be missing the
priority group/mode properties.
I think we need an nwamcfg solution whereby the prop_display_entry_table has an
additional field for a default value. Then for every value that is is deleted
(e.g. NWAM_ENM_PROP_ENABLED), when we switch the value to be one other than
those on the list in the prop_display_entry_table, we set the value (in this
case "enabled" back to the default). Thus we re-add deleted properties.
So adding a function as follows would fix these issues I think:
/*
* Adds any property that must exist because of the value of some other
* property, undoing the work of a previous delete_skipped_props().
* For example, enabled should exist if the activation-mode is manual.
* Similarly, priority-group and priority-mode should exist if the
* activation-mode is prioritized for an NCU. For these entries, if
* the property does not already exist, we set it to a reasonable default.
* For some properties (e.g. ipv4-addr for a static ipv4-addrsrc, there
* is no reasonable default so we simply do not set the property, letting
* validation fail, as this reports the missing member. If a default is
* not specified, we know not to set the value.
* This function uses the *_prop_display_entry_table[] to determine
*
* This function is called from set_func() and *_wait_input() after
* nwam_*_set_prop_value() succeeds.
*/
void
add_skipped_props(prop_display_entry_t *display_list, nwam_object_type_t
object_type)
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
