[Sisuite-devel] patch for a diskless support

[g***@free.fr]

Hi all,

Ferrol has been working on the extension of SystemImager for a diskless support. He did a pretty good job, the implementation being not intrusive.

Please find a description of the modification, a patch for si_prepareclient and a new Perl module for SystemImager that actually implements the diskless support. It does not aim at being perfect but it is a small extension that enables a basic diskless support, and we think the community may be interested by such a capability.

Is it something that could be included directly into SystemImager?

Of course, if you have any questions or remarks, feel free to contact us.

Thanks,

Description of changes made:
----------------------------

1. The user needs only modify a configuration file. This file is
/etc/systemimager/diskless.conf.

<ip> <path_to_kernel> <method_of_boot>

The <method_of_boot> section can define three methods:
nfs-root, ramfs-rsync, ramfs-http.

2. /usr/sbin/si_prepareclient was modified in order to include a flag that can
be used to signify whether or not modifications should be done.
The proper call is:

/usr/sbin/si_prepareclient --diskless

It looks to see if that flag is there and then calls a function named
diskless(). This function makes use of a perl module,
/usr/lib/systemimager/perl/SystemImager/Diskless.pm, that contains
most of the code that was used in si_mkdiskless.
After the function, diskless(), returns si_prepareclient exits. This
can be changed, it was just seen as a possible annoyance to have some
parts of si_prepareclient to run if the user only wanted the diskless
portion to run.

[Bernard Li]

Post by g***@free.fr
Ferrol has been working on the extension of SystemImager for a diskless support. He did a pretty good job, the implementation being not intrusive.

Cool!

Post by g***@free.fr
Please find a description of the modification, a patch for si_prepareclient and a new Perl module for SystemImager that actually implements the diskless support. It does not aim at being perfect but it is a small extension that enables a basic diskless support, and we think the community may be interested by such a capability.

Is the patch done against trunk?

Post by g***@free.fr
Is it something that could be included directly into SystemImager?

The first step for code to be included into the repo is to ensure that
the patch applies cleanly to our development trunk. Then we'll need
reviewers and testers.

I would suggest you file an enhancement report in
trac.systemimager.org so that we don't lose track of it.

Post by g***@free.fr
Of course, if you have any questions or remarks, feel free to contact us.

I don't have the time to review the patch right this second, but other
users/developers are welcome to jump in and provide their feed back.

Thanks for spending the time for adding support for this feature.

Cheers,

Bernard

[g***@free.fr]

Hi Bernard,

We will be happy to use trac as you suggested but the URL you give does not work (server down).

Let me know when the server will be back online.

Regards,

----- Mail Original -----
De: "Bernard Li" <***@vanhpc.org>
À: "geoffroy vallee" <***@free.fr>
Cc: sisuite-***@lists.sourceforge.net, ***@ornl.gov
Envoyé: Mardi 15 Juillet 2008 17:45:21 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support

Post by g***@free.fr
Ferrol has been working on the extension of SystemImager for a diskless support. He did a pretty good job, the implementation being not intrusive.

Cool!

Post by g***@free.fr
Please find a description of the modification, a patch for si_prepareclient and a new Perl module for SystemImager that actually implements the diskless support. It does not aim at being perfect but it is a small extension that enables a basic diskless support, and we think the community may be interested by such a capability.

Is the patch done against trunk?

Post by g***@free.fr
Is it something that could be included directly into SystemImager?

The first step for code to be included into the repo is to ensure that
the patch applies cleanly to our development trunk. Then we'll need
reviewers and testers.

I would suggest you file an enhancement report in
trac.systemimager.org so that we don't lose track of it.

Post by g***@free.fr
Of course, if you have any questions or remarks, feel free to contact us.

I don't have the time to review the patch right this second, but other
users/developers are welcome to jump in and provide their feed back.

Thanks for spending the time for adding support for this feature.

Cheers,

Bernard

[Bernard Li]

Post by g***@free.fr
We will be happy to use trac as you suggested but the URL you give does not work (server down).
Let me know when the server will be back online.

Thanks for letting us know the server is down, will let you know when
it's back up.

