Re: [Fuego] Adding board availability status to fserver

Thanks for working on this.

Here is some feedback.  When sending patches, it is helpful if the patch is "inline"
in the e-mail, instead of provided as an attachment.  When the patch is inline
in the body of the e-mail, I can quote it, and comment on individual lines or
sections, directly inside my email client.  This make it much easier to do reviews
and give feedback.

Please see the following for instructions about sending patches:
http://fuegotest.org/wiki/License_And_Contribution_Policy#Submitting_contributions

(and maybe look at this also: https://www.kernel.org/doc/html/latest/process/submitting-patches.html)

Also, this patch is missing the Signed-off-by line.  Please see this section:
http://fuegotest.org/wiki/License_And_Contribution_Policy#Contributor_agreement
for details about this.  Do a 'git log' of ftc to see other commits, to see what
the Signed-off-by lines look like.

Please make sure your patches include an appropriate "Signed-off-by" line
in the future.  Note that if you have git configured with your name and e-mail,
git will add a Signed-off-by line for you when you use the '-s' option with git commit.
ex: 'git commit -s'

See additional comments inline below.

> -----Original Message-----
> From: Pavan Arun Deshpande <[email protected]>
> 
> Hi Tim,
> 
> I have added a status variable to the board dictionary in the do_put_board() function of ftc script.
> Here are procedure to change board availability status and put that on the fserver:
> 
> *	change the status variable value either up or down according to board availability.

How does one do this?  In your patch, I only see a hardcoded value of "up" for the status,
and this value is embedded in the ftc source code.  Are you suggesting to edit 'ftc' when
a user wants to change the value of the status on the server?

Note that "do_put_board() takes an argument of "options", that has the remainder
of the command line arguments from the command.

One way to allow for dynamically changing the fserver board status from the command line
would be to pass in values on the command line.  So the command line would look like this:

ftc put-board bbb status=enabled
or
ftc put-board bbb status=disabled "status_description=down for lab maintenance. should be back on April 19"

Another possibility is for ftc to read status data from the local Fuego board file, and put that
into the request to update the board.

So, instead of giving the status on the ftc command line, a user would add it to the board
using the 'ftc set-var' command, and then the 'ftc put-board' could read server-relevant fields
from the system and send those to update the server with the information.

I'm not sure that "status" is the right field name for this.  status can refer to a number of different
attributes of the board.  In might include such things as reservation status, power status,
lab availability status, etc.  However, I can't think of a better field name for this at the moment.

Another issue, besides the name of the field in the board json file, is the set of values the field
is allowed to have.  In one of the existing boards I have the value of "Available".  You have "up"
in your patch.  In my example above I use "enabled" and "disabled" as possible values.

Since the 'status' field may be used by Fuego to determine whether to proceed with a test,
the set of values that are allowed should be specified.  That is, Fuego needs to know what
value strings to match against to control its operations relative to the board.
What I envision is that either fserver or ftc will reject operations for the board when it is in the "disabled" or "down" state, and requests will either be rejected, or deferred.

Also, I'm not sure that it's a good idea to overload the 'put-board' command with this attribute
update capability.  The put-board command is for originally registering the board with 
the server, and is intended to hold things like static data.  I think it might be better to create a
new command to update the board data, so the command would be something like:

 'ftc update-board bbb status=disabled'

This may require that I add another API to the server, to support this operation (separate
from the put-board operation).

> *	run the following command in the ttc container:
> 
> 
>                        ftc put-board  <board_name>
>   then it will reflect in <board_name>.json file on the fserver
> 
> please find the patch file of the ftc script and also the snapshot of the rpi.json below.

Adding the 'status' attribute to the board's json file on the server is the right approach.
But, as stated above, I'm not sure that 'status' is the field name I'd prefer for this.
Let me know what you think.

Overall, I think it would be good to give an overview of what I'm trying to accomplish
with the fserver system.  The main goal is to allow people to easily request that a test
be performed on a board in a different lab.  This is to allow people to have access to
boards and hardware that they otherwise would not have access to.  But I have other
secondary goals as well, that influence the design and architecture of the server, its APIs
and the ftc commands related to it.  Maybe I should do a presentation on one of our
conference calls, to describe the vision and architecture of the system, to help PPT
developers (including yourself) to understand what I'd like to accomplish with this system.

> 
> Thanks and regards
> Pavan Arun Deshpande
> 
> 
 
> This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you
> are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly
> prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be
> secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The
> sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail
> transmission.

This e-mail footer is a problem for contributing to open source projects.  The statement
in the footer directly contradicts the act of putting the message on a public mailing list.
I (mostly) ignore such footers in e-mails sent to the fuego mailing lists.  However, other
open source projects will explicitly ignore any emails that contain confidentiality and legal
notices like the one above.

I know you probably have no control over this footer (it's probably added automatically by 
your e-mail server).  But, if there's any way to avoid having this appear in your emails,
please remove it.  This will make it easier for you to contribute to open source projects.

Regards,
 -- Tim