Hi Geoffroy, Thanks for pointing out the old story. Yes, group_id for the "Nodes" table is added for the convenience. This makes it easy for a developer to query the corresponding group directly. (i.e., joining another relation table(Groups_Nodes) is not necessary to query the right group) But the reason that we have another relation table Group_Nodes is because I was not sure that one node always belongs to only one group. I believe that current cluster schema is fine with having one-to-one relation between Groups and Nodes tables but we can not find a way to save the Group information in the Nodes table without this relation table "Group_Nodes" if one node belongs to two groups or more in the future development.
So, for the clearance of the database schema, we can just remove the "group_id" field from the "Nodes" table but we may need to continue joining the relation table "Group_Nodes". BTW, as I mentioned above implicitly, if the OSCAR node has no reason to belong to the multiple groups even in the future, the relation table "Group_Nodes" is useless. I hope that this is clear to your questions. - DongInn Geoffroy Vallée wrote: > I reply to myself to precise a point: Group_Nodes is supposed to be the table > that make the relation between the Groups table and the Nodes table > (http://svn.oscar.openclustergroup.org/trac/oscar/attachment/wiki/DevODA_architecture/db_ER.png). > I can understand that but in that case, group_id information should _not_ be > stored into the Nodes table. > > So we will have to clean up the Nodes table (and i will create a new table to > store data about node partitioning) or Group_Nodes is deprecated (and > therefore i can use it). > > Which scenario seems the best to you? > > Thanks, > > Le jeudi 6 septembre 2007 14:56, Geoffroy Vallée a écrit : > >> Hi all, >> >> I try to implement a more effective way to deal with package sets & cluster >> partitioning and i have questions after reading the database documentation. >> >> For instance on the wiki, we can read: >> "Groups essentially provides categorizations of nodes and packages. >> For grouping of nodes, Groups typically includes the OSCAR server >> (a group simply containing the OSCAR head node of a given cluster), OSCAR >> clients >> (all the client nodes in a cluster), and images(one or more disk images >> that, for management purposes, are treated like real nodes). On the other >> hand, the Group_Packages relation contains the package groups to represent >> what packages are installed in a group. A default package group is setup >> and the packages that belong to this group are installed in all the nodes." >> >> First of all, the term "groups" does not make much sense, it is more a >> "type". Anyway this is not the main purpose of this email. In the current >> implementation of the database we have 2 different tables dealing directly >> with that definition of groups: Nodes, Groups. In fact, we store in the >> Nodes table the Group id that we get from the Groups table. For instance, >> it is possible to know "oscarnode1" is a client. >> >> The point that is confusing me is the Group_Nodes table. This table current >> stores the node id and the group id for each node. This is therefore >> completely redundant with the Nodes table. Is it normal? >> >> I think this table should be used to store information about the current >> partitioning. For instance mid-term we may want to say that we want to use >> a node as NFS server. In that case, we have different groups of nodes: - >> one group for which the server is the NFS server node and the clients are >> the compute nodes, >> - one group for which the server is the headnode (as currently defined) and >> the compute nodes are the clients. >> If you do that, it is then pretty simple to install and manage everything. >> >> The overall question is therefore: may i change the sementic of the >> Group_Nodes table (data we currently store is that table are available via >> the Nodes table) and use it to store partitioning information? >> This should not imply any deep modifications of the database code. >> >> Thanks, >> > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
