Jack Schwartz wrote: > 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?
Good point. This should have been more generic in saying a defined interface will be provided, not necessarily an API. > How will the users get to this API to add their overriding values? Why would the derivation process want or need to override any of these values? This is all supplemental data given to it about the client. It uses what it wants, ignores what it doesn't. -ethan > > 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 >
