| 2014-11-04 20:18:36 |
Matt Kassawara |
bug |
|
|
added bug |
| 2014-11-04 20:34:36 |
Matt Kassawara |
description |
During installation guide testing for Juno, I found the following issues with the swift content that we should consider addressing:
General:
1) From discussion with the swift PTL, we don't need to recommend a minimum of five storage nodes. For other services, the installation guide attempts to balance simplicity and functionality. People can deploy a service, learn how it works, and prepare it for a production environment. Most of the information regarding deployment in a production environment comes from a combination of other documentation. A minimum of two storage nodes, each with two block devices, lowers the barrier to entry and still demonstrates the architecture, particularly for people who just want to try swift. We can explain how to expand this architecture and/or refer people to the swift documentation.
2) The Ubuntu packages don't include useful example configuration files with sane defaults. By including the entire configuration in the installation guide, we have to track changes to configuration options rather than the upstream developers and/or package maintainers. A few options currently generate deprecation warnings. I'm trying to discuss this issue with the package maintainers, but in the meantime we need to update some options.
Install/configure storage nodes:
1) We should probably change from fdisk to parted because the former only officially supports DOS partition tables with a total disk size limitation of 2 TB.
2) We should probably change the fsck scan value in /etc/fstab from 0 to 2 based on the fstab manual page.
Install/configure the proxy node:
1) Why does Ubuntu the package installation explicitly install python-webob?
2) The horizon configuration expects memcached on 127.0.0.1. By default, swift also looks for memcached on 127.0.0.1. The swift instructions configure memcached to listen on the management IP on the controller node, but don't actually change the memcache_servers option to use it. This breaks memcached for both horizon and swift. If we stick to one proxy running on the controller node, I think we can leave memcached on 127.0.0.1. Alternatively, we can configure memcached to listen on multiple interfaces and configure swift accordingly. However, performing the latter raises security implications that require further discussion.
3) From discussion with the swift PTL, configuring the storage/replication network (R) during ring creation also requires running additional services on each storage node, but the guide doesn't explain how to achieve the latter.
4) From discussion with the swift PTL, we should put all storage nodes into one zone rather than a unique zone per node during ring creation.
6) From discussion with the swift PTL, we should reduce the partition power from 18 to 10 during ring creation because the former requires a significantly advanced configuration beyond what the guide covers.
7) During ring creation, we should specify the region to avoid a warning message.
I'll update this bug as I find issues with other distributions. Also, some patches for this bug may need backporting to Juno and possibly Icehouse. |
During installation guide testing for Juno, I found the following issues with the swift content that we should consider addressing:
General:
1) From discussion with the swift PTL, we don't need to recommend a minimum of five storage nodes. For other services, the installation guide attempts to balance simplicity and functionality. People can deploy a service, learn how it works, and prepare it for a production environment. Most of the information regarding deployment in a production environment comes from a combination of other documentation. A minimum of two storage nodes, each with two block devices, lowers the barrier to entry and still demonstrates the architecture, particularly for people who just want to try swift. We can explain how to expand this architecture and/or refer people to the swift documentation.
2) The Ubuntu packages don't include useful example configuration files with sane defaults. By including the entire configuration in the installation guide, we have to track changes to configuration options rather than the upstream developers and/or package maintainers. A few options currently generate deprecation warnings. I'm trying to discuss this issue with the package maintainers, but in the meantime we need to update some options.
3) The section file names and structure don't agree with the rest of the guide.
Install/configure storage nodes:
1) We should probably change from fdisk to parted because the former only officially supports DOS partition tables with a total disk size limitation of 2 TB.
2) We should probably change the fsck scan value in /etc/fstab from 0 to 2 based on the fstab manual page.
Install/configure the proxy node:
1) Why does Ubuntu the package installation explicitly install python-webob?
2) The horizon configuration expects memcached on 127.0.0.1. By default, swift also looks for memcached on 127.0.0.1. The swift instructions configure memcached to listen on the management IP on the controller node, but don't actually change the memcache_servers option to use it. This breaks memcached for both horizon and swift. If we stick to one proxy running on the controller node, I think we can leave memcached on 127.0.0.1. Alternatively, we can configure memcached to listen on multiple interfaces and configure swift accordingly. However, performing the latter raises security implications that require further discussion.
3) From discussion with the swift PTL, configuring the storage/replication network (R) during ring creation also requires running additional services on each storage node, but the guide doesn't explain how to achieve the latter.
4) From discussion with the swift PTL, we should put all storage nodes into one zone rather than a unique zone per node during ring creation.
6) From discussion with the swift PTL, we should reduce the partition power from 18 to 10 during ring creation because the former requires a significantly advanced configuration beyond what the guide covers.
7) During ring creation, we should specify the region to avoid a warning message.
I'll update this bug as I find issues with other distributions. Also, some patches for this bug may need backporting to Juno and possibly Icehouse. |
|
| 2014-11-07 16:35:08 |
OpenStack Infra |
tags |
install-guide |
in-stable-juno install-guide |
|
| 2014-11-15 03:12:32 |
Matt Kassawara |
description |
During installation guide testing for Juno, I found the following issues with the swift content that we should consider addressing:
General:
1) From discussion with the swift PTL, we don't need to recommend a minimum of five storage nodes. For other services, the installation guide attempts to balance simplicity and functionality. People can deploy a service, learn how it works, and prepare it for a production environment. Most of the information regarding deployment in a production environment comes from a combination of other documentation. A minimum of two storage nodes, each with two block devices, lowers the barrier to entry and still demonstrates the architecture, particularly for people who just want to try swift. We can explain how to expand this architecture and/or refer people to the swift documentation.
2) The Ubuntu packages don't include useful example configuration files with sane defaults. By including the entire configuration in the installation guide, we have to track changes to configuration options rather than the upstream developers and/or package maintainers. A few options currently generate deprecation warnings. I'm trying to discuss this issue with the package maintainers, but in the meantime we need to update some options.
3) The section file names and structure don't agree with the rest of the guide.
Install/configure storage nodes:
1) We should probably change from fdisk to parted because the former only officially supports DOS partition tables with a total disk size limitation of 2 TB.
2) We should probably change the fsck scan value in /etc/fstab from 0 to 2 based on the fstab manual page.
Install/configure the proxy node:
1) Why does Ubuntu the package installation explicitly install python-webob?
2) The horizon configuration expects memcached on 127.0.0.1. By default, swift also looks for memcached on 127.0.0.1. The swift instructions configure memcached to listen on the management IP on the controller node, but don't actually change the memcache_servers option to use it. This breaks memcached for both horizon and swift. If we stick to one proxy running on the controller node, I think we can leave memcached on 127.0.0.1. Alternatively, we can configure memcached to listen on multiple interfaces and configure swift accordingly. However, performing the latter raises security implications that require further discussion.
3) From discussion with the swift PTL, configuring the storage/replication network (R) during ring creation also requires running additional services on each storage node, but the guide doesn't explain how to achieve the latter.
4) From discussion with the swift PTL, we should put all storage nodes into one zone rather than a unique zone per node during ring creation.
6) From discussion with the swift PTL, we should reduce the partition power from 18 to 10 during ring creation because the former requires a significantly advanced configuration beyond what the guide covers.
7) During ring creation, we should specify the region to avoid a warning message.
I'll update this bug as I find issues with other distributions. Also, some patches for this bug may need backporting to Juno and possibly Icehouse. |
During installation guide testing for Juno, I found the following issues with the swift content that we should consider addressing:
General:
1) From discussion with the swift PTL, we don't need to recommend a minimum of five storage nodes. For other services, the installation guide attempts to balance simplicity and functionality. People can deploy a service, learn how it works, and prepare it for a production environment. Most of the information regarding deployment in a production environment comes from a combination of other documentation. A minimum of two storage nodes, each with two block devices, lowers the barrier to entry and still demonstrates the architecture, particularly for people who just want to try swift. We can explain how to expand this architecture and/or refer people to the swift documentation.
2) The Ubuntu packages don't include useful example configuration files with sane defaults. By including the entire configuration in the installation guide, we have to track changes to configuration options rather than the upstream developers and/or package maintainers. A few options currently generate deprecation warnings. I'm trying to discuss this issue with the package maintainers, but in the meantime we need to update some options.
3) The section file names and structure don't agree with the rest of the guide.
4) Integrate swift nodes with example architectures.
Install/configure storage nodes:
1) We should probably change from fdisk to parted because the former only officially supports DOS partition tables with a total disk size limitation of 2 TB.
2) We should probably change the fsck scan value in /etc/fstab from 0 to 2 based on the fstab manual page.
Install/configure the proxy node:
1) Why does Ubuntu the package installation explicitly install python-webob?
2) The horizon configuration expects memcached on 127.0.0.1. By default, swift also looks for memcached on 127.0.0.1. The swift instructions configure memcached to listen on the management IP on the controller node, but don't actually change the memcache_servers option to use it. This breaks memcached for both horizon and swift. If we stick to one proxy running on the controller node, I think we can leave memcached on 127.0.0.1. Alternatively, we can configure memcached to listen on multiple interfaces and configure swift accordingly. However, performing the latter raises security implications that require further discussion.
3) From discussion with the swift PTL, configuring the storage/replication network (R) during ring creation also requires running additional services on each storage node, but the guide doesn't explain how to achieve the latter.
4) From discussion with the swift PTL, we should put all storage nodes into one zone rather than a unique zone per node during ring creation.
5) From discussion with the swift PTL, we should reduce the partition power from 18 to 10 during ring creation because the former requires a significantly advanced configuration beyond what the guide covers.
6) During ring creation, we should specify the region to avoid a warning message.
I'll update this bug as I find issues with other distributions. Also, some patches for this bug may need backporting to Juno and possibly Icehouse. |
|
| 2014-12-25 12:40:44 |
OpenStack Infra |
openstack-manuals: status |
In Progress |
Fix Released |
|
