Hi Sarah.
On 07/09/09 08:14, Sarah Jelinek wrote:
> 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.
You are right: the external file isn't used by AI directly, except to
initialize/update the internal copy of the manifest. The pointer to the
external copy is provided as a convenience to the user, to help show the
source of the internal copy.
The spec mentions that the external copy's pathname is displayed even
though it is out of sync with the internal copy. The spec needs to be
clarified that if the two copies are out of sync, AI will flag this when
the external pathname is listed.
Thanks,
Jack and Sue
>
>>> 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
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
