I think what Geoffroy wants is to use the Group_Nodes table for exactly what you are suggesting here, to contain information about node groupings (which a node could belong to more than one of).
I think his confusion comes in because currently there is no usage of the table in this way. So the entry in the Nodes table would be a sort of "primary group" such as "master, client" or perhaps "multiple" if it has more than one entry in the groups table, I don't know... Just thinking out loud. On 9/6/07, DongInn Kim <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------------------------- 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