Cheers,

Bernard

[Bernard Li]

Post by Bernard Li
Thanks for letting us know the server is down, will let you know when
it's back up.

trac.systemimager.org has been restored. It would be great if you can
rebase your patch against the code in trunk, and submit it as an
enhancement issue in Trac.

Thanks,

Bernard

[Erich Focht]

Hi,

I am curious about the aproach taken but cannot easilly recognize it from
the code. Could you (or the author) please explain what the aproach is? What
is mounted from where, what is exported from where, which directories are
read-only and which are writable? What is the meaning of nfs-root,
ramfs-rsync, ramfs-http?

Is the approach only working for fedora?

Why is the ramdisk built as cramfs? It is uncommon to use anything else than
initramfs (simply buildable with cpio) since many years... If nothing speaks
against initramfs, you should probably switch to that.

Thanks & best regards,
Erich

Post by g***@free.fr
Hi all,
Ferrol has been working on the extension of SystemImager for a diskless support. He did a pretty good job, the implementation being not intrusive.
Please find a description of the modification, a patch for si_prepareclient and a new Perl module for SystemImager that actually implements the diskless support. It does not aim at being perfect but it is a small extension that enables a basic diskless support, and we think the community may be interested by such a capability.
Is it something that could be included directly into SystemImager?
Of course, if you have any questions or remarks, feel free to contact us.
Thanks,
----------------------------
1. The user needs only modify a configuration file. This file is
/etc/systemimager/diskless.conf.
<ip> <path_to_kernel> <method_of_boot>
nfs-root, ramfs-rsync, ramfs-http.
2. /usr/sbin/si_prepareclient was modified in order to include a flag that can
be used to signify whether or not modifications should be done.
/usr/sbin/si_prepareclient --diskless
It looks to see if that flag is there and then calls a function named
diskless(). This function makes use of a perl module,
/usr/lib/systemimager/perl/SystemImager/Diskless.pm, that contains
most of the code that was used in si_mkdiskless.
After the function, diskless(), returns si_prepareclient exits. This
can be changed, it was just seen as a possible annoyance to have some
parts of si_prepareclient to run if the user only wanted the diskless
portion to run.

[g***@free.fr]

Hi,

I never said the solution is perfect, we needed to have those solutions for a specific study and we do not plan to maintain the diskless solution (and all its different flavors, it is time consuming and we do not have this time).
Our plan was more to submit what we have to the community to see if someone else is interesting. Based on you email, it seems that it is not the case, just i guess you can just forget about the patch (we do not have more resources for further developments, sorry).

Best regards,

----- Mail Original -----
De: "Erich Focht" <***@gmail.com>
À: sisuite-***@lists.sourceforge.net
Cc: "geoffroy vallee" <***@free.fr>, ***@ornl.gov
Envoyé: Jeudi 17 Juillet 2008 05:02:23 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support

Hi,

I am curious about the aproach taken but cannot easilly recognize it from
the code. Could you (or the author) please explain what the aproach is? What
is mounted from where, what is exported from where, which directories are
read-only and which are writable? What is the meaning of nfs-root,
ramfs-rsync, ramfs-http?

Is the approach only working for fedora?

Why is the ramdisk built as cramfs? It is uncommon to use anything else than
initramfs (simply buildable with cpio) since many years... If nothing speaks
against initramfs, you should probably switch to that.

Thanks & best regards,
Erich

Post by g***@free.fr
Hi all,
Ferrol has been working on the extension of SystemImager for a diskless support. He did a pretty good job, the implementation being not intrusive.
Please find a description of the modification, a patch for si_prepareclient and a new Perl module for SystemImager that actually implements the diskless support. It does not aim at being perfect but it is a small extension that enables a basic diskless support, and we think the community may be interested by such a capability.
Is it something that could be included directly into SystemImager?
Of course, if you have any questions or remarks, feel free to contact us.
Thanks,
----------------------------
1. The user needs only modify a configuration file. This file is
/etc/systemimager/diskless.conf.
<ip> <path_to_kernel> <method_of_boot>
nfs-root, ramfs-rsync, ramfs-http.
2. /usr/sbin/si_prepareclient was modified in order to include a flag that can
be used to signify whether or not modifications should be done.
/usr/sbin/si_prepareclient --diskless
It looks to see if that flag is there and then calls a function named
diskless(). This function makes use of a perl module,
/usr/lib/systemimager/perl/SystemImager/Diskless.pm, that contains
most of the code that was used in si_mkdiskless.
After the function, diskless(), returns si_prepareclient exits. This
can be changed, it was just seen as a possible annoyance to have some
parts of si_prepareclient to run if the user only wanted the diskless
portion to run.

