rounding microseconds in vm conf update

Hello! Ovirt sdk process updating of vm template with rounding of microseconds in creation_time. And vm is marked as vm which has a newer configuration because of this, but there is not a new configuration, all difference between current configuration and next_run configuration is creation_time. It is not correct. For example, diff between curl get-request for this state of vm and next_run state is: [ovirt-system-tests]$ diff current_state.txt next_state.txt 55c55 < <creation_time>2017-06-14T06:18:03*.987*-04:00</creation_time> ---
<creation_time>2017-06-14T06:18:03*.000*-04:00</creation_time>
76a77 And example how to request update for reach rounding is a test in ovirt_system_test: @ovirtlago.testlib.with_ovirt_api def update_round(api): vm = api.vms.get('vm0') #there vm.creation_time.isoformat() is a real datetime with microseconds vm.update() #after this vm.creation_time.isoformat() contains a real datetime with microseconds, #but vm becames vm with newer configuration and # next_run creation time becomes rounded to seconds Does anyone have idea how to fix this? Sincerely, Valentina Makarova

On 06/21/2017 10:35 PM, Valentina Makarova wrote:
Hello!
Ovirt sdk process updating of vm template with rounding of microseconds in creation_time. And vm is marked as vm which has a newer configuration because of this, but there is not a new configuration, all difference between current configuration and next_run configuration is creation_time. It is not correct. For example, diff between curl get-request for this state of vm and next_run state is: [ovirt-system-tests]$ diff current_state.txt next_state.txt 55c55 < <creation_time>2017-06-14T06:18:03*.987*-04:00</creation_time> ---
<creation_time>2017-06-14T06:18:03*.000*-04:00</creation_time>
76a77
The SDKs don't round anything, they use the same precision than the engine. Is that with the latest version of the engine? There was a bug related to this which was fixed in 4.2 already: Updating a VM with 'next_run=true' returns the current memory instead of the next run memory https://bugzilla.redhat.com/1417201 The reason for that is that the 'creation_time' is stored with different precision in the database and in the OVF file.
And example how to request update for reach rounding is a test in ovirt_system_test:
@ovirtlago.testlib.with_ovirt_api def update_round(api): vm = api.vms.get('vm0') #there vm.creation_time.isoformat() is a real datetime with microseconds vm.update() #after this vm.creation_time.isoformat() contains a real datetime with microseconds, #but vm becames vm with newer configuration and # next_run creation time becomes rounded to seconds
Does anyone have idea how to fix this?
The ideal way to avoid this kind of problems is to update objects sending only the attributes that you really want to update. With version 3 of the SDK the only way to do that is to explicitly clear the attributes that you don't want to send before calling the 'update' method: # Set the attributes that you want to update: vm.set_description('Update description') ... # Clear the 'creation_time' attribute so that it won't be sent # as part of the update: vm.set_creation_time(None) # Send the update request: vm.update() With version 4 of the SDK it is simpler, as you need/should send only the attributes that you want to update: vm_service.update( vm=types.Vm( description='Updated description', ... ) )
participants (2)
-
Juan Hernández
-
Valentina Makarova