apache/cloudstack
1
0
Fork 0
mirror of https://github.com/apache/cloudstack.git synced 2025-10-26 08:42:29 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: fixes grammar and spelling in Markdown files only (#10656)

Browse Source
This commit is contained in:
John Bampton 2025-04-08 20:44:14 +10:00 committed by GitHub
parent fd3d605dd1
commit f206137f83
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
8 changed files with 18 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
plugins/storage/volume/adaptive/README.md
View File

@ -34,7 +34,7 @@ name=storage-volume-<providername>
parent=storage
```
### Spring Bean Context Configuration
This provides instructions of which provider implementation class to load when the Spring bean initilization is running.
This provides instructions of which provider implementation class to load when the Spring bean initialization is running.
```
<!-- resources/META-INF/cloudstack/storage-volume-<providername>/spring-storage-volume-<providername>-context.xml -->
<beans xmlns="http://www.springframework.org/schema/beans"

8
plugins/storage/volume/storpool/README.md
View File

@ -39,7 +39,7 @@ independent parts:
* ./src/com/... directory tree: agent related classes and commands send from management to agent
* ./src/org/... directory tree: management related classes
The plugin is intended to be self contained and non-intrusive, thus ideally deploying it would consist of only
The plugin is intended to be self-contained and non-intrusive, thus ideally deploying it would consist of only
dropping the jar file into the appropriate places. This is the reason why all StorPool related communication
(ex. data copying, volume resize) is done with StorPool specific commands even when there is a CloudStack command
that does pretty much the same.
@ -183,7 +183,7 @@ This storage tag may be used later, when defining service or disk offerings.
<td>takeSnapshot + copyAsync (S => S)</td>
</tr>
<tr>
<td>Create volume from snapshoot</td>
<td>Create volume from snapshot</td>
<td>create volume from snapshot</td>
<td>management + agent(?)</td>
<td>copyAsync (S => V)</td>
@ -279,7 +279,7 @@ In this case only snapshots won't be downloaded to secondary storage.
#### If bypass option is enabled
The snapshot exists only on PRIMARY (StorPool) storage. From this snapshot it will be created a template on SECONADRY.
The snapshot exists only on PRIMARY (StorPool) storage. From this snapshot it will be created a template on SECONDARY.
#### If bypass option is disabled
@ -290,7 +290,7 @@ This is independent of StorPool as snapshots exist on secondary.
### Creating ROOT volume from templates
When creating the first volume based on the given template, if snapshot of the template does not exists on StorPool it will be first downloaded (cached) to PRIMARY storage.
This is mapped to a StorPool snapshot so, creating succecutive volumes from the same template does not incur additional
This is mapped to a StorPool snapshot so, creating successive volumes from the same template does not incur additional
copying of data to PRIMARY storage.
This cached snapshot is garbage collected when the original template is deleted from CloudStack. This cleanup is done

4
tools/docker/README.md
View File

