[AG-DEV] Node-listing data, course of action

Jason Bell j.bell at cqu.edu.au
Wed Jun 6 18:27:35 CDT 2007


G'day Brian

Just a quick mention, but the QA and node listing database is separate,
just I feel they are closely linked in which can be seen as part of the
node listings.

Cheers,
Jason.

-----Original Message-----
From: Brian Corrie [mailto:bcorrie at sfu.ca] 
Sent: Saturday, 2 June 2007 1:38 AM
To: Jason Bell
Cc: qa at accessgrid.org; AG-DEV
Subject: Re: [AG-DEV] Node-listing data, course of action

Hi Jason,

Jason Bell wrote:
> G'day Brian and All
> 
> I would agree that they are two separate entities, but I would argue
> that to achieve the full benefits, you need to combine the QA results
to
> the node listing.

I completely agree (with the statement and your example)... I just think

that we want to keep the description of the node separate from its QA 
status. From a database standpoint, what this might mean is there are 
two tables, with the "node table" pointing to a record in the "QA 
table". We can define the "schema" for these two tables separately. I 
think the node schema is simpler and less contentious than the QA one
8-)

Brian

> Example:
> 
> If you look at the CQU-Rockhampton node listing
> (http://www.accessgrid.org/node/480) you can see that firstly it has
> passed a QA test.
> 
> Secondly, you can see that it has been certified for AGTK 2 and 3.
> 
> You can also see that it has been QA'ed tested and has the following
> capabilities:
> 
> Access Grid Version 3 Capabilities
> 
>     * Shared Presentation
>     * VenueVNC-Client
>     * VenueVNC-Server
> 
> Access Grid Version 2 Capabilities
> 
>     * VenueVNC-Client
>     * VenueVNC-Server
> 
> Therefore, if I was an outsider trying to organize an AG session,
> knowing the above applications have been tested in my opinion is very
> beneficial.
> 
> So, therefore, I would argue that the two need to be kept together for
> the full benefit.
> 
> Anyway, my 2 cents worth again!  
> 
> Thanks for your comments though, keep them coming.
> 
> Cheers,
> Jason. 
> 
> -----Original Message-----
> From: Brian Corrie [mailto:bcorrie at sfu.ca] 
> Sent: Friday, 1 June 2007 8:03 AM
> To: Jason Bell
> Cc: qa at accessgrid.org; AG-DEV
> Subject: Re: [AG-DEV] Node-listing data, course of action
> 
> Hello all,
> 
> Time for me to add my $0.02 cents worth.
> 
> Let me start with raising a point. In my view we are talking about two

> different things here, maintaining an international list of AG nodes
and
> 
> a QA process. These two are independent in my mind and having one does

> not necessarily depend on the other. It would be a good thing to have 
> them tightly linked (cross-referenced in some way) but they don't need

> to and probably shouldn't be a single entity...
> 
> Jason Bell wrote:
>> G'day all
>>
>> Progressing with the sharing of node-listing data, particularly in
>> regards to the QA process, may I suggest the following comments:
>>
>> *	Currently it appears that only the UK people have the need for
>> their own DB/system;
> 
> I don't think that is the case... We only started a discussion of a 
> unified schema for node listings a little over a week ago, or a bit 
> longer for those who were at the AG retreat. Heck, I have email in my 
> InBox that I consider important that is several months old!!! (but no,

> we won't digress into a discussion of my work habits 8-)
> 
> We are looking at this in some detail, and I can see we will likely
need
> 
> our own database (in fact we already have one that we are testing).
Our 
> anticipated use of this data base will require more information than 
> what a "simple" node listing would typically have, and that
information 
> will be very specific to our needs. That is, it doesn't make sense for

> the global node listing to reflect that information.
> 
> I suspect this will be true for many groups/consortias/countries...
> 
> There are three important things to consider here:
> 
> 1) What is the definitive data that is important for a global node
> listing.
> 
> 2) Where is that information stored
> 
> 3) How is that information utilized (e.g. displayed at a web site).
> 
> We have a good first pass at what 1) might be from what you sent from 
> the accessgrid.org node listing. With refinement I think we can
probably
> 
> come to some agreement on what this information should be.
> 
> In many ways, 3) is easy. Once we have the information in a database 
> somewhere, the information can be displayed in a variety of ways by a 
> variety of groups.
> 
> I think 2) is harder. The crux of the problem is where is the
definitive
> 
> data for a given node going to be, who is going to keep that data up
to 
> date, and how are others going to be able to make use of that data.
> 
> The needs from the perspective of 2) is different for different types
of
> 
> organizations. If you are a university and have a couple of nodes,
then 
> sure, put your nodes up on a central site. You certainly don't want to

> build a database yourself. So we clearly need that capability. But
what 
> if you are a consortium that is providing a service for a large number

> of nodes (AGSC, WestGrid). Does it make sense for WestGrid to enter
all 
> of our nodes into the accessgrid.org node listing site. Especially
when 
> we already have a database of nodes?
> 
> It seems to make more sense to me to pull information from the
regional 
> database and push that to the accessgrid.org site. The regional
database
> 
> is going to be kept up to date and is the definitive description of
the 
> node. Although I am not an expert, I would think that it would be 
> relatively easy to create a web service or some such beast that 
> transforms our description of a node to the global description for 
> either updating the central data  base or possibly just rendering to a

> web page.
> 
> The other option is of course to go the other way, with the definitive

> data at accessgrid.org and regional organizations pull information
from 
> there. That doesn't make a lot of sense to me. We will still need our 
> own database, so why are we storing important information to us at a 
> remote location...
> 
> If we aren't pushing data between these databases, then we will end up

> in the same position we are in now. We will run our own stuff for node

> listings, bookings, contact people, and when we get reminded by Jason
we
> 
> will up date our node information at the accessgrid.org site. 8-) I
know
> 
> which node listing will remain the most up to date from our sites...
> 
>> *	With this in mind, I will proceed with QA'ing nodes and regional
>> testers so that the AG's quality can be improved;
> 
> As I said, I think we should be careful here. I feel that the QA
process
> 
> and node listings are separate issues... Lets try to keep what we are 
> talking about clear...
> 
> Brian
> 
> 




More information about the ag-dev mailing list