| 2015-07-27 03:28:29 |
Sam Stoelinga |
bug |
|
|
added bug |
| 2015-07-27 03:28:55 |
Sam Stoelinga |
description |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services. |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services.
PS: Would like to a know a workaround on an existing environment. |
|
| 2015-07-27 05:57:02 |
Nastya Urlapova |
tags |
|
feature-plugins |
|
| 2015-07-27 06:11:42 |
Sam Stoelinga |
description |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services.
PS: Would like to a know a workaround on an existing environment. |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services.
PS: Would like to a know a workaround on an existing environment.
After some more research it looks like this is the line that's causing this behaviour:
cibadmin --query | grep vip_management | grep zabbix
<rsc_colocation id="vip_management-with-zabbix-server" rsc="vip__management" score="INFINITY" with-rsc="p_zabbix-server"/>
Please confirm whether my initial research makes sense and whether I can safely remove this line from the cib? |
|
| 2015-07-27 06:32:14 |
Sam Stoelinga |
description |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services.
PS: Would like to a know a workaround on an existing environment.
After some more research it looks like this is the line that's causing this behaviour:
cibadmin --query | grep vip_management | grep zabbix
<rsc_colocation id="vip_management-with-zabbix-server" rsc="vip__management" score="INFINITY" with-rsc="p_zabbix-server"/>
Please confirm whether my initial research makes sense and whether I can safely remove this line from the cib? |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services.
PS: Would like to a know a workaround on an existing environment.
After some more research it looks like this is the line that's causing this behaviour:
cibadmin --query | grep vip_management | grep zabbix
<rsc_colocation id="vip_management-with-zabbix-server" rsc="vip__management" score="INFINITY" with-rsc="p_zabbix-server"/>
Please confirm whether my initial research makes sense and whether I can safely remove this line from the cib?
It that the recommended way of achieving this is through Pacemaker resource groups:
http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-resource-sets-collocation.html
Example 6.15. A group resource with the equivalent colocation rules
<group id="dummy">
<primitive id="A" .../>
<primitive id="B" .../>
<primitive id="C" .../>
<primitive id="D" .../>
</group>
This notation can also be used in this context to tell the cluster that a set of resources must all be located with a common peer, but have no dependencies on each other. In this scenario, unlike the previous on, B would be allowed to remain active even if A or C (or both) were inactive. |
|
| 2015-07-27 06:42:58 |
Sam Stoelinga |
description |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services.
PS: Would like to a know a workaround on an existing environment.
After some more research it looks like this is the line that's causing this behaviour:
cibadmin --query | grep vip_management | grep zabbix
<rsc_colocation id="vip_management-with-zabbix-server" rsc="vip__management" score="INFINITY" with-rsc="p_zabbix-server"/>
Please confirm whether my initial research makes sense and whether I can safely remove this line from the cib?
It that the recommended way of achieving this is through Pacemaker resource groups:
http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-resource-sets-collocation.html
Example 6.15. A group resource with the equivalent colocation rules
<group id="dummy">
<primitive id="A" .../>
<primitive id="B" .../>
<primitive id="C" .../>
<primitive id="D" .../>
</group>
This notation can also be used in this context to tell the cluster that a set of resources must all be located with a common peer, but have no dependencies on each other. In this scenario, unlike the previous on, B would be allowed to remain active even if A or C (or both) were inactive. |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services.
After some more research it looks like this is the line that's causing this behaviour:
cibadmin --query | grep vip_management | grep zabbix
<rsc_colocation id="vip_management-with-zabbix-server" rsc="vip__management" score="INFINITY" with-rsc="p_zabbix-server"/>
The current workaround is to remove that line from the cib with:
cibadmin --delete --xml-text '<rsc_colocation id="vip_management-with-zabbix-server"/>'
It that the recommended way of achieving this is through Pacemaker resource groups:
http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-resource-sets-collocation.html
Example 6.15. A group resource with the equivalent colocation rules
<group id="dummy">
<primitive id="A" .../>
<primitive id="B" .../>
<primitive id="C" .../>
<primitive id="D" .../>
</group>
This notation can also be used in this context to tell the cluster that a set of resources must all be located with a common peer, but have no dependencies on each other. In this scenario, unlike the previous on, B would be allowed to remain active even if A or C (or both) were inactive. |
|
| 2015-07-27 06:43:26 |
Sam Stoelinga |
description |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services.
After some more research it looks like this is the line that's causing this behaviour:
cibadmin --query | grep vip_management | grep zabbix
<rsc_colocation id="vip_management-with-zabbix-server" rsc="vip__management" score="INFINITY" with-rsc="p_zabbix-server"/>
The current workaround is to remove that line from the cib with:
cibadmin --delete --xml-text '<rsc_colocation id="vip_management-with-zabbix-server"/>'
It that the recommended way of achieving this is through Pacemaker resource groups:
http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-resource-sets-collocation.html
Example 6.15. A group resource with the equivalent colocation rules
<group id="dummy">
<primitive id="A" .../>
<primitive id="B" .../>
<primitive id="C" .../>
<primitive id="D" .../>
</group>
This notation can also be used in this context to tell the cluster that a set of resources must all be located with a common peer, but have no dependencies on each other. In this scenario, unlike the previous on, B would be allowed to remain active even if A or C (or both) were inactive. |
Whole cluster goes down if you execute crm resource stop p_zabbix-server. This is because the resource vip__management (ocf::fuel:ns_IPaddr2) will also stop.
Steps to reproduce:
1. Deploy environment using Fuel 6.1 with Zabbix plugin enabled.
2. After deployment execute crm resource stop p_zabbix-server
Current result:
The vip_management resource also becomes stopped. Rendering lots of services unaccessible.
Expected result:
Ability to independently stop zabbix server wtihout influencing other services.
After some more research it looks like this is the line that's causing this behaviour:
cibadmin --query | grep vip_management | grep zabbix
<rsc_colocation id="vip_management-with-zabbix-server" rsc="vip__management" score="INFINITY" with-rsc="p_zabbix-server"/>
The current workaround is to remove that line from the cib with:
cibadmin --delete --xml-text '<rsc_colocation id="vip_management-with-zabbix-server"/>'
Recommended way of achieving this is through Pacemaker resource groups:
http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-resource-sets-collocation.html
Example 6.15. A group resource with the equivalent colocation rules
<group id="dummy">
<primitive id="A" .../>
<primitive id="B" .../>
<primitive id="C" .../>
<primitive id="D" .../>
</group>
This notation can also be used in this context to tell the cluster that a set of resources must all be located with a common peer, but have no dependencies on each other. In this scenario, unlike the previous on, B would be allowed to remain active even if A or C (or both) were inactive. |
|
| 2015-07-27 07:37:42 |
Oleksiy Molchanov |
fuel: milestone |
|
7.0 |
|
| 2015-07-27 07:38:02 |
Oleksiy Molchanov |
fuel: assignee |
|
Fuel Plugin Zabbix (fuel-plugin-zabbix) |
|
| 2015-07-27 09:06:28 |
Bartosz Kupidura |
fuel: status |
New |
Confirmed |
|
| 2015-07-28 11:46:45 |
Piotr Misiak |
fuel: assignee |
Fuel Plugin Zabbix (fuel-plugin-zabbix) |
Piotr Misiak (piotr-misiak) |
|
| 2015-07-28 11:59:30 |
Piotr Misiak |
fuel: assignee |
Piotr Misiak (piotr-misiak) |
|
|
| 2015-07-28 11:59:55 |
Piotr Misiak |
fuel: assignee |
|
Fuel Plugin Zabbix (fuel-plugin-zabbix) |
|
| 2015-07-29 10:17:13 |
Aleksandr Didenko |
fuel: importance |
Undecided |
High |
|
| 2015-07-29 11:55:08 |
OpenStack Infra |
fuel: status |
Confirmed |
In Progress |
|
| 2015-07-29 11:55:08 |
OpenStack Infra |
fuel: assignee |
Fuel Plugin Zabbix (fuel-plugin-zabbix) |
Bartosz Kupidura (zynzel) |
|
| 2015-07-30 08:22:42 |
OpenStack Infra |
fuel: status |
In Progress |
Fix Committed |
|
| 2015-09-03 12:00:05 |
Nikita Marchenko |
tags |
feature-plugins |
feature-plugins on-verification |
|
| 2015-09-04 15:05:21 |
Nikita Marchenko |
fuel: status |
Fix Committed |
Fix Released |
|
| 2015-09-04 15:05:30 |
Nikita Marchenko |
tags |
feature-plugins on-verification |
feature-plugins |
|
| 2015-11-11 17:32:11 |
Oleksandr Liemieshko |
nominated for series |
|
fuel/6.1.x |
|
| 2015-11-11 17:32:11 |
Oleksandr Liemieshko |
bug task added |
|
fuel/6.1.x |
|
| 2015-11-11 17:32:28 |
Oleksandr Liemieshko |
fuel/6.1.x: importance |
Undecided |
Critical |
|
| 2015-11-11 17:32:53 |
Oleksandr Liemieshko |
fuel/6.1.x: assignee |
|
Fuel Library Team (fuel-library) |
|
| 2015-11-11 17:33:13 |
Oleksandr Liemieshko |
tags |
feature-plugins |
customer-found feature-plugins support |
|
| 2015-11-12 10:24:38 |
Artem Roma |
fuel/6.1.x: status |
New |
Confirmed |
|
| 2015-11-12 10:24:57 |
Artem Roma |
fuel/6.1.x: milestone |
|
6.1-updates |
|
| 2015-12-10 11:31:15 |
Denis Meltsaykin |
fuel/6.1.x: status |
Confirmed |
Triaged |
|
| 2015-12-10 11:31:54 |
Denis Meltsaykin |
fuel/6.1.x: assignee |
Fuel Library Team (fuel-library) |
Denis Meltsaykin (dmeltsaykin) |
|
| 2015-12-10 15:16:07 |
Vitaly Sedelnik |
fuel/6.1.x: milestone |
6.1-updates |
6.1-mu-5 |
|
| 2016-01-25 10:45:22 |
Denis Meltsaykin |
fuel/6.1.x: status |
Triaged |
Won't Fix |
|
| 2016-02-19 04:54:44 |
Vitaly Sedelnik |
fuel/6.1.x: milestone |
6.1-mu-5 |
6.1-updates |
|
| 2016-03-10 10:27:06 |
Vitaly Sedelnik |
tags |
customer-found feature-plugins support |
customer-found feature-plugins support wontfix-feature |
|
