Re: [vdsm] new API verb: getVersionInfo()

2012-10-21 Thread Peter V. Saveliev 
21.10.2012 09:23, Dan Kenigsberg kirjoitti:

skip /
 We should decide NOW on the format of the capabilities «bag», and never
 change it. Testing for a capability is much more reliable than checking
 a version, and remembering which version had which capability.

 Dan.
Ok, so what will we decide?

1. (long)int bitmask?
… vdsm.caps.CAP_DRIVES = 0x2 …
2. list of literals?
… vdsm.caps.capabilities = [drives, …]
3. something else?


I would prefer the second way, with list of strings.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] new API verb: getVersionInfo()

2012-10-21 Thread Dan Kenigsberg 
On Sun, Oct 21, 2012 at 02:26:44PM +0200, Peter V. Saveliev wrote:
 21.10.2012 09:23, Dan Kenigsberg kirjoitti:
 
 skip /
  We should decide NOW on the format of the capabilities «bag», and never
  change it. Testing for a capability is much more reliable than checking
  a version, and remembering which version had which capability.
 
  Dan.
 Ok, so what will we decide?
 
 1. (long)int bitmask?
 … vdsm.caps.CAP_DRIVES = 0x2 …
 2. list of literals?
 … vdsm.caps.capabilities = [drives, …]

I believe that (2) is basically what Adam Litke has propesed earlier, and I've
liked:

{'enum': 'Capabilities',
 'data': ['StorageDomain_30', 'StorageDomain_22', 'Sanlock', ...]}

'capabilities': ['Capabilities']

Dan.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

[vdsm] unmanaged devices thrown into 'custom' feature

2012-10-21 Thread Dan Kenigsberg 
I have just noticed that when a VM is started for the second time, Engine
issues the create vdsm verb with some information regarding
unmanaged devices (an example is shown below[1]) in the 'custom'
propery bag.

I'm surprised about this, as I was not aware of this usage of the
'custom' dictionary, and Vdsm is not doing anything with the data.

Would anyone elaborate about it? On the face of it, it does not seem
like a pleasant API. If Engine wants to tell Vdsm about the location of
various devices, we should probably be using the 'devices' property, not
the bag of 'custom' property made for user-defined hooks.

I hope this API pecularity can be avoided, and very much hope that no
one is depending on it.

Dan.


[1]
'custom': {
'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice 
{vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide, type=controller, 
bootOrder=0, specParams={}, address={bus=0x00, domain=0x, type=pci, 
slot=0x01, function=0x1}, managed=false, plugged=true, readOnly=false, 
alias=ide0}',

'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709':
 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix, type=channel, 
bootOrder=0, specParams={}, address={port=1, bus=0, controller=0, 
type=virtio-serial}, managed=false, plugged=true, readOnly=false, 
alias=channel0}',

'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6':
 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6, device=virtio-serial, 
type=controller, bootOrder=0, specParams={}, address={bus=0x00, domain=0x, 
type=pci, slot=0x04, function=0x0}, managed=false, plugged=true, 
readOnly=false, alias=virtio-serial0}',

'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb':
 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb, device=spicevmc, type=channel, 
bootOrder=0, specParams={}, address={port=3, bus=0, controller=0, 
type=virtio-serial}, managed=false, plugged=true, readOnly=false, 
alias=channel2}',

'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424':
 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix, type=channel, 
bootOrder=0, specParams={}, address={port=2, bus=0, controller=0, 
type=virtio-serial}, managed=false, plugged=true, readOnly=false, 
alias=channel1}'
}
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] [Engine-devel] unmanaged devices thrown into 'custom' feature

2012-10-21 Thread Livnat Peer 
On 21/10/12 16:42, Dan Kenigsberg wrote:
 I have just noticed that when a VM is started for the second time, Engine
 issues the create vdsm verb with some information regarding
 unmanaged devices (an example is shown below[1]) in the 'custom'
 propery bag.
 
 I'm surprised about this, as I was not aware of this usage of the
 'custom' dictionary, and Vdsm is not doing anything with the data.
 

