[Adding vdsm-devel]
On 04/09/2013 03:40 PM, Sahina Bose wrote:
Hi all,
I'm testing the bootstrapping of host without reboot on Fedora 18. After host's bootstrap, Ifconfig output returns this:
ovirtmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 <snipped>
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 <snipped>
Running*glusterHostsList* vdsm verb, returns the ip address 192.168.122.1, whereas my host has been added with ip address 10.70.37.219
If I reboot the host, the virbr0 bridge is removed, and there's no issue.
The vdsm verb glusterHostsList - returns ipAddress of host + output of gluster peer probe. This is needed because a periodic sync job needs to make sure that the hosts added in engine are in sync with the gluster cli (hosts could also be added/removed from gluster cli).
How can we make sure glusterHostsList picks the correct ipAddress? Reading the inetinfo based on bridge has been vetoed as we are doing away with bridges.
It would also work if virbr0 was updated in vds_interfaces table. Since this is not happening either - we have an issue.
thanks sahina
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Tue, Apr 09, 2013 at 03:55:25PM +0530, Sahina Bose wrote:
[Adding vdsm-devel]
On 04/09/2013 03:40 PM, Sahina Bose wrote:
Hi all,
I'm testing the bootstrapping of host without reboot on Fedora 18. After host's bootstrap, Ifconfig output returns this:
ovirtmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255
<snipped>
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 <snipped>
Running*glusterHostsList* vdsm verb, returns the ip address 192.168.122.1, whereas my host has been added with ip address 10.70.37.219
If I reboot the host, the virbr0 bridge is removed, and there's no issue.
The vdsm verb glusterHostsList - returns ipAddress of host + output of gluster peer probe. This is needed because a periodic sync job needs to make sure that the hosts added in engine are in sync with the gluster cli (hosts could also be added/removed from gluster cli).
How can we make sure glusterHostsList picks the correct ipAddress?
Can you define (in plain English) what is the "correct" address? The host may have multiple valid addresses (storage, migration, display, whatnot).
Only when it's clear to us, we can start expressing this in Python.
Reading the inetinfo based on bridge has been vetoed as we are doing away with bridges.
It would also work if virbr0 was updated in vds_interfaces table. Since this is not happening either - we have an issue.
It might be a valid hack to drop this default virbr0 on vdsm start - not only the libvirt definition thereof, but also the running kernel device.
However, as expressed above, this would not solve your problem when you have a currently-running host with multiple addresses.
Dan.
Decoding "correct address" - glusterHostsList should return any ipAddress that engine knows as being associated with host. It could be either ipAddress used while adding host (stored as hostname in vds_static) or any of the ipAddresses populated in vds_interface table (addr column) . I do not have enough knowledge about this bit of code to say what entries are made in vds_interface table. I know there's an entry for ovirtmgmt here but not sure if this gets added as part of addHost flow or not.
thx sahina
On 04/09/2013 06:05 PM, Dan Kenigsberg wrote:
On Tue, Apr 09, 2013 at 03:55:25PM +0530, Sahina Bose wrote:
[Adding vdsm-devel]
On 04/09/2013 03:40 PM, Sahina Bose wrote:
Hi all,
I'm testing the bootstrapping of host without reboot on Fedora 18. After host's bootstrap, Ifconfig output returns this:
ovirtmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 <snipped>
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 <snipped>
Running*glusterHostsList* vdsm verb, returns the ip address 192.168.122.1, whereas my host has been added with ip address 10.70.37.219
If I reboot the host, the virbr0 bridge is removed, and there's no issue.
The vdsm verb glusterHostsList - returns ipAddress of host + output of gluster peer probe. This is needed because a periodic sync job needs to make sure that the hosts added in engine are in sync with the gluster cli (hosts could also be added/removed from gluster cli).
How can we make sure glusterHostsList picks the correct ipAddress?
Can you define (in plain English) what is the "correct" address? The host may have multiple valid addresses (storage, migration, display, whatnot).
Only when it's clear to us, we can start expressing this in Python.
Reading the inetinfo based on bridge has been vetoed as we are doing away with bridges.
It would also work if virbr0 was updated in vds_interfaces table. Since this is not happening either - we have an issue.
It might be a valid hack to drop this default virbr0 on vdsm start - not only the libvirt definition thereof, but also the running kernel device.
However, as expressed above, this would not solve your problem when you have a currently-running host with multiple addresses.
Dan.
On 04/09/2013 06:37 PM, Sahina Bose wrote:
Decoding "correct address" - glusterHostsList should return any ipAddress that engine knows as being associated with host. It could be either ipAddress used while adding host (stored as hostname in vds_static) or any of the ipAddresses populated in vds_interface table (addr column) . I do not have enough knowledge about this bit of code to say what entries are made in vds_interface table. I know there's an entry for ovirtmgmt here but not sure if this gets added as part of addHost flow or not.
I guess, vds_interface table is populated by ips given by vdsm through getVdsCaps.
Current glusterHostsList provides one of ipaddress of the local host (other than 127.*.*.*). If virbr0 is enabled, it picks up 192.168.122.1 ip address of the bridge and sends to the engine, but this entry is missing in the table.
The requirement is that we need a ip of the local host which is also stored in the database.
The database has entries of ips of a host those are from physical nics and/or bridges who has slaves to nics.
Regards, Bala
thx sahina
On 04/09/2013 06:05 PM, Dan Kenigsberg wrote:
On Tue, Apr 09, 2013 at 03:55:25PM +0530, Sahina Bose wrote:
[Adding vdsm-devel]
On 04/09/2013 03:40 PM, Sahina Bose wrote:
Hi all,
I'm testing the bootstrapping of host without reboot on Fedora 18. After host's bootstrap, Ifconfig output returns this:
ovirtmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 <snipped>
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 <snipped>
Running*glusterHostsList* vdsm verb, returns the ip address 192.168.122.1, whereas my host has been added with ip address 10.70.37.219
If I reboot the host, the virbr0 bridge is removed, and there's no issue.
The vdsm verb glusterHostsList - returns ipAddress of host + output of gluster peer probe. This is needed because a periodic sync job needs to make sure that the hosts added in engine are in sync with the gluster cli (hosts could also be added/removed from gluster cli).
How can we make sure glusterHostsList picks the correct ipAddress?
Can you define (in plain English) what is the "correct" address? The host may have multiple valid addresses (storage, migration, display, whatnot).
Only when it's clear to us, we can start expressing this in Python.
Reading the inetinfo based on bridge has been vetoed as we are doing away with bridges.
It would also work if virbr0 was updated in vds_interfaces table. Since this is not happening either - we have an issue.
It might be a valid hack to drop this default virbr0 on vdsm start - not only the libvirt definition thereof, but also the running kernel device.
However, as expressed above, this would not solve your problem when you have a currently-running host with multiple addresses.
Dan.
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote:
On 04/09/2013 06:37 PM, Sahina Bose wrote:
Decoding "correct address" - glusterHostsList should return any ipAddress that engine knows as being associated with host. It could be either ipAddress used while adding host (stored as hostname in vds_static) or any of the ipAddresses populated in vds_interface table (addr column) . I do not have enough knowledge about this bit of code to say what entries are made in vds_interface table. I know there's an entry for ovirtmgmt here but not sure if this gets added as part of addHost flow or not.
I guess, vds_interface table is populated by ips given by vdsm through getVdsCaps.
Current glusterHostsList provides one of ipaddress of the local host (other than 127.*.*.*). If virbr0 is enabled, it picks up 192.168.122.1 ip address of the bridge and sends to the engine, but this entry is missing in the table.
The requirement is that we need a ip of the local host which is also stored in the database.
The database has entries of ips of a host those are from physical nics and/or bridges who has slaves to nics.
It's not something I've tested, or want to encourage, but currently, outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. I.e., its local undress may be utterly different from the address used by Engine.
I'd like to keep having this flexibility, and not to assume otherwise.
Why does glusterHostsList need to return the ip of the management network? The client that issued this verb has to know that IP in the first place.
I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" is used all too often in vdsm/gluster/cli.py.
How about changing the Vdsm/Engine API so that the string "localhost" is returned instead? Then, Engine can replace it with whatever it seems fit.
Dan.
On 04/10/2013 12:25 AM, Dan Kenigsberg wrote:
On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote:
On 04/09/2013 06:37 PM, Sahina Bose wrote:
Decoding "correct address" - glusterHostsList should return any ipAddress that engine knows as being associated with host. It could be either ipAddress used while adding host (stored as hostname in vds_static) or any of the ipAddresses populated in vds_interface table (addr column) . I do not have enough knowledge about this bit of code to say what entries are made in vds_interface table. I know there's an entry for ovirtmgmt here but not sure if this gets added as part of addHost flow or not.
I guess, vds_interface table is populated by ips given by vdsm through getVdsCaps.
Current glusterHostsList provides one of ipaddress of the local host (other than 127.*.*.*). If virbr0 is enabled, it picks up 192.168.122.1 ip address of the bridge and sends to the engine, but this entry is missing in the table.
The requirement is that we need a ip of the local host which is also stored in the database.
The database has entries of ips of a host those are from physical nics and/or bridges who has slaves to nics.
It's not something I've tested, or want to encourage, but currently, outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. I.e., its local undress may be utterly different from the address used by Engine.
I'd like to keep having this flexibility, and not to assume otherwise.
Why does glusterHostsList need to return the ip of the management network? The client that issued this verb has to know that IP in the first place.
I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" is used all too often in vdsm/gluster/cli.py.
How about changing the Vdsm/Engine API so that the string "localhost" is returned instead? Then, Engine can replace it with whatever it seems fit.
Dan.
Dan,
Thanks for clarifying. Looks like relying on the IpAddress to determine the host will be prone to errors going forward. We will change the approach and start using the UUID that gluster peer status returns to identify host - will create a new verb glusterPeerList that does this.
And for the current host, like you mentioned, since the engine already knows which vdsm host this command is executed on, the engine will not rely on vdsm to return the host's IP.
thanks sahina
On 04/10/2013 11:18 AM, Sahina Bose wrote:
On 04/10/2013 12:25 AM, Dan Kenigsberg wrote:
On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote:
On 04/09/2013 06:37 PM, Sahina Bose wrote:
Decoding "correct address" - glusterHostsList should return any ipAddress that engine knows as being associated with host. It could be either ipAddress used while adding host (stored as hostname in vds_static) or any of the ipAddresses populated in vds_interface table (addr column) . I do not have enough knowledge about this bit of code to say what entries are made in vds_interface table. I know there's an entry for ovirtmgmt here but not sure if this gets added as part of addHost flow or not.
I guess, vds_interface table is populated by ips given by vdsm through getVdsCaps.
Current glusterHostsList provides one of ipaddress of the local host (other than 127.*.*.*). If virbr0 is enabled, it picks up 192.168.122.1 ip address of the bridge and sends to the engine, but this entry is missing in the table.
The requirement is that we need a ip of the local host which is also stored in the database.
The database has entries of ips of a host those are from physical nics and/or bridges who has slaves to nics.
It's not something I've tested, or want to encourage, but currently, outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. I.e., its local undress may be utterly different from the address used by Engine.
I'd like to keep having this flexibility, and not to assume otherwise.
Why does glusterHostsList need to return the ip of the management network? The client that issued this verb has to know that IP in the first place.
I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" is used all too often in vdsm/gluster/cli.py.
How about changing the Vdsm/Engine API so that the string "localhost" is returned instead? Then, Engine can replace it with whatever it seems fit.
Dan.
Dan,
Thanks for clarifying. Looks like relying on the IpAddress to determine the host will be prone to errors going forward. We will change the approach and start using the UUID that gluster peer status returns to identify host - will create a new verb glusterPeerList that does this.
Current glusterHostsList provides list of {'hostname': HOSTNAME, 'uuid': UUID, 'status': STATE} including local host.
What will be the difference between new glusterPeerList and existing glusterHostsList?
And for the current host, like you mentioned, since the engine already knows which vdsm host this command is executed on, the engine will not rely on vdsm to return the host's IP.
Regards, Bala
On 04/10/2013 02:19 PM, Balamurugan Arumugam wrote:
On 04/10/2013 11:18 AM, Sahina Bose wrote:
On 04/10/2013 12:25 AM, Dan Kenigsberg wrote:
On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote:
On 04/09/2013 06:37 PM, Sahina Bose wrote:
Decoding "correct address" - glusterHostsList should return any ipAddress that engine knows as being associated with host. It could be either ipAddress used while adding host (stored as hostname in vds_static) or any of the ipAddresses populated in vds_interface table (addr column) . I do not have enough knowledge about this bit of code to say what entries are made in vds_interface table. I know there's an entry for ovirtmgmt here but not sure if this gets added as part of addHost flow or not.
I guess, vds_interface table is populated by ips given by vdsm through getVdsCaps.
Current glusterHostsList provides one of ipaddress of the local host (other than 127.*.*.*). If virbr0 is enabled, it picks up 192.168.122.1 ip address of the bridge and sends to the engine, but this entry is missing in the table.
The requirement is that we need a ip of the local host which is also stored in the database.
The database has entries of ips of a host those are from physical nics and/or bridges who has slaves to nics.
It's not something I've tested, or want to encourage, but currently, outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. I.e., its local undress may be utterly different from the address used by Engine.
I'd like to keep having this flexibility, and not to assume otherwise.
Why does glusterHostsList need to return the ip of the management network? The client that issued this verb has to know that IP in the first place.
I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" is used all too often in vdsm/gluster/cli.py.
How about changing the Vdsm/Engine API so that the string "localhost" is returned instead? Then, Engine can replace it with whatever it seems fit.
Dan.
Dan,
Thanks for clarifying. Looks like relying on the IpAddress to determine the host will be prone to errors going forward. We will change the approach and start using the UUID that gluster peer status returns to identify host - will create a new verb glusterPeerList that does this.
Current glusterHostsList provides list of {'hostname': HOSTNAME, 'uuid': UUID, 'status': STATE} including local host.
What will be the difference between new glusterPeerList and existing glusterHostsList?
If this is the case, we just need to make sure at engine we use UUID and not IP address to identify host. We would still need a vdsm verb that will return the current host gluster UUID, to store in engine in case of Add Host flow.
And for the current host, like you mentioned, since the engine already knows which vdsm host this command is executed on, the engine will not rely on vdsm to return the host's IP.
Regards, Bala
On 04/10/2013 02:23 PM, Sahina Bose wrote:
On 04/10/2013 02:19 PM, Balamurugan Arumugam wrote:
On 04/10/2013 11:18 AM, Sahina Bose wrote:
On 04/10/2013 12:25 AM, Dan Kenigsberg wrote:
On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote:
On 04/09/2013 06:37 PM, Sahina Bose wrote:
Decoding "correct address" - glusterHostsList should return any ipAddress that engine knows as being associated with host. It could be either ipAddress used while adding host (stored as hostname in vds_static) or any of the ipAddresses populated in vds_interface table (addr column) . I do not have enough knowledge about this bit of code to say what entries are made in vds_interface table. I know there's an entry for ovirtmgmt here but not sure if this gets added as part of addHost flow or not.
I guess, vds_interface table is populated by ips given by vdsm through getVdsCaps.
Current glusterHostsList provides one of ipaddress of the local host (other than 127.*.*.*). If virbr0 is enabled, it picks up 192.168.122.1 ip address of the bridge and sends to the engine, but this entry is missing in the table.
The requirement is that we need a ip of the local host which is also stored in the database.
The database has entries of ips of a host those are from physical nics and/or bridges who has slaves to nics.
It's not something I've tested, or want to encourage, but currently, outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. I.e., its local undress may be utterly different from the address used by Engine.
I'd like to keep having this flexibility, and not to assume otherwise.
Why does glusterHostsList need to return the ip of the management network? The client that issued this verb has to know that IP in the first place.
I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" is used all too often in vdsm/gluster/cli.py.
How about changing the Vdsm/Engine API so that the string "localhost" is returned instead? Then, Engine can replace it with whatever it seems fit.
Dan.
Dan,
Thanks for clarifying. Looks like relying on the IpAddress to determine the host will be prone to errors going forward. We will change the approach and start using the UUID that gluster peer status returns to identify host - will create a new verb glusterPeerList that does this.
Current glusterHostsList provides list of {'hostname': HOSTNAME, 'uuid': UUID, 'status': STATE} including local host.
What will be the difference between new glusterPeerList and existing glusterHostsList?
If this is the case, we just need to make sure at engine we use UUID and not IP address to identify host. We would still need a vdsm verb that will return the current host gluster UUID, to store in engine in case of Add Host flow.
I think, getVdsCaps can include this. Dan, is it good idea?
And for the current host, like you mentioned, since the engine already knows which vdsm host this command is executed on, the engine will not rely on vdsm to return the host's IP.
Regards, Bala
On Wed, Apr 10, 2013 at 02:27:55PM +0530, Balamurugan Arumugam wrote:
On 04/10/2013 02:23 PM, Sahina Bose wrote:
On 04/10/2013 02:19 PM, Balamurugan Arumugam wrote:
On 04/10/2013 11:18 AM, Sahina Bose wrote:
On 04/10/2013 12:25 AM, Dan Kenigsberg wrote:
On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote:
On 04/09/2013 06:37 PM, Sahina Bose wrote: >Decoding "correct address" - glusterHostsList should return any >ipAddress that engine knows as being associated with host. >It could be either ipAddress used while adding host (stored as >hostname >in vds_static) or any of the ipAddresses populated in vds_interface >table (addr column) . >I do not have enough knowledge about this bit of code to say what >entries are made in vds_interface table. I know there's an entry for >ovirtmgmt here but not sure if this gets added as part of addHost >flow >or not. > I guess, vds_interface table is populated by ips given by vdsm through getVdsCaps.
Current glusterHostsList provides one of ipaddress of the local host (other than 127.*.*.*). If virbr0 is enabled, it picks up 192.168.122.1 ip address of the bridge and sends to the engine, but this entry is missing in the table.
The requirement is that we need a ip of the local host which is also stored in the database.
The database has entries of ips of a host those are from physical nics and/or bridges who has slaves to nics.
It's not something I've tested, or want to encourage, but currently, outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. I.e., its local undress may be utterly different from the address used by Engine.
I'd like to keep having this flexibility, and not to assume otherwise.
Why does glusterHostsList need to return the ip of the management network? The client that issued this verb has to know that IP in the first place.
I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" is used all too often in vdsm/gluster/cli.py.
How about changing the Vdsm/Engine API so that the string "localhost" is returned instead? Then, Engine can replace it with whatever it seems fit.
Dan.
Dan,
Thanks for clarifying. Looks like relying on the IpAddress to determine the host will be prone to errors going forward. We will change the approach and start using the UUID that gluster peer status returns to identify host - will create a new verb glusterPeerList that does this.
Current glusterHostsList provides list of {'hostname': HOSTNAME, 'uuid': UUID, 'status': STATE} including local host.
What will be the difference between new glusterPeerList and existing glusterHostsList?
If this is the case, we just need to make sure at engine we use UUID and not IP address to identify host. We would still need a vdsm verb that will return the current host gluster UUID, to store in engine in case of Add Host flow.
I think, getVdsCaps can include this. Dan, is it good idea?
I do not mind adding glusterUUID to this "bag of things". (preferably impleneting it within the vdsm-gluster subpackage)
I hope Saggi or Adam do not mind making getVdsCaps a little bit more dirty - they may sagguest that you add a getGlusterUUID verb.
Dan.
On Wed, Apr 10, 2013 at 02:23:14PM +0530, Sahina Bose wrote:
On 04/10/2013 02:19 PM, Balamurugan Arumugam wrote:
On 04/10/2013 11:18 AM, Sahina Bose wrote:
On 04/10/2013 12:25 AM, Dan Kenigsberg wrote:
On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote:
On 04/09/2013 06:37 PM, Sahina Bose wrote:
Decoding "correct address" - glusterHostsList should return any ipAddress that engine knows as being associated with host. It could be either ipAddress used while adding host (stored as hostname in vds_static) or any of the ipAddresses populated in vds_interface table (addr column) . I do not have enough knowledge about this bit of code to say what entries are made in vds_interface table. I know there's an entry for ovirtmgmt here but not sure if this gets added as part of addHost flow or not.
I guess, vds_interface table is populated by ips given by vdsm through getVdsCaps.
Current glusterHostsList provides one of ipaddress of the local host (other than 127.*.*.*). If virbr0 is enabled, it picks up 192.168.122.1 ip address of the bridge and sends to the engine, but this entry is missing in the table.
The requirement is that we need a ip of the local host which is also stored in the database.
The database has entries of ips of a host those are from physical nics and/or bridges who has slaves to nics.
It's not something I've tested, or want to encourage, but currently, outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. I.e., its local undress may be utterly different from the address used by Engine.
I'd like to keep having this flexibility, and not to assume otherwise.
Why does glusterHostsList need to return the ip of the management network? The client that issued this verb has to know that IP in the first place.
I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" is used all too often in vdsm/gluster/cli.py.
And what about these ^^^ ? Is there any reason to keep these guesses elsewhere in the code?
vdsm-devel@lists.fedorahosted.org