Hi Clay, you are right that this change is perhaps out of scope of this fix. Thank you for filing bug for this issue. Jan
Clay Baenziger wrote: > Hi Jan, > Very good idea to use SMF to do the lofi mounts! Yes, that could > be more reliable than adding entries to /etc/vfstab. Unfortunately, > this wad is only the removal side of installadm, so I've filed bug > 11537 (create-service: Look to mounting boot archives via SMF and not > modifying /etc/vfstab) for tracking this. > Thank you, > Clay > > On Wed, 23 Sep 2009, Jan Damborsky wrote: > >> 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 >> >>