If I recall correctly the idea of passing the unmanaged devices data in
the custom property was to enable managing stable device addresses in
the hooks (to devices that were added to the VM via hooks from the first
place), so this info is there not for VDSM use.
For example if you add a device in a hook it will be kept in the engine
as a non managed device. later when starting the VM again you would like
to assign the same device address to your device, and you can do so
because you have access to the original address in the custom properties
of the VM.



 Would anyone elaborate about it? On the face of it, it does not seem
 like a pleasant API. If Engine wants to tell Vdsm about the location of
 various devices, we should probably be using the 'devices' property, not
 the bag of 'custom' property made for user-defined hooks.
 
 I hope this API pecularity can be avoided, and very much hope that no
 one is depending on it.
 
 Dan.
 
 
 [1]
 'custom': {
 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice 
 {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
 deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide, type=controller, 
 bootOrder=0, specParams={}, address={bus=0x00, domain=0x, type=pci, 
 slot=0x01, function=0x1}, managed=false, plugged=true, readOnly=false, 
 alias=ide0}',
 
 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709':
  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
 deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix, type=channel, 
 bootOrder=0, specParams={}, address={port=1, bus=0, controller=0, 
 type=virtio-serial}, managed=false, plugged=true, readOnly=false, 
 alias=channel0}',
 
 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6':
  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
 deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6, device=virtio-serial, 
 type=controller, bootOrder=0, specParams={}, address={bus=0x00, 
 domain=0x, type=pci, slot=0x04, function=0x0}, managed=false, 
 plugged=true, readOnly=false, alias=virtio-serial0}',
 
 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb':
  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
 deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb, device=spicevmc, type=channel, 
 bootOrder=0, specParams={}, address={port=3, bus=0, controller=0, 
 type=virtio-serial}, managed=false, plugged=true, readOnly=false, 
 alias=channel2}',
 
 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424':
  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
 deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix, type=channel, 
 bootOrder=0, specParams={}, address={port=2, bus=0, controller=0, 
 type=virtio-serial}, managed=false, plugged=true, readOnly=false, 
 alias=channel1}'
 }
 ___
 Engine-devel mailing list
 engine-de...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 

___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] [Engine-devel] unmanaged devices thrown into 'custom' feature

2012-10-21 Thread Yair Zaslavsky 


- Original Message -
 From: Livnat Peer lp...@redhat.com
 To: Dan Kenigsberg dan...@redhat.com
 Cc: Genadi Chereshnya gcher...@redhat.com, engine-de...@ovirt.org, 
 vdsm-de...@fedorahosted.org
 Sent: Sunday, October 21, 2012 5:18:31 PM
 Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom' feature
 
 On 21/10/12 16:42, Dan Kenigsberg wrote:
  I have just noticed that when a VM is started for the second time,
  Engine
  issues the create vdsm verb with some information regarding
  unmanaged devices (an example is shown below[1]) in the 'custom'
  propery bag.
  
  I'm surprised about this, as I was not aware of this usage of the
  'custom' dictionary, and Vdsm is not doing anything with the data.
  
 
 If I recall correctly the idea of passing the unmanaged devices data
 in
 the custom property was to enable managing stable device addresses in
 the hooks (to devices that were added to the VM via hooks from the
 first
 place), so this info is there not for VDSM use.
 For example if you add a device in a hook it will be kept in the
 engine
 as a non managed device. later when starting the VM again you would
 like
 to assign the same device address to your device, and you can do so
 because you have access to the original address in the custom
 properties
 of the VM.

This is exactly what Eli has explained Gendai and Dan today.
However, just to elaborate - these extra properties are not stored at the two 
columns of vm_static (userdefined_properties, predefined_properties) at the DB.

 
 
 
  Would anyone elaborate about it? On the face of it, it does not
  seem
  like a pleasant API. If Engine wants to tell Vdsm about the
  location of
  various devices, we should probably be using the 'devices'
  property, not
  the bag of 'custom' property made for user-defined hooks.
  
  I hope this API pecularity can be avoided, and very much hope that
  no
  one is depending on it.
  
  Dan.
  
  
  [1]
  'custom': {
  'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice
  {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
  deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide,
  type=controller, bootOrder=0, specParams={},
  address={bus=0x00, domain=0x, type=pci, slot=0x01,
  function=0x1}, managed=false, plugged=true, readOnly=false,
  alias=ide0}',
  
  'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709':
  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
  deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix,
  type=channel, bootOrder=0, specParams={}, address={port=1,
  bus=0, controller=0, type=virtio-serial}, managed=false,
  plugged=true, readOnly=false, alias=channel0}',
  
  'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6':
  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
  deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6,
  device=virtio-serial, type=controller, bootOrder=0,
  specParams={}, address={bus=0x00, domain=0x, type=pci,
  slot=0x04, function=0x0}, managed=false, plugged=true,
  readOnly=false, alias=virtio-serial0}',
  
  'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb':
  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
  deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb,
  device=spicevmc, type=channel, bootOrder=0, specParams={},
  address={port=3, bus=0, controller=0, type=virtio-serial},
  managed=false, plugged=true, readOnly=false, alias=channel2}',
  
  'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424':
  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
  deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix,
  type=channel, bootOrder=0, specParams={}, address={port=2,
  bus=0, controller=0, type=virtio-serial}, managed=false,
  plugged=true, readOnly=false, alias=channel1}'
  }
  ___
  Engine-devel mailing list
  engine-de...@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 
 ___
 Engine-devel mailing list
 engine-de...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] [Engine-devel] unmanaged devices thrown into 'custom' feature

