| 2012-02-13 18:49:59 |
Armando Migliaccio |
bug |
|
|
added bug |
| 2012-02-13 18:50:07 |
Armando Migliaccio |
nova: assignee |
|
Armando Migliaccio (armando-migliaccio) |
|
| 2012-02-13 18:50:09 |
Armando Migliaccio |
nova: status |
New |
Confirmed |
|
| 2012-02-13 18:53:52 |
OpenStack Infra |
nova: status |
Confirmed |
In Progress |
|
| 2012-02-13 18:57:12 |
Armando Migliaccio |
description |
There is nothing particularly wrong with how RRD records are retrieved in xenapi today.
gi
However there are a couple of potential issues, as described below:
-RRD XMLs are always obtained using http over the XS management interface address. Albeit this is fine in most cases there are problems when: i) nova-compute domU is talking to xapi using the internal management network (e.g. talking to xapi via 169.254.0.1) and traffic cannot be routed between domU and dom0; ii) in resource pools, the host address from the xenapi session handle is always the master, which could get overloaded if there are too many requests.
-get_rrd and get_rrd_updates could politely log the IOError exceptions.
I propose to use FLAGS.xenapi_connection_url instead. By using this flag we have the following benefits:
- we transparently use the appropriate scheme and server (regardless of whether the host is a pool or not).
- it is quicker (we don't need to call xapi to get the address) |
There is nothing particularly wrong with how RRD records are retrieved in xenapi today.
However there are a couple of potential issues, as described below:
-RRD XMLs are always obtained using http over the XS management interface address. Albeit this is fine in most cases there are problems when: i) nova-compute domU is talking to xapi using the internal management network (e.g. talking to xapi via 169.254.0.1) and traffic cannot be routed between domU and dom0; ii) in resource pools, the host address from the xenapi session handle is always the master, which could get overloaded if there are too many requests.
- get_rrd and get_rrd_updates could politely log the IOError exceptions.
I propose to use FLAGS.xenapi_connection_url instead. By using this flag we have the following benefits:
- we transparently use the appropriate scheme and server (regardless of whether the host is a pool or not).
- it is quicker (we don't need to call xapi to get the address) |
|
| 2012-02-13 18:57:48 |
Armando Migliaccio |
description |
There is nothing particularly wrong with how RRD records are retrieved in xenapi today.
However there are a couple of potential issues, as described below:
-RRD XMLs are always obtained using http over the XS management interface address. Albeit this is fine in most cases there are problems when: i) nova-compute domU is talking to xapi using the internal management network (e.g. talking to xapi via 169.254.0.1) and traffic cannot be routed between domU and dom0; ii) in resource pools, the host address from the xenapi session handle is always the master, which could get overloaded if there are too many requests.
- get_rrd and get_rrd_updates could politely log the IOError exceptions.
I propose to use FLAGS.xenapi_connection_url instead. By using this flag we have the following benefits:
- we transparently use the appropriate scheme and server (regardless of whether the host is a pool or not).
- it is quicker (we don't need to call xapi to get the address) |
There is nothing particularly wrong with how RRD records are retrieved in xenapi today.
However there are a couple of potential issues, as described below:
- RRD XMLs are always obtained using http over the XS management interface address. Albeit this is fine in most cases there are problems when: i) nova-compute domU is talking to xapi using the internal management network (e.g. talking to xapi via 169.254.0.1) and traffic cannot be routed between domU and dom0; ii) in resource pools, the host address from the xenapi session handle is always the master, which could get overloaded if there are too many requests.
- get_rrd and get_rrd_updates could politely log the IOError exceptions.
I propose to use FLAGS.xenapi_connection_url instead. By using this flag we have the following benefits:
- we transparently use the appropriate scheme and server (regardless of whether the host is in a pool or not).
- it is quicker (we don't need to call xapi to get the address) |
|
| 2012-02-17 00:16:33 |
OpenStack Infra |
nova: status |
In Progress |
Fix Committed |
|
| 2012-02-29 10:27:20 |
Thierry Carrez |
nova: status |
Fix Committed |
Fix Released |
|
| 2012-02-29 10:27:20 |
Thierry Carrez |
nova: milestone |
|
essex-4 |
|
| 2012-04-05 10:14:11 |
Thierry Carrez |
nova: milestone |
essex-4 |
2012.1 |
|
