```bash
helm install --set existingSecret=my-minio-secret minio/minio
```

The following fields are expected in the secret:

| .data.\<key\> in Secret | Corresponding variable | Description    | Required |
|:------------------------|:-----------------------|:---------------|:---------|
| `rootUser`              | `rootUser`             | Root user.     | yes      |

      maintainer="MinIO Inc <******@****.***>" \
      version="${RELEASE}" \
      release="${RELEASE}" \
      summary="MinIO is a High Performance Object Storage, API compatible with Amazon S3 cloud storage service." \

assignees: ''

---

**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

**Describe the solution you'd like**
A clear and concise description of what you want to happen.

**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.

**Additional context**

## Software Metrics

| Name                          | Description                            |
|:------------------------------|:---------------------------------------|
| `minio_software_commit_info`  | Git commit hash for the MinIO release. |
| `minio_software_version_info` | MinIO Release tag for the server.      |

## Drive Metrics

| Name                                   | Description                                                         |

contains the following information:

- The project / component that contains the reported vulnerability.
- A description of the vulnerability. In particular, the type of the
   reported vulnerability and how it might be exploited. Alternatively,
   a well-established vulnerability identifier, e.g. CVE number, can be
   used instead.

Based on the description mentioned above, a MinIO engineer or security team
member investigates:

Upcoming Jobs

- Copy objects from NAS to MinIO
- Copy objects from HDFS to MinIO

## Replication Job
To perform replication via batch jobs, you create a job. The job consists of a job description YAML that describes

- Source location from where the objects must be copied from
- Target location from where the objects must be copied to

      maintainer="MinIO Inc <******@****.***>" \
      version="${RELEASE}" \
      release="${RELEASE}" \
      summary="MinIO is a High Performance Object Storage, API compatible with Amazon S3 cloud storage service." \

By creating this pull request I represent that I have the right to license the 
contributions to the project maintainers under the Apache 2 license.

## Description


## Motivation and Context


## How to test this PR?


## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)

# Bucket Versioning Design Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io) [![Docker Pulls](https://img.shields.io/docker/pulls/minio/minio.svg?maxAge=604800)](https://hub.docker.com/r/minio/minio/)

## Description of `xl.meta`

`xl.meta` is a new self describing backend format used by MinIO to support AWS S3 compatible versioning.
This file is the source of truth for each `version` at rest. `xl.meta` is a msgpack file serialized from a

### Request metrics 

These are metrics about requests served by the (current) node.

| Path            | Description                                      |
|-----------------|--------------------------------------------------|
| `/api/requests` | Metrics over all requests                        |