Hi everyone.
The problem statement says near the bottom: "Provide, as an API, a set
of known client attribute values available to the derivation process".
So this means that "default" or overriding values are specified in an
API. Is this really a programming interface, or will it be a file? How
will the users get to this API to add their overriding values?
Has adding overriding values via a manifest (or maybe a profile from
which a manifest will be generated) been considered? This seems like an
intuitive user interface. Missing fields in that manifest, or fields
with a special marker there can then signal to the "value deriver" to do
its thing for that field.
Thanks,
Jack
Clay Baenziger wrote:
> Hi Ethan,
> I think I have a vocabulary problem. Here's how I was envisioning
> the world. How's this compare to your world view?
> We have a base starting manifest, potentially. If we decide to be
> completely free-form (i.e. a program generates a manifest from
> scratch) that's different from what I'd envision as a derived
> manifest; perhaps an external manifest?
> I would see it as I have a static manifest (perhaps for my
> desktop); then I'd have derived manifests (perhaps for my test
> machines); then perhaps I'd have an external manifest with a program
> which iteratively generates manifests to test all possible manifest
> combinations.
> Perhaps this is a different paradigm or vocabulary than what you
> were intending?
> Thank you,
> Clay
>
> On Thu, 28 May 2009, Ethan Quach wrote:
>
>>
>>
>> Clay Baenziger wrote:
>>> In particular, my question was to how vastly different a machine
>>> installation should be from a derived profile. I'm not sure if we
>>> want to have two machines vastly differently installed from one
>>> manifest.
>>
>> When using derivation, we don't have one manifest. We have
>> however many manifest formations the derivation logic could
>> possibly form.
>>
>>> However, this mainly stems from how I would have run my systems when
>>> I was a sys. admin. I would have wanted to define each type of
>>> install I was doing in a manifest and only use a derivation system
>>> for tweaks.
>>
>> In these terms, I would consider the result of each tweak a different
>> manifest then.
>>
>>
>> -ethan
>>
>>>
>>> Thank you,
>>> Clay
>>>
>>> On Thu, 28 May 2009, Ethan Quach wrote:
>>>
>>>> Minutes from Wednesday's meeting:
>>>>
>>>> Attendees: Ethan, Ginnie, Clay
>>>>
>>>>
>>>> Summary
>>>> ----------------
>>>> Agreed on the requirements. The requirements list has been updated.
>>>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/DerivedProfilesProblemStatment/
>>>>
>>>>
>>>>
>>>> Clay had an issue with allowing the decision on whether to mirror
>>>> disks or not to be derivable. It is a requirement for now, but
>>>> further
>>>> discussion needs to be had on why this is objected to.
>>>>
>>>> SVM config removed.
>>>>
>>>> Extensibility was heavily discussed. This is still a requirement,
>>>> but at this point we do not know if it is feasible to provide full on
>>>> extensibility of the list of client attributes that are desired to
>>>> derive
>>>> a manifest from. The level of extensibility supported will need
>>>> to be determined.
>>>>
>>>>
>>>> Next step is discuss solution proposals. Proposals will be sent
>>>> out to caiman-discuss.
>>>>
>>>> Plan to have a reviewable draft of a functional spec out by
>>>> 6/5/09
>>>>
>>>>
>>>> thanks,
>>>> -ethan
>>>>
>>>>
>>>> Ethan Quach wrote:
>>>>> Meeting Wednesday 5/27/09 to discuss derived profiles.
>>>>> Ginnie's and Sanjay's presence requested. All others welcomed.
>>>>>
>>>>> Goals of the meeting:
>>>>>
>>>>>
>>>>> 1. Discuss and agree upon which requirements we will address
>>>>> from list here:
>>>>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/DerivedProfilesProblemStatment/
>>>>>
>>>>> 2. Next steps - solution proposals, functional spec. Who will
>>>>> be doing what?
>>>>>
>>>>>
>>>>> Meeting logistics:
>>>>> -------------------------
>>>>> Wednesday 5/27 10am PT / 11am MT / 1pm ET
>>>>>
>>>>> Duration: 1 hr
>>>>> US Toll-Free: 866-839-8145
>>>>> Caller Paid: 215-446-3660
>>>>> Acess code: 8264768
>>>>>
>>>>>
>>>>> thanks,
>>>>> -ethan
>>>>> _______________________________________________
>>>>> caiman-discuss mailing list
>>>>> caiman-discuss at opensolaris.org
>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>> _______________________________________________
>>>> caiman-discuss mailing list
>>>> caiman-discuss at opensolaris.org
>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>>
>>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
