5:10 a.m.
This is a multi-part message in MIME format.
--------------080204010900060200040902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
--------------080204010900060200040902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<pre><font face="sans-serif">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 <b class="moz-txt-star"><span
class="moz-txt-tag">*</span>glusterHostsList<span
class="moz-txt-tag">*</span></b> 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.</font>
<font face="sans-serif">
</font></pre>
<font face="sans-serif">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</font> are in sync with the gluster cli (hosts could
also be added/removed from gluster cli).<br>
<br>
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.<br>
<br>
It would also work if virbr0 was updated in vds_interfaces table.
Since this is not happening either - we have an issue.<br>
<br>
thanks<br>
sahina<br>
<br>
</body>
</html>
--------------080204010900060200040902--
5:25 a.m.
This is a multi-part message in MIME format.
--------------040701030207030604030109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
[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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--------------040701030207030604030109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
[Adding vdsm-devel]<br>
<br>
<div class="moz-cite-prefix">On 04/09/2013 03:40 PM, Sahina Bose
wrote:<br>
</div>
<blockquote cite="mid:5163E932.8040300@redhat.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre><font face="sans-serif">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 <b class="moz-txt-star"><span
class="moz-txt-tag">*</span>glusterHostsList<span
class="moz-txt-tag">*</span></b> 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.</font>
<font face="sans-serif">
</font></pre>
<font face="sans-serif">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</font> are in sync with the gluster cli (hosts
could also be added/removed from gluster cli).<br>
<br>
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.<br>
<br>
It would also work if virbr0 was updated in vds_interfaces table.
Since this is not happening either - we have an issue.<br>
<br>
thanks<br>
sahina<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/engine-devel">...
</pre>
</blockquote>
<br>
</body>
</html>
--------------040701030207030604030109--
7:35 a.m.
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.
8:07 a.m.
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.
8:58 a.m.
New subject: [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=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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
1:55 p.m.
New subject: [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.
12:48 a.m.
New subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges
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
3:49 a.m.
New subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges
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
3:53 a.m.
New subject: [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
3:57 a.m.
New subject: [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
6:41 a.m.
New subject: [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.
8:09 a.m.
New subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges
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?
4042
days inactive
4044
days old
11 comments
3 participants
participants (3)
-
Balamurugan Arumugam -
Dan Kenigsberg -
Sahina Bose