| rakhmerov | hi all | 06:46 |
|---|---|---|
| rakhmerov | Please let me know if you plan to attend the PTG in Denver following after the summit | 06:47 |
| rakhmerov | we need to decided if it makes sense to ask for a dedicated room for Mistral | 06:48 |
| rakhmerov | if there are at least 3 people who could come I'll ask for a room | 06:48 |
| *** jtomasek has joined #openstack-mistral | 06:49 | |
| *** apetrich has joined #openstack-mistral | 07:19 | |
| *** jtomasek has quit IRC | 07:27 | |
| *** jtomasek has joined #openstack-mistral | 07:28 | |
| *** pgaxatte has joined #openstack-mistral | 07:40 | |
| apetrich | morning | 07:47 |
| *** chkumar|ruck has joined #openstack-mistral | 07:57 | |
| apetrich | rakhmerov, you there? | 08:01 |
| *** gkadam has joined #openstack-mistral | 08:06 | |
| *** gkadam has quit IRC | 08:09 | |
| *** akovi has joined #openstack-mistral | 08:12 | |
| apetrich | d0ugal, ping? | 08:39 |
| rakhmerov | apetrich: yep | 08:43 |
| rakhmerov | I'm here now | 08:43 |
| apetrich | rakhmerov, cheers, so looking at the proposed revert | 08:43 |
| rakhmerov | I've abandoned it | 08:43 |
| apetrich | rakhmerov, is due to this bug https://bugs.launchpad.net/tripleo/+bug/1816026 | 08:43 |
| openstack | Launchpad bug 1816026 in tripleo "multinode promotion jobs timing out at overcloud deploy" [Critical,In progress] - Assigned to chandan kumar (chkumar246) | 08:43 |
| apetrich | yeah | 08:43 |
| apetrich | I know | 08:43 |
| rakhmerov | ok | 08:43 |
| rakhmerov | he wrote that it wasn't the cause | 08:44 |
| apetrich | but comment #8 | 08:44 |
| rakhmerov | and it really couldn't be IMO | 08:44 |
| rakhmerov | ok, looking | 08:44 |
| apetrich | basically <% $.running_config_download_workflows != [] %> is returning true always | 08:44 |
| rakhmerov | apetrich: I don't understand his comments in the patch | 08:49 |
| rakhmerov | he wrote: | 08:49 |
| apetrich | I know :) | 08:49 |
| rakhmerov | “In both jobs, https://github.com/openstack/mistral/commit/58d6634702014eb3c2bf70dbe487fe5983cef8e9 commit is used, | 08:49 |
| rakhmerov | check https://bugs.launchpad.net/tripleo/+bug/1816026/comments/8” | 08:49 |
| openstack | Launchpad bug 1816026 in tripleo "multinode promotion jobs timing out at overcloud deploy" [Critical,In progress] - Assigned to chandan kumar (chkumar246) | 08:49 |
| apetrich | that's the ci problems and tempest | 08:49 |
| rakhmerov | the commit that he pointed to is a different one and has nothing to do with the one that's being reverted | 08:49 |
| apetrich | but what it relates to us is that somehow | 08:49 |
| apetrich | this <% $.running_config_download_workflows != [] %> is returning true always | 08:50 |
| rakhmerov | so where exactly should I look at? | 08:50 |
| apetrich | and I'm trying to figure that out | 08:50 |
| rakhmerov | apetrich: where do I find this line? | 08:50 |
| apetrich | https://github.com/openstack/tripleo-common/blob/master/workbooks/deployment.yaml#L404 | 08:50 |
| rakhmerov | ok | 08:51 |
| apetrich | oh sorry. I meant comment #7 | 08:51 |
| apetrich | not 8 | 08:51 |
| rakhmerov | how is this related? | 08:51 |
| apetrich | my bad | 08:51 |
| rakhmerov | ok | 08:51 |
| apetrich | I'm trying to figure out why. if that somehow has something to do with the string conversion | 08:52 |
| rakhmerov | "str()" is not used here | 08:52 |
| apetrich | if the [] is being somehow converted to "[]" and failing the test | 08:52 |
| apetrich | internally not explicitly | 08:52 |
| rakhmerov | yes, but I see no reason why it can be converted | 08:53 |
| apetrich | on the other hand looking at comment #9 proposed change it might have nothing to do with us. | 08:54 |
| apetrich | so let ignore that for now and wait for that proposed change go through ci and if it fails and relates to us we can talk again | 08:54 |
| d0ugal | Morning | 08:55 |
| rakhmerov | morning d0ugal | 08:55 |
| apetrich | o/ | 08:55 |
| rakhmerov | apetrich: even if it's somehow magically related (I fail to see how though), we need to understand the details | 08:56 |
| rakhmerov | and might want to provide a real fix for this problem | 08:57 |
| rakhmerov | if any | 08:57 |
| apetrich | rakhmerov, aye. | 08:57 |
| rakhmerov | apetrich: I'll clarify. [] cannot be converted into "[]". That patch has nothing to do with that for sure. All it does is pre-processing a data context for | 08:58 |
| rakhmerov | not an expression | 08:58 |
| rakhmerov | [] here is a part of an expression | 08:59 |
| rakhmerov | this patch only disables tuplifying lists in a data context (as it's supposed to be), that's it | 08:59 |
| akovi | it would be good to know what times out | 09:03 |
| rakhmerov | yes | 09:04 |
| rakhmerov | d0ugal: did you happen to find out anything new about that dependency problem? | 09:04 |
| d0ugal | rakhmerov: No, not really | 09:05 |
| rakhmerov | ok | 09:05 |
| d0ugal | rakhmerov: the cap was removed from oslo.cache tho | 09:05 |
| d0ugal | so maybe that'll help | 09:05 |
| rakhmerov | when? | 09:06 |
| d0ugal | Today | 09:06 |
| rakhmerov | I checked in the morning (my morning) and it was still there | 09:06 |
| d0ugal | https://review.openstack.org/#/c/636037/ | 09:06 |
| *** vgvoleg has quit IRC | 09:06 | |
| rakhmerov | aah, yes | 09:06 |
| openstackgerrit | Dougal Matthews proposed openstack/mistral master: Update dogpile.cache to match global requirements https://review.openstack.org/637145 | 09:06 |
| *** vgvoleg has joined #openstack-mistral | 09:11 | |
| rakhmerov | d0ugal: your patch is still failing | 09:14 |
| rakhmerov | I guess it's not been enough time yet | 09:14 |
| d0ugal | We might even need a oslo.cache release, but I am not sure | 09:15 |
| rakhmerov | yeah, I think we need | 09:16 |
| rakhmerov | I guess only released dependencies are pulled in, right? | 09:17 |
| d0ugal | Yeah, I think so | 09:20 |
| openstackgerrit | Quique Llorente proposed openstack/mistral master: WIP: Test empty list comparation https://review.openstack.org/637507 | 09:43 |
| d0ugal | rakhmerov, akovi: ^ | 09:47 |
| rakhmerov | yes | 09:47 |
| akovi | yes | 09:49 |
| rakhmerov | d0ugal: do we need to ask oslo team to release oslo.cache? | 09:54 |
| d0ugal | I think so, you can propose it but they will need the PTL/release liaison to approve it anyway | 09:54 |
| d0ugal | Locally for me that test fails, but if I revert a39db2d3dc21afbe8b9e1d6f8dd870da272b9671 then it passes | 09:56 |
| d0ugal | So I don't understand in, but it seems there is indeed a regression in that patch | 09:57 |
| rakhmerov | yeah, I see... | 09:57 |
| rakhmerov | weird | 09:57 |
| rakhmerov | ok, then we'll have to revert that patch and I'll resend the initial patch when I modify it | 09:58 |
| d0ugal | rakhmerov: quiquell in #tripleo is trying to find a fix. I'll see if they can join here | 09:59 |
| rakhmerov | d0ugal: or we can try to fix it quickly in Mistral | 09:59 |
| rakhmerov | ok | 09:59 |
| d0ugal | That is what I mean, they are looking for a fix to go with that test | 10:00 |
| rakhmerov | ok | 10:00 |
| rakhmerov | let me also check.. | 10:00 |
| d0ugal | Thanks | 10:00 |
| *** quiquell|rover has joined #openstack-mistral | 10:01 | |
| quiquell|rover | rakhmerov: o/ | 10:01 |
| rakhmerov | quiquell|rover: hi, print what you get in $.my_list | 10:01 |
| rakhmerov | both value and type | 10:01 |
| quiquell|rover | rakhmerov: ack | 10:02 |
| quiquell|rover | rakhmerov: give me a sec | 10:02 |
| apetrich | rakhmerov, I did that | 10:03 |
| apetrich | list | 10:03 |
| apetrich | not tuple or string | 10:03 |
| rakhmerov | empty list? | 10:04 |
| rakhmerov | [] ? | 10:04 |
| apetrich | aye | 10:04 |
| rakhmerov | hm... | 10:04 |
| rakhmerov | mystery | 10:04 |
| d0ugal | :) | 10:04 |
| apetrich | so I guess it the != implementation :questionmark | 10:04 |
| d0ugal | apetrich: but isn't that in YAQL itself? Why would it change with the change in mistral? | 10:05 |
| rakhmerov | d0ugal: that's what surprises me most | 10:06 |
| quiquell|rover | ok | 10:06 |
| quiquell|rover | have a quickfix | 10:07 |
| rakhmerov | quiquell|rover: what fix? | 10:07 |
| rakhmerov | I assume that we just actually revealed a hidden bug | 10:07 |
| openstackgerrit | Quique Llorente proposed openstack/mistral master: WIP: Test empty list comparation https://review.openstack.org/637507 | 10:08 |
| quiquell|rover | ^ | 10:08 |
| quiquell|rover | Now it passes | 10:08 |
| rakhmerov | what I mean is that this expression could have always been False but it wasn't right | 10:08 |
| apetrich | bool($.my_list) is false as expected | 10:09 |
| rakhmerov | quiquell|rover: do you understand how this fix helped? | 10:10 |
| quiquell|rover | rakhmerov: not really :-) | 10:10 |
| quiquell|rover | I mean looks like empty list is converted into empty tuple = | 10:10 |
| quiquell|rover | since an empty list is not a string not a tuple | 10:10 |
| quiquell|rover | it goes to the wrong if statement | 10:10 |
| rakhmerov | no, it can't be converted into a tuple | 10:11 |
| rakhmerov | if I print $.my_list it's a list | 10:11 |
| quiquell|rover | make sense | 10:12 |
| rakhmerov | quiquell|rover: let me investigate this quickly.. | 10:13 |
| quiquell|rover | rakhmerov: is a promotion blocker for us | 10:13 |
| quiquell|rover | rakhmerov: the quickfix is good enough ? | 10:13 |
| quiquell|rover | rakhmerov: or better go with the revert ? | 10:13 |
| rakhmerov | quiquell|rover: it's not a good idea to merge something that we don't fully understand | 10:14 |
| rakhmerov | this is a very sensitive area | 10:15 |
| quiquell|rover | rakhmerov: Maybe we can merge the revert but with the unit test ? | 10:15 |
| quiquell|rover | rakhmerov: we mistral is covered ? | 10:16 |
| rakhmerov | quiquell|rover, d0ugal, apetrich, akovi: let's just merge a revert as is for now | 10:16 |
| d0ugal | Okay, so I see the difference | 10:16 |
| rakhmerov | d0ugal: ? | 10:16 |
| d0ugal | One sec | 10:17 |
| d0ugal | Trying to figure out how to share it | 10:17 |
| d0ugal | https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L59 | 10:17 |
| d0ugal | On this line, the "outer" list is never passed through yaql_utils.convert_input_data | 10:17 |
| d0ugal | I believe this would be more correct: | 10:18 |
| quiquell|rover | d0ugal: nop, is "reconstructed" | 10:18 |
| d0ugal | return yaql_utils.convert_input_data([rec(t, rec) for t in obj], rec) | 10:18 |
| d0ugal | and it seems that yaql_utils.convert_input_data actually converts it into a tuple | 10:18 |
| quiquell|rover | and printing types now | 10:19 |
| quiquell|rover | ERROR [mistral.utils.expression_utils] [] | 10:19 |
| quiquell|rover | ERROR [mistral.utils.expression_utils] () | 10:19 |
| quiquell|rover | ERROR [mistral.utils.expression_utils] [] | 10:19 |
| quiquell|rover | ERROR [mistral.utils.expression_utils] () | 10:19 |
| quiquell|rover | damn sorry | 10:19 |
| quiquell|rover | LOG.error(list(rec(t, rec) for t in obj)) | 10:19 |
| d0ugal | It is hard to know what that means :) | 10:19 |
| quiquell|rover | LOG.error(yaql_utils.convert_input_data(obj, rec)) | 10:19 |
| d0ugal | Right | 10:20 |
| quiquell|rover | yep my last paste was wrong | 10:20 |
| quiquell|rover | so it passes if we convert that into a tuple | 10:20 |
| quiquell|rover | d0ugal: your approach should work | 10:20 |
| d0ugal | quiquell|rover: I think it makes more sense, rather than a special case for an empty list | 10:21 |
| quiquell|rover | d0ugal: le tme refactor it a little | 10:21 |
| rakhmerov | d0ugal: please provide a fix then | 10:21 |
| d0ugal | rakhmerov: I think quiquell|rover is going to do it | 10:21 |
| rakhmerov | ok | 10:21 |
| rakhmerov | honestly, I'm not sure I understand everything you said | 10:22 |
| d0ugal | quiquell|rover: http://paste.openstack.org/show/745250/ | 10:22 |
| rakhmerov | what do you mean by outer list? | 10:22 |
| d0ugal | rakhmerov: the list() | 10:22 |
| d0ugal | rakhmerov: See that paste, that is the update I made to quiquell|rover's patch | 10:22 |
| d0ugal | rakhmerov: https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L59 | 10:22 |
| apetrich | d0ugal, sounds like a better solution | 10:22 |
| d0ugal | rakhmerov: that returns a list | 10:22 |
| openstackgerrit | Quique Llorente proposed openstack/mistral master: WIP: Test empty list comparation https://review.openstack.org/637507 | 10:23 |
| quiquell|rover | d0ugal: with your approach ^ | 10:23 |
| quiquell|rover | is passing | 10:23 |
| rakhmerov | d0ugal: yes | 10:23 |
| d0ugal | but it should return the result of yaql_utils.convert_input_data, which is a tuple | 10:23 |
| rakhmerov | why should it return a tuple? | 10:23 |
| rakhmerov | I don't understand.. | 10:23 |
| d0ugal | rakhmerov: because it does everywhere else | 10:23 |
| rakhmerov | where? | 10:23 |
| d0ugal | the yaql language utils converts to a tuple | 10:23 |
| d0ugal | but that line we don't call it | 10:23 |
| rakhmerov | wait | 10:23 |
| quiquell|rover | yaql thing maybe ? | 10:23 |
| d0ugal | https://github.com/openstack/yaql/blob/master/yaql/language/utils.py#L71 | 10:23 |
| rakhmerov | wait a second... | 10:24 |
| quiquell|rover | humm it breaks the other test | 10:24 |
| rakhmerov | d0ugal: the whole idea of my patch was that we stop converting lists into tuples everything recursively | 10:24 |
| rakhmerov | quiquell|rover: sure it does | 10:24 |
| rakhmerov | ... everything -> everywhere ... | 10:24 |
| d0ugal | Then we can't use the YAQL convert_input_data function, because it converts to tuples | 10:25 |
| d0ugal | :) | 10:25 |
| rakhmerov | we don't use it after my patch | 10:25 |
| rakhmerov | pay attention to "rec" | 10:25 |
| rakhmerov | it stands for "recursive" | 10:25 |
| d0ugal | but we must somewhere, or why do we have a tuple in one place and a list in the other? Which is why the expression fails | 10:26 |
| rakhmerov | in the very beginning of my function we do rec = _convert_yaql_input_data | 10:26 |
| rakhmerov | d0ugal: where do we have a tuple? | 10:26 |
| d0ugal | Could YAQL convert a listeral [] into a tuple? | 10:26 |
| rakhmerov | d0ugal: I'm printing right in the code and it's always a list | 10:26 |
| rakhmerov | not a tuple | 10:26 |
| rakhmerov | d0ugal: no, I just checked that | 10:27 |
| rakhmerov | it's always a list | 10:27 |
| d0ugal | So why does the comparison change :) | 10:27 |
| rakhmerov | I don't know yet | 10:27 |
| rakhmerov | :) | 10:27 |
| d0ugal | "Default #list function implementation in standard library produces a list (tuple) comprised of given elements. However, the host might decide to give it a different implementation." | 10:27 |
| d0ugal | From the YAQL docs | 10:27 |
| d0ugal | https://yaql.readthedocs.io/en/latest/language_reference.html#list-expressions | 10:28 |
| d0ugal | It seems to consider lists and tuples as the same thing? | 10:28 |
| rakhmerov | d0ugal: like I said, we might have just revealed the other bug | 10:28 |
| rakhmerov | that expression in the TripleO workflow could just always return False | 10:28 |
| rakhmerov | but it wasn't right | 10:29 |
| d0ugal | quiquell|rover: as a workaround in tripleo we could check the lengh is 0 | 10:29 |
| d0ugal | length | 10:29 |
| rakhmerov | yes | 10:29 |
| rakhmerov | d0ugal: it is more reliable | 10:29 |
| d0ugal | Something is wrong here, but that should unblock it | 10:29 |
| quiquell|rover | give me sec | 10:31 |
| rakhmerov | d0ugal, quiquell|rover: please let's not hurry with quick workarounds in Mistral | 10:31 |
| quiquell|rover | rakhmerov: sure no problem | 10:31 |
| rakhmerov | if you can change a condition in TripleO, it'd be good | 10:31 |
| rakhmerov | in the meantime I'll investigate what's going on | 10:32 |
| quiquell|rover | rakhmerov: just one to know what is the best a approach here | 10:32 |
| rakhmerov | ok | 10:32 |
| rakhmerov | this place is sensitive and pretty tricky, we need to be careful | 10:32 |
| quiquell|rover | rakhmerov, d0ugal: so we check length or we revert ? | 10:32 |
| quiquell|rover | unit test is legit though | 10:32 |
| d0ugal | quiquell|rover: I would suggest checking the length. That should work either way | 10:32 |
| d0ugal | quiquell|rover: agreeded, we need a fix in mistral but we also need to not break the other test :) | 10:33 |
| d0ugal | quiquell|rover: <% $.running_config_download_workflows.len() > 0 %> | 10:34 |
| d0ugal | quiquell|rover: <% $.running_config_download_workflows.len() = 0 %> | 10:34 |
| d0ugal | quiquell|rover: I guess that is the two we need. | 10:35 |
| quiquell|rover | d0ugal: let me add them | 10:35 |
| rakhmerov | d0ugal: just checked again in debugger, conversion works as expected, it's a list | 10:35 |
| rakhmerov | ok, I'll look at it more.. | 10:35 |
| d0ugal | FWIW, it seems that YAQL strongly suggests we use tuples everywhere | 10:44 |
| rakhmerov | no | 10:44 |
| rakhmerov | :) | 10:44 |
| d0ugal | yes | 10:44 |
| d0ugal | "Strongly prefer immutable data structures over mutable ones. Use tuple`s rather than `list`s, `frozenset instead of set. Python does not have a built-in immutable dictionary class so yaql provides one on its own - yaql.language.utils.FrozenDict." | 10:44 |
| d0ugal | https://yaql.readthedocs.io/en/latest/extending_yaql.html?highlight=converttuplestolists#function-development-hints | 10:44 |
| quiquell|rover | I am openning a pandora Âbox here ? | 10:45 |
| d0ugal | yup :) | 10:45 |
| rakhmerov | d0ugal: I know about it, yes | 10:45 |
| d0ugal | ok | 10:45 |
| rakhmerov | but the reason is just to use immutable types | 10:45 |
| rakhmerov | list itself is totally ok | 10:45 |
| d0ugal | Which seems like a good reason | 10:45 |
| d0ugal | ok | 10:46 |
| rakhmerov | yes, but we know how we use YAQL in Mistral | 10:46 |
| rakhmerov | we always make sure that the data context is not modified while YAQL is doing something with it | 10:46 |
| openstackgerrit | Quique Llorente proposed openstack/mistral master: WIP: Test empty list comparation https://review.openstack.org/637507 | 10:46 |
| quiquell|rover | rakhmero, d0ugal: with len ^ | 10:46 |
| rakhmerov | yes | 10:46 |
| rakhmerov | d0ugal: just hold on please, I'll investigate :) | 10:46 |
| rakhmerov | Have to run now though, will do it a little later | 10:46 |
| d0ugal | I'm not doing anything | 10:46 |
| d0ugal | I am just reading | 10:47 |
| rakhmerov | ok | 10:47 |
| quiquell|rover | rakhmerov: we can merge the revert though ? | 10:47 |
| quiquell|rover | rakhmerov: while we do proper solution ? | 10:47 |
| quiquell|rover | rakhmerov: or len is enouogh ? | 10:47 |
| d0ugal | quiquell|rover: hmm, we don't need the len in mistral | 10:47 |
| d0ugal | quiquell|rover: we should add that to the workflow in tripleo-common | 10:47 |
| d0ugal | and then we shouldn't need a change in Mistral | 10:47 |
| quiquell|rover | d0ugal: you mean we should compare with len instead of [] at workflow ? | 10:48 |
| d0ugal | quiquell|rover: yup | 10:48 |
| quiquell|rover | d0ugal: so we don't have to change mistral to fix stuff ? | 10:48 |
| rakhmerov | quiquell|rover: let's not merge the revert | 10:48 |
| d0ugal | exactly | 10:48 |
| d0ugal | and we can leave mistral broken for now lol | 10:48 |
| rakhmerov | the patch fixed another compatibility problem | 10:48 |
| quiquell|rover | d0ugal: let me see the impact though | 10:48 |
| rakhmerov | for a different user | 10:48 |
| rakhmerov | d0ugal: we're not sure exactly that it's now broken ) | 10:49 |
| rakhmerov | the investigation is not over | 10:49 |
| d0ugal | rakhmerov: I agree, but it doesn't seem correct either | 10:49 |
| d0ugal | That patch shouldn't have changed the behaviour of the YAQL expression | 10:49 |
| d0ugal | so I'm pretty certain it was broken | 10:50 |
| openstackgerrit | Quique Llorente proposed openstack/mistral master: Return empty list as tuple https://review.openstack.org/637507 | 10:50 |
| quiquell|rover | Updateed commit message | 10:50 |
| rakhmerov | let's not argue anymore :) | 10:50 |
| quiquell|rover | Going to look at workflows | 10:50 |
| d0ugal | sure | 10:50 |
| d0ugal | I just don't know what needs to change to fix it | 10:50 |
| rakhmerov | d0ugal: again, think about it. The expression could have been always evaluating in a wrong way :) | 10:50 |
| rakhmerov | can you assume that too? :) | 10:51 |
| rakhmerov | may be [] can't be really used as well | 10:52 |
| rakhmerov | in expressions | 10:52 |
| rakhmerov | I'm not sure about that either | 10:52 |
| quiquell|rover | rakhmerov, d0ugal: Only those two places use this comparation at tripleo-common | 10:52 |
| d0ugal | rakhmerov: but the unit test result was different when reverting the patch - so I'm not sure how it could always have been that way | 10:52 |
| rakhmerov | d0ugal: hm.. yes.. ok | 10:53 |
| rakhmerov | right | 10:53 |
| rakhmerov | damn.. ok | 10:53 |
| rakhmerov | ok, I'm gone | 10:53 |
| d0ugal | Sure | 10:53 |
| d0ugal | Thanks for the help | 10:53 |
| rakhmerov | will be back later | 10:53 |
| d0ugal | quiquell|rover: Yeah, I checked that too. We use len in a couple of places | 10:53 |
| quiquell|rover | d0ugal: so sure it was a known issue | 10:54 |
| d0ugal | quiquell|rover: I don't think so, I think I have used len because it seems more logical to me | 10:54 |
| quiquell|rover | d0ugal: two in one :-) | 10:55 |
| quiquell|rover | d0ugal: this is it ? https://review.openstack.org/637522 | 10:55 |
| quiquell|rover | d0ugal: well previous mistral version was good though | 10:55 |
| d0ugal | Agreed | 10:55 |
| quiquell|rover | so mistral is no good there | 10:55 |
| d0ugal | lol | 10:56 |
| quiquell|rover | Or it cannot drop support for [] comparation | 10:56 |
| quiquell|rover | s/casnnot/can/ | 10:56 |
| quiquell|rover | chkumar|ruck: ^ | 10:57 |
| d0ugal | quiquell|rover: Sure, lets not worry about that now. I think the change in approach will solve the problems in tripleo | 10:57 |
| chkumar|ruck | quiquell|rover: yes looks, good it will help to unblock the ci | 10:57 |
| d0ugal | bbiab | 10:58 |
| * chkumar|ruck is going to test it right now | 10:58 | |
| quiquell|rover | cool thank sa lot rakhmerov, d0ugal | 10:58 |
| quiquell|rover | chkumar|ruck: go go go go | 10:58 |
| *** apetrich has quit IRC | 12:11 | |
| *** apetrich has joined #openstack-mistral | 12:25 | |
| *** apetrich has quit IRC | 12:30 | |
| *** apetrich has joined #openstack-mistral | 12:48 | |
| *** quiquell|rover is now known as quique|rover|eat | 13:28 | |
| openstackgerrit | Adriano Petrich proposed openstack/mistral master: Return empty list as tuple https://review.openstack.org/637507 | 13:40 |
| *** akovi has quit IRC | 13:47 | |
| *** akovi has joined #openstack-mistral | 13:48 | |
| *** quique|rover|eat is now known as quiquell|rover | 14:09 | |
| *** chkumar|ruck is now known as chandankumar | 14:28 | |
| *** quiquell|rover is now known as quiquell|off | 15:11 | |
| rakhmerov | d0ugal: [] is internally represented as a tuple | 15:43 |
| d0ugal | rakhmerov: Yeah, that is what I thought | 15:43 |
| rakhmerov | that's why the comparison fails | 15:43 |
| rakhmerov | yeah.. | 15:43 |
| rakhmerov | I don't like all this stuff ) | 15:43 |
| rakhmerov | ok, I'll try to come up with some idea | 15:44 |
| d0ugal | and I guess that is why they suggest using tuple | 15:44 |
| d0ugal | It is a bit messy | 15:44 |
| rakhmerov | d0ugal: the interesting thing is that we used to use YAQL w/o any context pre-processing at all | 15:45 |
| rakhmerov | and most of the things worked | 15:45 |
| rakhmerov | except list of dicts | 15:45 |
| rakhmerov | sorry, sets of dicts | 15:45 |
| d0ugal | Interesting | 15:45 |
| rakhmerov | yes, because dict is an unhashable type | 15:46 |
| rakhmerov | it can't be put into a set | 15:46 |
| d0ugal | Right, that makes sense | 15:46 |
| d0ugal | I have hit that before :) | 15:46 |
| rakhmerov | that's why we started using yaql_utils.convert_input_data in the first place | 15:46 |
| rakhmerov | to replace sets with something else | 15:46 |
| rakhmerov | it is a mess, indeed | 15:47 |
| *** akovi has quit IRC | 15:50 | |
| rakhmerov | d0ugal, apetrich: btw, the special handling of [] is not going to help because we can also use a non-empty string literal in an expression | 16:14 |
| rakhmerov | like [1,2,3] | 16:14 |
| rakhmerov | so | 16:14 |
| rakhmerov | most likely we'll have to revert my patch | 16:14 |
| rakhmerov | :) | 16:14 |
| rakhmerov | but give me some time, I want to debug YAQL a little bit more | 16:15 |
| apetrich | :( | 16:15 |
| *** pgaxatte has quit IRC | 16:57 | |
| d0ugal | rakhmerov: Agreed, that is why I added a -1 :) | 18:14 |
| d0ugal | Let us know when you have something ready to review | 18:14 |
| *** jtomasek has quit IRC | 21:40 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!