Hi Sarah, After discussions with Sue, I'll take Scenario 5 and question 5. Sue will answer the others...
Sarah Jelinek wrote: > 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 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? Correct. In a situation where a WAN-based AI server supports a network with multiple DHCP servers, there really is no global service in the AI server administrator's view, so a naming convention is inappropriate. I'm revising the user model. > > 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? All services require a manifest at creation time. If the user doesn't specify a manifest, the standard manifest would be used. > > A few general questions: > > > 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. I disagree. Given two manifests, one with the criteria "disk greater than 30GB" and one with the criteria "RAM greater than 5GB", which manifest would be selected for a client that has a 40GB disk and 8 GB of RAM? Given many manifests, each with its own potentially complex set of criteria, a user would not be able to consistently predict which manifest would be selected. I believe that a simple ordering of manifests and "first match" approach is much more predictable and manageable. Frank > > >> 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
