You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
-5Lines changed: 0 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,11 +51,9 @@ $ git fetch upstream
51
51
$ git rebase upstream/main
52
52
```
53
53
54
-
55
54
Making changes
56
55
--------------
57
56
58
-
59
57
It is important that you create a new branch to make changes on and that you do not change the `main` branch (other than to rebase in changes from `upstream/main`). In this example I will assume you will be making your changes to a branch called `feature_x`. This `feature_x` branch will be created on your local repository and will be pushed to your forked repository on GitHub. Once this branch is on your fork you will create a Pull Request for the changes to be added to the ACS project.
60
58
61
59
It is best practice to create a new branch each time you want to contribute to the project and only track the changes for that pull request in this branch.
@@ -70,7 +68,6 @@ $ git commit -a -m "descriptive commit message for your changes"
70
68
71
69
> The `-b` specifies that you want to create a new branch called `feature_x`. You only specify `-b` the first time you checkout because you are creating a new branch. Once the `feature_x` branch exists, you can later switch to it with only `git checkout feature_x`.
72
70
73
-
74
71
Rebase `feature_x` to include updates from `upstream/main`
@@ -118,7 +114,6 @@ To initiate the pull request, do the following:
118
114
119
115
If you are requested to make modifications to your proposed changes, make the changes locally on your `feature_x` branch, re-push the `feature_x` branch to your fork. The existing pull request should automatically pick up the change and update accordingly.
Copy file name to clipboardExpand all lines: plugins/storage/volume/storpool/README.md
-6Lines changed: 0 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,6 @@ Secondary storage stores the following:
11
11
* ISO images — disc images containing data or bootable media for operating systems
12
12
* Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
13
13
14
-
15
14
### ROOT and DATA volumes
16
15
17
16
ROOT volumes correspond to the boot disk of a VM. They are created automatically by CloudStack during VM creation.
@@ -21,7 +20,6 @@ is based on. We may change the ROOT volume disk offering but only to another sys
21
20
DATA volumes correspond to additional disks. These can be created by users and then attached/detached to VMs.
22
21
DATA volumes are created based on a user-defined disk offering.
23
22
24
-
25
23
## Plugin Organization
26
24
27
25
The StorPool plugin consists of two parts:
@@ -49,7 +47,6 @@ that does pretty much the same.
49
47
Note that for the present the StorPool plugin may only be used for a single primary storage cluster; support for
50
48
multiple clusters is planned.
51
49
52
-
53
50
## Build, Install, Setup
54
51
55
52
### Build
@@ -122,7 +119,6 @@ SP_TEMPLATE - name of StorPool's template
122
119
Storage Tags: If left blank, the StorPool storage plugin will use the pool name to create a corresponding storage tag.
123
120
This storage tag may be used later, when defining service or disk offerings.
124
121
125
-
126
122
## Plugin Functionality
127
123
128
124
<tablecellpadding="5">
@@ -361,7 +357,6 @@ Users who were using the offerings to change the StorPool template via the `SP_T
361
357
-`resizeVolume` API call for DATA disk
362
358
-`scaleVirtualMachine` API call for ROOT disk
363
359
364
-
365
360
If the disk offering has both `SP_TEMPLATE` and `SP_QOSCLASS` defined, the `SP_QOSCLASS` detail will be prioritised, setting the volume’s QoS using the respective ‘qc’ tag value. In case the QoS for a volume is changed manually, the ‘storpool_qos’ service will automatically reset the QoS limits following the ‘qc’ tag value once per minute.
366
361
367
362
<h4>Usage</h4>
@@ -374,7 +369,6 @@ Add disk offering detail with API call in CloudStack CLI.
374
369
375
370
add resourcedetail resourcetype=diskoffering resourceid=$UUID details[0].key=SP_QOSCLASS details[0].value=$Tier Name
376
371
377
-
378
372
Creating VM with QoS
379
373
380
374
Deploy virtual machine: Go to Compute> Instances> Add Instances.
Copy file name to clipboardExpand all lines: tools/docker/README.md
-4Lines changed: 0 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,10 +2,8 @@
2
2
3
3
Dockerfiles used to build CloudStack images are available on Docker hub.
4
4
5
-
6
5
## Using images from docker-hub
7
6
8
-
9
7
### CloudStack Simulator
10
8
11
9
CloudStack Simulator is an all in one CloudStack Build including the simulator that mimic Hypervisor. This is useful to test CloudStack API behavior without having to deploy real hypervisor nodes. CloudStack Simulator is used for tests and CI.
0 commit comments