Return-Path: X-Original-To: apmail-incubator-cloudstack-commits-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-commits-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F20C5D94F for ; Mon, 19 Nov 2012 14:11:35 +0000 (UTC) Received: (qmail 24697 invoked by uid 500); 19 Nov 2012 14:11:34 -0000 Delivered-To: apmail-incubator-cloudstack-commits-archive@incubator.apache.org Received: (qmail 24573 invoked by uid 500); 19 Nov 2012 14:11:34 -0000 Mailing-List: contact cloudstack-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-commits@incubator.apache.org Received: (qmail 22202 invoked by uid 99); 19 Nov 2012 14:11:29 -0000 Received: from tyr.zones.apache.org (HELO tyr.zones.apache.org) (140.211.11.114) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Nov 2012 14:11:29 +0000 Received: by tyr.zones.apache.org (Postfix, from userid 65534) id 0F02B314A1A; Mon, 19 Nov 2012 14:11:29 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: ke4qqq@apache.org To: cloudstack-commits@incubator.apache.org X-Mailer: ASF-Git Admin Mailer Subject: [21/29] cleaning up docs temp, publish directories - adding gitignore entries for them for the future Message-Id: <20121119141129.0F02B314A1A@tyr.zones.apache.org> Date: Mon, 19 Nov 2012 14:11:29 +0000 (UTC) http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/private-public-template.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/private-public-template.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/private-public-template.html deleted file mode 100644 index f23387a..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/private-public-template.html +++ /dev/null @@ -1,16 +0,0 @@ - - -12.5. Private and Public Templates

Product SiteDocumentation Site

12.5. Private and Public Templates

- When a user creates a template, it can be designated private or public. -
- Private templates are only available to the user who created them. By default, an uploaded template is private. -
- When a user marks a template as “public,” the template becomes available to all users in all accounts in the user's domain, as well as users in any other domains that have access to the Zone where the template is stored. This depends on whether the Zone, in turn, was defined as private or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any domain. If a public template is created in a private Zone, it is available only to users in the domain assigned to that Zone. If a public template is created in a public Zone, it is available to all users in all domains. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects-overview.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects-overview.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects-overview.html deleted file mode 100644 index 630cb40..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects-overview.html +++ /dev/null @@ -1,18 +0,0 @@ - - -6.1. Overview of Projects

Product SiteDocumentation Site

6.1. Overview of Projects

- Projects are used to organize people and resources. CloudStack users within a single domain can group themselves into project teams so they can collaborate and share virtual resources such as VMs, snapshots, templates, data disks, and IP addresses. CloudStack tracks resource usage per project as well as per user, so the usage can be billed to either a user account or a project. For example, a private cloud within a software company might have all members of the QA department assigned to one project, so the company can track the resources used in testing while the project members can more easily isolate their efforts from other users of the same cloud -
- You can configure CloudStack to allow any user to create a new project, or you can restrict that ability to just CloudStack administrators. Once you have created a project, you become that project’s administrator, and you can add others within your domain to the project. CloudStack can be set up either so that you can add people directly to a project, or so that you have to send an invitation which the recipient must accept. Project members can view and manage all virtual resources created by anyone in the project (for example, share VMs). A user can be a member of any number of projects and can switch views in the CloudStack UI to show only project-related information, such as project VMs, fellow project members, project-related alerts, and so on. -
- The project administrator can pass on the role to another project member. The project administrator can also add more members, remove members from the project, set new resource limits (as long as they are below the global defaults set by the CloudStack administrator), and delete the project. When the administrator removes a member from the project, resources created by that user, such as VM instances, remain with the project. This brings us to the subject of resource ownership and which resources can be used by a project. -
- Resources created within a project are owned by the project, not by any particular CloudStack account, and they can be used only within the project. A user who belongs to one or more projects can still create resources outside of those projects, and those resources belong to the user’s account; they will not be counted against the project’s usage or resource limits. You can create project-level networks to isolate traffic within the project and provide network services such as port forwarding, load balancing, VPN, and static NAT. A project can also make use of certain types of resources from outside the project, if those resources are shared. For example, a shared network or public template is available to any project in the domain. A project can get access to a private template if the template’s owner will grant permission. A project can use any service offering or disk offering available in its domain; however, you can not create private service and disk offerings at the p roject level.. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects.html deleted file mode 100644 index 07939ab..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects.html +++ /dev/null @@ -1,10 +0,0 @@ - - -Chapter 6. Using Projects to Organize Users and Resources

