Keith Mitchell wrote: > Hi Sarah, > > I have a few pennies to throw into the thought pool - see below. > > Sarah Jelinek wrote: >> 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? > That makes sense. I just spent a good 10 minutes coming up with a > counterpoint, before I fully understood your point about the nesting. > Explicitly setting the ordering means a user could inadvertently set > the broad-case scenario before the narrow-case scenario. In the > example above, if the address range criteria were explicitly set > first, then the address range + memory criteria would never get hit. > > As a secondary note, I don't think the order of publishing should have > an effect on the order in which disparate manifests are considered. > That type of user interface requires un-publishing and re-publishing > if the user ever wants to change the ordering, which doesn't sound > particularly "compelling" to me. > I believe that we will propose a simple user-controlled list-based ordering for manifest selection, i.e. the criteria are checked, one manifest at a time in the user specified order. When a match is found, checking ceases and the matched manifest is returned to the client. There is no attempt by the system to compare the criteria specified in each manifest and order the evaluation based type and number of criteria specified. The results would be too difficult for a user to predict.
User ordering would be based on last published, first evaluated, but altering the order does not require unpublish/republish. Rather the user could specify that manifest A should be evaluated before B. Placement of a manifest could also be specified when initially published. Frank
