Jan Damborsky wrote: > Joseph J VLcek wrote: >> Jan Damborsky wrote: >>> Hi Caimaniacs, >>> >>> initial proposal for install service redesign has been posted >>> for review: >>> >>> http://www.opensolaris.org/os/project/caiman/auto_install/is_redesign.pdf >>> >>> >>> It covers following main topics >>> >>> * concept of install service >>> * install service discovery >>> * establishing install environment on AI client side >>> * server side environment >>> * supported scenarios and use cases >>> (already sent out today as meeting minutes with subject >>> "Meeting for AI Services User Scenarios") >>> >>> Yell with questions/comments - please provide the feedback >>> before COB Monday 6/15. The outcome of this discussion will >>> be reflected in install service functional specification. >>> >>> Thank you very much, >>> Jan >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> >> > >> Jan, >> >> Sorry this is a little late. I mostly have questions > > Hi Joe, > > No problem :-) Please see my response in line. > > Thank you very much for the feedback ! > Jan > >> >> Joe >> >> >> Section 2 >> >> Should the first bullet be changed from: >> >> ? allow only deployment of clients running OpenSolaris operating >> system is considered >> >> To: >> >> ? limit clients to only installing the OpenSolaris operating system > > changed > >> >> >> --- >> >> Section 4.3 >> >> allows managing local as well as remote DHCP server >> ? >> >> Joe's Question: >> By remote do you mean not set up on the local host? > > Yes - it is allowed that DHCP server can be deployed on other machine > than AI server. > >> To what extent can "remote" DHCP servers be managed? on different >> host, on only the local host? > > If user has appropriate privileges, AI server will allow to manage > DHCP server on other machine using standard AI server user interface. > >> >> >> Section 4.4 >> >> can detect and report collisions with existing configurations >> ? >> >> Will configuration collisions be allowed? When a configuration >> collision is detected will the user be given the opportunity to abort >> the new configuration? > > Yes, if collision is detected, user will be informed and > the modification will not be done. > >> >> Section 4.5 >> >> Joe's Questions: >> Will installadm no longer provide DHCP configuration too? Will the >> user be required to issue installadm wanboot specific commands to >> configure DHCP or will it still work as is does today with a single >> installadm create-service able to take DHCP configuration arguments? > > In simple scenario, no special commands will be > necessary - DHCP configuration will be handled automatically > when service is created. > It is TBD how appropriate UI will look like and what level of > flexibility will need to be provided in more complex scenarios > (e.g. managing multiple DHCP servers). > >> >> >> Section 6.2.1 >> >> Joe's question: >> What happens if there is both a global scope and a per client scope AI >> service on the same net? How does the Global Scope AI server know >> there is also a per client scope AI server running? Do they both need >> to use the same DHCP server? Does the Global scope AI service query >> the DHCP server being used by the Per Client AI server? > > Yes. If services with global scope and client scope are deployed > on different AI servers on one subnet, then they will manage the > same DHCP server and will be able to detect collisions - e.g. when > 2nd AI server tries to create install service with global scope when > there is already one created by 1st AI server. > >> >> Section 7.1.1 >> >> Requirements should also include: >> >> . list services > > You are right - added. > >> >> Section 8 >> >> small typo: one too many "up"s >> >> up the AI client up > > Changed. >
Thank you Jan! Joe
