Hi Jan, Comments below... > 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.
I agree we could do syntactic validation of the SMF profile, but the question is do we want to? What do we do if the profile doesn't validate? Also, Ethan and I were talking yesterday about this and it seemed possible that we might want to apply a specified system configuration parameter, such as networking, before we apply the full profile to the altroot. The user may want the network settings to take affect immediately. In this case, we would need to pull out the specification for say netwoirking, apply it in the microroot, or apply the whole eSMF profile to the microroot. Of course, we need to understand what the possible implications are of applying system configuration in the microroot. > > * 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. > I think the interface we want to export for system configuration is the SMF DTD. We don't want to be in the business of statically defining tags in the AI manifest and then having to update them as more services become configurable via this mechanism. I think passing this off to SMF is the most extensible way for us to manage this. > * 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, ... > > Why would this inhibit the ability of derived manifests? I am not seeing the issue. Can you clarify? > 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). > > 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. > exactly. I don't like having to manage this data in this way. > 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. This is certainly true, but the difference is in AI we have a way to bypass the middle layer and simply allow the user to specify the configuration data in an eSMF profile. It makes the schema easier to manage and certainly means that we won't have to update it do to system configuration changes. The fact that we might have to take user input for system configuration from the interactive install and translate it to the appropriate SMF profile, is easier for us to manage in terms of extensibility, imo. It doesn't require a versioning change for the user interface, unless we introduce a new screen, which really just works when the user uses a new installer. With AI manifest, we have version management to consider as well. thanks, sarah ***** > > >> >> >> 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 >>>>> >>> >
