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
>
>
