Activity log for bug #1588481

Date Who What changed Old value New value Message
2016-06-02 18:21:25 Andrey Epifanov bug added bug
2016-06-02 18:21:31 Andrey Epifanov fuel: status New Confirmed
2016-06-02 18:21:43 Andrey Epifanov tags customer-found support
2016-06-02 20:14:21 Andrey Epifanov summary [Doc]Fix NICs map reference architecture Fix NICs map reference architecture
2016-06-02 20:15:32 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) So, our recommendation should look like: - Admin * Should be untagged * >= 1G * Might be united with other networks * Ensure no DHCP services are interfering on this segment - Management * Must be separated (except Admin, might be united with Admin) * >= 10G * Bonding is recommended - Private * Depends on purpose of the cloud * If it is not critical might be united with Private net * >= 10G (Depends on cluster size, 1G - for small and test clouds) * Bonding is recommended * Separate NIC is recommended - Public * Depends on purpose of the cloud * If it is not critical might be united with Private net * >= 10G (Depends on cluster size, 1G - for small and internal clouds) * Bonding is recommended * Separate NIC is recommended - Storage * Should be separate * >= 10G * Bonding is strongly recommended * CEPH should have one more separate NIC for replication If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication * Should be separate   * >= 10G   * Bonding is strongly recommended If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 20:38:02 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication * Should be separate   * >= 10G   * Bonding is strongly recommended If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: 2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag) Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag) Private (tag) Private (tag) Private (tag) Storage (tag) CEPH Repl(tag) eth2 Storage (tag) Storage (untag) CEPH Repl (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 20:39:15 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: 2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag) Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag) Private (tag) Private (tag) Private (tag) Storage (tag) CEPH Repl(tag) eth2 Storage (tag) Storage (untag) CEPH Repl (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like:    2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag)                              CEPH Repl (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 20:40:36 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like:    2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag)                              CEPH Repl (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like:    2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag)                              CEPH Repl (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 21:42:28 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like:    2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag)                              CEPH Repl (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: 2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag) Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag) Private (tag) Private (tag) Private (tag) Storage (tag) CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 21:44:56 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: 2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag) Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag) Private (tag) Private (tag) Private (tag) Storage (tag) CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like:         2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 21:50:18 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like:         2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: ```         2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) ``` If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 21:50:59 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: ```         2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) ``` If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: ~~~         2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) ~~~ If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 21:53:18 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: ~~~         2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) ~~~ If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: ~~~         '''2 NICs''' 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) ~~~ If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 21:54:23 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: ~~~         '''2 NICs''' 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) ~~~ If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: ~~~         '''2 NICs''' 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) ~~~ ^super^script If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 21:57:16 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: ~~~         '''2 NICs''' 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) eth3 CEPH Repl (untag) ~~~ ^super^script If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like:         2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) CEPH Repl (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 22:08:10 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like:         2 NICs 3 NICs 4 NICs eth0 Admin (untag) Admin (untag) Admin (untag)         Mgmt (tag) Mgmt (tag) Mgmt (tag) eth1 Public (untag/tag) Public (untag/tag) Public (untag/tag)         Private (tag) Private (tag) Private (tag)         Storage (tag)         CEPH Repl(tag) eth2 Storage (tag) Storage (untag) CEPH Repl (untag) eth3 CEPH Repl (untag) If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: http://paste.openstack.org/show/507370/ If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 22:17:38 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: http://paste.openstack.org/show/507370/ If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: http://paste.openstack.org/show/507371/ If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-02 22:24:12 Andrey Epifanov description The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map should look like: http://paste.openstack.org/show/507371/ If current configuration is not satisfied to our recommendations to generate a warning with risks description and confirmation whether the user is ready to take these risks. The current Fuel documentation contains very strange recommendation according network architecture: https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network The main points: 1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc) 2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic - Storage network. - CEPH replication network. So, our recommendation should look like: - Admin   * Should be untagged   * >= 1G   * Might be united with other networks   * Ensure no DHCP services are interfering on this segment - Management   * Must be separated (except Admin, might be united with Admin)   * >= 10G   * Bonding is recommended - Private   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and test clouds)   * Bonding is recommended   * Separate NIC is recommended - Public   * Depends on purpose of the cloud   * If it is not critical might be united with Private net   * >= 10G (Depends on cluster size, 1G - for small and internal clouds)   * Bonding is recommended   * Separate NIC is recommended - Storage   * Should be separate   * >= 10G   * Bonding is strongly recommended  - CEPH Replication   * Should be separate   * >= 10G   * Bonding is strongly recommended According these requirements our network map might look like: http://paste.openstack.org/show/507371/ During the choosing nic mapping for cloud you should keep in mind the main purpose of cloud and make decision based on which kind of traffic will be more significant in this cloud. If the configuration before the deploy is not satisfied to our recommendations FUEL should generate a warning with risks description and confirmation whether the user is ready to take these risks.
2016-06-06 09:52:34 Aleksey Zvyagintsev tags customer-found support area-docs customer-found support
2016-06-06 09:54:22 Olga Gusarenko fuel: assignee Fuel Documentation Team (fuel-docs)
2016-06-06 09:56:07 Evgeny Konstantinov fuel: milestone 9.0-updates
2016-06-06 09:56:13 Evgeny Konstantinov fuel: importance Undecided High
2016-10-13 11:59:39 Roman Vyalov fuel/mitaka: importance Undecided High
2016-10-13 11:59:39 Roman Vyalov fuel/mitaka: status New Confirmed
2016-10-13 11:59:39 Roman Vyalov fuel/mitaka: milestone 9.2
2016-10-13 11:59:39 Roman Vyalov fuel/mitaka: assignee Fuel Documentation Team (fuel-docs)
2016-10-13 11:59:41 Roman Vyalov fuel: status Confirmed Won't Fix
2016-11-16 06:53:53 Andrey Epifanov fuel/mitaka: status Confirmed In Progress
2016-11-16 06:54:01 Andrey Epifanov fuel/mitaka: status In Progress Incomplete