Skip to content
Permalink
Browse files
Tool for consistent documentation generation (#810)
  • Loading branch information
ishank011 committed Jun 9, 2020
1 parent f57a621 commit fa72def88033bf9d1d1da2843e26f67d4666b3b2
Showing 63 changed files with 87 additions and 56 deletions.

This file was deleted.

@@ -8,8 +8,8 @@ menu:
weight: 20
---

This is the documentation for the Reva project.
This is the documentation for the Reva project.

We recommend you to start reading the [Overview]({{< ref "docs/Overview" >}}).
We recommend you to start reading the [Overview]({{< ref "docs/overview" >}}).

If you find a typo or you want to contribute to the documentation go to [Contribution Guidelines]({{< ref "docs/Contribution Guidelines" >}}).
If you find a typo or you want to contribute to the documentation go to [Contribution Guidelines]({{< ref "docs/contribution-guidelines" >}}).
File renamed without changes.
@@ -1,7 +1,7 @@
---
title: "Concepts"
linkTitle: "Concepts"
weight: 4
weight: 10
description: >
What does your user need to understand about your project in order to use it - or potentially contribute to it?
---
File renamed without changes.
@@ -1,7 +1,7 @@
---
title: "Configuration"
linkTitle: "Configuration"
weight: 3
weight: 10
description: >
Configuration reference for all Reva directives
---
@@ -1,7 +1,7 @@
---
title: "Core"
linkTitle: "Core"
weight: 1
weight: 5
description: >
Directives to tweak the running Reva process.
---
@@ -1,7 +1,7 @@
---
title: "GRPC"
linkTitle: "GRPC"
weight: 11
weight: 10
description: >
Configuration reference for GRPC
---
@@ -7,7 +7,7 @@ description: >
---

{{% dir name="network" type="string" default="tcp" %}}
Specifies the network type.
Specifies the network type.
{{< highlight toml >}}
[http]
network = "tcp"
@@ -1,7 +1,7 @@
---
title: "Log"
linkTitle: "Log"
weight: 2
weight: 5
description: >
Directives to configure the logging system
---
@@ -0,0 +1,7 @@
---
title: "Packages"
linkTitle: "Packages"
weight: 10
description: >
Configuration reference for utility packages
---
@@ -8,7 +8,7 @@ description: >

This guide gives a basic introduction to Reva and describes some simple tasks that can be done with it.
This guide assumes that Reva is already installed on the reader's machine.
If this isn't the case refer to [Install Reva]({{< relref "docs/Getting Started/install-reva" >}})
If this isn't the case refer to [Install Reva]({{< relref "docs/getting-started/install-reva" >}})

This guide describes how to start and stop the **Reva daemon (revad)**, and reload its configuration, explains the structure of the configuration
file and describes how to set up revad to serve some basic services.
@@ -44,7 +44,7 @@ If you don't specify the pid file with the -p flag Reva will create one in the O
You can always obtain the location of the file from the logs
{{% /alert %}}

Once revad is started, it can be controlled by invoking the executable with the -s parameter. Use the following syntax:
Once revad is started, it can be controlled by invoking the executable with the -s parameter. Use the following syntax:

```
revad -s <signal> -p /var/tmp/revad.pid
@@ -56,7 +56,7 @@ Where signal may be one of the following:
* quit — graceful shutdown
* reload — reloading the configuration file (forks a new process)

For example, to stop revad gracefully, the following command can be executed:
For example, to stop revad gracefully, the following command can be executed:

```
revad -s quit -p /var/tmp/revad.pid
@@ -66,27 +66,27 @@ revad -s quit -p /var/tmp/revad.pid
This command should be executed under the same user that started the server.
{{% /alert %}}

Changes made in the configuration file will not be applied until the command to reload configuration is sent to revad. Let's reload the config:
Changes made in the configuration file will not be applied until the command to reload configuration is sent to revad. Let's reload the config:

```
revad -s reload -p /var/tmp/revad.pid
```

Once the main process receives the signal to reload configuration, it checks the syntax validity of the new configuration file and tries to apply the configuration provided in it. If this is a success, the main process forks a new process. The new forked process will gracefully kill the parent process. During a period of time until all ongoing requests are served, both processes will share the same network socket, the old parent process will serve ongoing requests and the new process will serve only new requests. No requests are dropped during the reload. If the provided configuration is invalid, the forked process will die and the master process will continue serving requests.

A signal may also be sent to the revad process with the help of Unix tools such as the *kill* utility. In this case a signal is sent directly to a process with a given process ID. The process ID of the revad master process is written to the pid file, as configured with the *-s* flag. For example, if the master process ID is 1610, to send the QUIT signal resulting in revad’s graceful shutdown, execute:
A signal may also be sent to the revad process with the help of Unix tools such as the *kill* utility. In this case a signal is sent directly to a process with a given process ID. The process ID of the revad master process is written to the pid file, as configured with the *-s* flag. For example, if the master process ID is 1610, to send the QUIT signal resulting in revad’s graceful shutdown, execute:

```
kill -s QUIT 1610
```

For getting the list of all running revad processes, the *ps* utility may be used, for example, in the following way:
For getting the list of all running revad processes, the *ps* utility may be used, for example, in the following way:

```
ps -ax | grep revad
```

For more information on sending signals to revad, see [Controlling Reva]({{< ref "docs/Getting Started/control-reva" >}}).
For more information on sending signals to revad, see [Controlling Reva]({{< ref "docs/getting-started/control-reva" >}}).

## Running your first service

@@ -132,5 +132,4 @@ Let's analyze the output:

**Congratulations, you've run your first Reva service!**

You can head to [Tutorials]({{< ref "docs/Tutorials" >}}) to find more advanced guides.

You can head to [Tutorials]({{< ref "docs/tutorials" >}}) to find more advanced guides.
@@ -11,12 +11,12 @@ description: >
Reva is an open source platform developed in the Go programming language with two purposes:

1. As an interoperability platform to link platforms with the storage and application providers.
2. As the reference implementation of the CS3APIS.
2. As the reference implementation of the CS3APIS.

#### The problem we try to solve

Today any cloud sync and share provider either closed-source (Dropbox, Google Drive, ...) or open source (ownCloud, Seafile, ...) have their own catalogue
of integrations with many applicaition providers. The pitty about these integrations is that they are ad-hoc to the cloud vendor, making it impossible to port
of integrations with many applicaition providers. The pitty about these integrations is that they are ad-hoc to the cloud vendor, making it impossible to port
anywhere else.

{{< imgproc "overview.png" Fit "800x600" >}}
@@ -25,8 +25,8 @@ anywhere else.
#### The goal

Our ultimate goal is that any open source project and software vendor that provides either storage or applications to an EFSS platform
will adopt the CS3APIS as the facto standard way to collaborate. Having all the partners using the same APIs will enable all of us for a new dimension
of portability of applications across vendors.
will adopt the CS3APIS as the facto standard way to collaborate. Having all the partners using the same APIs will enable all of us for a new dimension
of portability of applications across vendors.

{{< imgproc "final.png" Fit "800x600">}}
{{< /imgproc >}}
@@ -38,7 +38,7 @@ In the mean time, we have another approach to make these systems talk to each ot
#### The approach with Reva

The motivation is to move out the ad-hoc APIs from the sync and share platform to Reva. As Reva is a vendor-neutral and open source
project we expect that many institutions and application providers will contribute with their ad-hoc APIs to Reva, creating an inter-operability platform
project we expect that many institutions and application providers will contribute with their ad-hoc APIs to Reva, creating an inter-operability platform
that could potencially connect to an eco-system of applications and storage catalogs as never seen before.

The platform acts as middleware component in your current infrastructure, and by connecting your cloud to Reva you gain access
@@ -56,12 +56,11 @@ How many times have you been using an app that you lost when you switched cloud
and runs alongside your infrastructure.

* **What is it *not yet* good for?**: Reva is still very young to be used in production. We are working hard to reach a stable version soon with decent integrations to storage
and applications. We don't want to re-invent the wheel so we have in mind that Reva will provide integrations with [rclone](https://rclone.org/) for multiple-storage support and with other protocols out there like [WOPI](https://wopi.readthedocs.io/en/latest/)
and applications. We don't want to re-invent the wheel so we have in mind that Reva will provide integrations with [rclone](https://rclone.org/) for multiple-storage support and with other protocols out there like [WOPI](https://wopi.readthedocs.io/en/latest/)
, [Learning Tools Interoperability](https://www.imsglobal.org/activity/learning-tools-interoperability) and
[OpenCloudMesh](https://rawgit.com/GEANT/OCM-API/v1/docs.html) to enable seamless collaboration.

## Where should I go next?

* [Getting Started]({{< ref "docs/Getting Started" >}}): Get started with the project
* [Concepts]({{< ref "docs/Concepts" >}}): Deep-dive into the conceps behind Reva

* [Getting Started]({{< ref "docs/getting-started" >}}): Get started with the project
* [Concepts]({{< ref "docs/concepts" >}}): Deep-dive into the conceps behind Reva
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.