Product SiteDocumentation Site

http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-auth-api.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-auth-api.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-auth-api.html deleted file mode 100644 index 91c9aa1..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-auth-api.html +++ /dev/null @@ -1,14 +0,0 @@ - - -20.1. Provisioning and Authentication API

Product SiteDocumentation Site

20.1. Provisioning and Authentication API

- CloudStack expects that a customer will have their own user provisioning infrastructure. It provides APIs to integrate with these existing systems where the systems call out to CloudStack to add/remove users.. -
- CloudStack supports pluggable authenticators. By default, CloudStack assumes it is provisioned with the user’s password, and as a result authentication is done locally. However, external authentication is possible as well. For example, see Using an LDAP Server for User Authentication. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-steps-overview.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-steps-overview.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-steps-overview.html deleted file mode 100644 index 4897af2..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-steps-overview.html +++ /dev/null @@ -1,32 +0,0 @@ - - -7.1. Overview of Provisioning Steps

Product SiteDocumentation Site

7.1. Overview of Provisioning Steps

- After the Management Server is installed and running, you can add the compute resources for it to manage. For an overview of how a CloudStack cloud infrastructure is organized, see Section 1.3.2, “Cloud Infrastructure Overview”. -
- To provision the cloud infrastructure, or to scale it up at any time, follow these procedures: -
  1. - Change the root password. See Section 5.1.4, “Changing the Root Password”. -
  2. - Add a zone. See Section 7.2, “Adding a Zone”. -
  3. - Add more pods (optional). See Section 7.3, “Adding a Pod”. -
  4. - Add more clusters (optional). See Section 7.4, “Adding a Cluster”. -
  5. - Add more hosts (optional). See Section 7.5, “Adding a Host”. -
  6. - Add primary storage. See Section 7.6, “Add Primary Storage”. -
  7. - Add secondary storage. See Section 7.7, “Add Secondary Storage”. -
  8. - Initialize and test the new cloud. See Section 7.8, “Initialize and Test”. -
- When you have finished these steps, you will have a deployment with the following basic structure: -
provisioning-overview.png: Conceptual overview of a basic deployment
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-steps.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-steps.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-steps.html deleted file mode 100644 index 284484b..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/provisioning-steps.html +++ /dev/null @@ -1,12 +0,0 @@ - - -Chapter 7. Steps to Provisioning Your Cloud Infrastructure

Product SiteDocumentation Site

http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/re-install-hosts.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/re-install-hosts.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/re-install-hosts.html deleted file mode 100644 index f1159ae..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/re-install-hosts.html +++ /dev/null @@ -1,12 +0,0 @@ - - -11.5. Re-Installing Hosts

Product SiteDocumentation Site

11.5. Re-Installing Hosts

- You can re-install a host after placing it in maintenance mode and then removing it. If a host is down and cannot be placed in maintenance mode, it should still be removed before the re-install. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/release-ip-address.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/release-ip-address.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/release-ip-address.html deleted file mode 100644 index c3afd51..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/release-ip-address.html +++ /dev/null @@ -1,24 +0,0 @@ - - -15.12. Releasing an IP Address

Product SiteDocumentation Site

15.12. Releasing an IP Address

  1. - Log in to the CloudPlatform UI as an administrator or end user. -
  2. - In the left navigation, choose Network. -
  3. - Click the name of the network where you want to work with. -
  4. - Click View IP Addresses. -
  5. - Click the IP address you want to release. -
  6. - Click the Release IP button - ReleaseIPButton.png: button to release an IP - . -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/removing-hosts.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/removing-hosts.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/removing-hosts.html deleted file mode 100644 index a9f497e..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/removing-hosts.html +++ /dev/null @@ -1,26 +0,0 @@ - - -11.4. Removing Hosts

