On Thursday 06 September 2007 16:19, DongInn Kim 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".
I agree with you. I just think this is bad to have the info twice because this is always a source of bugs (risk of updating only one of these values). I really think you should remove the group_id from 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. To be honnest, i prefer to keep this relation table because it may be nice in the future to be able to describe and manage more complex cluster architectures (i.e., not a simple Beowulf cluster). > > I hope that this is clear to your questions. Yes it does. Thanks DongInn. For my current development i think i will create a new table. Thanks again. > > - 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 -- Geoff ------------------------------------------------------------------------- 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
