=f.text_field:name,class: "form-control top qa-new-user-name js-block-emoji",required: true,title: _("This field is required.")
=f.text_field:name,class: "form-control top qa-new-user-name js-block-emoji js-validate-length",:data=>{:max_length=>max_name_length,:max_length_message=>s_("SignUp|Name is too long (maximum is %{max_length} characters).")%{max_length: max_name_length}},required: true,title: _("This field is required.")
.username.form-group
=f.label:username,class: 'label-bold'
=f.text_field:username,class: "form-control middle qa-new-user-username js-block-emoji",pattern: Gitlab::PathRegex::NAMESPACE_FORMAT_REGEX_JS,required: true,title: _("Please create a username with only alphanumeric characters.")
%p.validation-error.hide=_('Username is already taken.')
%p.validation-success.hide=_('Username is available.')
=f.text_field:username,class: "form-control middle qa-new-user-username js-block-emoji js-validate-length",:data=>{:max_length=>max_username_length,:max_length_message=>s_("SignUp|Username is too long (maximum is %{max_length} characters).")%{max_length: max_username_length}},pattern: Gitlab::PathRegex::NAMESPACE_FORMAT_REGEX_JS,required: true,title: _("Please create a username with only alphanumeric characters.")
%p.validation-error.field-validation.hide=_('Username is already taken.')
%p.validation-success.field-validation.hide=_('Username is available.')
@@ -106,13 +106,14 @@ deploy the bundled PostgreSQL.
### High Availability with GitLab Omnibus **[PREMIUM ONLY]**
> Important notes:
>
> - This document will focus only on configuration supported with [GitLab Premium](https://about.gitlab.com/pricing/), using the Omnibus GitLab package.
> - If you are a Community Edition or Starter user, consider using a cloud hosted solution.
> - This document will not cover installations from source.
>
> - If HA setup is not what you were looking for, see the [database configuration document](http://docs.gitlab.com/omnibus/settings/database.html)
> for the Omnibus GitLab packages.
>
> Please read this document fully before attempting to configure PostgreSQL HA
> for GitLab.
>
...
...
@@ -171,13 +172,10 @@ Similarly, PostgreSQL access is controlled based on the network source.
This is why you will need:
> IP address of each nodes network interface
> - This can be set to `0.0.0.0` to listen on all interfaces. It cannot
> be set to the loopack address `127.0.0.1`
>
> Network Address
> - This can be in subnet (i.e. `192.168.0.0/255.255.255.0`) or CIDR (i.e.
> `192.168.0.0/24`) form.
- IP address of each nodes network interface. This can be set to `0.0.0.0` to
listen on all interfaces. It cannot be set to the loopack address `127.0.0.1`.
- Network Address. This can be in subnet (i.e. `192.168.0.0/255.255.255.0`)
or CIDR (i.e. `192.168.0.0/24`) form.
##### User information
...
...
@@ -220,8 +218,7 @@ the number of database nodes in the cluster.
This is used to prevent replication from using up all of the
available database connections.
> Note:
> - In this document we are assuming 3 database nodes, which makes this configuration:
In this document we are assuming 3 database nodes, which makes this configuration:
```
postgresql['max_wal_senders'] = 4
...
...
@@ -327,7 +324,7 @@ On each Consul node perform the following:
Before moving on, make sure Consul is configured correctly. Run the following
command to verify all server nodes are communicating:
```
```sh
/opt/gitlab/embedded/bin/consul members
```
...
...
@@ -401,14 +398,15 @@ check the [Troubleshooting section](#troubleshooting) before proceeding.
repmgr['master_on_initialization'] = false
```
1. [Reconfigure GitLab] for te changes to take effect.
1. [Reconfigure GitLab] for the changes to take effect.
> Please note:
>
> - If you want your database to listen on a specific interface, change the config:
> `postgresql['listen_address'] = '0.0.0.0'`
> `postgresql['listen_address'] = '0.0.0.0'`.
> - If your Pgbouncer service runs under a different user account,
> you also need to specify: `postgresql['pgbouncer_user'] = PGBOUNCER_USERNAME` in
> your configuration
> your configuration.
##### Database nodes post-configuration
...
...
@@ -449,7 +447,6 @@ Select one node as a primary node.
is not an IP address, it will need to be a resolvable name (via DNS or
`/etc/hosts`)
###### Secondary nodes
1. Set up the repmgr standby:
...
...
@@ -500,7 +497,7 @@ Before moving on, make sure the databases are configured correctly. Run the
following command on the **primary** node to verify that replication is working
properly:
```
```sh
gitlab-ctl repmgr cluster show
```
...
...
@@ -518,7 +515,7 @@ If the 'Role' column for any node says "FAILED", check the
Also, check that the check master command works successfully on each node:
```
```sh
su - gitlab-consul
gitlab-ctl repmgr-check-master ||echo'This node is a standby repmgr node'
```
...
...
@@ -665,13 +662,13 @@ can connect to each freely other on those addresses.
Here is a list and description of each machine and the assigned IP:
*`10.6.0.11`: Consul 1
*`10.6.0.12`: Consul 2
*`10.6.0.13`: Consul 3
*`10.6.0.21`: PostgreSQL master
*`10.6.0.22`: PostgreSQL secondary
*`10.6.0.23`: PostgreSQL secondary
*`10.6.0.31`: GitLab application
-`10.6.0.11`: Consul 1
-`10.6.0.12`: Consul 2
-`10.6.0.13`: Consul 3
-`10.6.0.21`: PostgreSQL master
-`10.6.0.22`: PostgreSQL secondary
-`10.6.0.23`: PostgreSQL secondary
-`10.6.0.31`: GitLab application
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
...
...
@@ -735,7 +732,7 @@ consul['configuration'] = {
On secondary nodes, edit `/etc/gitlab/gitlab.rb` and add all the configuration
added to primary node, noted above. In addition, append the following
configuration
configuration:
```
# HA setting to specify if a node should attempt to be master on initialization
...
...
@@ -839,10 +836,10 @@ In this example we start with all servers on the same 10.6.0.0/16 private networ
Here is a list and description of each machine and the assigned IP:
*`10.6.0.21`: PostgreSQL master
*`10.6.0.22`: PostgreSQL secondary
*`10.6.0.23`: PostgreSQL secondary
*`10.6.0.31`: GitLab application
-`10.6.0.21`: PostgreSQL master
-`10.6.0.22`: PostgreSQL secondary
-`10.6.0.23`: PostgreSQL secondary
-`10.6.0.31`: GitLab application
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
...
...
@@ -853,6 +850,7 @@ Please note that after the initial configuration, if a failover occurs, the Post
##### Example minimal configuration for database servers
##### Primary node
On primary database node edit `/etc/gitlab/gitlab.rb`:
If you are running on an untrusted network, repmgr can use md5 authentication
...
...
@@ -1157,8 +1154,6 @@ If you're running into an issue with a component not outlined here, be sure to c
**Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#high-availability-with-gitlab-omnibus-premium-only).
If you are reading this section due to an old bookmark, you can find that old documentation [in the repository](https://gitlab.com/gitlab-org/gitlab-ce/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus).
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 10.5.
...
...
@@ -19,13 +23,20 @@ Epics in the view can be sorted by:
-**Start date**
-**Due date**
Each option contains a button that can toggle the order between **ascending** and **descending**. The sort option and order will be persisted to be used wherever epics are browsed including the [epics list view](../epics/index.md).
Each option contains a button that toggles the sort order between **ascending** and **descending**. The sort option and order will be persisted when browsing Epics,
including the [epics list view](../epics/index.md).
Roadmaps can also be [visualized inside an epic](../epics/index.md#roadmap-in-epics).
## Timeline duration
Starting with [GitLab Ultimate][ee] 11.0, Roadmap supports three different date ranges; Quarters, Months (Default) and Weeks.
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.0.
Roadmap supports the following date ranges:
- Quarters
- Months (Default)
- Weeks
### Quarters
...
...
@@ -62,3 +73,15 @@ and due date. If an epic doesn't have a due date, the timeline bar fades
away towards the future. Similarly, if an epic doesn't have a start date, the
timeline bar becomes more visible as it approaches the epic's due date on the
timeline.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->