Hi Sarah.
On 06/17/09 08:44, Sarah Jelinek wrote:
> Hi Jack,
>
> I cannot attend today's meeting. I do have some thoughts about this
> topic which I have included below.
Bummer that you couldn't attend the meeting. Thanks for making your
thoughts heard. My replies are inline.
>
>> Hi everyone.
>>
>> I am calling a meeting tomorrow regarding AI manifest organization.
>> We need to discuss the structure of the files again in a context of
>> scalability and a compelling user experience.
>>
>> I request that those people explicitly addressed attend, others are
>> most welcome as well.
>>
>> Meeting logistics:
>> 14:00 - 16:00 PST (2 hours, just in case)
>> Toll Free Dial In Number: (866)545-5227
>> Int'l Access/Caller Paid Dial In Number: (215)446-3648
>> ACCESS CODE: 7385082
>>
>> The main issue is that the functional spec defines two or three
>> files, in two different formats, and that the user will probably have
>> to edit them to set up an installation. How to simplify this from
>> the user point of view and make this a more compelling experience?
>> How to set the files up to make it as easy for a first-time
>> one-system user as for an admin of a large lab with many different
>> groups of systems?
>>
>> We have many factors to consider.
>> - One hard constraint: The System Configuration (SC) manifest must be
>> a DTD to fit as an enhanced SMF profile.
>> - We can't rely on existence of GUI tools to set up the files.
>> - We don't want to have the contents of the SC manifest specified in
>> another schema format because we don't want to make users learn two
>> different formats for specifying the same data.
> If we have a hard constraint that the SC manifest be a DTD, and we say
> we don't want the contents of the SC manifest to be in a different
> schema format, seems like conflicting requirements. Although, I don't
> know how hard a requirement the statement above is.
Today I realized that, under the covers, we can pull apart a manifest
which has all three sections (including an SC manifest portion) before
validating any of the sections, so we can place all three sections in
one file.
>
> I think it is desirable, as much as possible, to hide the details from
> users with regard to the SC manifest contents. Although, anything we
> do to manage this means we track any changes in the SMF enhanced
> profiles schema. Someone has to track the changes I suppose, just a
> point to think about.
We discussed today the usefulness of a tool not just for SMF setup but
for everything, and we will recommend that as a future enhancement. We
also discussed a tool which could export a running system's SMF
configuration to a file. Should such a tool be developed, the file
structuring will be ready for it. Being that we can't count on a tool
for now, we are focused on the files and their relationships for now.
>
> I think the real issue is not the schema definition that is different,
> imo, but that if the users have to manually edit and provide
> individual SMF enhanced profiles for every SC entry, it could be
> cumbersome. What is the intended delivery mechanism for any SC
> manifests users want for installation? I mean is this something users
> must provide or is provided by other groups who own the piece of SC
> functionality?
>
> If it is part of the standard OpenSolaris service definitions,
> couldn't we provide a way for users to override the settings that are
> defined in these enhanced profiles via our schema?
The SMF profile (except for a couple of header lines specific to DTDs)
is XML like the rest of the manifest. The main difference is that it is
validated via a DTD vs a RelaxNG schema.
Being that the SMF profiles are XML just as the rest of the AI manifest
is, it would be all the same to the user to modify the SMF profile
directly rather than do it in another part of the manifest.
>> - RelaxNG schema is much easier to read and work with than DTDs.
>>
>> Agenda:
>>
>> Let's start with a few minutes (really) to discuss broadening the
>> problem statement and set the tone. I'll suggest the following to
>> start things:
>>
>> "AI manifest structure and organization should be easy to use and
>> understand, and scale to a wide variety of installation environments."
>
> It wasn't clear to me in yesterdays discussion why we would have 2
> manifests in the simple case? I thought the 'standard' manifest would
> be only one manifest, with no sysmap pointer(the pointer would be
> null). The SC stuff could be embedded in the standard AI manifest and
> something users could modify if they wanted. The AI manifest is then
> embedded in the sysmap manifest. Is this not the case?
The terminology isn't quite accurate, but after the meeting today, it
changed again anyway. It is simpler now. One manifest with three
sections: criteria, installation, configuration. Either or both of the
latter two sections can be populated with data, or a pointer to a file
containing the data.
>
> I think the proposal you have currently works very well in the
> 'scaling to a wide variety of systems'.
Thanks. We kept the option of having pointers to files to those last
two sections for scalability.
>
> One thing we have talked about is making it easier for users to use AI
> out of the box. To setup services and understand what the client
> behavior will be. Is simply making the manifest(s) easier to edit a
> possibility to ease the learning curve? Do we know of an XML editor
> that might be useful for this?
We thought that having many files and incomplete examples would make it
harder for users to learn.
We will be proposing working examples for a single, self-contained
manifest; and a manifest with pointers to files containing the
installation and configuration sections. These will be fully commented,
and list all fields to serve as an example. They will also work - out
of the box. Users can start with these and tweek them as needed.
I'll be posting meeting minutes tomorrow and a revised functional spec
as soon as I can.
Thanks,
Jack
>
>
> thanks,
> sarah
> ****
>
>
>>
>> Then we'll move into discussing what our options are to solving this
>> problem.
>>
>> Thanks,
>> Jack
>>
>> P.S. I'd like to leverage what we already have, at:
>> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.6.pdf
>>
>>
>>
>
