Open Stack

Hello Andrew,

I've reproduced the issue on the patch set #5 too.
But at the same time, I have no issue on the latest patch set (#9).

Thanks,
Igor


On Mon, Apr 14, 2014 at 9:00 AM, Andrew Woodward <xarses at gmail.com> wrote:

> Igor,
>
> Ryan was able to repeat the issue in his env by checking out the patch set
> (5) with db().refresh(task_provision) enabled.
>
>
> On Sun, Apr 13, 2014 at 3:28 AM, Igor Kalnitsky <ikalnitsky at mirantis.com>wrote:
>
>> Hi guys,
>>
>> *@Roman*, we have
>>
>>     db().refresh(task_provision)
>>
>> since the line above (self._call_silently) may change task status
>> directly in db, not in SQLAlchemy session.
>>
>> *@Andrew*, it's really strange. I just checkout your request, return
>> refreshing task and run tests.
>> As a result, I have no failed tests in the test_task_manager.py.
>>
>> Are you sure your environment is ok?
>>
>> Thanks,
>> Igor
>>
>>
>> On Sun, Apr 13, 2014 at 12:57 PM, Roman Podoliaka <
>> rpodolyaka at mirantis.com> wrote:
>>
>>> Hi Andrew,
>>>
>>> I believe, it's just the way SQLAlchemy Session works: all the changes
>>> you've made within a session aren't propagated to the db (read: no
>>> actual queries are issued) until you explicitly do:
>>>
>>> - flush(), or
>>> - commit() (as commit() calls flush() first), or
>>> - Query - one(), first(), all(), update(), delete() - as these are
>>> actions that can only be performed by contacting the db.
>>>
>>> >>> db().refresh(task_provision) call appeared to be reseting the object
>>>
>>> Yes, and this is exactly what it is supposed to do: get the current
>>> state of the model instance from the db (basically: select * from
>>> model_table where id = instance_primary_key_value). This means, that
>>> all the changes you've made, but haven't flushed yet, will be lost.
>>> I've made a small snippet to see this in action:
>>> http://xsnippet.org/359888/  (with logging of SQL queries enabled)
>>>
>>> I hope this helps. I'm just wondering, why would you want to call
>>> refresh() there?
>>>
>>> Thanks,
>>> Roman
>>>
>>> On Sat, Apr 12, 2014 at 1:33 AM, Andrew Woodward <xarses at gmail.com>
>>> wrote:
>>> > Recently in one of my changes [1] I was fighting with one of the unit
>>> > tests showing a failure for a test which should have been outside the
>>> > sphere of influence.
>>> >
>>> > Traceback (most recent call last):
>>> >   File
>>> "/home/andreww/.virtualenvs/fuel/local/lib/python2.7/site-packages/mock.py",
>>> > line 1190, in patched
>>> >     return func(*args, **keywargs)
>>> >   File
>>> "/home/andreww/git/fuel-web/nailgun/nailgun/test/integration/test_task_managers.py",
>>> > line 65, in test_deployment_task_managers
>>> >     self.assertEquals(provision_task.weight, 0.4)
>>> > AssertionError: 1.0 != 0.4
>>> >
>>> > After walking through a number of times and finally playing with it we
>>> > where able to find that the db().refresh(task_provision) call appeared
>>> > to be reseting the object. This caused the loss of the weight being
>>> > set to 0.4 (1.0 is the model default). db().commit(), db().flush() and
>>> > no call to db all caused the test to pass again.
>>> >
>>> > Does anyone have any input on why this would occur? The oddly odd part
>>> > is that this test doesn't fail outside of the change set in [1]
>>> >
>>> > [1]
>>> https://review.openstack.org/#/c/78406/8/nailgun/nailgun/task/manager.py
>>> >
>>> > --
>>> > Andrew
>>> > Mirantis
>>> > Ceph community
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Andrew
> Mirantis
> Ceph community
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140414/5fcb12bd/attachment.html>