Hi Sarah, Thanks for the feedback. I am going to respond to some of your questions and Frank will address the others in a separate email.
On 06/12/09 07:32, 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 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? You are correct in that you can only have one service per architecture with global scope. The comment in the notes is incorrect and I have removed it. There was some discussion (not directly related to the scenario) about whether one wanted/needed multiple services associates with the same image. It was decided that there was no reason not to allow that. > 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? My comment was not intended to convey that one must always have global services. It meant that a single global service could not be shared by both sparc and x86, because the service is tied to the image. So if one wants global services, there needs to be one for each arch. It is possible that there could be client specific services setup without a global service and scenario 5 has that situation, with the second ai server. > 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. Yes, the ai image is optional for the global service as well. > 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. If I understand what you saying, you are asking about the case where the user provides a remote DHCP server that is thought to be accessible, but isn't for some reason. I wasn't thinking this needed to be a called out separately, but would be covered by error handling that would print out macros if configuring automatically failed for some reason. > 4. Is it required that a service have a default manifest defined? I > can't quite get that from the notes. At the time of service creation, a default manifest is provided if no manifest is specified. However, there will be a way to remove a default manifest from the service. Thanks, Sue > 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 >
