Hi Geoffroy, Honestly, I am not clear of the usage of the "Groups" table either.
mysql> select * from Groups; +----+---------------+----------+---------+ | id | name | selected | type | +----+---------------+----------+---------+ | 1 | core | 0 | package | | 2 | Default | 1 | package | | 3 | oscar_clients | 0 | node | | 4 | included | 0 | package | | 5 | oscar_server | 0 | node | | 6 | image | 0 | image | | 7 | all | 0 | node | | 8 | Default_node | 0 | node | +----+---------------+----------+---------+ 8 rows in set (0.02 sec) We have several groups here and we use the entries at the group related tables(Group_Nodes and Group_Packages) according to the "type" field. For me, there is no big use of this table "Groups" and it is kind of a collection of groups that we may have to use so that we can clearly find out what groups we use in the oscar database. That's all. > 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. You are talking about the "Group_Nodes" table, right? Sure, basically the relation table is used for that. But I wonder if the table fields are good enough to implement what you want. mysql> desc Group_Nodes; +------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------+--------------+------+-----+---------+-------+ | group_name | varchar(100) | NO | PRI | NULL | | | node_id | int(11) | NO | PRI | NULL | | +------------+--------------+------+-----+---------+-------+ 2 rows in set (0.00 sec) If you need any additional fields which I hope do not make any conflicts among the existing fields (group_name and node_id), please try to do so. > 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. > > What is the partition information to add to the database? Regards, - DongInn Geoffroy Vallée wrote: > 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
