AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070305114426.4ca796dc@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<charissa.willard@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#mh/Mailbox/design review	0	BB375AF679D4A34E9CA8DFA650E2B04E02A95BCB@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 5 Mar 2007 11:45:05 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Charissa Willard" <charissa.willard@onstor.com>
Subject: Re: CLI Refactoring Functional Spec
Message-ID: <20070305114505.08d14a34@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E02A95BCB@onstor-exch02.onstor.net>
References: <A5437B3F-8053-409A-B2AD-1F3BEB6A5990@onstor.com>
	<BB375AF679D4A34E9CA8DFA650E2B04E02A95BCB@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Charissa,

It's probably best to use standard email reply quoting conventions
instead.  Note that there are no colors in your email, so your comments
aren't colored, nor are anyone else's.  The colors that you see are
just an affectation of your email client.

Cheers,

a


On Mon, 5 Mar 2007 11:39:35 -0800 "Charissa Willard"
<charissa.willard@onstor.com> wrote:

> Ian,
> 
>  
> 
> Thanks for your comments. Please see my responses below in blue.
> 
>  
> 
> -Charissa
> 
>  
> 
> ________________________________
> 
> From: Ian Brown 
> Sent: Monday, March 05, 2007 10:56 AM
> To: Charissa Willard
> Cc: Jonathan Goldick; Jay Michlin; Brian DeForest; dl-Design Review
> Subject: Re: CLI Refactoring Functional Spec
> 
>  
> 
> I have an interview candidate today that will keep me from being at
> this meeting for the whole time, however I have some comments, please
> bring these up at the meeting.
> 
>  
> 
> 0, This looks good over all.
> 
>  
> 
> 1, The nfxsh should always return an error value if an error occurs,
> -- I mention this because the design doc should explicitly say this.
> Currently some of the nfxsh commands will print an error and then the
> return value from the shell will be successful -- this makes running
> nfxsh commands from a shell script difficult.
> 
> [clw] I consider the fact that the cli code returned success when a
> failure occurred to be a bug. We discussed that this was happening in
> the cli code in one of our conference calls so we are aware of this
> issue. Also, the DEFUN macro will be defined to return success or
> failure the same way for all cli commands in addition to making sure
> success is not returned when an error occurs.
> 
>  
> 
> 2, The "SSC" name is going away with cougar, so now would be a good
> time to take it out of all the API names in the project.  Things like
> "sscapi_status_t" should be changed to something like
> "mgmtapi_status_t".
> 
> [clw} I wasn't aware that the "SSC" name was going away in Cougar.
> I'll ask about this in the design review.
> 
>  
> 
> 3, All "printf"'s and the ilk (like "sprintf") should be replaced with
> the bounded version of the call "snprintf", so there are no buffer
> overflows.  This design document should specify that only the bounded
> 'n' versions of these APIs should be used.
> 
> [clw] Thanks. I'll look into incorporating "snprintf".
> 
>  
> 
> 4, The structure "sscapi_exception_t" is not defined in the
> specification.  It needs to be design reviewed, so it needs to appear
> in this design document.
> 
> [clw] sscapi_exception_t is defined in /ssc-api/ApiError.h (at least
> the one I have.) It contains the app ID, error line number, error
> code, err string, etc.
> 
>  
> 
> 5, This design document should include (in Section 9) the code for
> testing the "cluster add nasgateway" command.  One thing that is
> plaguing the software engineering process at ONStor is the lack of
> regression testing -- this has been especially problematic with the
> CLI and changes to it.  Due to the size/complexity of the ONStor
> product, it is impossible to fully regress releases unless testing is
> automated. Automated testing needs a design, and this is the proper
> document to include that design in.  Every command and it's
> variations should have automated tests.  
> 
>             Since the new nfxsh is going to live on top of the a
> management API, then it can be tested in it's own environment, with a
> mock management API under it.  
> 
>             All output should be tested, so that it is known when
> someone changes the output of a command -- the current tests will
> fail. This has been a constant problem, and even with this project,
> it will not go away right away.
> 
>             Also included in the testing strategy, there should be
> tests that specify exactly how many commands there are (i.e. count
> the number of lines outputted by the "list" command), so that when an
> new command is added, it is immediately known when running the nfxsh
> regression test suite.
> 
>             I would be happy to help develop this test suite framework
> and the tests for one of the commands (like the "cluster add
> nasgateway") command, so that there are examples to follow when
> building out the test suite.
> 
>             I'm not sure how to say this stronger, but the testing
> strategy is very important with this project, and the long term cost
> reduction of developing an automated test suite -- along side of
> building each command in this new nfxsh/mgmtapi will be significant --
> so much so that it is foolish to proceed with this project without
> developing the test suite in parallel (or even prior) to the
> development of this code.
> 
>  
> 
> [clw] I totally agree with that there is indeed a huge testing effort
> needed for this project. I also agree that we need to automate
> testing. Not only because of this project, but because of the effect
> any cli change has on other applications. Automated cli regression
> testing would be a big benefit. In addition, because this project
> requires testing all of the cli commands and possibly command option
> combinations, we are already looking into what it would take to
> automate this task. We discussed this issue in the last 2 conference
> calls I had with HCL. I'm waiting for more information on this from
> them. I'll keep you in the loop regarding this issue. 
> 
>  
> 
> Ian
> 
>  
> 
>  
> 
> On Feb 27, 2007, at 2:40 PM, Charissa Willard wrote:
> 
> 
> 
> 
> 
> <meeting.ics>
> 
> <CLI Refactoring - Functional Spec.doc>
> 
>  
> 
