On 02/10/10 04:40, Jan Damborsky wrote: > Hi Ethan, > > (CCing c-d, since we have started to discuss design) > > > On 02/ 9/10 06:58 PM, Ethan Quach wrote: >> >> >> On 02/09/10 06:58, Jan Damborsky wrote: >>> Hi Sarah, >>> >>> >>> On 02/ 9/10 03:20 PM, Sarah Jelinek wrote: >>>> Hi Jan, >>>> >>>> The answer is yes and no :-). >>> >>> I like that one :-) >>> >>>> I need you and your team to define the relevant tags/data/attributes >>>> that are required to specify system configuration in the AI sysconfig >>>> manifest. However, it is partly in the scope of my work since I am >>>> looking at possibly changing the schema we use from relaxNG to another >>>> type that might help us more with extensibility and versioning. So, >>>> the decisions I make will affect how we specify the sysconfig data. >>> >>> I see - it is good to know that nothing is set to stone at this point. >>> We have relatively good vision what configuration parameters >>> we would like to support for purposes of the installers: >>> >>> * user account >>> * network configuration >>> - static IP >>> - DNS naming service >>> - hostname >>> * locale >>> * timezone >>> * keyboard layout >>> >>> There are dependences which might affect the final list (e.g. zones), >>> but I assume those might be addressed later when we come to agreement >>> on requirements, since I assume that the design will allow to extend >>> list of supported config parameters (mapped as XML entities) once >>> new requirement is identified. >>> >>> >>>> >>>> Please put together the proposal, in the current schema format. >>> >>> I will do this. >>> We currently use RelaxNG for AI portion and commented out >>> DTD for configuration parameters. Would you prefer RelaxNG in order >>> to be consistent with AI portion of the manifest ? >>> >>> I feel that it might make things easier for user and for us as well >>> if we consolidate and stick with one type of XML schema across >>> all install technologies. Just curios, is this planned or are we >>> considering to use multiple XML schemas ? >>> >>> >>>> If the decision is to change the schema type we use to something else, >>>> we will need to revise your proposal to fit the new schema syntax. >>>> What is important, to me anyway, in the definition of the sysconfig >>>> schema(besides the tags, etc.. defined in the schema) is to articulate >>>> what values are required, what are optional, what are the scenarios in >>>> which we have the AI client semantically understand what is specified. >>>> We can chat by phone if this isn't clear. >>> >>> I would prefer to talk on the phone about this for a while >>> in order to clarify. I have to leave early today, but I am available >>> any time We-Fr (modulo meeting marathon on Th and 1:1 with Dana >>> on Wednesday 6am PT). >>> >>> >>>> >>>> I do have a question for you.. would using DTD as our schema language >>>> help you at all in defining and implementing the system configuration >>>> functionality in AI? >>> >>> The answer is yes and no :-) It depends on how much we would like to >>> involve the Automated Installer in processing the system configuration >>> manifest. >>> The extreme which we were initially considering was just to take >>> sysconfig manifest and directly apply it as an SMF profile without >>> any processing. In that case, we would need to use DTD, since >>> SMF profiles use DTD XML schema. >> >> This was my assumption of what we were going to do. With this >> approach, the set of possible configuration is automatically >> extensible based on whatever is supported as configuration in >> SMF service properties going forward. >> >>> I am in process of thinking about this and I feel we would like to have >>> installer involved in this process - e.g. for syntactic and semantic >>> validation. In this case, chosen XML schema is less important. >> >> We had requested the ability to syntactically validate a given SMF >> profile, and they'd already provided that -- "svccfg apply -n >> <profile>" -- >> with the eSMF profiles work PSARC 2009/371 >> >> There are still limitations to this because if we try to validate the >> file >> on the server, it is perhaps incomplete since a server could be >> running a different release of Osol than what is being installed. >> However, the install environment should be able to syntactically >> validate the file as well. >> >> These were just my thoughts/assumption on the matter. Jan/John, >> if you've thought about other reasons/aspects regarding this, lets >> discuss. I haven't really thought through the possible negative >> consequences of just making the "sysconfig manifest" an SMF profile. > > Thinking about this, I can see there might be some disadvantages > of this approach - however, it is to be determined if they are important. > > * since the client would apply given SMF profile without being involved in > processing it, I agree that it would easily allow to extend set of > supported > properties without need to modify the installer. > On the other hand it would means that any SMF property (not only those > considered as Sysconfig parameters) might be unconditionally set > on installed system via Sysconfig manifest. Not sure if this might be > considered as potential security issue. > > * Only syntactic validation of sysconfig parameters would be done before > first boot. If any parameter is semantically invalid or not applicable > to the installed system (e.g. invalid NIC name), it would be recognized > during first boot when particular SMF services would apply the > configuration > which might not be considered as good user experience. > Not sure how much we would like to involve the installer into this - > in current installer we at least validate settings for user account, > I can see more validation might be possible. > > * user would need to remember appropriate services & SMF properties to > configure > particular things which might not be considered as user friendly. Also, > since some > of those properties will be private to the installer, it might not be > appropriate > to expose them to the end user. > > * Support for dynamic/derived manifests might not be possible on client > side. For instance, some network parameters might be dynamically > determined by client - e.g. > - NIC name set to name of boot NIC > - static IP set to the one obtained from DHCP, ... > > > Based on this, I am thinking about alternate approach > > - unify AI & Sysconfig XML schemas and define new set of XML > tags for supported Sysconfig parameters > > - installer then would transform parameters obtained from sysconfig > manifest to appropriate SMF profile. During that operation, it could > > * derive some parameters if desired > * semantically validate Sysconfig portion of manifest (syntactic validation > would be common for AI & Sysconfig if provided in unified XML file).
Couldn't the installer just specially do these two things for the set of parameters that it cares about? In other words, instead of defining a set of supported sysconfig parameters to be exposed through a sysconfig manifest file, could the installer just grok/process for them from a superset of configuration given through an smf profile? This processing can do those two points you describe above, but only on the set the installer cares about. Everything else gets "passed through" (perhaps just syntactically validated) so we still get a form of extensibility. The special processing can also inject any private properties needed. It just seems that if we need to define for the installer to know about some special set anyway, what is the advantage of defining for those values to come from an installer specific "sysconfig manifest" vs. from an smf profile? > > The disadvantage of this approach is that whenever new Sysconfig parameter > would be introduced, installer would need to be modified accordingly - > at least new entry added to the dictionary which would serve to transform > particular Sysconfig parameter to SMF profile. This was also a disadvantage with sysidtool(1M), which is what steered us to look at a more extensible approach. -ethan > > We would also need to design appropriate module for these tasks. > However, part of the design will need to be done anyway for cases > when we need to generate SMF profile from Sysconfig data provided > in different format than XML - e.g. for purposes of interactive > installers. > > >> >> >> Reason why this is important is because of the manifest simplification >> design. We need to sort out how we're going to be handling the >> "sysconfig manifest" -- as a separate file?, etc. > > > I think we can still allow to provide sysconfig manifest as separate > file (as we do for now), but if desired, AI & Sysconfig manifest could > be passed as one valid XML file if we unify AI & Sysconfig schemas. > > Thank you, > Jan > > >> >> >> thanks, >> -ethan >> >>> >>>> Since I am not sure how you plan to take the eSMF profiles and apply >>>> them for system configuration I thought I would ask. If you have any >>>> data, even a preliminary proposal for this, can you forward that to me? >>> >>> The proposal is currently not available, I am currently >>> in process of sorting things out. I will try to summarize >>> what I have in my mind and will get back to you with this >>> data. >>> >>> Thank you very much, >>> Jan >>> >>> >>>> >>>> thanks, >>>> sarah >>>> **** >>>> >>>> On 02/ 9/10 06:27 AM, Jan Damborsky wrote: >>>>> Hi Sarah, >>>>> >>>>> I am currently working on sysconfig project and as a part of >>>>> the effort, I am trying to identify dependencies. >>>>> >>>>> As far as Automated Installer is concerned, Sysconfig >>>>> manifest represents API users will consume to express >>>>> the desired post install configuration. >>>>> >>>>> Since AI is also the first candidate to be enhanced, I would >>>>> like to put together proposal for final format of Sysconfig >>>>> manifest. >>>>> >>>>> I can see that you are assigned to AI/DC manifest rework >>>>> project - I would like to check if/how it covers Sysconfig >>>>> manifest - is it considered as part of this effort or is it out >>>>> of scope ? >>>>> >>>>> Thank you, >>>>> Jan >>>>> >>> >
