Hi Frank, Sorry for the delay in responding, I wanted to understand how we currently serve manifests based on criteria today so I was looking around in the code. My answers below... > > 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.
Ok, thanks. >> >> 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. Ok, but as Sue pointed out we can remove the standard manifest from the service later? So, that the service doesn't always return a manifest? >> >> 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. > In the example you give above, the disk size isn't criteria, it is AI manifest specification for target selection. However, I can see where we might get some ordering issues if multiple criteria were specified that matched a client. Right now that could be a combination of memory size and address range criteria(based on current implementation). It looks like, in looking at the current AI webserver code, that we don't allow multiple manifests to be published that have overlapping or the same criteria. Overlapping ranges for the currently supported range criteria, is the current 'overlap' check we do. We also publish manifests with the criteria specified and fill in NULL values for those that are not specified for a particular manifest. During AI processing on the client side, it asks the server for the list of criteria the server is interested in from that client. The server provides a list of criteria used(actually non NULL values) for that service to the client. These non-NULL criteria could have been published with independent AI manifests. If the client returned criteria values that matched both of the published manifests, it seems like we would get the 'default' manifest returned to the AI client, since the manifests published were published with separate criteria. That is a match on the 'AND' of the criteria requested from the server would not match. (I believe this is the way the code currently works). For the legacy jumpstart code we use the rules file, and the user must set the rules in an order that works for them. The first rule found that matches is used for a client. So, in general, users create more specific 'rules' first in the rules file, and then they get more general from there. Jumpstart 'rules' are analogous to criteria in AI. What I think we need to consider with regard to order of manifests returned to a client is the criteria specified. We currently limit the ability of a user to specify any of the criteria fields with the same values for multiple manifests we publish to a service. So, if I wanted a manifest that served a mac address range and then another one to serve that same mac address range and with a memory criteria requirement, I cannot do that. If we allowed this 'nesting' of criteria, that would help us ensure the correct ordering. The most specific criteria would always be chosen. I think that enforcing a numbering system isn't the way we want to look at solving the issues we currently have. The criteria is intended, in my mind, to allow users to specify which manifest is chosen for a specific client. Much like the legacy jumpstart rules file. I should be able to as a user publish multiple manifests for a service, each one with more specific criteria, which might include a piece of the criteria that was used for publishing a prior manifest. Essentially, there would be a hierarchy of criteria with associated manifests for searching. The ordering is then set by the user based on how they publish manifests and the corresponding criteria. We still could have the issue of disparate criteria that the client matches on and it seems to me we would use the first criteria matched in the DB, which would have been the first one published. So, an ordering is provided by the order of publication. Does this make sense? thanks, sarah
