Hey Sarah, * Sarah Jelinek (Sarah.Jelinek at Sun.COM) wrote: > Hi Glenn and Team, > > Thanks for getting this out! Overall it looks really good. Some > comments and questions below...
Thanks! And thanks for the feedback. Our responses 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 point. We'll make them more generic. > >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. The installer in the VM or perhaps just the VM. The point is, it's entirely possible that *something* just stops. I'd rather we didn't sit-n-spin forever ;-) > >_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? Yes, AI observability. > 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 firm decisions, but I'm very much slanted towards not building one in a VMC context. > 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? This is where the vm_timeout comes in. When the timeout expires, we'll forcibly shut down the vm and tell the user that vm creation failed. Though why it failed is going to be tricky to explain. > 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. We'll definitely need to handle errors from vboxmanage. We haven't looked at what it returns yet in the cases we're going to call it in. We'll flesh that out. Thanks Sarah! -- Glenn
