Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 8, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion plugins/storage/volume/adaptive/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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"
Expand Down
8 changes: 4 additions & 4 deletions plugins/storage/volume/storpool/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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

Expand All @@ -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
Expand Down
4 changes: 2 additions & 2 deletions tools/docker/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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.

```
Expand Down
8 changes: 4 additions & 4 deletions tools/marvin/marvin/misc/build/CI.md
Original file line number Diff line number Diff line change
Expand Up @@ -72,15 +72,15 @@ 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.

c. dnsmasq - DNS is controlled by cobbler but its configuration of hosts is set within dnsmasq.d/hosts. This is a simple 1-1 mapping of hostnames with IPs. For the most part this should be the single place where one needs to alter for replicating the test setup. Everywhere else only DNS names are/should-be used. open ports 53, 67 on server

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.

Expand All @@ -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.

Expand All @@ -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.

Expand Down
2 changes: 1 addition & 1 deletion ui/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion ui/docs/full-test-plan.template.md
Original file line number Diff line number Diff line change
Expand Up @@ -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**
Expand Down
2 changes: 1 addition & 1 deletion ui/docs/smoke-test-plan.template.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
8 changes: 4 additions & 4 deletions ui/src/style/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,15 @@
## 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'
- default theme @variables
- 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

Expand All @@ -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
Expand All @@ -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)

Expand Down