Hi Clay, looking at the changes, I have one generic comment. I can see that we are still touching /etc/vfstab. I am wondering if it is something we could completely avoid, since I could see this is fragile solution and could be source of potential issues.
I assume that we are adding entries into /etc/vfstab to make sure that 'boot' directories are automatically lofi mounted by system during boot - is it correct ? If this is the case, I am thinking if it might be better to let AI SMF part take care of it - pros: * better isolation - if we don't touch /etc/vfstab, we don't need to be afraid about people complaining that AI damaged their vfstab - we will not need to prove that user or other part of system actually did this and will not need to evaluate those kind of bugs. * robustness - something might always go wrong - for instance user or AI could accidentally delete mount point or source image. If we have explicit control over this process (mounting), we can implement appropriate checks and inform user accordingly if some prerequisites are not met. We will avoid need to evaluate failures from fs-local SMF method. * better user experience - currently, if there is a problem, it prevents system from coming up - system/filesystem/local:default goes to maintenance and user ends up in console prompt which is seems scary, since nothing indicates that it is AI failure, it rather seems something is wrong with system itself. We should be more user friendly in such scenario. Thank you, Jan Clay Baenziger wrote: > Hi again all, > Well the addition of a thousand lines of code and 50+ pages of > comments I think I've got this re-spun for everyone's enjoyment, > please see: > > http://cr.opensolaris.org/~clayb/delete_service/webrev2.diff/ > (Unfortunately I can't get webrev to track that delete-service.py > became delete_service.py (so that it can be imported by delete_client)) > > Or full webrev: > http://cr.opensolaris.org/~clayb/delete_service/webrev2/ > > The bug list has grown to include: > 4526 delete-service is not deleting service as described in > section 4.3.2 > ai_design_doc > 6587 delete-service shouldn't remove the source image if there's other > services actives 'linked' to the same source image > 8666 create-service: prints out SMF messages no matter what's going on > 8773 create-service followed quickly by delete-service hangs > 10740 Need way to interact with SMF from Python for installadm > components > in Python > 11292 delete-client: should remove SPARC clients too > 11486 delete-service/delete-client: should check inetd.conf for > tftp root > > > To Drew: > -------- > To address the ps(1) pain, I consolidated the function down and filed > 11524 - Should look to using PSI (Python System > Information) for Python process management > > I looked into Bill's bootadm work but I don't fit an "alternate root" > environment and I'd still need to provide a lot of parsing anyways. > > To Sundar: > ---------- > I think our phone call Thursday cleared up your questions? > > For those in the code walk-through: > ----------------------------------- > I chose to append our findings of being able to have both a SPARC and > X86 client to a bug on create-client rather than address finding all > possible nooks for a client and spewing lots of not found messages to > a user (or having to catch the messages in funky ways). > > Jack: > ----- > Per the agreement between Drew's coding style suggestions, those of > PEP8's hanging indents and Google's Python style guide I've followed > PEP8/Google's Style guide, however, I hope next Tuesday we'll have > time to come to a consensus on Python style there as this should > expand past this one push, of course. Thank you for getting me to > think about this so much! > > Thank you, > Clay > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
