2
0
mirror of https://github.com/xcat2/xcat-core.git synced 2025-06-12 00:00:12 +00:00

Remove please

This commit is contained in:
Mark Gurevich
2016-10-17 14:00:11 -04:00
parent 76b69ad05d
commit d0b5360a2c
4 changed files with 6 additions and 6 deletions

View File

@ -5,7 +5,7 @@ Docker Registry is a stateless, highly scalable server side application that sto
This document describes how to set up a local private docker registry on Ubuntu 15.04 on x86_64.
**Note:** Please ensure that docker registry is not already set up on this docker host.
**Note:** Ensure that docker registry is not already set up on this docker host.
Setting Up Docker Host
----------------------

View File

@ -81,7 +81,7 @@ Once you attach or ssh to the container, you will find that xCAT is running and
Currently, since xCAT can only generate the diskless osimages of Linux distributions with the same OS version and architecture with xCAT MN. If you need to provision diskless osimages besides ubuntu x86_64 with xCAT running in the Docker, you can use ``imgexport`` and ``imgimport`` to import the diskless osimages generated before.
If you start up the xCAT Docker container by following the steps described in sections above strictly, without specifying "--dns=IP_ADDRESS...", "--dns-search=DOMAIN...", or "--dns-opt=OPTION..." options, Docker uses the /etc/resolv.conf of the host machine (where the docker daemon runs). Any DNS problem inside container, please make sure the DNS server on the Docker host works well.
If you start up the xCAT Docker container by following the steps described in sections above strictly, without specifying "--dns=IP_ADDRESS...", "--dns-search=DOMAIN...", or "--dns-opt=OPTION..." options, Docker uses the /etc/resolv.conf of the host machine (where the docker daemon runs). Any DNS problem inside container, make sure the DNS server on the Docker host works well.
Save and Restore xCAT data
----------------------------

View File

@ -3,7 +3,7 @@ Global Configuration
All the xCAT global configurations are stored in site table, xCAT Admin can adjust the configuration by modifying the site attribute with ``tabedit``.
This section only presents some key global configurations, for the complete reference on the xCAT global configurations, please refer to the ``tabdump -d site``.
This section only presents some key global configurations, for the complete reference on the xCAT global configurations, refer to the ``tabdump -d site``.
Database Attributes
@ -71,7 +71,7 @@ Install/Deployment Attributes
The local directory name used to hold the node deployment packages.
* runbootscripts:
If set to ``yes`` the scripts listed in the postbootscripts attribute in the osimage and postscripts tables will be run during each reboot of stateful (diskful) nodes. This attribute has no effect on stateless nodes. Please run the following command after you change the value of this attribute ::
If set to ``yes`` the scripts listed in the postbootscripts attribute in the osimage and postscripts tables will be run during each reboot of stateful (diskful) nodes. This attribute has no effect on stateless nodes. Run the following command after you change the value of this attribute ::
updatenode <nodes> -P setuppostbootscripts
@ -85,7 +85,7 @@ Install/Deployment Attributes
'1': enable basic debug mode
'2': enable expert debug mode
For the details on 'basic debug mode' and 'expert debug mode', please refer to xCAT documentation.
For the details on 'basic debug mode' and 'expert debug mode', refer to xCAT documentation.
Remoteshell Attributes

View File

@ -32,7 +32,7 @@ Nodes boot from a RAMdisk OS image downloaded from the xCAT mgmt node or service
You can't use a large image with many different applications in the image for varied users, because it uses too much of the node's memory to store the ramdisk. (To mitigate this disadvantage, you can put your large application binaries and libraries in shared storage to reduce the ramdisk size. This requires some manual configuration of the image).
Each node can also have a local "scratch" disk for ``swap``, ``/tmp``, ``/var``, ``log`` files, dumps, etc. The purpose of the scratch disk is to provide a location for files that are written to by the node that can become quite large or for files that you don't want to disappear when the node reboots. There should be nothing put on the scratch disk that represents the node's "state", so that if the disk fails you can simply replace it and reboot the node. A scratch disk would typically be used for situations like: job scheduling preemption is required (which needs a lot of swap space), the applications write large temp files, or you want to keep gpfs log or trace files persistently. (As a partial alternative to using the scratch disk, customers can choose to put ``/tmp`` ``/var/tmp``, and log files (except GPFS logs files) in GPFS, but must be willing to accept the dependency on GPFS). This can be done by enabling the 'localdisk' support. For the details, please refer to the section [TODO Enabling the localdisk Option].
Each node can also have a local "scratch" disk for ``swap``, ``/tmp``, ``/var``, ``log`` files, dumps, etc. The purpose of the scratch disk is to provide a location for files that are written to by the node that can become quite large or for files that you don't want to disappear when the node reboots. There should be nothing put on the scratch disk that represents the node's "state", so that if the disk fails you can simply replace it and reboot the node. A scratch disk would typically be used for situations like: job scheduling preemption is required (which needs a lot of swap space), the applications write large temp files, or you want to keep gpfs log or trace files persistently. (As a partial alternative to using the scratch disk, customers can choose to put ``/tmp`` ``/var/tmp``, and log files (except GPFS logs files) in GPFS, but must be willing to accept the dependency on GPFS). This can be done by enabling the 'localdisk' support. For the details, refer to the section [TODO Enabling the localdisk Option].
OSimage Definition