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? 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. 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. 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. 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? Section 4: > ?concept of install service Maybe this should say 'definition' of the install service? I am not sure what you mean by concept. 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. 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? 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". 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? -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. 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. 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? 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. That's it. thanks, sarah *****
