Hi Sarah,
Comments in-line.
Thank you,
Clay
On Thu, 28 May 2009, Sarah Jelinek wrote:
> Hi Ethan,
>
> I have some comments/questions:
>
> In the requirements list:
>>
>> * Allow derivation process to arbitrarily get rules from some
>> external source (external to the AI server, e.g. a database, cmdb).
>>
>
> -What is the purpose of this? What types of rules do we envision might come
> from an external source? I know we talked some about this last week, so I am
> wondering if in subsequent discussions you all came up with use cases that
> provide support for this requirement.
The thought is that data might be derived out of something like a CMDB
(configuration management DB) for example at a large site like
Network.COM, while some admins may use something more simple like our test
lab which used to have machine location in a comment in the NIS maps.
> -Should we allow supporting of specification of a software payload that may
> not be IPS? The requirement says "i.e. the packages to install". Which I
> interpret as 'that is'. So, it seems like we are limiting the payload to be
> packages only. Is this the intent?
>
> -It isn't currently listed that we want to support deriving non-disk targets
> to install onto. We can derive disk setup, and derive which disk to install
> onto, but the more general requirement here, I think, would be to say we will
> support deriving which target to install onto. This is something I can
> imagine would be needed for replication and recovery.
I'm not sure I follow what you mean by installing to a non-disk target.
Do you mean installing to a VM or a replication archive?
> thanks,
> sarah
>
>
>
>
>
>
>> 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
>