[Erich Focht]

Hi,

well, actually I was really interested in the details, and from my questions
you could recognize that I at least spent some time to try to understand
some small pieces. Because I was interested in the details I asked questions
and suggested changes. I still think it would help if you guys would comment
on your work...

Regards,
Erich

Post by g***@free.fr
Hi,
I never said the solution is perfect, we needed to have those solutions for a specific study and we do not plan to maintain the diskless solution (and all its different flavors, it is time consuming and we do not have this time).
Our plan was more to submit what we have to the community to see if someone else is interesting. Based on you email, it seems that it is not the case, just i guess you can just forget about the patch (we do not have more resources for further developments, sorry).
Best regards,
----- Mail Original -----
Envoyé: Jeudi 17 Juillet 2008 05:02:23 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support
Hi,
I am curious about the aproach taken but cannot easilly recognize it from
the code. Could you (or the author) please explain what the aproach is? What
is mounted from where, what is exported from where, which directories are
read-only and which are writable? What is the meaning of nfs-root,
ramfs-rsync, ramfs-http?
Is the approach only working for fedora?
Why is the ramdisk built as cramfs? It is uncommon to use anything else than
initramfs (simply buildable with cpio) since many years... If nothing speaks
against initramfs, you should probably switch to that.
Thanks & best regards,
Erich

Post by g***@free.fr
Hi all,
Ferrol has been working on the extension of SystemImager for a diskless support. He did a pretty good job, the implementation being not intrusive.
Please find a description of the modification, a patch for si_prepareclient and a new Perl module for SystemImager that actually implements the diskless support. It does not aim at being perfect but it is a small extension that enables a basic diskless support, and we think the community may be interested by such a capability.
Is it something that could be included directly into SystemImager?
Of course, if you have any questions or remarks, feel free to contact us.
Thanks,
----------------------------
1. The user needs only modify a configuration file. This file is
/etc/systemimager/diskless.conf.
<ip> <path_to_kernel> <method_of_boot>
nfs-root, ramfs-rsync, ramfs-http.
2. /usr/sbin/si_prepareclient was modified in order to include a flag that can
be used to signify whether or not modifications should be done.
/usr/sbin/si_prepareclient --diskless
It looks to see if that flag is there and then calls a function named
diskless(). This function makes use of a perl module,
/usr/lib/systemimager/perl/SystemImager/Diskless.pm, that contains
most of the code that was used in si_mkdiskless.
After the function, diskless(), returns si_prepareclient exits. This
can be changed, it was just seen as a possible annoyance to have some
parts of si_prepareclient to run if the user only wanted the diskless
portion to run.

[g***@free.fr]

Hi,

Let's see:
- nfsroot, means that NFS root is used to setup the diskless environment,
- ramfs-rsync, means that rsync is used to setup the diskless environment (transfer of "images"),
- ramfs-http, means that rsync is used to setup the diskless environment (transfer of "images").

I have to admit that i do not understand what you want me to explain, names are pretty obvious. I can understand that we have a lack of technical documentation but if you want me to explain what is nfsroot and so on, sorry but i do not have the time. About initramfs, this is a technical detail that can easily be fixed but clearly if you expect us to do it, we do not have the resources.

Based on your email, it seems this is a problem (e.g., "you should probably switch to that"); if so, forget about it. I actually plan to maintain my own packages and diffuse them; if someone is interested, it is still possible to take them.

Regards,

