headers
Andrea Righi | 1 Sep 2007 16:59
Picon
Favicon

SystemImager 3.9.4 (-unstable) released

The new version 3.9.4 of the "-unstable" branch is available here:
http://sourceforge.net/project/showfiles.php?group_id=259&package_id=37046&release_id=536468

Official announcement:
http://sourceforge.net/forum/forum.php?forum_id=731448

Best regards,
-Andrea

PS [for OSCAR developers]: read carefully the comments about tfptboot
improvements. The default tftpboot path has been moved from /tftpboot to
/var/lib/tftpboot. Anyway, the integration in OSCAR of 3.9.4 shouldn't need too
much work if you change the tftpboot dir explicitly to the old path in
/etc/systemimager/systemimager.conf.

-------------------------------------------------------------------------
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/
Permalink | Reply | 0 comments |
headers
DongInn Kim | 4 Sep 2007 18:37
Picon
Favicon

opkgc to support the RPM based distro

Hi Jean,

Can you please look into the problem(#401) that I filed a few weeks ago?
I don't think I can go further without this thing fixed.
http://svn.oscar.openclustergroup.org/trac/oscar/ticket/401

If you have any workaround, can you please point it out for me?

Regards,

--

-- 
- DongInn

-------------------------------------------------------------------------
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/
Permalink | Reply | 6 comments |
headers
Dominik Schips | 5 Sep 2007 15:17
Picon
Favicon

Re: Create OSCAR client image with mksiimage on openSUSE 10.2 fail

Hello,

Am Freitag, den 31.08.2007, 10:08 -0700 schrieb Bernard Li:
> Hi Dominik:
> 
> On 8/31/07, Dominik Schips <dominik.schips@...> wrote:
> 
> > There are 5 failed/skipped tests (see above).
> > Please check for .err and .out files in /home/oscartst/≤package>.
> 
> Can you please also post in http://www.pastebin.ca the above mentioned
> error files for the packages which failed?

Here is a actual log with the errors from Step8.

http://pastebin.ca/682265

--

-- 
Best regards

Dominik Schips

-------------------------------------------------------------------------
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/
Permalink | Reply | 1 comment |
headers
Dominik Schips | 5 Sep 2007 16:01
Picon
Favicon

Re: Create OSCAR client image with mksiimage on openSUSE 10.2 fail

Hello Bernard,

Am Freitag, den 31.08.2007, 02:57 -0700 schrieb Bernard Li:
> Hi Dominik:
> 
> If it's convenient can you please email spec file diffs instead of the
> whole files?  This way it is easier for me to determine whether the
> patches are necessary.

I checked all packages again to verify the build. Here is the output of
the diff.

http://pastebin.ca/682270 (ganglia.spec.patch)

http://pastebin.ca/682293 (udpcast.spec.patch)

http://pastebin.ca/682297 (udpcast-linux-types.patch)

http://pastebin.ca/682303 (apitest-1.0.0.spec.patch)

> So I take it you now have a cluster running OSCAR 5.0 on openSUSE 10.2 x86_64?

Still only the errors from the other Mail.

http://pastebin.ca/682265

> > > Typically all you need to do is use our src.rpm and execute `rpmbuild
> > > --rebuild` on your distro.  If you had to modify the spec files,
> > > please post diffs against the original spec files to the list.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jean Parpaillon | 6 Sep 2007 13:49
Picon
Favicon

Re: opkgc to support the RPM based distro


Hi,
Sorry for being laaaaaate

Le 04.09.2007 18:37, DongInn Kim a écrit :
> Hi Jean,
> 
> Can you please look into the problem(#401) that I filed a few weeks ago?
> I don't think I can go further without this thing fixed.
> http://svn.oscar.openclustergroup.org/trac/oscar/ticket/401
> 
> If you have any workaround, can you please point it out for me?

Packages are generated in your RPMS environment (depending on your
config: /usr/src/RPMS, ~/RPMS or any else). The failure just occur when
opkgc try to copy packages from its place to current dir. So, your
packages are ok, just in the wrong place.

Trying to fix this asap.

> 
> Regards,
> 

Best regards,
Jean

--
------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 5 comments |
headers
DongInn Kim | 6 Sep 2007 19:16
Picon
Favicon

Maintenance of OSL NFS

Hi,

We need to upgrade the RAID firmware of the OSL NFS server for the
better maintenance of the OSL NFS. This firmware upgrade requires to
reboot the NFS server and we may have one hour outage of our NFS server.

Date: Friday, Sep 7, 2007.
Time:
- 5:30am-6:30am Pacific US time
- 6:30am-7:30am Mountain US time
- 7:30am-8:30am Central US time
- 8:30am-9:30am Eastern US time
- 12:30pm-1:30pm GMT

I expect that the following services would not work during the outage:
- login to users' $HOME
- web site whose contents are on the NFS (e.g.,
http://oscar.openclustergroup.org, http://www.openclustergroup.org, ...)
- All the NFS contents are not accessible via the OSL machines
- All services depending on the NFS contents

Please let me know if you have any questions or concerns about this outage.

Best Regards,

--

-- 
- DongInn

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geoffroy Vallée | 6 Sep 2007 20:56
Picon
Favicon

Proposition about the database architecture

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:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Geoffroy Vallée | 6 Sep 2007 21:23
Picon
Favicon

Re: Proposition about the database architecture

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."
(Continue reading)

Permalink | Reply | 4 comments |
headers
DongInn Kim | 6 Sep 2007 22:19
Picon
Favicon

Re: Proposition about the database architecture

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Edwards | 7 Sep 2007 00:13
Picon

Re: Proposition about the database architecture

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 <dikim@...> 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
(Continue reading)

Permalink | Reply | 1 comment |

Gmane