Hi Ethan,
On 02/11/10 08:02 AM, Ethan Quach wrote: > > > 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. Yep, you are right. We could do that. > > 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? In this case, the only pros I could think about are * we could define namespace which would be easier to manipulate/remember for user * we could encapsulate private interfaces (some SMF properties will not be public) > >> >> 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. I see. I was not aware of how much extensibility is important. If it is high priority requirement, I agree that we should use SMF profiles directly as Sysconfig API. Thank you very much for your comments, Jan
