11:24 a.m.
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com>
To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org>
Sent: Friday, December 14, 2012 2:07:04 AM
Subject: Re: [vdsm] Host bios information
----- Original Message -----
>
>
> ----- Original Message -----
> > From: "Ayal Baron" <abaron(a)redhat.com>
> > To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> > Cc: "VDSM Project Development"
> > <vdsm-devel(a)lists.fedorahosted.org>,
> > "Shu Ming" <shuming(a)linux.vnet.ibm.com>
> > Sent: Thursday, December 13, 2012 11:30:56 AM
> > Subject: Re: [vdsm] Host bios information
> >
> >
> >
> > ----- Original Message -----
> > > I think that for the new current XML-RPC API it's OK to add it
> > > to
> > > the
> > > getVdsCaps() verb.
> > > For the new API I suggest moving it to it's own API. The
> > > smaller
> > > the
> > > APIs the easier they are to deprecate and support.
> > > I quite doubt the fields in getBiosInfo() will change half as
> > > frequently as whatever getVdsCaps() returns.
> > > I also kind of want to throw away getVdsCaps() and split it to
> > > better
> > > named better encapsulated methods.
> >
> > Ack. I just don't understand why not start right now?
> > Any new patch should improve things at least a little.
> > We know getVdsCaps() is wrong so let's put the bios info (and
> > anything in getVdsCaps that makes sense to put with it if
> > relevant)
> > in a separate call. Adding a call in engine to this new method
> > should be a no brainer, I don't think that is a good reason for
> > not
> > doing things properly in vdsm, even if we're talking about the
> > current API.
> Well, from what I know the current overhead per call is too large
> to
> mandate a lot of calls.
> At least that is what I've been told. If that is not an issue, do
> it
> in the XML-RPC API too.
if you call it every 2 seconds to each host then perhaps, but
getVdsCaps is called in initvdsonup which is pretty rare (hours,
days or more) so avoiding an extra call there seems wrong to me.
I totally agree that in the long run it is correct to add a different API on vdsm,
However for the initial 6 bios params:
1. Host Manufacturer - Manufacturer of the host's machine and bios' vendor (e.g
LENOVO)
2. Host Version - For each host the manufacturer gives a unique name (e.g. Lenovo T420s)
3. Host Product Name - ID of the product - same for all similar products (e.g 4174BH4)
4. Host UUID - Unique ID for each host (e.g E03DD601-5219-11CB-BB3F-892313086897)
5. Host Family - Type of host's CPU - (e.g Core i5)
6. Host Serial Number - Unique ID for host's chassis (e.g R9M4N4G)
As Dan stated below, is o.k. for this specific phase to add them to getVdsCaps
So I suggest:
1 Adding the above 6 above params to getVdsCaps
2 Add a new API to vdsm to retrieve host bios information - that will eventually return
the entire list (current will retrieve the exact 6 params and will use the same underlying
implementation)
3 In the future engine will start using the new API
Start using the new API now on the engine side will require much more testing as it might
have an influence on the host state machine.
Thanks
Barak Azulay
> >
> > >
> > > Also, in the json-rpc base model, calls are not only cheaper,
> > > you
> > > also have batch calls. This means you can send multiple
> > > requests
> > > as
> > > one message and have VDSM send you the responses as one message
> > > once
> > > all tasks completed. This makes splitting aggregated methods to
> > > smaller methods painless and with minimal overhead.
> > >
> > > ----- Original Message -----
> > > > From: "Shu Ming" <shuming(a)linux.vnet.ibm.com>
> > > > To: "ybronhei" <ybronhei(a)redhat.com>
> > > > Cc: "VDSM Project Development"
> > > > <vdsm-devel(a)lists.fedorahosted.org>
> > > > Sent: Thursday, December 13, 2012 11:04:09 AM
> > > > Subject: Re: [vdsm] Host bios information
> > > >
> > > > After a quick review of the wiki page, it was stated that
> > > > dmidecode
> > > > gave
> > > > too much informations. Only five fields will be displayed in
> > > > the
> > > > hardware tab, "Manufactory", "Version",
"Family", "UUID" and
> > > > "serial
> > > > number". For "Family", it is mean the CPU core's
family.
> > > > And
> > > > it
> > > > confuses me a bit with the "CPU name" and "CPU
type" fields
> > > > in
> > > > general
> > > > tab. I think we should chose the best one to characterizethe
> > > > CPU
> > > > type.
> > > >
> > > >
> > > > ybronhei:
> > > > > Today in the Api we display general information about the
> > > > > host
> > > > > that
> > > > > vdsm export by getCapabilities Api.
> > > > >
> > > > > We decided to add bios information as part of the
> > > > > information
> > > > > that
> > > > > is
> > > > > displayed in UI under host's general sub-tab.
> > > > >
> > > > > To summaries the feature - We'll modify General tab to
> > > > > Software
> > > > > Information and add another tab for Hardware Information
> > > > > which
> > > > > will
> > > > > include all the bios data that we'll decide to gather from
> > > > > the
> > > > > host
> > > > > and display.
> > > > >
> > > > > Following this feature page:
> > > > > http://www.ovirt.org/Features/Design/HostBiosInfo for more
> > > > > details.
> > > > > All the parameters that can be displayed are mentioned in
> > > > > the
> > > > > wiki.
> > > > >
> > > > > I would greatly appreciate your comments and questions.
> > > > >
> > > > > Thanks.
> > > > >
> > > >
> > > >
> > > > --
> > > > ---
> > > > 舒明 Shu Ming
> > > > Open Virtualization Engineerning; CSTL, IBM Corp.
> > > > Tel: 86-10-82451626 Tieline: 9051626 E-mail:
> > > > shuming(a)cn.ibm.com
> > > > or
> > > > shuming(a)linux.vnet.ibm.com
> > > > Address: 3/F Ring Building, ZhongGuanCun Software Park,
> > > > Haidian
> > > > District, Beijing 100193, PRC
> > > >
> > > >
> > > > _______________________________________________
> > > > vdsm-devel mailing list
> > > > vdsm-devel(a)lists.fedorahosted.org
> > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > >
> > > _______________________________________________
> > > vdsm-devel mailing list
> > > vdsm-devel(a)lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > >
> >
>
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
12:04 p.m.
New subject: [Engine-devel] [vdsm] Host bios information
On 12/16/2012 06:24 PM, Barak Azulay wrote:
----- Original Message -----
> From: "Ayal Baron" <abaron(a)redhat.com>
> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org>
> Sent: Friday, December 14, 2012 2:07:04 AM
> Subject: Re: [vdsm] Host bios information
>
>
>
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> From: "Ayal Baron" <abaron(a)redhat.com>
>>> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
>>> Cc: "VDSM Project Development"
>>> <vdsm-devel(a)lists.fedorahosted.org>,
>>> "Shu Ming" <shuming(a)linux.vnet.ibm.com>
>>> Sent: Thursday, December 13, 2012 11:30:56 AM
>>> Subject: Re: [vdsm] Host bios information
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> I think that for the new current XML-RPC API it's OK to add it
>>>> to
>>>> the
>>>> getVdsCaps() verb.
>>>> For the new API I suggest moving it to it's own API. The
>>>> smaller
>>>> the
>>>> APIs the easier they are to deprecate and support.
>>>> I quite doubt the fields in getBiosInfo() will change half as
>>>> frequently as whatever getVdsCaps() returns.
>>>> I also kind of want to throw away getVdsCaps() and split it to
>>>> better
>>>> named better encapsulated methods.
>>>
>>> Ack. I just don't understand why not start right now?
>>> Any new patch should improve things at least a little.
>>> We know getVdsCaps() is wrong so let's put the bios info (and
>>> anything in getVdsCaps that makes sense to put with it if
>>> relevant)
>>> in a separate call. Adding a call in engine to this new method
>>> should be a no brainer, I don't think that is a good reason for
>>> not
>>> doing things properly in vdsm, even if we're talking about the
>>> current API.
>> Well, from what I know the current overhead per call is too large
>> to
>> mandate a lot of calls.
>> At least that is what I've been told. If that is not an issue, do
>> it
>> in the XML-RPC API too.
>
> if you call it every 2 seconds to each host then perhaps, but
> getVdsCaps is called in initvdsonup which is pretty rare (hours,
> days or more) so avoiding an extra call there seems wrong to me.
I totally agree that in the long run it is correct to add a different API on vdsm,
However for the initial 6 bios params:
1. Host Manufacturer - Manufacturer of the host's machine and bios' vendor (e.g
LENOVO)
2. Host Version - For each host the manufacturer gives a unique name (e.g. Lenovo T420s)
3. Host Product Name - ID of the product - same for all similar products (e.g 4174BH4)
4. Host UUID - Unique ID for each host (e.g E03DD601-5219-11CB-BB3F-892313086897)
5. Host Family - Type of host's CPU - (e.g Core i5)
6. Host Serial Number - Unique ID for host's chassis (e.g R9M4N4G)
As Dan stated below, is o.k. for this specific phase to add them to getVdsCaps
So I suggest:
1 Adding the above 6 above params to getVdsCaps
2 Add a new API to vdsm to retrieve host bios information - that will eventually return
the entire list (current will retrieve the exact 6 params and will use the same underlying
implementation)
3 In the future engine will start using the new API
Start using the new API now on the engine side will require much more testing as it might
have an influence on the host state machine.
Thanks
Barak Azulay
Agree,
In vdsm side as Andrew suggested we can add new xml-rpc Api that
internally calls by getCapabilities until we will define the flow
changes that we need to do in the engine side to permit split calls that
fill VDS object fields.
Before we change the engine side to perform 2 calls to fill vds data, we
need to define the flows for retrieving the data, in which table to keep
it, and when to refresh it.
getCapabilities API call signs for the engine that the host is
operational. By performing another API call we will get into cases that
we've never checked and we need to define and test.
This feature can be split to 2 levels, first we have the requirement for
6 field, and only those fields (as i mentioned in the wiki), those can
be added as part of host capabilities structure, in declared structure
that defines the bios information, until we define the new api.
Additionally, we can add vdsm API the returns only this structure for
future use by the engine.
Anyhow, when defining new structure for bios information we can add more
values of dmidecode in the future if the users will request for such
info, and it won't effect the changes we add to the UI as part of this
feature.
IMPOV, I think we should implement that feature as described now in the
engine side. Using new vdsm API by the engine should be part of another
feature that arranges getCapabilities variables, defines the flows of
requesting bios variables and in which VDS table engine should store
this data.
The engine part patches of this feature are:
http://gerrit.ovirt.org/#/c/10114/ - Modifying db tables
http://gerrit.ovirt.org/#/c/9337/ - Adding bios data to backend's objects
http://gerrit.ovirt.org/#/c/10115/ - UI changes to add host subtab for
Bios info
vdsm part:
http://gerrit.ovirt.org/#/c/9258/ - will be modified asap to external
structure.
I would appreciate your comments and reviews
thanks!
>
>>>
>>>>
>>>> Also, in the json-rpc base model, calls are not only cheaper,
>>>> you
>>>> also have batch calls. This means you can send multiple
>>>> requests
>>>> as
>>>> one message and have VDSM send you the responses as one message
>>>> once
>>>> all tasks completed. This makes splitting aggregated methods to
>>>> smaller methods painless and with minimal overhead.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Shu Ming" <shuming(a)linux.vnet.ibm.com>
>>>>> To: "ybronhei" <ybronhei(a)redhat.com>
>>>>> Cc: "VDSM Project Development"
>>>>> <vdsm-devel(a)lists.fedorahosted.org>
>>>>> Sent: Thursday, December 13, 2012 11:04:09 AM
>>>>> Subject: Re: [vdsm] Host bios information
>>>>>
>>>>> After a quick review of the wiki page, it was stated that
>>>>> dmidecode
>>>>> gave
>>>>> too much informations. Only five fields will be displayed in
>>>>> the
>>>>> hardware tab, "Manufactory", "Version",
"Family", "UUID" and
>>>>> "serial
>>>>> number". For "Family", it is mean the CPU core's
family.
>>>>> And
>>>>> it
>>>>> confuses me a bit with the "CPU name" and "CPU
type" fields
>>>>> in
>>>>> general
>>>>> tab. I think we should chose the best one to characterizethe
>>>>> CPU
>>>>> type.
>>>>>
>>>>>
>>>>> ybronhei:
>>>>>> Today in the Api we display general information about the
>>>>>> host
>>>>>> that
>>>>>> vdsm export by getCapabilities Api.
>>>>>>
>>>>>> We decided to add bios information as part of the
>>>>>> information
>>>>>> that
>>>>>> is
>>>>>> displayed in UI under host's general sub-tab.
>>>>>>
>>>>>> To summaries the feature - We'll modify General tab to
>>>>>> Software
>>>>>> Information and add another tab for Hardware Information
>>>>>> which
>>>>>> will
>>>>>> include all the bios data that we'll decide to gather from
>>>>>> the
>>>>>> host
>>>>>> and display.
>>>>>>
>>>>>> Following this feature page:
>>>>>> http://www.ovirt.org/Features/Design/HostBiosInfo for more
>>>>>> details.
>>>>>> All the parameters that can be displayed are mentioned in
>>>>>> the
>>>>>> wiki.
>>>>>>
>>>>>> I would greatly appreciate your comments and questions.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ---
>>>>> 舒明 Shu Ming
>>>>> Open Virtualization Engineerning; CSTL, IBM Corp.
>>>>> Tel: 86-10-82451626 Tieline: 9051626 E-mail:
>>>>> shuming(a)cn.ibm.com
>>>>> or
>>>>> shuming(a)linux.vnet.ibm.com
>>>>> Address: 3/F Ring Building, ZhongGuanCun Software Park,
>>>>> Haidian
>>>>> District, Beijing 100193, PRC
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> vdsm-devel mailing list
>>>>> vdsm-devel(a)lists.fedorahosted.org
>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>>>>
>>>> _______________________________________________
>>>> vdsm-devel mailing list
>>>> vdsm-devel(a)lists.fedorahosted.org
>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>>>
>>>
>>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Yaniv Bronhaim.
RedHat, Israel
09-7692289
054-7744187
12:32 p.m.
New subject: [Engine-devel] [vdsm] Host bios information
----- Original Message -----
From: "ybronhei" <ybronhei(a)redhat.com>
To: "Barak Azulay" <bazulay(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "VDSM Project
Development" <vdsm-devel(a)lists.fedorahosted.org>
Sent: Sunday, December 16, 2012 12:04:32 PM
Subject: Re: [vdsm] [Engine-devel] Host bios information
On 12/16/2012 06:24 PM, Barak Azulay wrote:
>
>
> ----- Original Message -----
>> From: "Ayal Baron" <abaron(a)redhat.com>
>> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
>> Cc: "VDSM Project Development"
<vdsm-devel(a)lists.fedorahosted.org>
>> Sent: Friday, December 14, 2012 2:07:04 AM
>> Subject: Re: [vdsm] Host bios information
>>
>>
>>
>> ----- Original Message -----
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Ayal Baron" <abaron(a)redhat.com>
>>>> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
>>>> Cc: "VDSM Project Development"
>>>> <vdsm-devel(a)lists.fedorahosted.org>,
>>>> "Shu Ming" <shuming(a)linux.vnet.ibm.com>
>>>> Sent: Thursday, December 13, 2012 11:30:56 AM
>>>> Subject: Re: [vdsm] Host bios information
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> I think that for the new current XML-RPC API it's OK to add it
>>>>> to
>>>>> the
>>>>> getVdsCaps() verb.
>>>>> For the new API I suggest moving it to it's own API. The
>>>>> smaller
>>>>> the
>>>>> APIs the easier they are to deprecate and support.
>>>>> I quite doubt the fields in getBiosInfo() will change half as
>>>>> frequently as whatever getVdsCaps() returns.
>>>>> I also kind of want to throw away getVdsCaps() and split it to
>>>>> better
>>>>> named better encapsulated methods.
>>>>
>>>> Ack. I just don't understand why not start right now?
>>>> Any new patch should improve things at least a little.
>>>> We know getVdsCaps() is wrong so let's put the bios info (and
>>>> anything in getVdsCaps that makes sense to put with it if
>>>> relevant)
>>>> in a separate call. Adding a call in engine to this new method
>>>> should be a no brainer, I don't think that is a good reason for
>>>> not
>>>> doing things properly in vdsm, even if we're talking about the
>>>> current API.
>>> Well, from what I know the current overhead per call is too large
>>> to
>>> mandate a lot of calls.
>>> At least that is what I've been told. If that is not an issue, do
>>> it
>>> in the XML-RPC API too.
>>
>> if you call it every 2 seconds to each host then perhaps, but
>> getVdsCaps is called in initvdsonup which is pretty rare (hours,
>> days or more) so avoiding an extra call there seems wrong to me.
>
>
> I totally agree that in the long run it is correct to add a
> different API on vdsm,
> However for the initial 6 bios params:
>
> 1. Host Manufacturer - Manufacturer of the host's machine and bios'
> vendor (e.g LENOVO)
> 2. Host Version - For each host the manufacturer gives a unique
> name (e.g. Lenovo T420s)
> 3. Host Product Name - ID of the product - same for all similar
> products (e.g 4174BH4)
> 4. Host UUID - Unique ID for each host (e.g
> E03DD601-5219-11CB-BB3F-892313086897)
> 5. Host Family - Type of host's CPU - (e.g Core i5)
> 6. Host Serial Number - Unique ID for host's chassis (e.g R9M4N4G)
>
> As Dan stated below, is o.k. for this specific phase to add them to
> getVdsCaps
>
> So I suggest:
> 1 Adding the above 6 above params to getVdsCaps
> 2 Add a new API to vdsm to retrieve host bios information - that
> will eventually return the entire list (current will retrieve the
> exact 6 params and will use the same underlying implementation)
> 3 In the future engine will start using the new API
>
> Start using the new API now on the engine side will require much
> more testing as it might have an influence on the host state
> machine.
>
> Thanks
> Barak Azulay
>
Agree,
In vdsm side as Andrew suggested we can add new xml-rpc Api that
internally calls by getCapabilities until we will define the flow
changes that we need to do in the engine side to permit split calls
that
fill VDS object fields.
Before we change the engine side to perform 2 calls to fill vds data,
we
need to define the flows for retrieving the data, in which table to
keep
it, and when to refresh it.
getCapabilities API call signs for the engine that the host is
operational. By performing another API call we will get into cases
that
we've never checked and we need to define and test.
This feature can be split to 2 levels, first we have the requirement
for
6 field, and only those fields (as i mentioned in the wiki), those
can
be added as part of host capabilities structure, in declared
structure
that defines the bios information, until we define the new api.
Additionally, we can add vdsm API the returns only this structure for
future use by the engine.
Anyhow, when defining new structure for bios information we can add
more
values of dmidecode in the future if the users will request for such
info, and it won't effect the changes we add to the UI as part of
this
feature.
IMPOV, I think we should implement that feature as described now in
the
engine side. Using new vdsm API by the engine should be part of
another
feature that arranges getCapabilities variables, defines the flows of
requesting bios variables and in which VDS table engine should store
this data.
The engine part patches of this feature are:
http://gerrit.ovirt.org/#/c/10114/ - Modifying db tables
http://gerrit.ovirt.org/#/c/9337/ - Adding bios data to backend's
objects
http://gerrit.ovirt.org/#/c/10115/ - UI changes to add host subtab
for
Bios info
I think we are still missing some information even for the smaller subset - eg asset tag
James can you do a little research with our oem partners and see which makes sense
vdsm part:
http://gerrit.ovirt.org/#/c/9258/ - will be modified asap to external
structure.
I would appreciate your comments and reviews
thanks!
>>
>>>>
>>>>>
>>>>> Also, in the json-rpc base model, calls are not only cheaper,
>>>>> you
>>>>> also have batch calls. This means you can send multiple
>>>>> requests
>>>>> as
>>>>> one message and have VDSM send you the responses as one message
>>>>> once
>>>>> all tasks completed. This makes splitting aggregated methods to
>>>>> smaller methods painless and with minimal overhead.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Shu Ming" <shuming(a)linux.vnet.ibm.com>
>>>>>> To: "ybronhei" <ybronhei(a)redhat.com>
>>>>>> Cc: "VDSM Project Development"
>>>>>> <vdsm-devel(a)lists.fedorahosted.org>
>>>>>> Sent: Thursday, December 13, 2012 11:04:09 AM
>>>>>> Subject: Re: [vdsm] Host bios information
>>>>>>
>>>>>> After a quick review of the wiki page, it was stated that
>>>>>> dmidecode
>>>>>> gave
>>>>>> too much informations. Only five fields will be displayed in
>>>>>> the
>>>>>> hardware tab, "Manufactory", "Version",
"Family", "UUID" and
>>>>>> "serial
>>>>>> number". For "Family", it is mean the CPU
core's family.
>>>>>> And
>>>>>> it
>>>>>> confuses me a bit with the "CPU name" and "CPU
type" fields
>>>>>> in
>>>>>> general
>>>>>> tab. I think we should chose the best one to characterizethe
>>>>>> CPU
>>>>>> type.
>>>>>>
>>>>>>
>>>>>> ybronhei:
>>>>>>> Today in the Api we display general information about the
>>>>>>> host
>>>>>>> that
>>>>>>> vdsm export by getCapabilities Api.
>>>>>>>
>>>>>>> We decided to add bios information as part of the
>>>>>>> information
>>>>>>> that
>>>>>>> is
>>>>>>> displayed in UI under host's general sub-tab.
>>>>>>>
>>>>>>> To summaries the feature - We'll modify General tab to
>>>>>>> Software
>>>>>>> Information and add another tab for Hardware Information
>>>>>>> which
>>>>>>> will
>>>>>>> include all the bios data that we'll decide to gather
from
>>>>>>> the
>>>>>>> host
>>>>>>> and display.
>>>>>>>
>>>>>>> Following this feature page:
>>>>>>> http://www.ovirt.org/Features/Design/HostBiosInfo for more
>>>>>>> details.
>>>>>>> All the parameters that can be displayed are mentioned in
>>>>>>> the
>>>>>>> wiki.
>>>>>>>
>>>>>>> I would greatly appreciate your comments and questions.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ---
>>>>>> 舒明 Shu Ming
>>>>>> Open Virtualization Engineerning; CSTL, IBM Corp.
>>>>>> Tel: 86-10-82451626 Tieline: 9051626 E-mail:
>>>>>> shuming(a)cn.ibm.com
>>>>>> or
>>>>>> shuming(a)linux.vnet.ibm.com
>>>>>> Address: 3/F Ring Building, ZhongGuanCun Software Park,
>>>>>> Haidian
>>>>>> District, Beijing 100193, PRC
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> vdsm-devel mailing list
>>>>>> vdsm-devel(a)lists.fedorahosted.org
>>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>>>>>
>>>>> _______________________________________________
>>>>> vdsm-devel mailing list
>>>>> vdsm-devel(a)lists.fedorahosted.org
>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>>>>
>>>>
>>>
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel(a)lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
--
Yaniv Bronhaim.
RedHat, Israel
09-7692289
054-7744187
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
4168
days inactive
4168
days old
2 comments
3 participants
participants (3)
-
Andrew Cathrow -
Barak Azulay -
ybronhei