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, -- Geoffroy ------------------------------------------------------------------------- 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
