Removed FuelWeb from docs
This commit is contained in:
Pavel Lechenko
parent
cd2bbfe1c9
commit
b3ddb8d75e
@ -5,3 +5,4 @@ Fuel License
|
||||
============
|
||||
|
||||
.. literalinclude:: LICENSE
|
||||
:language: none
|
||||
@ -55,11 +55,11 @@ The Fuel User Guide is organized as follows:
|
||||
|
||||
* :ref:`Create a multi-node OpenStack cluster using Fuel UI <Create-Cluster-UI>`,
|
||||
takes you step-by-step through the process of creating a high-availability
|
||||
OpenStack cluster using Fuel Web.
|
||||
OpenStack cluster using Fuel Web UI.
|
||||
|
||||
* :ref:`Deploy an OpenStack cluster using Fuel CLI <Deploy-Cluster-CLI>`,
|
||||
takes you step-by-step through the more advanced process of creating a
|
||||
high-availability OpenStack cluster using the standard Fuel tools.
|
||||
high-availability OpenStack cluster using the command line and Puppet manifests.
|
||||
|
||||
* :ref:`Production Considerations <Production>`, looks at the
|
||||
real-world questions and problems involved in creating an OpenStack cluster
|
||||
|
||||
@ -1,21 +1,23 @@
|
||||
Installing FuelWeb
|
||||
------------------
|
||||
.. index:: Installing Fuel Admin Node
|
||||
|
||||
Installing Fuel Admin Node
|
||||
==========================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
FuelWeb is distributed as both an ISO and an IMG image, each of which contains
|
||||
an installer for an admin node. The ISO image is used for CD media devices, iLO
|
||||
or similar remote access systems. The IMG file is used for USB memory drives.
|
||||
Fuel is distributed as both ISO and IMG image, each of them contains
|
||||
an installer for Fuel Admin node. The ISO image is used for CD media devices, iLO
|
||||
or similar remote access systems. The IMG file is used for USB memory sticks.
|
||||
|
||||
Once installed, FuelWeb can be used to deploy and manage OpenStack clusters. It
|
||||
Once installed, Fuel can be used to deploy and manage OpenStack clusters. It
|
||||
will assign IP addresses to the nodes, perform PXE boot and initial
|
||||
configuration, and provision of OpenStack nodes according to their roles in the
|
||||
cluster.
|
||||
|
||||
On Physical Hardware
|
||||
--------------------
|
||||
On Bare-Metal Environment
|
||||
-------------------------
|
||||
|
||||
To install FuelWeb on physical hardware, you need to burn the provided ISO to a
|
||||
To install Fuel on bare-metal environment, you need to burn the provided ISO to a
|
||||
CD/DVD, or IMG file to a USB stick, and start the installation process by
|
||||
booting from that media, very much like any other OS.
|
||||
|
||||
@ -23,7 +25,7 @@ Linux and Mac users can prepare an installation USB stick with the ``dd``
|
||||
command. For example, if your flash drive is ``/dev/sdb``, you can use following
|
||||
command line::
|
||||
|
||||
dd if=fuelweb.img of=/dev/sdb
|
||||
dd if=fuel.img of=/dev/sdb
|
||||
|
||||
You can find the actual device name in the output of the ``dmesg`` command for
|
||||
Linux or ``diskutil list`` for Mac OS.
|
||||
@ -31,7 +33,7 @@ Linux or ``diskutil list`` for Mac OS.
|
||||
On Windows, you can write the installation image with
|
||||
`Win32 Disk Imager <http://sourceforge.net/projects/win32diskimager/>`_.
|
||||
|
||||
After the installation is complete, you will need to allocate physical nodes for
|
||||
After the installation is complete, you will need to allocate bare-metal nodes for
|
||||
your OpenStack cluster, put them on the same L2 network as the admin node, and
|
||||
PXE boot. The UI will discover them and make them available for installing
|
||||
OpenStack.
|
||||
@ -39,19 +41,18 @@ OpenStack.
|
||||
On VirtualBox
|
||||
-------------
|
||||
|
||||
If you are going to evaluate FuelWeb on VirtualBox, you should know that we
|
||||
If you are going to evaluate Fuel on VirtualBox, you should know that we
|
||||
provide a set of scripts that create and configure all of the required VMs for
|
||||
you, including the admin node and slave nodes for OpenStack itself. It's a very
|
||||
simple, single-click installation.
|
||||
|
||||
.. note::
|
||||
These scripts are not supported on Windows, but you can still test on
|
||||
.. note:: These scripts are not supported on Windows, but you can still test on
|
||||
VirtualBox by creating the VMs yourself. See "Manual Mode" for more
|
||||
information.
|
||||
|
||||
The requirements for running FuelWeb on VirtualBox are:
|
||||
The requirements for running Fuel on VirtualBox are:
|
||||
|
||||
* A physical machine with Linux or Mac OS.
|
||||
* A host machine with Linux or Mac OS.
|
||||
|
||||
* The scripts have been tested on Mac OS 10.7.5, Mac OS 10.8.3, and Ubuntu 12.04.
|
||||
|
||||
@ -74,7 +75,7 @@ When you unpack the scripts, you will see the following important files and fold
|
||||
|
||||
* iso
|
||||
|
||||
* This folder needs to contain a single ISO image for FuelWeb. Once you
|
||||
* This folder needs to contain a single ISO image for Fuel. Once you
|
||||
download ISO from the portal, copy or move it into this directory
|
||||
|
||||
* config.sh
|
||||
@ -102,7 +103,7 @@ Manual mode
|
||||
^^^^^^^^^^^
|
||||
|
||||
If you cannot or would rather not run the convenience scripts, you can still run
|
||||
FuelWeb on VirtualBox by following these steps.
|
||||
Fuel on VirtualBox by following these steps.
|
||||
|
||||
Admin node deployment
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -126,7 +127,7 @@ First, create the admin node.
|
||||
3. Power on the VM in order to start the installation.
|
||||
|
||||
4. Wait for the welcome message with all information needed to login into the UI
|
||||
of FuelWeb.
|
||||
of Fuel.
|
||||
|
||||
Adding slave nodes
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
@ -168,10 +169,13 @@ installation to complete.
|
||||
Changing network parameters after booting
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once IP settings are set at the boot time for FuelWeb master node, it **must not
|
||||
be changed during the whole lifecycle of FuelWeb.**
|
||||
.. warning::
|
||||
|
||||
Once IP settings are set at the boot time for Fuel master node, it **must not
|
||||
be changed during the whole lifecycle of Fuel.**
|
||||
|
||||
It is still possible to configure other interfaces, or add 802.1Q subinterfaces
|
||||
to the FuelWeb to be able to access it from office network if required.
|
||||
to the Fuel to be able to access it from office network if required.
|
||||
It is easy to do via standard network configuration scripts for CentOS. When the
|
||||
installation is complete, you can modify
|
||||
``/etc/sysconfig/network-scripts/ifcfg-eth* `` scripts. For example, if *eth1*
|
||||
@ -210,18 +214,18 @@ new configuration::
|
||||
|
||||
service network restart
|
||||
|
||||
Now you should be able to connect to FuelWeb from the office network
|
||||
Now you should be able to connect to Fuel UI from the office network
|
||||
via `<http://172.18.0.5:8000/>`_
|
||||
|
||||
Name resolution (DNS)
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
During master node installation, it is assumed that there is a recursive DNS
|
||||
During admin node installation, it is assumed that there is a recursive DNS
|
||||
service on 10.20.0.1.
|
||||
|
||||
If you want to make it possible for slave nodes to be able to resolve public names,
|
||||
you need to change this default value to point to an actual DNS service.
|
||||
To make the change, run the following command on FuelWeb node (replace IP to
|
||||
To make the change, run the following command on Fuel node (replace IP to
|
||||
your actual DNS)::
|
||||
|
||||
echo "nameserver 172.0.0.1" > /etc/dnsmasq.upstream
|
||||
@ -229,7 +233,7 @@ your actual DNS)::
|
||||
PXE booting settings
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
By default, eth0 on FuelWeb master node serves PXE requests. If you are planning
|
||||
By default, eth0 on Fuel admin node serves PXE requests. If you are planning
|
||||
to use another interface, then it is required to modify dnsmasq settings (which
|
||||
acts as DHCP server). Edit the file /etc/cobbler/dnsmasq.template, find the line
|
||||
``"interface=eth0"`` and replace the interface name with the one you want to use.
|
||||
@ -242,7 +246,7 @@ During synchronization cobbler builds actual dnsmasq configuration file
|
||||
why you should not edit ``/etc/dnsmasq.conf``.
|
||||
Cobbler rewrites it each time when it is synchronized.
|
||||
|
||||
If you try to use virtual machines to launch **FuelWeb** then you have to be sure
|
||||
If you try to use virtual machines to launch Fuel then you have to be sure
|
||||
that dnsmasq on master node is configured to support that PXE client you use on your
|
||||
virtual machines. We enabled *dhcp-no-override* option because without it enabled
|
||||
dnsmasq tries to move out PXE filename and PXE servername special fields into DHCP options.
|
||||
@ -253,7 +257,7 @@ iPXE by default.
|
||||
When configuration is done
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once the master node is installed, power on all other nodes and open the FuelWeb on
|
||||
Once the admin node is installed, power on all other nodes and open the Fuel on
|
||||
the configured network.
|
||||
Slave nodes will be booted in bootstrap mode (Centos based Linux in memory) via
|
||||
PXE and you will see notifications on the user interface about discovered nodes.
|
||||
|
||||
@ -3,11 +3,13 @@ Network Issues
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
FuelWeb has built-in capability to run network check before or after OpenStack deployment. Currently it can check
|
||||
connectivity between nodes within configured VLANs on configured server interfaces. Image below shows sample
|
||||
result of such check. By using this simple table it is easy to say which interfaces do not receive certain VLAN IDs.
|
||||
Usually it measn that switch or multiple switches are not configured correctly and do not allow certain tagged
|
||||
traffic to pass through.
|
||||
Fuel has built-in capability to run network check before or after OpenStack
|
||||
deployment. Currently it can check connectivity between nodes within configured
|
||||
VLANs on configured server interfaces. Image below shows sample result of such
|
||||
check. By using this simple table it is easy to say which interfaces do not
|
||||
receive certain VLAN IDs.
|
||||
Usually it means that switch or multiple switches are not configured correctly
|
||||
and do not allow certain tagged traffic to pass through.
|
||||
|
||||
.. image:: /_images/net_verify_failure.png
|
||||
:width: 100%
|
||||
@ -15,19 +17,24 @@ traffic to pass through.
|
||||
On VirtualBox
|
||||
-------------
|
||||
|
||||
Scripts which are provided for quick FuelWeb setup, create 3 host-interface adapters. Basically
|
||||
networking works as this being a 3 bridges, in each of them the only one VMs interfaces is connected.
|
||||
It means there is only L2 connectivity between VMs on interfaces named by the same name.
|
||||
If you try to move, for example, management network to eth1 on controller node, and the same network
|
||||
to eth2 on the compute, then there will be no connectivity between OpenStack services in spite of being
|
||||
configured to live on the same VLAN.
|
||||
It easy to validate settings before deploy by clicking on "Verify Networks" button before deployment.
|
||||
Scripts which are provided for quick Fuel setup, create 3 host-interface
|
||||
adapters. Basically networking works as this being a 3 bridges, in each of them
|
||||
the only one VMs interfaces is connected.
|
||||
It means there is only L2 connectivity between VMs on interfaces with the
|
||||
same name. If you try to move, for example, management network to eth1 on
|
||||
controller node, and the same network to eth2 on the compute, then there will be
|
||||
no connectivity between OpenStack services in spite of being configured to live
|
||||
on the same VLAN.
|
||||
It is very easy to validate network settings before deployment by clicking the
|
||||
"Verify Networks" button.
|
||||
|
||||
Timeout in connection to OpenStack API from client applications
|
||||
---------------------------------------------------------------
|
||||
|
||||
If you use Java, Python or any other code to work with OpenStack API, all connections should be done over OpenStack public network.
|
||||
To explain why we can not use FuelWeb admin network, let's try to run nova client with debug option enabled::
|
||||
If you use Java, Python or any other code to work with OpenStack API, all
|
||||
connections should be done over OpenStack public network.
|
||||
To explain why we can not use Fuel admin network, let's try to run nova
|
||||
client with debug option enabled::
|
||||
|
||||
[root@controller-6 ~]# nova --debug list
|
||||
|
||||
@ -43,7 +50,10 @@ To explain why we can not use FuelWeb admin network, let's try to run nova clien
|
||||
|
||||
INFO (connectionpool:191) Starting new HTTP connection (1): 240.0.1.5
|
||||
|
||||
Even though initial connection was in 192.168.0.5, then client tries to access public network for Nova API. The reason is because Keystone
|
||||
returns the list of OpenStack services URLs, and for production-grade deployments it is required to access services over public network.
|
||||
If you still need to work with OpenStack API without routing configured, tell us your use case on IRC channel **#openstack-fuel** (on freenode) and
|
||||
Even though initial connection was in 192.168.0.5, then client tries to access
|
||||
public network for Nova API. The reason is because Keystone
|
||||
returns the list of OpenStack services URLs, and for production-grade deployments
|
||||
it is required to access services over public network.
|
||||
If you still need to work with OpenStack API without routing configured, tell us
|
||||
your use case on IRC channel **#openstack-fuel** (on freenode) and
|
||||
we might be able to figure it out together.
|
||||
|
||||
@ -5,8 +5,8 @@ Understanding and configuring the network
|
||||
|
||||
OpenStack clusters use several types of network managers: FlatDHCPManager,
|
||||
VlanManager and Neutron (formerly Quantum).
|
||||
The current version of FuelWeb supports only the first two (FlatDHCP and
|
||||
VlanManager), but the FUEL library supports all three.
|
||||
The current version of Fuel UI supports only two (FlatDHCP and
|
||||
VlanManager), but Fuel CLI supports all three.
|
||||
For more information about how the first two network managers work, you can read
|
||||
these two resources:
|
||||
|
||||
@ -71,7 +71,7 @@ interface is the management network interface.
|
||||
compute2_eth0 .up. [L2 switch]
|
||||
compute3_eth0 .up. [L2 switch]
|
||||
|
||||
FuelWeb deploys OpenStack in FlatDHCP mode with the so called **multi-host**
|
||||
Fuel deploys OpenStack in FlatDHCP mode with the so called **multi-host**
|
||||
feature enabled.
|
||||
Without this feature enabled, network traffic from each VM would go through the
|
||||
single gateway host, which basically becomes a single point of failure. In
|
||||
@ -80,7 +80,7 @@ host, providing a balanced networking solution.
|
||||
In this case, if one of the computes goes down, the rest of the environment
|
||||
remains operational.
|
||||
|
||||
The current version of FuelWeb uses VLANs, even for the FlatDHCP network manager.
|
||||
The current version of Fuel uses VLANs, even for the FlatDHCP network manager.
|
||||
On the Linux host, it is implemented in such a way that it is not the physical
|
||||
network interfaces that are connected to the bridge, but the VLAN interface
|
||||
(i.e. **eth0.102**).
|
||||
@ -195,15 +195,15 @@ scheme to work.
|
||||
compute1_eth0 -up- [L2 switch]
|
||||
compute2_eth0 -up- [L2 switch]
|
||||
|
||||
FuelWeb deployment schema
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Fuel deployment schema
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
One of the physical interfaces on each host has to be chosen to carry VM-to-VM
|
||||
traffic (fixed network), and switch ports must be configured to allow tagged traffic
|
||||
to pass through. OpenStack Computes will untag the IP packets and send them to
|
||||
the appropriate VMs.
|
||||
Simplifying the configuration of VLAN Manager, there is no known limitation
|
||||
which FuelWeb could add in this particular networking mode.
|
||||
which Fuel could add in this particular networking mode.
|
||||
|
||||
Configuring the network
|
||||
-----------------------
|
||||
@ -214,9 +214,9 @@ accordingly. The diagram below shows an example configuration.
|
||||
.. image:: /_images/physical_sample.png
|
||||
:width: 100%
|
||||
|
||||
FuelWeb operates with following logical networks:
|
||||
Fuel operates with following logical networks:
|
||||
|
||||
* **FuelWeb** network is used for internal FuelWeb communications only and PXE
|
||||
* **Fuel** network is used for internal Fuel communications only and PXE
|
||||
booting (untagged on the scheme);
|
||||
* **Public** network is used to get access from virtual machines to outside,
|
||||
Internet or office network (vlan 101 on the scheme);
|
||||
@ -231,7 +231,7 @@ FuelWeb operates with following logical networks:
|
||||
Mapping logical networks to physical interfaces on servers
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
FuelWeb allows you to use different physical interfaces to handle different
|
||||
Fuel allows you to use different physical interfaces to handle different
|
||||
types of traffic. When a node is added to the environment, click at the bottom
|
||||
line of the node icon. In the detailed information window, click the "Network
|
||||
Configuration" button to open the physical interfaces configuration screen.
|
||||
@ -242,7 +242,7 @@ Configuration" button to open the physical interfaces configuration screen.
|
||||
On this screen you can drag-and-drop logical networks to physical interfaces
|
||||
according to your network setup.
|
||||
|
||||
All networks are presented on the screen, except **fuelweb**.
|
||||
All networks are presented on the screen, except **fuel**.
|
||||
It runs on the physical interface from which node was initially PXE booted,
|
||||
and in the current version it is not possible to map it on any other physical
|
||||
interface. Also, once the network is configured and OpenStack is deployed,
|
||||
@ -252,31 +252,31 @@ physical interface or VLAN number.
|
||||
Switch
|
||||
^^^^^^
|
||||
|
||||
FuelWeb can configure hosts, however switch configuration is still manual work.
|
||||
Fuel can configure hosts, however switch configuration is still manual work.
|
||||
Unfortunately the set of configuration steps, and even the terminology used, is
|
||||
different for different vendors, so we will try to provide vendor-agnostic
|
||||
information on how traffic should flow and leave the vendor-specific details to
|
||||
you. We will provide an example for a Cisco switch.
|
||||
|
||||
First of all, you must configure access ports to allow non-tagged PXE booting
|
||||
connections from all slave nodes to the FuelWeb node. We refer this network
|
||||
as the "admin" network, or "fuelweb".
|
||||
By default, the FuelWeb master node uses the ``eth0`` interface to serve PXE
|
||||
connections from all slave nodes to the Fuel node. We refer this network
|
||||
as the "admin" network, or "fuel".
|
||||
By default, the Fuel master node uses the ``eth0`` interface to serve PXE
|
||||
requests on this network.
|
||||
So if that's left unchanged, you must set the switch port for eth0 of FuelWeb to
|
||||
So if that's left unchanged, you must set the switch port for eth0 of Fuel to
|
||||
access mode.
|
||||
We recommend that you use the eth0 interfaces of all other nodes for PXE booting
|
||||
as well. Corresponding ports must also be in access mode.
|
||||
|
||||
Taking into account that this is the network for PXE booting, you must not mix
|
||||
this L2 segment with any other company infrastructure. FuelWeb runs a DHCP
|
||||
this L2 segment with any other company infrastructure. Fuel runs a DHCP
|
||||
server, and if there is another company DHCP on the same L2, both the company's
|
||||
infrastructure and FuelWeb's will be unable to function properly.
|
||||
infrastructure and Fuel's will be unable to function properly.
|
||||
You also need to configure each of the switch's ports connected to nodes as an
|
||||
"STP Edge port" (or a "spanning-tree portfast trunk", according to Cisco
|
||||
terminology). If you don't do that, DHCP timeout issues may occur.
|
||||
|
||||
As long as the "admin" network is configured, FuelWeb can operate.
|
||||
As long as the "admin" network is configured, Fuel can operate.
|
||||
Other networks are required for OpenStack environments, and currently all of
|
||||
these networks live in VLANs over the one or multiple physical interfaces on a
|
||||
node. This means that the switch should pass tagged traffic, and untagging is done
|
||||
@ -284,7 +284,7 @@ on the Linux hosts.
|
||||
|
||||
.. note::
|
||||
For the sake of simplicity, all the VLANs specified on the networks tab of
|
||||
the FuelWeb should be configured on switch ports, pointing to slave nodes,
|
||||
the Fuel should be configured on switch ports, pointing to slave nodes,
|
||||
as tagged.
|
||||
|
||||
Of course, it is possible to specify as tagged only certain ports for a certain
|
||||
@ -297,9 +297,9 @@ This is enough to deploy the OpenStack environment. However, from a practical
|
||||
standpoint, it's still not really usable because there is no connection to other
|
||||
corporate networks yet. To make that possible, you must configure uplink port(s).
|
||||
|
||||
One of the VLANs may carry the office network. To provide access to the FuelWeb
|
||||
One of the VLANs may carry the office network. To provide access to the Fuel
|
||||
from the office network, any other free physical network interface on the
|
||||
FuelWeb master node can be used and configured according to the office network
|
||||
Fuel master node can be used and configured according to the office network
|
||||
rules (static IP or DHCP). The same corporate network segment can be used for
|
||||
public and floating ranges. In this case, you must provide the corresponding
|
||||
VLAN ID and IP ranges in the UI. One public IP per node will be used to SNAT
|
||||
@ -308,7 +308,7 @@ instance will be used to get access to the VM from the corporate network, or
|
||||
even the global Internet. To have a VM visible from the Internet is similar to
|
||||
having it visible from corporate network - corresponding IP ranges and VLAN IDs
|
||||
must be specified for the floating and public networks. One current limitation
|
||||
of FuelWeb is that the user must use the same L2 segment for both public and
|
||||
of Fuel is that the user must use the same L2 segment for both public and
|
||||
floating networks.
|
||||
|
||||
Example configuration for one of the ports on a Cisco switch html::
|
||||
@ -330,7 +330,7 @@ To make it possible for VMs to access the outside world, you must have an IP
|
||||
address set on a router in the public network.
|
||||
In the examples provided, that IP is 12.0.0.1 in VLAN 101.
|
||||
|
||||
FuelWeb has a special field on the networking tab for the gateway address. As
|
||||
Fuel has a special field on the networking tab for the gateway address. As
|
||||
soon as deployment of OpenStack is started, the network on nodes is reconfigured
|
||||
to use this gateway IP as the default gateway.
|
||||
|
||||
|
||||
@ -35,10 +35,14 @@ controller or another in the cluster, depending on load conditions.
|
||||
Each of the services housed on the controller nodes has its own
|
||||
mechanism for achieving HA:
|
||||
|
||||
* nova-api, glance-api, keystone-api, quantum-api and nova-scheduler are stateless services that do not require any special attention besides load balancing.
|
||||
* Horizon, as a typical web application, requires sticky sessions to be enabled at the load balancer.
|
||||
* nova-api, glance-api, keystone-api, quantum-api and nova-scheduler are
|
||||
stateless services that do not require any special attention besides load
|
||||
balancing.
|
||||
* Horizon, as a typical web application, requires sticky sessions to be enabled
|
||||
at the load balancer.
|
||||
* RabbitMQ provides active/active high availability using mirrored queues.
|
||||
* MySQL high availability is achieved through Galera active/active multi-master deployment.
|
||||
* MySQL high availability is achieved through Galera active/active multi-master
|
||||
deployment.
|
||||
|
||||
Compute Nodes
|
||||
+++++++++++++
|
||||
|
||||
@ -41,7 +41,7 @@ provided OpenStack distribution onto CentOS powered nodes or installing the Red
|
||||
Hat provided OpenStack distribution onto Red Hat Enterprise Linux powered nodes.
|
||||
|
||||
.. note:: A Red Hat subscription is required to download and deploy Red Hat
|
||||
Enterprise Linux OpenStack Platform.
|
||||
Enterprise Linux OpenStack Platform.
|
||||
|
||||
Mirantis OpenStack Health Check
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Loading…
Reference in New Issue
Block a user