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. -Keith > > thanks, > sarah > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
