Huge thanks Sarah! My comments below. Glenn may have more to add.
Joe Sarah Jelinek wrote: > Hi Glenn and Team, > > Thanks for getting this out! Overall it looks really good. Some > comments and questions below... > >> XML tag for pointer to existing bootable AI media >> >> Tag: AI_Client_Image >> >> String. Path to AI client image. >> >> No Default >> > > It might be better not to tag these with the AI_ prefix for the > installer image tags and manifests. Perhaps Installer_image or > something. That way we don't tie ourselves in to having to add new > tags if we decide we can support a different installer. Up to you, > just a thought. Good suggestion. Dave Miner also suggested we pass this info as arguments to the install finish scripts > >> XML tag for the VM hang timeout. >> >> Tag: vm_install_timeout >> >> Numeric, Integer representing time in minutes until the >> >> VM install is aborted. >> >> Default is TBD >> > What is expected to hang specifically? The installer in the VM? I am > just wondering what we can detect with the installer with regard to a > hang to do anything about it. If either the installer or VM hang the VMC would also hang. We were thinking to avoid this we could loop waiting for the install to finish. If the timer expired we could assume something hung. This is mostly necessary because of the difficulty observing the install process in the VM from the host. > >> _Boot and Monitor VM finalizer script_ >> >> >> Overview: >> >> >> Monitoring will be limited to what is provided by the AI client. >> >> It is expected that at a minimum the AI client will need some >> >> method to communicate that the install has completed for failed. >> > > Is there a requirement on the AI completeness work Ethan and folk are > doing for something here? There should be. Glenn is there? I'll connect with Glenn and we will follow up on this. > > The diagram you have with the steps still shows creating of an AI iso > if not provided. I know this is up for discussion. Have you made any > decisions on this yet? No, is an acceptable answer, just checking :-). No - I don't think we have decided yet. > > In install_VM you show a loop that monitors state with regard to the > VM. If the VM is hung, what can we do here in terms of shutting down > the VM? We could stop the VM, the equivalent of pulling the plug. > > What about error handling? I see each script does some sort of error > handling, at least it is mentioned. Maybe your more detailed design > will delve in to the error handling stuff more? I just don't want to > gloss over this, in particular if there are peculiarities with > invoking Vbox and capturing errors. Kind of like the snap stuff has > issues today. I was expecting we would produce a VMC error that the particular vbox call failed and we could bubble up whatever the failed vbox call reported and write all this to the VMC (DC) log. > > > thanks, > sarah > **** > > > > > > > >> All, >> >> I've posted the first rev of the design document for the Virtual Machine >> Constructor project at the following location: >> >> <http://www.opensolaris.org/os/project/caiman/VMC> >> >> Please provide any comments you may have by COB Friday, July 31st. If >> you need more time to review the document, please let me know. >> >> Thanks, >> >> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