----- Mail Original -----
De: "Erich Focht" <***@gmail.com>
À: "geoffroy vallee" <***@free.fr>
Cc: ***@ornl.gov, sisuite-***@lists.sourceforge.net
Envoyé: Jeudi 17 Juillet 2008 13:42:53 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support

Hi,

well, actually I was really interested in the details, and from my questions
you could recognize that I at least spent some time to try to understand
some small pieces. Because I was interested in the details I asked questions
and suggested changes. I still think it would help if you guys would comment
on your work...

Regards,
Erich

Post by g***@free.fr
Hi,
I never said the solution is perfect, we needed to have those solutions for a specific study and we do not plan to maintain the diskless solution (and all its different flavors, it is time consuming and we do not have this time).
Our plan was more to submit what we have to the community to see if someone else is interesting. Based on you email, it seems that it is not the case, just i guess you can just forget about the patch (we do not have more resources for further developments, sorry).
Best regards,
----- Mail Original -----
Envoyé: Jeudi 17 Juillet 2008 05:02:23 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support
Hi,
I am curious about the aproach taken but cannot easilly recognize it from
the code. Could you (or the author) please explain what the aproach is? What
is mounted from where, what is exported from where, which directories are
read-only and which are writable? What is the meaning of nfs-root,
ramfs-rsync, ramfs-http?
Is the approach only working for fedora?
Why is the ramdisk built as cramfs? It is uncommon to use anything else than
initramfs (simply buildable with cpio) since many years... If nothing speaks
against initramfs, you should probably switch to that.
Thanks & best regards,
Erich

Post by g***@free.fr
Hi all,
Ferrol has been working on the extension of SystemImager for a diskless support. He did a pretty good job, the implementation being not intrusive.
Please find a description of the modification, a patch for si_prepareclient and a new Perl module for SystemImager that actually implements the diskless support. It does not aim at being perfect but it is a small extension that enables a basic diskless support, and we think the community may be interested by such a capability.
Is it something that could be included directly into SystemImager?
Of course, if you have any questions or remarks, feel free to contact us.
Thanks,
----------------------------
1. The user needs only modify a configuration file. This file is
/etc/systemimager/diskless.conf.
<ip> <path_to_kernel> <method_of_boot>
nfs-root, ramfs-rsync, ramfs-http.
2. /usr/sbin/si_prepareclient was modified in order to include a flag that can
be used to signify whether or not modifications should be done.
/usr/sbin/si_prepareclient --diskless
It looks to see if that flag is there and then calls a function named
diskless(). This function makes use of a perl module,
/usr/lib/systemimager/perl/SystemImager/Diskless.pm, that contains
most of the code that was used in si_mkdiskless.
After the function, diskless(), returns si_prepareclient exits. This
can be changed, it was just seen as a possible annoyance to have some
parts of si_prepareclient to run if the user only wanted the diskless
portion to run.

[Erich Focht]

... not quite the level of communication I aimed at, but somehow enlightening...

Post by g***@free.fr
Hi,
- nfsroot, means that NFS root is used to setup the diskless environment,

Is this one writable nfsroot? Do all hosts get the same? Is anything else
but the nfsroot mounted?

Post by g***@free.fr
- ramfs-rsync, means that rsync is used to setup the diskless environment (transfer of "images"),

What does "diskless environment" exactly mean? What you transfer is something
like a tmpfs content? How is the NFS coming in and what is mounted by the client,
or what needs to be exported by the server?

Regards,
Erich

Post by g***@free.fr
- ramfs-http, means that rsync is used to setup the diskless environment (transfer of "images").
I have to admit that i do not understand what you want me to explain, names are pretty obvious. I can understand that we have a lack of technical documentation but if you want me to explain what is nfsroot and so on, sorry but i do not have the time. About initramfs, this is a technical detail that can easily be fixed but clearly if you expect us to do it, we do not have the resources.
Based on your email, it seems this is a problem (e.g., "you should probably switch to that"); if so, forget about it. I actually plan to maintain my own packages and diffuse them; if someone is interested, it is still possible to take them.
Regards,
----- Mail Original -----
Envoyé: Jeudi 17 Juillet 2008 13:42:53 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support
Hi,
well, actually I was really interested in the details, and from my questions
you could recognize that I at least spent some time to try to understand
some small pieces. Because I was interested in the details I asked questions
and suggested changes. I still think it would help if you guys would comment
on your work...
Regards,
Erich

