Sarah. I responded to you before I had noticed the below email which Glenn had already sent.
Sorry for any confusion. Joe Glenn Lagasse wrote: > 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! > >
