mirror of
https://github.com/apache/cloudstack.git
synced 2025-10-25 09:12:38 +02:00
pre-commit: enable markdownlint rule MD012 (#9364)
MD012 no-multiple-blanks - Multiple consecutive blank lines https://github.com/DavidAnson/markdownlint/blob/main/doc/md012.md
This commit is contained in:
John Bampton
GitHub
parent
631bba279b
commit
6a2c7b0220
3
.github/linters/.markdown-lint.yml
vendored
3
.github/linters/.markdown-lint.yml
vendored
@ -33,9 +33,6 @@ MD009: false
|
||||
# MD010/no-hard-tabs Hard tabs
|
||||
MD010: false
|
||||
|
||||
# MD012/no-multiple-blanks Multiple consecutive blank lines
|
||||
MD012: false
|
||||
|
||||
# MD013/line-length Line length
|
||||
MD013: false
|
||||
|
||||
|
||||
@ -242,7 +242,6 @@ Bug ID | Description
|
||||
[CLOUDSTACK-7722](https://issues.apache.org/jira/browse/CLOUDSTACK-7722) | add.label: Add button for tags show the label not "Add" text...
|
||||
[CLOUDSTACK-7246](https://issues.apache.org/jira/browse/CLOUDSTACK-7246) | VM deployment failed due to wrong in script name createipalias.sh...
|
||||
|
||||
|
||||
Version 4.4.1
|
||||
-------------
|
||||
|
||||
@ -276,7 +275,6 @@ Bug ID | Description
|
||||
[CLOUDSTACK-1632](https://issues.apache.org/jira/browse/CLOUDSTACK-1632) | Mistakes in authorizeSecurityGroup* API docs...
|
||||
[CLOUDSTACK-401](https://issues.apache.org/jira/browse/CLOUDSTACK-401) | Storage options missing from table...
|
||||
|
||||
|
||||
Version 4.4.0
|
||||
-------------
|
||||
|
||||
@ -930,7 +928,6 @@ Security Fixes:
|
||||
|
||||
* CVE-2012-4501: Apache CloudStack configuration vulnerability
|
||||
|
||||
|
||||
Version 4.0.2
|
||||
------------------------
|
||||
|
||||
@ -979,7 +976,6 @@ Issues fixed in this release:
|
||||
* CLOUDSTACK-2090: Upgrade from version 4.0.1 to version 4.0.2 triggers the 4.0.0 to 4.0.1.
|
||||
* CLOUDSTACK-2091: Error in API documentation for 4.0.x.
|
||||
|
||||
|
||||
Version 4.0.1-incubating
|
||||
------------------------
|
||||
|
||||
@ -1023,7 +1019,6 @@ Bugs fixed in this release:
|
||||
* CLOUDSTACK-961: Installation docs don't detail dependencies for building RPMs
|
||||
* CLOUDSTACK-995: Not able to add the KVM host
|
||||
|
||||
|
||||
Version 4.0.0-incubating
|
||||
------------------------
|
||||
|
||||
@ -1056,7 +1051,6 @@ Security Fixes:
|
||||
|
||||
* CVE-2012-4501: Apache CloudStack configuration vulnerability
|
||||
|
||||
|
||||
Updating this file
|
||||
------------------
|
||||
|
||||
|
||||
@ -51,11 +51,9 @@ $ git fetch upstream
|
||||
$ git rebase upstream/main
|
||||
```
|
||||
|
||||
|
||||
Making changes
|
||||
--------------
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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"
|
||||
|
||||
> 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`.
|
||||
|
||||
|
||||
Rebase `feature_x` to include updates from `upstream/main`
|
||||
------------------------------------------------------------
|
||||
|
||||
@ -92,7 +89,6 @@ $ git rebase main
|
||||
|
||||
> Now your `feature_x` branch is up-to-date with all the code in `upstream/main`.
|
||||
|
||||
|
||||
Make a GitHub Pull Request to contribute your changes
|
||||
-----------------------------------------------------
|
||||
|
||||
@ -118,7 +114,6 @@ To initiate the pull request, do the following:
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Cleaning up after a successful pull request
|
||||
-------------------------------------------
|
||||
|
||||
|
||||
@ -35,17 +35,14 @@ New line separated list of affected versions, commit ID for issues on main branc
|
||||
Information about the configuration if relevant, e.g. basic network, advanced networking, etc. N/A otherwise
|
||||
-->
|
||||
|
||||
|
||||
##### OS / ENVIRONMENT
|
||||
<!--
|
||||
Information about the environment if relevant, N/A otherwise
|
||||
-->
|
||||
|
||||
|
||||
##### SUMMARY
|
||||
<!-- Explain the problem/feature briefly -->
|
||||
|
||||
|
||||
##### STEPS TO REPRODUCE
|
||||
<!--
|
||||
For bugs, show exactly how to reproduce the problem, using a minimal test-case. Use Screenshots if accurate.
|
||||
|
||||
@ -40,10 +40,8 @@ This PR...
|
||||
- [ ] Minor
|
||||
- [ ] Trivial
|
||||
|
||||
|
||||
### Screenshots (if appropriate):
|
||||
|
||||
|
||||
### How Has This Been Tested?
|
||||
|
||||
<!-- Please describe in detail how you tested your changes. -->
|
||||
@ -53,5 +51,4 @@ This PR...
|
||||
|
||||
<!-- see how your change affects other areas of the code, etc. -->
|
||||
|
||||
|
||||
<!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document -->
|
||||
|
||||
@ -11,7 +11,6 @@ Secondary storage stores the following:
|
||||
* ISO images — disc images containing data or bootable media for operating systems
|
||||
* Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
|
||||
|
||||
|
||||
### ROOT and DATA volumes
|
||||
|
||||
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
|
||||
DATA volumes correspond to additional disks. These can be created by users and then attached/detached to VMs.
|
||||
DATA volumes are created based on a user-defined disk offering.
|
||||
|
||||
|
||||
## Plugin Organization
|
||||
|
||||
The StorPool plugin consists of two parts:
|
||||
@ -49,7 +47,6 @@ that does pretty much the same.
|
||||
Note that for the present the StorPool plugin may only be used for a single primary storage cluster; support for
|
||||
multiple clusters is planned.
|
||||
|
||||
|
||||
## Build, Install, Setup
|
||||
|
||||
### Build
|
||||
@ -122,7 +119,6 @@ SP_TEMPLATE - name of StorPool's template
|
||||
Storage Tags: If left blank, the StorPool storage plugin will use the pool name to create a corresponding storage tag.
|
||||
This storage tag may be used later, when defining service or disk offerings.
|
||||
|
||||
|
||||
## Plugin Functionality
|
||||
|
||||
<table cellpadding="5">
|
||||
@ -361,7 +357,6 @@ Users who were using the offerings to change the StorPool template via the `SP_T
|
||||
- `resizeVolume` API call for DATA disk
|
||||
- `scaleVirtualMachine` API call for ROOT disk
|
||||
|
||||
|
||||
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.
|
||||
|
||||
<h4>Usage</h4>
|
||||
@ -374,7 +369,6 @@ Add disk offering detail with API call in CloudStack CLI.
|
||||
|
||||
add resourcedetail resourcetype=diskoffering resourceid=$UUID details[0].key=SP_QOSCLASS details[0].value=$Tier Name
|
||||
|
||||
|
||||
Creating VM with QoS
|
||||
|
||||
Deploy virtual machine: Go to Compute> Instances> Add Instances.
|
||||
|
||||
@ -71,15 +71,11 @@ The included VagrantFile will give you:
|
||||
|
||||
#### For Advanced Networking you will need:
|
||||
|
||||
|
||||
|
||||
##### vboxnet1
|
||||
- IPv4 IP address of 192.168.23.1
|
||||
- Subnet of 255.255.255.0
|
||||
- DHCP server disabled
|
||||
|
||||
|
||||
|
||||
##### vboxnet2
|
||||
- IPv4 IP address of 192.168.24.1
|
||||
- Subnet of 255.255.255.0
|
||||
|
||||
@ -21,7 +21,6 @@
|
||||
- Subnet of 255.255.255.0
|
||||
- DHCP server disabled
|
||||
|
||||
|
||||
### Start the vagrant boxes
|
||||
|
||||
```bash
|
||||
@ -33,7 +32,6 @@ vagrant up
|
||||
- 'Cannot forward the specified ports on this VM': There could be MySQL or some other
|
||||
service running on the host OS causing vagrant to fail setting up local port forwarding.
|
||||
|
||||
|
||||
### Start Cloudstack
|
||||
|
||||
1. Clone the Cloudstack Repository:
|
||||
|
||||
@ -11,7 +11,6 @@
|
||||
- Subnet of 255.255.255.0
|
||||
- DHCP server disabled
|
||||
|
||||
|
||||
### Start the vagrant boxes
|
||||
|
||||
```bash
|
||||
@ -23,7 +22,6 @@ vagrant up
|
||||
- 'Cannot forward the specified ports on this VM': There could be MySQL or some other
|
||||
service running on the host OS causing vagrant to fail setting up local port forwarding.
|
||||
|
||||
|
||||
### Start Cloudstack
|
||||
|
||||
1. Clone the Cloudstack Repository:
|
||||
|
||||
@ -2,10 +2,8 @@
|
||||
|
||||
Dockerfiles used to build CloudStack images are available on Docker hub.
|
||||
|
||||
|
||||
## Using images from docker-hub
|
||||
|
||||
|
||||
### CloudStack Simulator
|
||||
|
||||
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.
|
||||
@ -90,7 +88,6 @@ docker run -ti --rm --link simulator:8096 \
|
||||
|
||||
Image provided by CloudStack are automatically built by Jenkins performing following tasks:
|
||||
|
||||
|
||||
### CentOS 6
|
||||
|
||||
CentOS 6 image use RPM's from jenkins.buildacloud.org
|
||||
@ -114,7 +111,6 @@ tag:latest = main branch
|
||||
docker commit -m "init system.iso" -a "Apache CloudStack" cloudstack cloudstack/management_centos6
|
||||
```
|
||||
|
||||
|
||||
### Marvin
|
||||
|
||||
Build Marvin container usable to deploy cloud in the CloudStack management server container.
|
||||
|
||||
@ -15,7 +15,6 @@
|
||||
# specific language governing permissions and limitations
|
||||
# under the License.
|
||||
|
||||
|
||||
about
|
||||
=====
|
||||
|
||||
@ -34,7 +33,6 @@ components
|
||||
. scheduling
|
||||
. networking setup
|
||||
|
||||
|
||||
[insert diagram here]
|
||||
|
||||
The above illustration shows a high-level view of the test infrastructure setup. In this section we explain the tools and their organization in the infrastructure. The workflow detailed in a later section shows how this setup works together:
|
||||
@ -96,7 +94,6 @@ b. multiple cluster
|
||||
c. inter-zone tests
|
||||
d. multi-pod tests
|
||||
|
||||
|
||||
marvin integration
|
||||
==================
|
||||
|
||||
|
||||
@ -15,7 +15,6 @@
|
||||
#specific language governing permissions and limitations
|
||||
#under the License.
|
||||
|
||||
|
||||
#Cloud AutoDeploy
|
||||
|
||||
Scripts here are used to refresh the builds of the management server with those
|
||||
|
||||
@ -60,7 +60,6 @@ import the new section's (newconfig.js as example) configuration file and rules
|
||||
|
||||
generateRouterMap(newSection),
|
||||
|
||||
|
||||
### Section
|
||||
|
||||
An existing or new section's config/js file must export the following parameters:
|
||||
@ -81,7 +80,6 @@ An existing or new section's config/js file must export the following parameters
|
||||
- `component`: When children is not defined, the custom component for rendering
|
||||
the route view
|
||||
|
||||
|
||||
See `src/config/section/compute.js` and `src/config/section/project.js` for example.
|
||||
|
||||
The children should have:
|
||||
|
||||
@ -38,7 +38,6 @@
|
||||
7. components
|
||||
- complex elements like dropdown, forms, table, search (usually include this to components/FooterToolbar/ folder)
|
||||
|
||||
|
||||
# The "/deep/" combinator
|
||||
- use the /deep/ combinator (or in other versions ">>>") helps us to exclude "scoped" rules into global
|
||||
- e.g. <style scoped> .a .b .c {}</style> will scope a generated data ID like .a .b .c[data-abcde] {}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user