Post by g***@free.fr
Hi,
I never said the solution is perfect, we needed to have those solutions for a specific study and we do not plan to maintain the diskless solution (and all its different flavors, it is time consuming and we do not have this time).
Our plan was more to submit what we have to the community to see if someone else is interesting. Based on you email, it seems that it is not the case, just i guess you can just forget about the patch (we do not have more resources for further developments, sorry).
Best regards,
----- Mail Original -----
Envoyé: Jeudi 17 Juillet 2008 05:02:23 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support
Hi,
I am curious about the aproach taken but cannot easilly recognize it from
the code. Could you (or the author) please explain what the aproach is? What
is mounted from where, what is exported from where, which directories are
read-only and which are writable? What is the meaning of nfs-root,
ramfs-rsync, ramfs-http?
Is the approach only working for fedora?
Why is the ramdisk built as cramfs? It is uncommon to use anything else than
initramfs (simply buildable with cpio) since many years... If nothing speaks
against initramfs, you should probably switch to that.
Thanks & best regards,
Erich

Post by g***@free.fr
Hi all,
Ferrol has been working on the extension of SystemImager for a diskless support. He did a pretty good job, the implementation being not intrusive.
Please find a description of the modification, a patch for si_prepareclient and a new Perl module for SystemImager that actually implements the diskless support. It does not aim at being perfect but it is a small extension that enables a basic diskless support, and we think the community may be interested by such a capability.
Is it something that could be included directly into SystemImager?
Of course, if you have any questions or remarks, feel free to contact us.
Thanks,
----------------------------
1. The user needs only modify a configuration file. This file is
/etc/systemimager/diskless.conf.
<ip> <path_to_kernel> <method_of_boot>
nfs-root, ramfs-rsync, ramfs-http.
2. /usr/sbin/si_prepareclient was modified in order to include a flag that can
be used to signify whether or not modifications should be done.
/usr/sbin/si_prepareclient --diskless
It looks to see if that flag is there and then calls a function named
diskless(). This function makes use of a perl module,
/usr/lib/systemimager/perl/SystemImager/Diskless.pm, that contains
most of the code that was used in si_mkdiskless.
After the function, diskless(), returns si_prepareclient exits. This
can be changed, it was just seen as a possible annoyance to have some
parts of si_prepareclient to run if the user only wanted the diskless
portion to run.

[g***@free.fr]

precise questions -> precise answers:

NFSRoot:
- in tftpboot, there are two created directory "shared" and then each compute nodes get his directory for rw mapping.
shared directories: media mnt scratch selinux srv usr
unshared directories: bin dev etc home lib opt proc root sbin sys var
- we using NFsroot, NFSroot is the only solution used _by default_

ramfs-rsync and ramfs-http:
- you boot up a minimal image via PXE, then using rsync or http you download the rest the file system. When the file system is in memory (using tmpfs), we switch root to the new file system.

If you have any other precise questions, Ferrol and I will be happy to answer.

Regards,

----- Mail Original -----
De: "Erich Focht" <***@gmail.com>
À: "geoffroy vallee" <***@free.fr>
Cc: ***@ornl.gov, sisuite-***@lists.sourceforge.net
Envoyé: Jeudi 17 Juillet 2008 14:25:35 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support

... not quite the level of communication I aimed at, but somehow enlightening...

Post by g***@free.fr
Hi,
- nfsroot, means that NFS root is used to setup the diskless environment,

Is this one writable nfsroot? Do all hosts get the same? Is anything else
but the nfsroot mounted?

Post by g***@free.fr
- ramfs-rsync, means that rsync is used to setup the diskless environment (transfer of "images"),

What does "diskless environment" exactly mean? What you transfer is something
like a tmpfs content? How is the NFS coming in and what is mounted by the client,
or what needs to be exported by the server?