@ -58,7 +58,7 @@ docker run -ti --name cloudstack --link cloudstack-mysql:mysql -d -p 8080:8080 -
### Marvin
Use marvin to deploy or test your CloudStack environment.
Use Marvin with cloudstack connection thru the API port (8096)
Use Marvin with cloudstack connection through the API port (8096)
```
docker pull cloudstack/marvin
@ -99,7 +99,7 @@ tag:latest = main branch
docker build -f Dockerfile.centos6 -t cloudstack/management_centos6 .
```
2. on jenkins, database and systemvm.iso are pre-deployed. the inital start require privileged container to
2. on jenkins, database and systemvm.iso are pre-deployed. the initial start require privileged container to
mount systemvm.iso and copy ssh_rsa.pub into it.
```

8
tools/marvin/marvin/misc/build/CI.md
View File

@ -72,7 +72,7 @@ systems - these are virtual/physical infrastructure mapped to cobbler profiles b
When a new image needs to be added we create a 'distro' in cobbler and associate that with a profile's kickstart. Any new systems to be hooked-up to be serviced by the profile can then be added easily by cmd line.
b. Puppet master - Cobbler reimages machines on-demand but it is upto puppet recipes to do configuration management within them. The configuration management is required for kvm hypervisors (kvm agent for eg:) and for the cloudstack management server which needs mysql, cloudstack, etc. The puppetmasterd daemon on the driver-vm is responsible for 'kicking' nodes to initiate configuration management on themselves when they come alive.
b. Puppet master - Cobbler reimages machines on-demand, but it is upto puppet recipes to do configuration management within them. The configuration management is required for kvm hypervisors (kvm agent for eg:) and for the cloudstack management server which needs mysql, cloudstack, etc. The puppetmasterd daemon on the driver-vm is responsible for 'kicking' nodes to initiate configuration management on themselves when they come alive.
So the driver-vm is also the repository of all the puppet recipes for various modules that need to be configured for the test infrastructure to work. The modules are placed in /etc/puppet and bear the same structure as our GitHub repo. When we need to affect a configuration change on any of our systems we only change the GitHub repo and the systems in place are affected upon next run.
@ -80,7 +80,7 @@ c. dnsmasq - DNS is controlled by cobbler but its configuration of hosts is set
d. dhcp - DHCP is also done by dnsmasq. All configuration is in /etc/dnsmasq.conf. static mac-ip-name mappings are given for hypervisors while the virtual instances get dynamic ips
e. ipmitool - ipmi for power management is setup on all the test servers and the ipmitool provides a convienient cli for booting the machines on the network into PXEing.
e. ipmitool - ipmi for power management is setup on all the test servers and the ipmitool provides a convenient cli for booting the machines on the network into PXEing.
f. jenkins-slave - jenkins slave.jar is placed on the driver-vm as a service in /etc/init.d to react to jenkins schedules and to post reports to. The slave runs in headless mode as the driver-vm does not run X.
@ -99,7 +99,7 @@ d. multi-pod tests
marvin integration
==================
once cloudstack has been installed and the hypervisors prepared we are ready to use marvin to stitch together zones, pods, clusters and compute and storage to put together a 'cloud'. once configured - we perform a cursory health check to see if we have all systemVMs running in all zones and that built-in templates are downloaded in all zones. Subsequently we are able to launch tests on this environment
once cloudstack has been installed and the hypervisors prepared we are ready to use marvin to stitch together zones, pods, clusters and compute and storage to put together a 'cloud'. once configured - we perform a cursory health check to see if we have all systemVMs running in all zones and that built-in templates are downloaded in all zones. Subsequently, we are able to launch tests on this environment
Only the latest tests from git are run on the setup. This allows us to test in a pseudo-continuous fashion with a nightly build deployed on the environment. Each test run takes a few hours to finish.
@ -121,7 +121,7 @@ When jenkins triggers the job following sequence of actions occur on the test in
3. we fetch the last successful marvin build from builds.a.o and install it within this virtualenv. installing a new marvin on each run helps us test with the latest APIs available.
4. we fetch the latest version of the driver script from github:cloud-autodeploy. fetching the latest allows us to make adjustments to the infra without having to copy scripts in to the test infrastrcuture.
4. we fetch the latest version of the driver script from github:cloud-autodeploy. fetching the latest allows us to make adjustments to the infra without having to copy scripts in to the test infrastructure.
5. based on the hypervisor chosen we choose a profile for cobbler to reimage the hosts in the infrastructure. if xen is chosen we bring up the profile of the latest xen kickstart available in cobbler. currently - this is at xen 6.0.2. if kvm is chosen we can pick between ubuntu and rhel based host OS kickstarts.

2
ui/README.md
View File

@ -62,7 +62,7 @@ Fix issues and vulnerabilities:
npm audit
A basic development guide and explaination of the basic components can be found
A basic development guide and explanation of the basic components can be found
[here](docs/development.md)
## Production

2
ui/docs/full-test-plan.template.md
View File

@ -484,7 +484,7 @@ This requires configuring and setting up CKS: http://docs.cloudstack.apache.org/
- [ ] Disable/enable host
- [ ] Enable/cancel maintenance mode
- [ ] Enable/disable out-of-band management
- [ ] Enable/disale HA
- [ ] Enable/disable HA
- [ ] Delete host (only if disabled)
**Infrastructure > Primary Storage**

2
ui/docs/smoke-test-plan.template.md
View File

@ -58,7 +58,7 @@ This requires configuring and setting up CKS: http://docs.cloudstack.apache.org/
**VPC**
- [ ] Add VPC
- [ ] VPC actions - updat, restart, delete
- [ ] VPC actions - update, restart, delete
- [ ] Add security group
- [ ] Add/delete ingress/egress rule

8
ui/src/style/README.md
View File

@ -5,7 +5,7 @@
## main .less entry points:
1. dist/antd.less
- imports everthing with index.less + components.less
- imports everything with index.less + components.less
2. lib/style/index.less
- themes/default.less
- color/colors'
@ -13,7 +13,7 @@
- core/index.less
- includes base styles, motion rules and iconfont
# src/style/ explaination
# src/style/ explanation
- index.less includes ant styles, as well as all custom variables and rules
@ -25,7 +25,7 @@
- include all rules that reset styles, define global stuffs without classes at all
- e.g. body {} p, ul, li {} h1, h2, h3 {}
3. ant-overwrite
- any styles that overwrites the existin ant rules by any reason
- any styles that overwrites the existing ant rules by any reason
- e.g. classes like .ant-layout-header .anticon {}
4. frame
- everything that belongs to the frame
@ -34,7 +34,7 @@
- rules that modify the page at all if new layout class is set.
- e.g. #html class="layout-ant-black"#
6. objects
- repeatly used elements like buttons, inputs
- repeatedly used elements like buttons, inputs
7. components
- complex elements like dropdown, forms, table, search (usually include this to components/FooterToolbar/ folder)