2012-10-21 Thread Eli Mesika 


- Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: Livnat Peer lp...@redhat.com
 Cc: Genadi Chereshnya gcher...@redhat.com, engine-de...@ovirt.org, 
 vdsm-de...@fedorahosted.org
 Sent: Sunday, October 21, 2012 5:38:54 PM
 Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom' feature
 
 
 
 - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Dan Kenigsberg dan...@redhat.com
  Cc: Genadi Chereshnya gcher...@redhat.com,
  engine-de...@ovirt.org, vdsm-de...@fedorahosted.org
  Sent: Sunday, October 21, 2012 5:18:31 PM
  Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom'
  feature
  
  On 21/10/12 16:42, Dan Kenigsberg wrote:
   I have just noticed that when a VM is started for the second
   time,
   Engine
   issues the create vdsm verb with some information regarding
   unmanaged devices (an example is shown below[1]) in the
   'custom'
   propery bag.
   
   I'm surprised about this, as I was not aware of this usage of the
   'custom' dictionary, and Vdsm is not doing anything with the
   data.
   
  
  If I recall correctly the idea of passing the unmanaged devices
  data
  in
  the custom property was to enable managing stable device addresses
  in
  the hooks (to devices that were added to the VM via hooks from the
  first
  place), so this info is there not for VDSM use.
  For example if you add a device in a hook it will be kept in the
  engine
  as a non managed device. later when starting the VM again you would
  like
  to assign the same device address to your device, and you can do so
  because you have access to the original address in the custom
  properties
  of the VM.
 
 This is exactly what Eli has explained Gendai and Dan today.

This is taken from the Stable Device Address design in
http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses

Unmanaged Device
-
Unmanaged Device will be supported in the new format and will include all 
unhandled devices as sound/controller/etc and future devices. Those devices 
will be persistent and will have Type , SubType (device specific) and an 
Address. For 3.1 an unmanaged Device is not exposed to any GUI/REST API. 
Unmanaged devices are passed to vdsm inside a Custom property. VDSM in it turn 
is passing this as is for possible hook processing. 



 However, just to elaborate - these extra properties are not stored
 at the two columns of vm_static (userdefined_properties,
 predefined_properties) at the DB.
 
  
  
  
   Would anyone elaborate about it? On the face of it, it does not
   seem
   like a pleasant API. If Engine wants to tell Vdsm about the
   location of
   various devices, we should probably be using the 'devices'
   property, not
   the bag of 'custom' property made for user-defined hooks.
   
   I hope this API pecularity can be avoided, and very much hope
   that
   no
   one is depending on it.
   
   Dan.
   
   
   [1]
   'custom': {
   'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice
   {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
   deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide,
   type=controller, bootOrder=0, specParams={},
   address={bus=0x00, domain=0x, type=pci, slot=0x01,
   function=0x1}, managed=false, plugged=true, readOnly=false,
   alias=ide0}',
   
   'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709':
   'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
   deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix,
   type=channel, bootOrder=0, specParams={}, address={port=1,
   bus=0, controller=0, type=virtio-serial}, managed=false,
   plugged=true, readOnly=false, alias=channel0}',
   
   'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6':
   'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
   deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6,
   device=virtio-serial, type=controller, bootOrder=0,
   specParams={}, address={bus=0x00, domain=0x, type=pci,
   slot=0x04, function=0x0}, managed=false, plugged=true,
   readOnly=false, alias=virtio-serial0}',
   
   'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb':
   'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
   deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb,
   device=spicevmc, type=channel, bootOrder=0, specParams={},
   address={port=3, bus=0, controller=0, type=virtio-serial},
   managed=false, plugged=true, readOnly=false,
   alias=channel2}',
   
   'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424':