Regards,
Erich

Post by g***@free.fr
- ramfs-http, means that rsync is used to setup the diskless environment (transfer of "images").
I have to admit that i do not understand what you want me to explain, names are pretty obvious. I can understand that we have a lack of technical documentation but if you want me to explain what is nfsroot and so on, sorry but i do not have the time. About initramfs, this is a technical detail that can easily be fixed but clearly if you expect us to do it, we do not have the resources.
Based on your email, it seems this is a problem (e.g., "you should probably switch to that"); if so, forget about it. I actually plan to maintain my own packages and diffuse them; if someone is interested, it is still possible to take them.
Regards,
----- Mail Original -----
Envoyé: Jeudi 17 Juillet 2008 13:42:53 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support
Hi,
well, actually I was really interested in the details, and from my questions
you could recognize that I at least spent some time to try to understand
some small pieces. Because I was interested in the details I asked questions
and suggested changes. I still think it would help if you guys would comment
on your work...
Regards,
Erich

Post by g***@free.fr
Hi,
I never said the solution is perfect, we needed to have those solutions for a specific study and we do not plan to maintain the diskless solution (and all its different flavors, it is time consuming and we do not have this time).
Our plan was more to submit what we have to the community to see if someone else is interesting. Based on you email, it seems that it is not the case, just i guess you can just forget about the patch (we do not have more resources for further developments, sorry).
Best regards,
----- Mail Original -----
Envoyé: Jeudi 17 Juillet 2008 05:02:23 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support
Hi,
I am curious about the aproach taken but cannot easilly recognize it from
the code. Could you (or the author) please explain what the aproach is? What
is mounted from where, what is exported from where, which directories are
read-only and which are writable? What is the meaning of nfs-root,
ramfs-rsync, ramfs-http?
Is the approach only working for fedora?
Why is the ramdisk built as cramfs? It is uncommon to use anything else than
initramfs (simply buildable with cpio) since many years... If nothing speaks
against initramfs, you should probably switch to that.
Thanks & best regards,
Erich

Post by g***@free.fr
Hi all,
Ferrol has been working on the extension of SystemImager for a diskless support. He did a pretty good job, the implementation being not intrusive.
Please find a description of the modification, a patch for si_prepareclient and a new Perl module for SystemImager that actually implements the diskless support. It does not aim at being perfect but it is a small extension that enables a basic diskless support, and we think the community may be interested by such a capability.
Is it something that could be included directly into SystemImager?
Of course, if you have any questions or remarks, feel free to contact us.
Thanks,
----------------------------
1. The user needs only modify a configuration file. This file is
/etc/systemimager/diskless.conf.
<ip> <path_to_kernel> <method_of_boot>
nfs-root, ramfs-rsync, ramfs-http.
2. /usr/sbin/si_prepareclient was modified in order to include a flag that can
be used to signify whether or not modifications should be done.
/usr/sbin/si_prepareclient --diskless
It looks to see if that flag is there and then calls a function named
diskless(). This function makes use of a perl module,
/usr/lib/systemimager/perl/SystemImager/Diskless.pm, that contains
most of the code that was used in si_mkdiskless.
After the function, diskless(), returns si_prepareclient exits. This
can be changed, it was just seen as a possible annoyance to have some
parts of si_prepareclient to run if the user only wanted the diskless
portion to run.

[g***@free.fr]

Hi Bernard,

I will try to do that today.

Thanks,

----- Mail Original -----
De: "Bernard Li" <***@vanhpc.org>
À: "geoffroy vallee" <***@free.fr>
Cc: sisuite-***@lists.sourceforge.net, ***@ornl.gov
Envoyé: Jeudi 17 Juillet 2008 17:55:25 GMT -05:00 USA/Canada - États de l'Est
Objet: Re: [Sisuite-devel] patch for a diskless support

Post by Bernard Li
Thanks for letting us know the server is down, will let you know when
it's back up.

trac.systemimager.org has been restored. It would be great if you can
rebase your patch against the code in trunk, and submit it as an
enhancement issue in Trac.

Thanks,

Bernard