Hi Sue, My comments/questions on the notes posted. I tried not to repeat the comments already given. If I have, point me to the answers you may have already given.
Scenario 2: > We can have more than one service with global scope, but they need to use > same ai image. > Do we want more than one service to be associated with one image? > It isn't clear to me what this means. I thought we could have only 1 service per architecture with global scope. Is this what you mean? nothing in the scenario indicates that we have multiple AI servers. And, why wouldn't we want multiple services associated with the same image? Scenario 5: > How do they indicate that this service isn't global? > Global service should always have standard name. If name is passed as > parameter > to create-service command, new service not set as global. > Isn't the specification of the global service really about the dhcp setup, not the service name? So, why would we enforce a naming scheme on the global service? Maybe we have an option that indicates 'global' so that the name isn't the indicator. We have indicated that we will detect collisions when a user tries to setup multiple global services by looking at the dhcp server, right? I am not sure we need to enforce a naming convention if we can detect collisions this way. In this specific scenario the global service is on the 'corporate' subnet with the local dhcp server containing a global entry pointing to the ai server on different subnet. So, this dhcp entry is the indicator of the global service, right? Also: > all non-global services require manifest at creation time. So, do global services require a manifest at creation time? Why would we have different requirements for global and non-global services with regard to manifests? A few general questions: 1. Why do we require a global service for each arch? Isn't it possible users would setup services and have client specific setup for those services without a global service specified? 2. You stated: > Non-global service creation requires the user to provide a name, platform, > and manifest. The AI image is optional. Is the ai image optional for the global service? Seems like it could be, if we can find the appropriate ai image. 3. For dhcp setup seems like we need to include in this scenario: > Remote non-AI accessible DHCP server: Neither DHCP IP address > nor IP address range are specified. DHCP macro(s) will be > printed on the console for manual DHCP setup. If the user specifies an ip address we cannot access the outcome is the same. Basically, the user could specific what they think to be an accessible DHCP server address and we determine we cannot actually add macros to it. 4. Is it required that a service have a default manifest defined? I can't quite get that from the notes. 5. In item 5.3 in the summary, you indicate that LIFO is the ordering. I know Dave commented on this but my comment is different. The ordering of manifests served to the client should be based on criteria, right? What I am saying is that manifests should be ordered by criteria specified. The hierarchy of the manifests in a service is dependent on the criteria. If a user tries to add a manifest that has the same, exact criteria as another manifest that is already stored, then they need to know we will overwrite the existing one, or something like that. My point is that manual ordering isn't required. The criteria and increasing specificity of the criteria settings means the client(s) will get the most specific manifest they should get. thanks, sarah ***** > Thanks, > Sue > > > On 06/09/09 11:06, Sue Sohn wrote: >> There will be a meeting tomorrow to discuss user scenarios for the >> service redesign. The following scenarios will be used as a start >> point for the discussion: >> >> http://www.opensolaris.org/os/project/caiman/auto_install/ai_svs_redesign_scenarios.txt >> >> >> >> >> Please allow 2 hours for the meeting. >> >> Here are the meeting details: >> >> AI Services user scenario meeting: >> Wed, 6/10 >> 8am PT/9am MT/11pm ET/5pm CEST >> >> USA Toll-Free: 866-839-8145 >> Caller Paid (Intl): 215-446-3660 >> Participant Code: 9041875 >> >> Thanks, >> Sue >> _______________________________________________ >> 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
