Due to getting slammed on my own end for QE work, I'm not going to have 
the cycles to do a full code review of these bits.

I apologize for coming up short on this one.

-Drew

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

Reply via email to