Hi all,
I''m sending this to the public list since I see no reason to keep it
secret. I have a few items I''d like to add to our requirements if
nobody objects:
1. The serial console via our service processor needs to work. I saw
several cases at our beta site where they didn''t. Here''s a
specific
list of things that need to work when connected to the service processor
via ssh:
a. BIOS - view POST screens, interact with configuration screens.
b. Bootloader (grub) - view all messages, break the automated boot,
interact with the menu (if installed) and command line.
c. Kernel console messages need to be viewable.
d. Userland console messages need to be viewable.
e. A getty that you can login to and interact with needs to be setup.
All these things must work out of the box. Additionally, it would be
nice to use the highest baud rate that still allows all these things to
work reliably.
2. I thought this was obvious, but my experience at our beta site shows
that it was not: the head node must run Linux. Solaris''s userland lags
behind Linux in several important ways, and it must be possible for
anyone to use the system without having to face these issues. Our
customers are expecting a Linux system, so that is what we should give
them.
Assuming you all agree, who can work on these? Larry, can you add them
to our requirements or is someone else maintaining that?
Cheers,
Jody
You are right in the need for both of these, and they have been targeted (with Ihara looking at a few of the tools). Right now, Ihara has been taking a look at freeipmi, which includes ipmiconsole. The question is whether it will work well, and if it does, if it will work at a high enough baud rate. Another option (and a very good opensource console management application) is conman (http://home.gna.org/conman/). Many BIOS'' have an option of "Console after boot" (or something along those lines). What will generally happen is (if this is not enabled) you will see the POST screens, but once the boot loader/PXE boot takes over you see nothing until linux kicks in. The Console After Boot option will capture the boot loader output and put it to serial as well. One issue that can be seen with this is with the handling, sometimes whatever is doing the translation within the hardware doesn''t really like the console after boot stuff, and will hang the system. So, this is just something that needs to be tried. As for linux on the front-end ... I highly agree. The thought of having any other OS type within a linux cluster is laughable (from my viewpoint) and a poor idea in general. You can see this in many flavors: requiring solaris for xvm, requiring windows for firmware upgrades. This is something that we have to fight against as best as we can, and provide the means to make sure for OS homogeneity. Jody McIntyre wrote:> Hi all, > > I''m sending this to the public list since I see no reason to keep it > secret. I have a few items I''d like to add to our requirements if > nobody objects: > > 1. The serial console via our service processor needs to work. I saw > several cases at our beta site where they didn''t. Here''s a specific > list of things that need to work when connected to the service processor > via ssh: > > a. BIOS - view POST screens, interact with configuration screens. > > b. Bootloader (grub) - view all messages, break the automated boot, > interact with the menu (if installed) and command line. > > c. Kernel console messages need to be viewable. > > d. Userland console messages need to be viewable. > > e. A getty that you can login to and interact with needs to be setup. > > All these things must work out of the box. Additionally, it would be > nice to use the highest baud rate that still allows all these things to > work reliably. > > 2. I thought this was obvious, but my experience at our beta site shows > that it was not: the head node must run Linux. Solaris''s userland lags > behind Linux in several important ways, and it must be possible for > anyone to use the system without having to face these issues. Our > customers are expecting a Linux system, so that is what we should give > them. > > Assuming you all agree, who can work on these? Larry, can you add them > to our requirements or is someone else maintaining that? > > Cheers, > Jody > _______________________________________________ > Linux_hpc_swstack mailing list > Linux_hpc_swstack at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/linux_hpc_swstack-- "I don''t want to be the hamster in this wheel of insanity."
Jody, I wonder if you encountered some anomalies because typically via the console in the SP item a. should not be a problem. Item b. should work with the correct console redirect string at boot so that you can see c. and d. Or maybe I am misinterpreting what you are pointing out. But, regarding your beta site I am familiar with the problems you encountered and can say they should not be the norm and in my limited experience are not. Mike On Mar 6, 2008, at 10:55 AM, Jody McIntyre wrote:> Hi all, > > I''m sending this to the public list since I see no reason to keep it > secret. I have a few items I''d like to add to our requirements if > nobody objects: > > 1. The serial console via our service processor needs to work. I saw > several cases at our beta site where they didn''t. Here''s a specific > list of things that need to work when connected to the service > processor > via ssh: > > a. BIOS - view POST screens, interact with configuration screens. > > b. Bootloader (grub) - view all messages, break the automated boot, > interact with the menu (if installed) and command line. > > c. Kernel console messages need to be viewable. > > d. Userland console messages need to be viewable. > > e. A getty that you can login to and interact with needs to be setup. > > All these things must work out of the box. Additionally, it would be > nice to use the highest baud rate that still allows all these things > to > work reliably. > > 2. I thought this was obvious, but my experience at our beta site > shows > that it was not: the head node must run Linux. Solaris''s userland > lags > behind Linux in several important ways, and it must be possible for > anyone to use the system without having to face these issues. Our > customers are expecting a Linux system, so that is what we should give > them. > > Assuming you all agree, who can work on these? Larry, can you add > them > to our requirements or is someone else maintaining that? > > Cheers, > Jody > _______________________________________________ > Linux_hpc_swstack mailing list > Linux_hpc_swstack at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/linux_hpc_swstack
Hi Jody, I agree with you. The regarding BIOS, I''m working that ipmiconsole (including in freeIPMI) can be fit for this area. And also, we can gather the console messages using the "netconsole" to one node (like log server). Thanks, -Ihara -------- Original Message --------> Hi all, > > I''m sending this to the public list since I see no reason to keep it > secret. I have a few items I''d like to add to our requirements if > nobody objects: > > 1. The serial console via our service processor needs to work. I saw > several cases at our beta site where they didn''t. Here''s a specific > list of things that need to work when connected to the service processor > via ssh: > > a. BIOS - view POST screens, interact with configuration screens. > > b. Bootloader (grub) - view all messages, break the automated boot, > interact with the menu (if installed) and command line. > > c. Kernel console messages need to be viewable. > > d. Userland console messages need to be viewable. > > e. A getty that you can login to and interact with needs to be setup. > > All these things must work out of the box. Additionally, it would be > nice to use the highest baud rate that still allows all these things to > work reliably. > > 2. I thought this was obvious, but my experience at our beta site shows > that it was not: the head node must run Linux. Solaris''s userland lags > behind Linux in several important ways, and it must be possible for > anyone to use the system without having to face these issues. Our > customers are expecting a Linux system, so that is what we should give > them. > > Assuming you all agree, who can work on these? Larry, can you add them > to our requirements or is someone else maintaining that? > > Cheers, > Jody > _______________________________________________ > Linux_hpc_swstack mailing list > Linux_hpc_swstack at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/linux_hpc_swstack
I agree with Mike that you may have encountered issues at the site where you were using Early Access systems that had HW problems that are being rectified. All of the items listed in item 1 should be supported and are recognized as requirements. Also we are working with some open tools that will provide access for the list you have expressed the need and requirements for but these are also supported today via console redirection on the products and should work. Mike Berg wrote On 03/06/08 14:18,:>Jody, > >I wonder if you encountered some anomalies because typically via the >console in the SP item a. should not be a problem. Item b. should work >with the correct console redirect string at boot so that you can see >c. and d. Or maybe I am misinterpreting what you are pointing out. > >But, regarding your beta site I am familiar with the problems you >encountered and can say they should not be the norm and in my limited >experience are not. > >Mike > >On Mar 6, 2008, at 10:55 AM, Jody McIntyre wrote: > > > >>Hi all, >> >>I''m sending this to the public list since I see no reason to keep it >>secret. I have a few items I''d like to add to our requirements if >>nobody objects: >> >>1. The serial console via our service processor needs to work. I saw >>several cases at our beta site where they didn''t. Here''s a specific >>list of things that need to work when connected to the service >>processor >>via ssh: >> >>a. BIOS - view POST screens, interact with configuration screens. >> >>b. Bootloader (grub) - view all messages, break the automated boot, >> interact with the menu (if installed) and command line. >> >>c. Kernel console messages need to be viewable. >> >>d. Userland console messages need to be viewable. >> >>e. A getty that you can login to and interact with needs to be setup. >> >>All these things must work out of the box. Additionally, it would be >>nice to use the highest baud rate that still allows all these things >>to >>work reliably. >> >>2. I thought this was obvious, but my experience at our beta site >>shows >>that it was not: the head node must run Linux. Solaris''s userland >>lags >>behind Linux in several important ways, and it must be possible for >>anyone to use the system without having to face these issues. Our >>customers are expecting a Linux system, so that is what we should give >>them. >> >>Assuming you all agree, who can work on these? Larry, can you add >>them >>to our requirements or is someone else maintaining that? >> >>Cheers, >>Jody >>_______________________________________________ >>Linux_hpc_swstack mailing list >>Linux_hpc_swstack at lists.lustre.org >>http://lists.lustre.org/mailman/listinfo/linux_hpc_swstack >> >> > >_______________________________________________ >Linux_hpc_swstack mailing list >Linux_hpc_swstack at lists.lustre.org >http://lists.lustre.org/mailman/listinfo/linux_hpc_swstack > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/linux_hpc_swstack/attachments/20080306/21709978/attachment-0002.html
Hi Makia, On Thu, Mar 06, 2008 at 01:10:42PM -0500, Makia Minich wrote:> You are right in the need for both of these, and they have been targeted > (with Ihara looking at a few of the tools). Right now, Ihara has been > taking a look at freeipmi, which includes ipmiconsole. The question is > whether it will work well, and if it does, if it will work at a high > enough baud rate. Another option (and a very good opensource console > management application) is conman (http://home.gna.org/conman/).I''ve used conman before and it''s good. If ipmiconsole can do the same job and is easier for us to deploy, we can use that too. Conman does a few nice things (that I''m aware of) so we should make sure whatever solution we choose allows: - Console sharing between more than one user. - A simple command line tool to access the console of a given node. This could be a wrapper script, but I don''t want people having to memorize the incantations I had to use at our beta site. - Console logging, per node. E.g. /var/log/conman/console.client6. My original point is that aside from the tool we use to access the console and log its output, everything (BIOS, boot loader, messages, and getty) needs to work reliably, and our team needs to take responsibility for configuring and testing this. Cheers, Jody> Many BIOS'' have an option of "Console after boot" (or something along > those lines). What will generally happen is (if this is not enabled) > you will see the POST screens, but once the boot loader/PXE boot takes > over you see nothing until linux kicks in. The Console After Boot > option will capture the boot loader output and put it to serial as well. > One issue that can be seen with this is with the handling, sometimes > whatever is doing the translation within the hardware doesn''t really > like the console after boot stuff, and will hang the system. So, this > is just something that needs to be tried. > > As for linux on the front-end ... I highly agree. The thought of having > any other OS type within a linux cluster is laughable (from my > viewpoint) and a poor idea in general. You can see this in many > flavors: requiring solaris for xvm, requiring windows for firmware > upgrades. This is something that we have to fight against as best as we > can, and provide the means to make sure for OS homogeneity. > > Jody McIntyre wrote: > >Hi all, > > > >I''m sending this to the public list since I see no reason to keep it > >secret. I have a few items I''d like to add to our requirements if > >nobody objects: > > > >1. The serial console via our service processor needs to work. I saw > >several cases at our beta site where they didn''t. Here''s a specific > >list of things that need to work when connected to the service processor > >via ssh: > > > > a. BIOS - view POST screens, interact with configuration screens. > > > > b. Bootloader (grub) - view all messages, break the automated boot, > > interact with the menu (if installed) and command line. > > > > c. Kernel console messages need to be viewable. > > > > d. Userland console messages need to be viewable. > > > > e. A getty that you can login to and interact with needs to be setup. > > > >All these things must work out of the box. Additionally, it would be > >nice to use the highest baud rate that still allows all these things to > >work reliably. > > > >2. I thought this was obvious, but my experience at our beta site shows > >that it was not: the head node must run Linux. Solaris''s userland lags > >behind Linux in several important ways, and it must be possible for > >anyone to use the system without having to face these issues. Our > >customers are expecting a Linux system, so that is what we should give > >them. > > > >Assuming you all agree, who can work on these? Larry, can you add them > >to our requirements or is someone else maintaining that? > > > >Cheers, > >Jody > >_______________________________________________ > >Linux_hpc_swstack mailing list > >Linux_hpc_swstack at lists.lustre.org > >http://lists.lustre.org/mailman/listinfo/linux_hpc_swstack > > -- > "I don''t want to be the hamster in this wheel of insanity."--
Hi Ihara, On Fri, Mar 07, 2008 at 09:10:27AM +0900, Shuichi Ihara wrote:> I agree with you. The regarding BIOS, I''m working that ipmiconsole > (including in freeIPMI) can be fit for this area.OK. See my previous email - can ipmiconsole support all of this?> And also, we can gather the console messages using the "netconsole" to > one node (like log server).Good idea, but that has to be _in addition to_ console access and logging. There''s no way netconsole can handle BIOS and boot loader messages, and I don''t believe it offers a way to interact with the console. Cheers, Jody> > Thanks, > > -Ihara > > -------- Original Message -------- > > >Hi all, > > > >I''m sending this to the public list since I see no reason to keep it > >secret. I have a few items I''d like to add to our requirements if > >nobody objects: > > > >1. The serial console via our service processor needs to work. I saw > >several cases at our beta site where they didn''t. Here''s a specific > >list of things that need to work when connected to the service processor > >via ssh: > > > > a. BIOS - view POST screens, interact with configuration screens. > > > > b. Bootloader (grub) - view all messages, break the automated boot, > > interact with the menu (if installed) and command line. > > > > c. Kernel console messages need to be viewable. > > > > d. Userland console messages need to be viewable. > > > > e. A getty that you can login to and interact with needs to be setup. > > > >All these things must work out of the box. Additionally, it would be > >nice to use the highest baud rate that still allows all these things to > >work reliably. > > > >2. I thought this was obvious, but my experience at our beta site shows > >that it was not: the head node must run Linux. Solaris''s userland lags > >behind Linux in several important ways, and it must be possible for > >anyone to use the system without having to face these issues. Our > >customers are expecting a Linux system, so that is what we should give > >them. > > > >Assuming you all agree, who can work on these? Larry, can you add them > >to our requirements or is someone else maintaining that? > > > >Cheers, > >Jody > >_______________________________________________ > >Linux_hpc_swstack mailing list > >Linux_hpc_swstack at lists.lustre.org > >http://lists.lustre.org/mailman/listinfo/linux_hpc_swstack >--
I should mention that I believe conman can be a front end to freeipmi (though it''s been a while for me). Also, looking at the Release Notes, I see that Conman''s last update was for Sun''s ILOM. Just wanted to mention that and that I highly agree with what you''re saying. Jody McIntyre wrote:> Hi Makia, > > On Thu, Mar 06, 2008 at 01:10:42PM -0500, Makia Minich wrote: >> You are right in the need for both of these, and they have been targeted >> (with Ihara looking at a few of the tools). Right now, Ihara has been >> taking a look at freeipmi, which includes ipmiconsole. The question is >> whether it will work well, and if it does, if it will work at a high >> enough baud rate. Another option (and a very good opensource console >> management application) is conman (http://home.gna.org/conman/). > > I''ve used conman before and it''s good. If ipmiconsole can do the same > job and is easier for us to deploy, we can use that too. Conman does a > few nice things (that I''m aware of) so we should make sure whatever > solution we choose allows: > > - Console sharing between more than one user. > > - A simple command line tool to access the console of a given node. > This could be a wrapper script, but I don''t want people having to > memorize the incantations I had to use at our beta site. > > - Console logging, per node. E.g. /var/log/conman/console.client6. > > My original point is that aside from the tool we use to access the > console and log its output, everything (BIOS, boot loader, messages, and > getty) needs to work reliably, and our team needs to take responsibility > for configuring and testing this. > > Cheers, > Jody > > >> Many BIOS'' have an option of "Console after boot" (or something along >> those lines). What will generally happen is (if this is not enabled) >> you will see the POST screens, but once the boot loader/PXE boot takes >> over you see nothing until linux kicks in. The Console After Boot >> option will capture the boot loader output and put it to serial as well. >> One issue that can be seen with this is with the handling, sometimes >> whatever is doing the translation within the hardware doesn''t really >> like the console after boot stuff, and will hang the system. So, this >> is just something that needs to be tried. >> >> As for linux on the front-end ... I highly agree. The thought of having >> any other OS type within a linux cluster is laughable (from my >> viewpoint) and a poor idea in general. You can see this in many >> flavors: requiring solaris for xvm, requiring windows for firmware >> upgrades. This is something that we have to fight against as best as we >> can, and provide the means to make sure for OS homogeneity. >> >> Jody McIntyre wrote: >>> Hi all, >>> >>> I''m sending this to the public list since I see no reason to keep it >>> secret. I have a few items I''d like to add to our requirements if >>> nobody objects: >>> >>> 1. The serial console via our service processor needs to work. I saw >>> several cases at our beta site where they didn''t. Here''s a specific >>> list of things that need to work when connected to the service processor >>> via ssh: >>> >>> a. BIOS - view POST screens, interact with configuration screens. >>> >>> b. Bootloader (grub) - view all messages, break the automated boot, >>> interact with the menu (if installed) and command line. >>> >>> c. Kernel console messages need to be viewable. >>> >>> d. Userland console messages need to be viewable. >>> >>> e. A getty that you can login to and interact with needs to be setup. >>> >>> All these things must work out of the box. Additionally, it would be >>> nice to use the highest baud rate that still allows all these things to >>> work reliably. >>> >>> 2. I thought this was obvious, but my experience at our beta site shows >>> that it was not: the head node must run Linux. Solaris''s userland lags >>> behind Linux in several important ways, and it must be possible for >>> anyone to use the system without having to face these issues. Our >>> customers are expecting a Linux system, so that is what we should give >>> them. >>> >>> Assuming you all agree, who can work on these? Larry, can you add them >>> to our requirements or is someone else maintaining that? >>> >>> Cheers, >>> Jody >>> _______________________________________________ >>> Linux_hpc_swstack mailing list >>> Linux_hpc_swstack at lists.lustre.org >>> http://lists.lustre.org/mailman/listinfo/linux_hpc_swstack >> -- >> "I don''t want to be the hamster in this wheel of insanity." >-- "I don''t want to be the hamster in this wheel of insanity."
On Fri, 2008-03-07 at 11:55 -0500, Jody McIntyre wrote:> Hi Makia,Hi All. I hope you don''t mind my poking my nose in.> I''ve used conman before and it''s good.Indeed.> If ipmiconsole can do the same > job and is easier for us to deploy,I''ve not used ipmiconsole but it sounds narrowly focused and single-purposed -- for controlling impi type consoles only. AFAIU, conman can talk to impi devices as well as a zillion (or nearly) other devices, so provides a nice general, consistent abstraction to the console and is open source, so easily adapted to future devices. General abstractions to lots of devices (past, current and future) is better than adopting an interface to today''s (only) technology and having to retrain and redocument a new interface when a new technology is used.> so we should make sure whatever > solution we choose allows: > > - Console sharing between more than one user. > > - A simple command line tool to access the console of a given node. > This could be a wrapper script, but I don''t want people having to > memorize the incantations I had to use at our beta site. > > - Console logging, per node. E.g. /var/log/conman/console.client6.- provides a consistent interface to many pieces of hardware, past, present and future. Cheers, b.
Apparently this reply got stuck in the system (we''re still working the kinks out). Brian J. Murrell wrote:> On Fri, 2008-03-07 at 11:55 -0500, Jody McIntyre wrote: >> Hi Makia, > > Hi All. I hope you don''t mind my poking my nose in. > >> I''ve used conman before and it''s good. > > Indeed. > >> If ipmiconsole can do the same >> job and is easier for us to deploy, > > I''ve not used ipmiconsole but it sounds narrowly focused and > single-purposed -- for controlling impi type consoles only. AFAIU, > conman can talk to impi devices as well as a zillion (or nearly) other > devices, so provides a nice general, consistent abstraction to the > console and is open source, so easily adapted to future devices. > General abstractions to lots of devices (past, current and future) is > better than adopting an interface to today''s (only) technology and > having to retrain and redocument a new interface when a new technology > is used.You are correct, conman is a much better choice for this as it allows us to provide a common frontend (common command line) to just about any console method out there. Pair this with powerman, and now we have a great power/console combination. Both allow for easy additions of new hardware.>> so we should make sure whatever >> solution we choose allows: >> >> - Console sharing between more than one user. >> >> - A simple command line tool to access the console of a given node. >> This could be a wrapper script, but I don''t want people having to >> memorize the incantations I had to use at our beta site. >> >> - Console logging, per node. E.g. /var/log/conman/console.client6. > > - provides a consistent interface to many pieces of hardware, past, > present and future.Quite right, this is a very important feature.> Cheers, > b. > > > _______________________________________________ > Linux_hpc_swstack mailing list > Linux_hpc_swstack at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/linux_hpc_swstack-- "A simile is not a lie, unless it is a bad simile." - Christopher John Francis Boone