From 715291e873125d3f8fec6f8f37643a69485718f7 Mon Sep 17 00:00:00 2001 From: Jorge Miguel Lobo Escalona Date: Fri, 12 Jul 2024 14:27:36 +0200 Subject: [PATCH] F OpenNebula/One#6430: large-scale and HA (#2976) --- .../ha/frontend_ha.rst | 25 +- .../fireedge_for_large_deployments.rst | 228 ++++++++++++++++++ .../large-scale_deployment/index.rst | 2 +- .../large-scale_deployment/overview.rst | 2 +- .../large-scale_deployment/scalability.rst | 6 +- .../legacy_components/ruby_sunstone/index.rst | 1 + .../ruby_sunstone/sunstone.rst | 2 +- .../sunstone_for_large_deployments.rst | 16 +- .../vcenter_driver/vcenter_driver.rst | 2 +- .../administration/sunstone_gui/sunstone.po | 2 +- .../scalability/one_scalability.po | 2 +- source/marketplace/appliances/marketapps.rst | 2 +- .../private_marketplaces/market_http.rst | 2 +- .../private_marketplaces/market_s3.rst | 2 +- 14 files changed, 264 insertions(+), 30 deletions(-) create mode 100644 source/installation_and_configuration/large-scale_deployment/fireedge_for_large_deployments.rst rename source/{installation_and_configuration/large-scale_deployment => legacy_components/ruby_sunstone}/sunstone_for_large_deployments.rst (99%) diff --git a/source/installation_and_configuration/ha/frontend_ha.rst b/source/installation_and_configuration/ha/frontend_ha.rst index d7e2421461..5fb5ea1a08 100644 --- a/source/installation_and_configuration/ha/frontend_ha.rst +++ b/source/installation_and_configuration/ha/frontend_ha.rst @@ -45,7 +45,6 @@ Every HA cluster requires: The servers should be configured in the following way: -* Sunstone (with or without Apache/Passenger) running on all the nodes. * Shared datastores must be mounted on all the nodes. Bootstrapping the HA cluster @@ -351,16 +350,16 @@ OpenNebula stores virtual machine logs inside ``/var/log/one/`` as files named ` Optionally, if you are planning to use the FireEdge OneProvision GUI, in order to have all provision logs available in all HA nodes (hence, available on leader change), all nodes need to share the same ``/var/lib/one/fireedge`` folder. -Sunstone and FireEdge +FireEdge ================================================================================ -There are several types of Sunstone deployments in an HA environment. The basic one is Sunstone running on each OpenNebula Front-end node configured with the local OpenNebula. Only one server, the *leader* with floating IP, is used by the clients. +There are several types of FireEdge deployments in an HA environment. The basic one is FireEdge running on **each OpenNebula Front-end node** configured with the local OpenNebula. Only one server, the *leader* with floating IP, is used by the clients. -It is possible to configure a load balancer (e.g. HAProxy, Pound, Apache, or Nginx) over the Front-ends to spread the load (read operations) among the nodes. In this case, the **Memcached** and shared ``/var/tmp/`` may be required. Please see :ref:`Configuring Sunstone for Large Deployments `. +It is possible to configure a load balancer (e.g. HAProxy, Pound, Apache, or Nginx) over the Front-ends to spread the load (read operations) among the nodes. -To easily scale out beyond the total number of core OpenNebula daemons, Sunstone can be running on separate machines. They should talk to the cluster floating IP (see ``:one_xmlprc:`` in ``sunstone-server.conf``) and may also require **Memcached** and shared ``/var/tmp/`` between Sunstone and Front-end nodes. Please check :ref:`Configuring Sunstone for Large Deployments `. +To easily scale out beyond the total number of core OpenNebula daemons, FireEdge can be running on separate machines. They should talk to the cluster floating IP (see ``:one_xmlprc:`` in ``fireedge-server.conf``) and shared ``/var/tmp/`` between Fireedge and Front-end nodes. Please check :ref:`Configuring FireEdge for Large Deployments `. -FireEdge and Sunstone need to share the same ``/var/lib/one/.one/fireedge_key``. This is covered by the above procedure. Additionally, to have all provision logs available in all HA nodes (hence, available on leader change), all nodes need to share the same ``/var/lib/one/fireedge`` folder. +FireEdge need to share the same ``/var/lib/one/.one/fireedge_key``. This is covered by the above procedure. Additionally, to have all provision logs available in all HA nodes (hence, available on leader change), all nodes need to share the same ``/var/lib/one/fireedge`` folder. Raft Configuration Attributes ================================================================================ @@ -416,17 +415,14 @@ Individual files: - ``/etc/one/oneflow-server.conf`` - ``/etc/one/onegate-server.conf`` - ``/etc/one/sched.conf`` -- ``/etc/one/sunstone-logos.yaml`` -- ``/etc/one/sunstone-server.conf`` - ``/etc/one/vcenter_driver.default`` Folders: -- ``/etc/one/sunstone-views`` +- ``/etc/one/fireedge`` - ``/etc/one/auth`` - ``/etc/one/ec2query_templates`` - ``/etc/one/hm`` -- ``/etc/one/sunstone-views`` - ``/etc/one/vmm_exec`` .. note:: Any file inside previous folders that doesn't exist on the remote server (like backups) will **not** be removed. @@ -441,3 +437,12 @@ Usage # onezone serversync [--db] where ```` needs to be replaced by a hostname/IP of the OpenNebula server that will be used to fetch configuration files from. If ``--db`` option is used, the local database will be synced with the one located on remote server. + +You also have to adjust the configuration file of each FireEdge ``/etc/one/fireedge-server.conf``, to know which FireEdge corresponds to which zone. + +.. code:: + + default_zone: + id: 0 + name: 'OpenNebula' + endpoint: 'http://localhost:2633/RPC2' \ No newline at end of file diff --git a/source/installation_and_configuration/large-scale_deployment/fireedge_for_large_deployments.rst b/source/installation_and_configuration/large-scale_deployment/fireedge_for_large_deployments.rst new file mode 100644 index 0000000000..a3a0d8eb65 --- /dev/null +++ b/source/installation_and_configuration/large-scale_deployment/fireedge_for_large_deployments.rst @@ -0,0 +1,228 @@ +.. _fireedge_advance: + +============================== +FireEdge for Large Deployments +============================== + +Low to medium size enterprise clouds will typically deploy FireEdge on a single machine with the other OpenNebula daemons as part. However, this simple deployment can be extended by + +- **Improving scalability** of the server for large user pools, usually by deploying FireEdge as a separate application on one or more hosts. + +This guide introduces various deployment options to achieve this. Check also the :ref:`API Scalability ` guide for tips on how to improve FireEdge and OpenNebula Daemon performance. + +.. _fireedge_large_web: + +Deploy in Webserver +=================== + +Self-contained deployment of :ref:`FireEdge `. (using ``opennebula-fireedge`` system service) is sufficient for small to medium installations. This is no longer enough when the service has lots of concurrent users and the number of objects in the system is high (for example, more than 2000 simultaneous Virtual Machines). + +The FireEdge server is implemented as a nodejs server. This makes it suitable to run on any server. Also, embed the service inside Apache HTTP Server or NGINX. Another advantage is the ability to run FireEdge on multiple servers and balance the load between them. + +**Guacamole** + +If you want to use Guacamole you need to have it running. You can start this service with the command: + +.. prompt:: bash # auto + + # systemctl enable opennebula-guacd + # systemctl start opennebula-guacd + +.. _fireedge_fs_permissions: + +**Filesystem Permissions** + +Another thing you have to take into account is the user under which the server will run. The installation sets the permissions for the ``oneadmin`` user and group, and files like the FireEdge configuration and credentials cannot be read by other users. + +.. prompt:: bash # auto + + # chmod a+x /var + # chmod a+x /var/lib + # chmod a+x /var/lib/one + # chmod a+x /var/lib/one/.one + +.. _fireedge_advance_apache_proxy: + +Non-TLS Configuration +^^^^^^^^^^^^^^^^^^^^^ +If FireEdge is installed and you want to place an apache to forward traffic to fireedge you can inside ``VirtualHost``, insert the following snippet and **adjust** it to your current configuration. + +**Apache** + +.. code-block:: bash + + + ... + + ProxyRequests off + ProxyPreserveHost on + + # no proxy for /error/ (Apache HTTPd errors messages) + ProxyPass /error/ ! + + ProxyPass /fireedge http://localhost:2616/fireedge + ProxyPassReverse /fireedge http://localhost:2616/fireedge + + RewriteEngine on + RewriteCond %{HTTP:Upgrade} websocket [NC] + RewriteCond %{HTTP:Connection} upgrade [NC] + RewriteRule ^/fireedge/?(.*) "ws://localhost:2616/fireedge/$1" [P,L] + + + Order deny,allow + Allow from all + + + +.. note:: + + As you can see in the configuration inside the **location** is in ``/fireedge`` that means that it is a path of your domain ``/fireedge``. If you want the fireedge to be in the root you must change it to ``/`` + +**NGINX** + +You will need to configure a new virtual host in NGINX. Depending on the operating system and the method of installation, NGINX loads virtual host configurations from either ``/etc/nginx/conf.d`` or ``/etc/nginx/sites-enabled``. + +- A sample ``cloudserver.org`` virtual host is presented next: + +.. code-block:: bash + + # No squealing. + server_tokens off; + + #### OpenNebula FireEdge upstream + upstream fire-edge { + server 127.0.0.1:2616; + } + + #### cloudserver.org HTTPS virtual host + server { + listen 80; + server_name cloudserver.org; + + ### Proxy requests to upstream + + location /fireedge { + proxy_pass http://fire-edge/fireedge; + proxy_redirect off; + log_not_found off; + proxy_buffering off; + proxy_cache_bypass $http_upgrade + proxy_http_version 1.1; + proxy_set_header Upgrade $http_upgrade; + proxy_set_header Connection "upgrade"; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header Host $http_host; + proxy_set_header X-Forwarded-FOR $proxy_add_x_forwarded_for; + access_log off; + } + } + +.. note:: + + As you can see in the configuration inside the **location** is in ``/fireedge`` that means that it is a path of your domain ``/fireedge``. If you want the fireedge to be in the root you must change it to ``/`` + + +.. _fireedge_advance_apache_tls_proxy: + +TLS-secured Configuration +^^^^^^^^^^^^^^^^^^^^^^^^^ + +We must create the Virtual Host that will run our FireEdge. Here is an example: + +**Apache** + +.. code:: + + + ServerName one.example.com + + SSLEngine on + SSLCertificateKeyFile /etc/ssl/private/opennebula-key.pem + SSLCertificateFile /etc/ssl/certs/opennebula-certchain.pem + + SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 + SSLHonorCipherOrder On + SSLCompression off + Header always set Strict-Transport-Security "max-age=15768000" + SSLCipherSuite 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256' + + RequestHeader set X-Forwarded-Proto "https" + + ProxyRequests off + ProxyPreserveHost on + + # no proxy for /error/ (Apache HTTPd errors messages) + ProxyPass /error/ ! + + ProxyPass /fireedge http://localhost:2616/fireedge + ProxyPassReverse /fireedge http://localhost:2616/fireedge + + RewriteEngine on + RewriteCond %{HTTP:Upgrade} websocket [NC] + RewriteCond %{HTTP:Connection} upgrade [NC] + RewriteRule ^/fireedge/?(.*) "ws://localhost:2616/fireedge/$1" [P,L] + + + Order deny,allow + Allow from all + + + +Now the configuration should be ready. Restart or reload the Apache configuration to start the application and point to the virtual host to check that everything is running. + +.. note:: + + As you can see in the configuration inside the **location**, **ProxyPass** and **ProxyPassReverse** is in ``/fireedge`` that means it is a path of your domain ``/fireedge``. If you want the fireedge to be in the root you must change it to ``/``. + +**NGINX** + +You will need to configure a new virtual host in NGINX. Depending on the operating system and the method of installation, NGINX loads virtual host configurations from either ``/etc/nginx/conf.d`` or ``/etc/nginx/sites-enabled``. + +.. code-block:: bash + + # No squealing. + server_tokens off; + + #### OpenNebula FireEdge upstream + upstream fire-edge { + server 127.0.0.1:2616; + } + + #### cloudserver.org HTTP virtual host + server { + listen 80; + server_name cloudserver.org; + + ### Permanent redirect to HTTPS (optional) + return 301 https://$server_name:8443; + } + + #### cloudserver.org HTTPS virtual host + server { + listen 8443; + server_name cloudserver.org; + + ### SSL Parameters + ssl on; + ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem; + ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key; + + location /fireedge { + proxy_pass http://fire-edge/fireedge; + proxy_redirect off; + log_not_found off; + proxy_buffering off; + proxy_cache_bypass $http_upgrade + proxy_http_version 1.1; + proxy_set_header Upgrade $http_upgrade; + proxy_set_header Connection "upgrade"; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header Host $http_host; + proxy_set_header X-Forwarded-FOR $proxy_add_x_forwarded_for; + access_log off; + } + } + +.. note:: + + As you can see in the configuration inside the **location** is in ``/fireedge`` that means that it is a path of your domain ``/fireedge``. If you want the fireedge to be in the root you must change it to ``/`` diff --git a/source/installation_and_configuration/large-scale_deployment/index.rst b/source/installation_and_configuration/large-scale_deployment/index.rst index 599813f735..ab54ce53e1 100644 --- a/source/installation_and_configuration/large-scale_deployment/index.rst +++ b/source/installation_and_configuration/large-scale_deployment/index.rst @@ -9,5 +9,5 @@ Large-scale Deployment Overview Scalability Testing and Tuning - Sunstone for Large Deployments + FireEdge for Large Deployments Advanced SSH Usage diff --git a/source/installation_and_configuration/large-scale_deployment/overview.rst b/source/installation_and_configuration/large-scale_deployment/overview.rst index 3620607409..61d77b696d 100644 --- a/source/installation_and_configuration/large-scale_deployment/overview.rst +++ b/source/installation_and_configuration/large-scale_deployment/overview.rst @@ -9,7 +9,7 @@ This chapter describes the performance capabilities of various OpenNebula compon How Should I Read This Chapter ================================================================================ -Read the :ref:`Scalability Testing and Tuning ` to understand the performance capabilities of OpenNebula and ways to improve performance by following test scenarios. Move on to the :ref:`Sunstone for Large Deployment ` to learn how to achieve a better performance and security by running Sunstone GUI within a web server or behind HTTP(S) proxy. After this, you can get familiar with how OpenNebula deals with SSH and how to streamline the SSH configuration in :ref:`Advanced SSH Usage `. +Read the :ref:`Scalability Testing and Tuning ` to understand the performance capabilities of OpenNebula and ways to improve performance by following test scenarios. Move on to the :ref:`Sunstone for Large Deployment ` to learn how to achieve a better performance and security by running Sunstone GUI within a web server or behind HTTP(S) proxy. After this, you can get familiar with how OpenNebula deals with SSH and how to streamline the SSH configuration in :ref:`Advanced SSH Usage `. Hypervisor Compatibility ================================================================================ diff --git a/source/installation_and_configuration/large-scale_deployment/scalability.rst b/source/installation_and_configuration/large-scale_deployment/scalability.rst index cf8d138c92..22fb85d134 100644 --- a/source/installation_and_configuration/large-scale_deployment/scalability.rst +++ b/source/installation_and_configuration/large-scale_deployment/scalability.rst @@ -279,7 +279,7 @@ To connect to the cluster from another server you can use one of the two followi export ONE_XMLRPC=http://ENDPOINT_IP:2633/RPC2 -- Using Sunstone: Modify ``one_xmlrpc`` in :ref:`/etc/one/sunstone-server.conf ` +- Using FireEdge: Modify ``one_xmlrpc`` in :ref:`/etc/one/fireedge-server.conf ` The new endpoint will be the load balancer address. @@ -295,10 +295,10 @@ For non-test installations use a MySQL/MariaDB database. SQLite is too slow for Be sure to review the :ref:`recommended maintenance procedures ` for the MySQL database backend. -Sunstone Tuning +FireEdge Tuning --------------------------- -Please refer to the guide on :ref:`Configuring Sunstone for Large Deployments `. +Please refer to the guide on :ref:`Configuring FireEdge for Large Deployments `. .. |scala| image:: /images/one_scalability.jpg diff --git a/source/legacy_components/ruby_sunstone/index.rst b/source/legacy_components/ruby_sunstone/index.rst index f57cc5ac0a..f13976399d 100644 --- a/source/legacy_components/ruby_sunstone/index.rst +++ b/source/legacy_components/ruby_sunstone/index.rst @@ -14,3 +14,4 @@ Ruby Sunstone Sunstone views Cloud view Sunstone Authentication + Sunstone for Large Deployments diff --git a/source/legacy_components/ruby_sunstone/sunstone.rst b/source/legacy_components/ruby_sunstone/sunstone.rst index 8791704714..a4817eaa3f 100644 --- a/source/legacy_components/ruby_sunstone/sunstone.rst +++ b/source/legacy_components/ruby_sunstone/sunstone.rst @@ -440,7 +440,7 @@ Different Endpoint for Different View OpenNebula :ref:`Sunstone Views ` can be adapted to use a different endpoint for each kind of user, such as if you want one endpoint for the admins and a different one for the -cloud users. You just have to deploy a :ref:`new sunstone server ` and set a default +cloud users. You just have to deploy a :ref:`new sunstone server ` and set a default view for each sunstone instance: .. code:: diff --git a/source/installation_and_configuration/large-scale_deployment/sunstone_for_large_deployments.rst b/source/legacy_components/ruby_sunstone/sunstone_for_large_deployments.rst similarity index 99% rename from source/installation_and_configuration/large-scale_deployment/sunstone_for_large_deployments.rst rename to source/legacy_components/ruby_sunstone/sunstone_for_large_deployments.rst index 437713974c..0a08576d8a 100644 --- a/source/installation_and_configuration/large-scale_deployment/sunstone_for_large_deployments.rst +++ b/source/legacy_components/ruby_sunstone/sunstone_for_large_deployments.rst @@ -1,4 +1,4 @@ -.. _suns_advance: +.. _sunstone_advance: ============================== Sunstone for Large Deployments @@ -20,7 +20,7 @@ Self-contained deployment of Sunstone (using ``opennebula-sunstone`` system serv The Sunstone server is implemented as a Rack server. This makes it suitable to run in any web server that supports this protocol. In the Ruby world this is the standard supported by most web servers. We can now select web servers that support spawning multiple processes, like Unicorn, or embedding the service inside Apache HTTP Server or Nginx using the Passenger module. Another benefit is the ability to run Sunstone on several servers and balance the load between them. -.. _suns_advance_federated: +.. _sunstone_advance_federated: .. warning:: Deploying Sunstone behind a proxy in a federated environment requires specific configuration to properly handle the Sunstone headers required by the Federation. @@ -65,7 +65,7 @@ Another thing you have to take into account is the user under which the server w # chmod a+x /var/lib/one/.one # chmod a+x /var/lib/one/sunstone -.. _suns_advance_marketplace: +.. _sunstone_advance_marketplace: **Marketplace** @@ -79,7 +79,7 @@ If you are using a Back-end other than Passenger, please adapt these recommendat We advise using **Apache/Passenger** in your installation, but we'll also present the other options. For more information on Rack and web servers that support it, you can check the `Rack documentation `__ page. Alternatively, you can check a `list of Ruby web servers `__. -.. _suns_advance_web_proxy: +.. _sunstone_advance_web_proxy: Deploy with Apache/Passenger (Recommended) ------------------------------------------ @@ -103,7 +103,7 @@ Deploy with Apache/Passenger (Recommended) The first thing you have to do is install Phusion Passenger. For this you can use binary packages for your distribution or follow the `installation instructions `__ from their web page. The installation is self explanatory and will guide you through the whole process. Follow the guidance and you will be ready to run Sunstone. -.. _suns_advance_apache_proxy: +.. _sunstone_advance_apache_proxy: Non-TLS Configuration ^^^^^^^^^^^^^^^^^^^^^ @@ -178,7 +178,7 @@ In Sunstone configuration (:ref:`/etc/one/sunstone-server.conf `) :public_fireedge_endpoint: http://one.example.one -.. _suns_advance_apache_tls_proxy: +.. _sunstone_advance_apache_tls_proxy: TLS-secured Configuration ^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -326,7 +326,7 @@ It is also possible to use Sunstone ``remote`` authentication with Apache and Pa Now, our configuration is ready to use Passenger and Kerberos. Restart or reload the Apache HTTP server and point to the Virtual Host while using a valid Kerberos ticket to check that everything is running. -.. _suns_advance_unicorn: +.. _sunstone_advance_unicorn: Deploy with Unicorn (Legacy) ---------------------------- @@ -391,7 +391,7 @@ Multiple Hosts You can run Sunstone on several servers and use a load balancer that connects to them. Make sure you are using ``memcache`` for sessions and both Sunstone servers connect to the same ``memcached`` server. To do this, change the parameter ``:memcache_host`` in the configuration file. Also make sure that both Sunstone instances connect to the same OpenNebula server. -.. _ss_proxy: +.. _ss_sunstone_proxy: Configuring an SSL Proxy ======================== diff --git a/source/legacy_components/vcenter_driver/vcenter_driver.rst b/source/legacy_components/vcenter_driver/vcenter_driver.rst index e2ca9c25c5..a483810b06 100644 --- a/source/legacy_components/vcenter_driver/vcenter_driver.rst +++ b/source/legacy_components/vcenter_driver/vcenter_driver.rst @@ -140,7 +140,7 @@ vCenter clusters, VM templates, networks, datastores, and VMDK files located in * Using the Import button in Sunstone. -.. warning:: The image import operation may take a long time. If you use the Sunstone client and receive a "Cannot contact server: is it running and reachable?" the 30-second Sunstone timeout may have been reached. In this case, either :ref:`configure Sunstone to run behind Apache/NGINX ` or use the CLI tool instead. +.. warning:: The image import operation may take a long time. If you use the Sunstone client and receive a "Cannot contact server: is it running and reachable?" the 30-second Sunstone timeout may have been reached. In this case, either :ref:`configure Sunstone to run behind Apache/NGINX ` or use the CLI tool instead. The following vCenter resources can be easily imported into OpenNebula: diff --git a/source/locale/es/LC_MESSAGES/administration/sunstone_gui/sunstone.po b/source/locale/es/LC_MESSAGES/administration/sunstone_gui/sunstone.po index 3e38d976f8..ac77e757ae 100644 --- a/source/locale/es/LC_MESSAGES/administration/sunstone_gui/sunstone.po +++ b/source/locale/es/LC_MESSAGES/administration/sunstone_gui/sunstone.po @@ -489,6 +489,6 @@ msgstr "" #: ../../source/administration/sunstone_gui/sunstone.rst:162 msgid "" -":ref:`Advanced Deployments `, improving scalability and " +":ref:`Advanced Deployments `, improving scalability and " "isolating the server" msgstr "" diff --git a/source/locale/es/LC_MESSAGES/advanced_administration/scalability/one_scalability.po b/source/locale/es/LC_MESSAGES/advanced_administration/scalability/one_scalability.po index 7f6a2b9db9..a9d80cdb5d 100644 --- a/source/locale/es/LC_MESSAGES/advanced_administration/scalability/one_scalability.po +++ b/source/locale/es/LC_MESSAGES/advanced_administration/scalability/one_scalability.po @@ -235,5 +235,5 @@ msgstr "" #: ../../source/advanced_administration/scalability/one_scalability.rst:87 msgid "" "Please refer to guide about :ref:`Configuring Sunstone for Large Deployments" -" `." +" `." msgstr "" diff --git a/source/marketplace/appliances/marketapps.rst b/source/marketplace/appliances/marketapps.rst index c77c5dcd88..dec2a70b52 100644 --- a/source/marketplace/appliances/marketapps.rst +++ b/source/marketplace/appliances/marketapps.rst @@ -224,7 +224,7 @@ You can also download an app to a standalone file in your desktop: .. warning:: This command requires that the `ONE_SUNSTONE` environment variable is set. Read :ref:`here ` for more information. -.. warning:: Make sure Sunstone is properly deployed to handle this feature. Read :ref:`here ` for more information. +.. warning:: Make sure Sunstone is properly deployed to handle this feature. Read :ref:`here ` for more information. Additional Commands diff --git a/source/marketplace/private_marketplaces/market_http.rst b/source/marketplace/private_marketplaces/market_http.rst index 005d710da7..d129dd3e57 100644 --- a/source/marketplace/private_marketplaces/market_http.rst +++ b/source/marketplace/private_marketplaces/market_http.rst @@ -65,7 +65,7 @@ which is created by passing the following command: $ onemarket create market.conf ID: 100 -.. note:: In order to use the :ref:`download ` functionality, make sure you read the :ref:`Sunstone Advanced Guide `. +.. note:: In order to use the :ref:`download ` functionality, make sure you read the :ref:`Sunstone Advanced Guide `. Tuning & Extending ================================================================================ diff --git a/source/marketplace/private_marketplaces/market_s3.rst b/source/marketplace/private_marketplaces/market_s3.rst index b111ac0487..2909b6cadf 100644 --- a/source/marketplace/private_marketplaces/market_s3.rst +++ b/source/marketplace/private_marketplaces/market_s3.rst @@ -86,7 +86,7 @@ which is created by passing the following command: $ onemarket create market.conf ID: 100 -.. note:: In order to use the :ref:`download ` functionality make sure you read the :ref:`Sunstone Advanced Guide `. +.. note:: In order to use the :ref:`download ` functionality make sure you read the :ref:`Sunstone Advanced Guide `. Tuning & Extending ================================================================================