Re: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges
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
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges
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
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges
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.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges
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=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 snipped virbr0: flags=4099UP,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-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges
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. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