Product SiteDocumentation Site

11.4. Removing Hosts

- Hosts can be removed from the cloud as needed. The procedure to remove a host depends on the hypervisor type. -

11.4.1. Removing XenServer and KVM Hosts

- A node cannot be removed from a cluster until it has been placed in maintenance mode. This will ensure that all of the VMs on it have been migrated to other Hosts. To remove a Host from the cloud: -
  1. - Place the node in maintenance mode. -
    - See Section 11.2, “Scheduled Maintenance and Maintenance Mode for Hosts”. -
  2. - For KVM, stop the cloud-agent service. -
  3. - Use the UI option to remove the node. -
    - Then you may power down the Host, re-use its IP address, re-install it, etc -

11.4.2. Removing vSphere Hosts

- To remove this type of host, first place it in maintenance mode, as described in Section 11.2, “Scheduled Maintenance and Maintenance Mode for Hosts”. Then use CloudStack to remove the host. CloudStack will not direct commands to a host that has been removed using CloudStack. However, the host may still exist in the vCenter cluster. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/requirements-templates.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/requirements-templates.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/requirements-templates.html deleted file mode 100644 index 05cfd32..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/requirements-templates.html +++ /dev/null @@ -1,14 +0,0 @@ - - -12.2. Requirements for Templates

Product SiteDocumentation Site

12.2. Requirements for Templates

  • - For XenServer, install PV drivers / Xen tools on each template that you create. This will enable live migration and clean guest shutdown. -
  • - For vSphere, install VMware Tools on each template that you create. This will enable console view to work properly. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/responses.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/responses.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/responses.html deleted file mode 100644 index a21f9a1..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/responses.html +++ /dev/null @@ -1,49 +0,0 @@ - - -4.4. Responses

Product SiteDocumentation Site

4.4. Responses

4.4.1. Response Formats: XML and JSON

- CloudStack supports two formats as the response to an API call. The default response is XML. If you would like the response to be in JSON, add &response=json to the Command String. -
- Sample XML Response: - 
-     <listipaddressesresponse> 
-        <allocatedipaddress>
-        <ipaddress>192.168.10.141</ipaddress> 
-        <allocated>2009-09-18T13:16:10-0700</allocated> 
-        <zoneid>4</zoneid> 
-            <zonename>WC</zonename> 
-            <issourcenat>true</issourcenat> 
-        </allocatedipaddress>
-     </listipaddressesresponse>
-
- Sample JSON Response: - 
-        { "listipaddressesresponse" : 
-          { "allocatedipaddress" :
-            [ 
-              { 
-                "ipaddress" : "192.168.10.141", 
-                "allocated" : "2009-09-18T13:16:10-0700",
-                "zoneid" : "4", 
-                "zonename" : "WC", 
-                "issourcenat" : "true" 
-              } 
-            ]
-          } 
-        } 
-

4.4.2. Maximum Result Pages Returned

- For each cloud, there is a default upper limit on the number of results that any API command will return in a single page. This is to help prevent overloading the cloud servers and prevent DOS attacks. For example, if the page size limit is 500 and a command returns 10,000 results, the command will return 20 pages. -
- The default page size limit can be different for each cloud. It is set in the global configuration parameter default.page.size. If your cloud has many users with lots of VMs, you might need to increase the value of this parameter. At the same time, be careful not to set it so high that your site can be taken down by an enormous return from an API call. For more information about how to set global configuration parameters, see "Describe Your Deployment" in the Installation Guide. -
- To decrease the page size limit for an individual API command, override the global setting with the page and pagesize parameters, which are available in any list* command (listCapabilities, listDiskOfferings, etc.). -
  • - Both parameters must be specified together. -
  • - The value of the pagesize parameter must be smaller than the value of default.page.size. That is, you can not increase the number of possible items in a result page, only decrease it. -
- For syntax information on the list* commands, see the API Reference. -

4.4.3. Error Handling

