Hi Sue, Comments inline... > Hi Sarah, > > Thank you for reading the spec and for your comments. Responses below. > > On 07/06/09 14:36, Sarah Jelinek wrote: >> Hi Sue, >> >> My comments on services spec. Apologies for delay. I have browsed >> Ethan's review and your responses prior to sending my comments. If I >> am repeating anything that has been said in those threads, please >> just point me to the data. >> >> Section 1.4.1: >> >> -What about support for zones? I am not sure what is meant by >> 'supported' in this context. I am assuming creation of and >> installation in to these VM's? If so, would zones support fall in >> this category? > > You are correct about your assumption (creation and installation into > VMs). As for zones, Jan will look into this further. >
I see that Jan and Dave had an exchange on this and that the zones will be added. >> Section 2.7: >> >> ?already instantiated AI images ? it would need to be investigated if >> instantiated images can be used >> for regenerating original AI images >> >> I am not sure what this transition note means, I am assuming it means >> if you have an older AI image you want to use to create a new, post >> 2009.06 service with? Seems to me we could at least at a minimum >> check to see if the image the user is pointing to is compatible with >> our new install service. > > If the user deleted the original iso image, it would not be available > and might need to be recreated. It needs to be investigated if this is > possible (it shoudl be) and to make sure that no information is lost > in that process. The image should be compatible with the service > because the manifests would still be compatible with the original image. > Ok. >> Section 3.1.2: >> >> Could we possibly also as part of asking the user to remove the >> invalid manifests, copy them off to a well known location for them as >> backup? I am not sure what you mean by removed(not deleted from fs). >> Maybe this is what you intend. > > Yes, this is what was meant here - to remove the invalid manifest from > the > service, but not delete them from the file system. I will clarify that > in the doc. > >> Section 3.1.3: >> I assume that as part of the removal of a service we will remove: >> -services configuration >> -dhcp setup >> -wanboot info >> -db/repository info >> >> I would like if you would list all the things the delete service will >> do. > > In general, everything service-specific that is related to the service > will be > removed, including the following: > All manifests associated with the service. > Service specific dhcp configuration information. > Service specific wanboot configuration information. > Service information removed from service configuration database. > >> Section 3.3: >> >>> >>> ?manage list of preconfigured as well as user created AI image >>> resources >> Isn't manage just list, add, remove as you noted in previous bullets? > > As this bullet has caused confusion, I have reworded it as follows: > > * manage list of preconfigured image locations as well as user > specified AI > image locations > Ok, thanks. this is clearer. > This bullet refers to management of locations where images can be > found, rather > than the management of the images themselves as in the previous bullets. > >> Section 4: >>> ?concept of install service >> >> Maybe this should say 'definition' of the install service? I am not >> sure what you mean by concept. > > Agreed. > >> Section 5.2: >> >> In this section you specifically state: >> >>> ?All services except for the service with global scope (see below) >>> are client-specific: they can only be >>> reached if a client-specific entry has been created for that client >>> or group of clients. A client-specific >>> entry can be based on client MAC addresses or address of subnet. >> >> But, in the case of a media based AI image(for example the one >> planned for the VMC project) an install service will have different >> characteristics in terms of global scope. I don't see anything that >> restricts a media based AI client/service from working in your spec, >> I just wanted to point this out and perhaps you can add some text >> that indicates that this will be supported(it has to be). A service >> on local media may be the same as on an install server, although that >> seems heavyweight. Even if it is simply a file based locator of the >> manifest, it is still the install service which isn't tied to DHCP. >> The client specific setup in this case is likely just a well known >> location for the client to look for the manifest. > > The install service uses a client-server model, so the AI client is > provided > with a service from the AI server. In the case of media installation, > there is > no server and it does seem heavyweight to use a service in this > scenario. We > thought that media installations using AI would not use service > discovery, but > the manifest would be provided via some other mechanism. We would need to > clarify the requirements of the vmc project on how the manifest will > be provided > to the vmc image. > It is still an install service on local media. We are doing manifest discovery, although not using the network and looking in a well known location. I think that it would be better to generalize the notion of an install service to include the locating of the manifest if a network isn't available. I don't think we need a 'server' in the local media case, it is heavyweight. But the notion of install service discovery can be generalized to include this case. >> Section 5.3.3: >> >>> It is required that x86 and Sparc install services with global scope >>> be served by the same AI server. >> >> Why is this a requirement? > > I was talking with Jan about this point this morning, and we think this > restriction was made earlier in the design efforts and may be outdated > now. So > we will relax the requirement and I will remove it from the spec. > ok. >> Section 5.3.4: >>> ?scalable - can store/serve information about 1000s of services >> >> This might be better worded "can store and serve information for >> thousands(is there a limit you have in mind here) of install services". > > I assume you meant 5.4.3. Will change this as suggested. > >> Section 5.5: >> >> -I assume you are not continuing with the mdns/dns service setup and >> discovery for future AI? If so, can you elaborate a bit more as to >> why not? >> >> I am assuming the why not is: >> >> -We already know which machine and image we have booted from at the >> time service 'discovery' has run. So, in the truest sense we are not >> doing service discovery, we are doing manifest discovery. So, >> mdns/dns doesn't really buy us anything? Is this correct? > > Yes, that is correct. > >> -I don't see mention of this, but I believe at one point early on in >> AI we talked about storing the AI manifests in a hierarchical way in >> the webserver that allowed for efficient 'search' for the manifests. >> So, the client would essentially pass in a structured POST string to >> the server that had, in order, criteria, that on the server side >> represented directory structure of manifests for a service, and the >> client would get back the associated manifest if found. Is this >> something we could consider to enable fast lookups? I haven't thought >> about the cons of doing this, such as restricted user setup. > > This sounds interesting and like something to investigate further > during the > design phase. > >> Section 5.6.4: >> >> What do we store internally with regard to AI manifests that is in >> different format than the external version? Are you talking about a >> db store on the backend? It isn't clear to me what this section is >> trying to convey. > > The user originally designates the manifest through some external > file. When the > original file has been validated, an internal copy of that file is > made which is > then used by AI. If the user then changes the external copy of the > file, it > would need to be revalidated before the changes are copied over to the > internal > copy. Does that help clarify? I'm not clear on where you're not > clear. :) > No, this is clear. I think the confusion comes from the fact that a manifest that was only changed externally is not a part of the service. It hasn't been validated and stored. So, I am not sure why we need to worry about the external format except when the user tries to add it to the service. >> Section 5.6.5: >> Why is it that the instance of criteria means a manifest is not the >> default manifest? Can't we allow the user to specify with the >> addition of this manifest that they want it to be the default as >> opposed to making them come back and update it? > > We didn't originally discuss this as a possibility, but it seems like > a reasonable thing to be able to do and Frank is ok with it too. > >> Section 6.3: >> This section is a little confusing. First you say: >> >> >>> Once the AI client obtains the service discovery engine, it will >>> invoke it for service discovery and >>> obtaining an AI manifest. If none of the available AI services >>> provide a valid AI manifest, the >>> Automated Installer will exit with a failure. >>> There is one service discovery model to be delivered >> >> But then later: >>> There are three scenarios available for this service discovery model: >>> ?client doesn't have service explicitly associated with it ? then it >>> is served by service with global scope >>> ?client is connected to a subnet which has an install service >>> associated with it >>> ?client has one service explicitly associated with it >>> In all three scenarios, the client will be provided with one and >>> only one install service which is >>> appropriate with respect to the scopes available for that particular >>> client: >> >> so, an install service will only ever have one service to search for >> a manifest, correct? Just want to be sure I understand the model. > > If you mean that a client will only ever have one service to search for a > manifest, then the answer is yes. I will reword 6.3: > > If none of the available AI services provide a valid AI manifest > -> > If the specified AI service doesn't provide a valid AI manifest.... > ok, thanks, >> That's it. > > Thanks again for the feedback, You are welcome. sarah ***** > Sue
