Hi Dave,
Dave Miner wrote: > Jan Damborsky wrote: >> Hi Sarah, >> >> >> Sarah Jelinek wrote: >>>>> 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. >> >> To be honest, I am thinking if install service model is applicable >> in the VMC case. In general it assumes there is service provider >> and service consumer - service consumer communicates with >> service provider in order to locate and obtain correct AI manifest >> associated with identified AI service. >> In VMC case, all this information is known in advance and controlled >> by one entity (Distro Constructor) which also takes care of preparing >> installation environment, so that doesn't seem that anything >> is to be negotiated. >> Maybe it might help if we could envision in more detail how things are >> supposed to work in VMC case and what level of flexibility would >> be useful. >> > > I had suggested in the context of another discussion the concept of a > null transport be used; I'd be inclined to think about this similarly. That is a good point - after taking a look at AI Transport mechanism functional spec and talking with Sarah, Sue and Joe it seems useful to apply this concept to install service model - and since install service will consume AI transport module for exchanging data between service provider and consumer, null transport will be almost transparent from AI service point of view. As Sarah already pointed out, using this model will allow to use the same concept regardless of location where AI image was booted from which makes room for easier implementation of possible enhancements. We will check that AI Service design spec is flexible enough in this point. Thank you, Jan