- If an error occurs while processing an API request, the appropriate response in the format specified is returned. Each error response consists of an error code and an error text describing what possibly can go wrong. For an example error response, see page 12. -
- An HTTP error code of 401 is always returned if API request was rejected due to bad signatures, missing API Keys, or the user simply did not have the permissions to execute the command. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/roles.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/roles.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/roles.html deleted file mode 100644 index 18e91d1..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/roles.html +++ /dev/null @@ -1,11 +0,0 @@ - - -2.1. Roles

Product SiteDocumentation Site

2.1. Roles

- The CloudPlatform API supports three access roles: -
  1. - Root Admin. Access to all features of the cloud, including both virtual and physical resource management. -
  2. - Domain Admin. Access to only the virtual resources of the clouds that belong to the administrator’s domain. -
  3. - User. Access to only the features that allow management of the user’s virtual instances, storage, and network. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/scheduled-maintenance-maintenance-mode-hosts.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/scheduled-maintenance-maintenance-mode-hosts.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/scheduled-maintenance-maintenance-mode-hosts.html deleted file mode 100644 index 57f5371..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/scheduled-maintenance-maintenance-mode-hosts.html +++ /dev/null @@ -1,12 +0,0 @@ - - -11.2. Scheduled Maintenance and Maintenance Mode for Hosts

Product SiteDocumentation Site

11.2. Scheduled Maintenance and Maintenance Mode for Hosts

- You can place a host into maintenance mode. When maintenance mode is activated, the host becomes unavailable to receive new guest VMs, and the guest VMs already running on the host are seamlessly migrated to another host not in maintenance mode. This migration uses live migration technology and does not interrupt the execution of the guest. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-add.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-add.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-add.html deleted file mode 100644 index e596025..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-add.html +++ /dev/null @@ -1,32 +0,0 @@ - - -7.7. Add Secondary Storage

Product SiteDocumentation Site

7.7. Add Secondary Storage

7.7.1. System Requirements for Secondary Storage

  • - NFS storage appliance or Linux NFS server -
  • - (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org) -
  • - 100GB minimum capacity -
  • - A secondary storage device must be located in the same zone as the guest VMs it serves. -
  • - Each Secondary Storage server must be available to all hosts in the zone. -

7.7.2. Adding Secondary Storage

- When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone. -

Warning

- Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data. -
  1. - If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to CloudStack before you add the local zone secondary storage servers. See Section 7.2, “Adding a Zone”. -
  2. - To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See Preparing NFS Shares in the Installation Guide. -
  3. - Make sure you prepared the system VM template during Management Server installation. See Prepare the System VM Template in the Installation Guide. -
  4. - Now that the secondary storage server for per-zone storage is prepared, add it to CloudStack. Secondary storage is added as part of the procedure for adding a new zone. See Section 7.2, “Adding a Zone”. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-outage-and-data-loss.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-outage-and-data-loss.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-outage-and-data-loss.html deleted file mode 100644 index 675afa8..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-outage-and-data-loss.html +++ /dev/null @@ -1,14 +0,0 @@ - - -17.5. Secondary Storage Outage and Data Loss

Product SiteDocumentation Site

17.5. Secondary Storage Outage and Data Loss

- For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online. -
- Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-vm.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-vm.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-vm.html deleted file mode 100644 index 02245cb..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage-vm.html +++ /dev/null @@ -1,18 +0,0 @@ - - -16.5. Secondary Storage VM

Product SiteDocumentation Site

16.5. Secondary Storage VM

- In addition to the hosts, CloudStack’s Secondary Storage VM mounts and writes to secondary storage. -
- Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols. -
- The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups. -
- The administrator can log in to the secondary storage VM if needed. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage.html deleted file mode 100644 index 41d7433..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/secondary-storage.html +++ /dev/null @@ -1,12 +0,0 @@ - - -13.3. Secondary Storage

Product SiteDocumentation Site

13.3. Secondary Storage

- This section gives concepts and technical details about CloudStack secondary storage. For information about how to install and configure secondary storage through the CloudStack UI, see the Advanced Installation Guide. -
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/35666a52/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/sect-source-builddebs.html ---------------------------------------------------------------------- diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/sect-source-builddebs.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/sect-source-builddebs.html deleted file mode 100644 index 5456d26..0000000 --- a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/sect-source-builddebs.html +++ /dev/null @@ -1,54 +0,0 @@ - - -3.5. Building DEB packages

