On Thursday 06 September 2007 18:13, Michael Edwards wrote: > 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).
Actually no because the notion of groups we currently have is more a type rather then a "group of nodes". > > I think his confusion comes in because currently there is no usage of > the table in this way. I think the confusion come from the name "group", i think "type" makes more sense. > > 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... I think the information the table current store is fine (server versus client versus image). But it is not enough to describe for instance that node A is the server for the service 1 and node B the server for the service 2. That's why i think we need to store information about the "node partitioning" (typically because most of the cluster today are not simple Beowulf clusters were the headnode hosts all the services. For instance most of the time the NFS server is a separate node. > > Just thinking out loud. Me too but i think i start to have an idea of how to address the problem. > > 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/DevOD > > >A_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 -- 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
