Quoth Tom Whitten on Thu, May 17, 2007 at 11:43:08AM -0600: > Immutability - 1st two sentences > "The proposed upgrade procedure calls for upgrading > developer-delivered profiles by replacement. For administrators who > place customizations in such a profile, this will result in a truly > lousy experience." > > Why would administrator customizations go in the > developer-delivered profile? Shouldn't they go in the local > profile? Perhaps, you are saying that making a profile immutable > is the way to enforce this behavior.
Right. Administrators may need to put customizations into specific profiles, but if they accidentially wander into a developer-delivered profile, that would lead to problems. And that's a beartrap we can proactively eliminate. > Conditional Configuration > - How are conditions defined? Abstractly, they are entirely up to developers. Concretely, we'll provide libscf interfaces for developers to create condition objects and set their values. In the future we'll provide a packaging interface for developers to deliver condition objects, and ideally a way to specify how their value should be determined (though I think they would still be settable through libscf). > - How does SMF (startd?) know when conditions change? A condition value changes when a developer informs SMF that the value should be changed. If this results in the naive view of configuration changing, then clients will be notified. svc.startd will be notified by a private event mechanism, and svc.startd will notify services by their refresh methods. > - Really don't like the idea of hard coding conditions into > svc.configd. Developers in non-ON consolidations would have a > hard time creating conditions. I agree. It's essentially a time concession. I think it's reasonable because I think most developers won't need to make conditions. > Conditional Profile Order: > - This section is difficult to understand. Some examples would be > helpful. Ok, we'll add some examples, and maybe some diagrams. > Also perhaps a little more detail on "will provide a > mechanism for condition developers to declare mutual exclusivity" > and why it would be useful. Ok, we'll work on that. The "Conditions" section of "2.3 Details" should help for now. > Secure by Default: > - I agree that the netservices command should remain. It is so > easy to use and hides all the complexity of making the > transition. It appears to me that manipulating profiles is going > to be so difficult to comprehend that it should only be done with > tools that hide the profile complexity. Right, though I think in the end secure by default should be handled through an NWAM-aware GUI. For example, when you create the "home" network environment, you could choose between "enable secure network services only" and "enable traditional network services (less secure)" or something. > Profiles: > libscf Interface: > - An example of "negative entry" would be helpful to me. > Alternatively, perhaps you can show one on the diagram. Also, > how does the administrator create negative entries. Ok. I'm not exactly sure how this should be represented in the interface. It'll be... strange. > Administrative Features: > - It may be handy if the "profile list" and "property in profiles" > commands would contain an option to tell which authorizations are > necessary to make changes. I say this, because the administrator > can no longer just look at the manifest to make that > determination. Ok. > - Other tools that might be handy: > o list condition values Right. > o tool to help determine which predicates are being > evaluated in the decision to activate a given profile. > Since profiles, precedences and inclusions all have > predicates, the picture can get complicated Hmm, true. > o Is punch-through active? Right. > Service implementation: > - "Services which disable themselves when they determine they > shouldn't run should instead employ conditional configuration." > > The conditions for whether or not a service should run may be > more complex than can be represented by conditions and > predicates. This is especially true if the conditions are hard > coded in configd. Well if a developer is capable of delivering his own condition, then he should be able to make it as complex as he wants. I think hard-coding is only a hurdle for developers outside of Sun, but that's why we're calling for a follow-on project for that. > General comments: > Once all the levels have been introduced, it would be good to have > a level summary. For each level it would be handy to have the > following information in the summary: > - How does it get populated? > - Can it be modified? If so, how? > - Is it conditional? > - Is it modifiable by admin? Via svc* commands or > indirectly via a special tool? > - any other special characteristics, > e.g. punch-throughable, immutable, etc. Ok. I think we can expand the "2.2.6 Profile List" section for this. > Can new levels be created on the fly? From my reading of the wpad > use case, it looks as if they can. New profiles can be created and activated on-the-fly, yes. David