Product SiteDocumentation Site

3.5. Building DEB packages

- In addition to the bootstrap dependencies, you'll also need to install several other dependencies. Note that we recommend using Maven 3, which is not currently available in 12.04.1 LTS. So, you'll also need to add a PPA repository that includes Maven 3. After running the command add-apt-repository, you will be prompted to continue and a GPG key will be added. - 
-$ sudo apt-get update
-$ sudo apt-get install python-software-properties
-$ sudo add-apt-repository ppa:natecarlson/maven3
-$ sudo apt-get update
-$ sudo apt-get install ant debhelper openjdk-6-jdk tomcat6 libws-commons-util-java genisoimage python-mysqldb libcommons-codec-java libcommons-httpclient-java liblog4j1.2-java maven3
- While we have defined, and you have presumably already installed the bootstrap prerequisites, there are a number of build time prerequisites that need to be resolved. CloudStack uses maven for dependency resolution. You can resolve the buildtime depdencies for CloudStack by running: - 
$ mvn3 -P deps
- Now that we have resolved the dependencies we can move on to building CloudStack and packaging them into DEBs by issuing the following command. - 
-$ dpkg-buildpackge -uc -us
- This command will build 16 Debian packages. You should have all of the following: - 
-cloud-agent_4.0.0-incubating_amd64.deb
-cloud-agent-deps_4.0.0-incubating_amd64.deb
-cloud-agent-libs_4.0.0-incubating_amd64.deb
-cloud-awsapi_4.0.0-incubating_amd64.deb
-cloud-cli_4.0.0-incubating_amd64.deb
-cloud-client_4.0.0-incubating_amd64.deb
-cloud-client-ui_4.0.0-incubating_amd64.deb
-cloud-core_4.0.0-incubating_amd64.deb
-cloud-deps_4.0.0-incubating_amd64.deb
-cloud-python_4.0.0-incubating_amd64.deb
-cloud-scripts_4.0.0-incubating_amd64.deb
-cloud-server_4.0.0-incubating_amd64.deb
-cloud-setup_4.0.0-incubating_amd64.deb
-cloud-system-iso_4.0.0-incubating_amd64.deb
-cloud-usage_4.0.0-incubating_amd64.deb
-cloud-utils_4.0.0-incubating_amd64.deb
-

3.5.1. Setting up an APT repo

- After you've created the packages, you'll want to copy them to a system where you can serve the packages over HTTP. You'll create a directory for the packages and then use dpkg-scanpackages to create Packages.gz, which holds information about the archive structure. Finally, you'll add the repository to your system(s) so you can install the packages using APT. -
- The first step is to make sure that you have the dpkg-dev package installed. This should have been installed when you pulled in the debhelper application previously, but if you're generating Packages.gz on a different system, be sure that it's installed there as well. - 
$ sudo apt-get install dpkg-dev
- The next step is to copy the DEBs to the directory where they can be served over HTTP. We'll use /var/www/cloudstack/repo in the examples, but change the directory to whatever works for you. - 
-sudo mkdir -p /var/www/cloudstack/repo/binary
-sudo cp *.deb /var/www/cloudstack/repo/binary
-sudo cd /var/www/cloudstack/repo/binary
-sudo dpkg-scanpackages . /dev/null | tee Packages | gzip -9 > Packages.gz

Note: Override Files

- You can safely ignore the warning about a missing override file. -
- Now you should have all of the DEB packages and Packages.gz in the binary directory and available over HTTP. (You may want to use wget or curl to test this before moving on to the next step.) -

3.5.2. Configuring your machines to use the APT repository

- Now that we have created the repository, you need to configure your machine to make use of the APT repository. You can do this by adding a repository file under /etc/apt/sources.list.d. Use your preferred editor to create /etc/apt/sources.list.d/cloudstack.list with this line: - 
deb http://server.url/cloudstack/repo binary/
- Now that you have the repository info in place, you'll want to run another update so that APT knows where to find the CloudStack packages. - 
$ sudo apt-get update
- You can now move on to the instructions under Install on Ubuntu. -