*** ddeja has quit IRC | 00:16 | |
*** ddeja has joined #openstack-mistral | 00:20 | |
*** thrash is now known as thrash|g0ne | 00:26 | |
*** jkilpatr has quit IRC | 00:44 | |
*** ddeja has quit IRC | 00:47 | |
*** ddeja has joined #openstack-mistral | 00:48 | |
*** jkilpatr has joined #openstack-mistral | 00:56 | |
*** jkilpatr has quit IRC | 01:01 | |
*** jkilpatr has joined #openstack-mistral | 01:06 | |
*** jkilpatr has quit IRC | 01:16 | |
*** jkilpatr has joined #openstack-mistral | 01:17 | |
*** chlong has joined #openstack-mistral | 01:47 | |
*** jkilpatr has quit IRC | 02:19 | |
*** jkilpatr has joined #openstack-mistral | 02:19 | |
*** jkilpatr has quit IRC | 02:36 | |
*** jkilpatr has joined #openstack-mistral | 02:41 | |
*** gongysh has joined #openstack-mistral | 04:33 | |
*** gongysh has quit IRC | 05:01 | |
*** dmellado has quit IRC | 05:14 | |
*** thrash|g0ne has quit IRC | 05:14 | |
*** chlong has quit IRC | 05:14 | |
*** toure has quit IRC | 05:15 | |
*** toure has joined #openstack-mistral | 05:16 | |
*** dmellado has joined #openstack-mistral | 05:16 | |
*** thrash has joined #openstack-mistral | 05:18 | |
*** thrash has quit IRC | 05:18 | |
*** thrash has joined #openstack-mistral | 05:18 | |
*** sharatss has joined #openstack-mistral | 05:40 | |
*** gongysh has joined #openstack-mistral | 06:04 | |
*** zhurong has joined #openstack-mistral | 06:15 | |
rakhmerov | hi, does anybody know if there are some issues with CI? | 06:23 |
---|---|---|
rakhmerov | all our patches started failing unexpectedly | 06:23 |
rakhmerov | different tests with different errors | 06:23 |
*** gongysh has quit IRC | 06:36 | |
*** openstackgerrit has joined #openstack-mistral | 06:37 | |
openstackgerrit | Istvan Imre proposed openstack/mistral master: Dynamic workflow name evaluation. https://review.openstack.org/434106 | 06:37 |
*** zhurong has quit IRC | 06:38 | |
openstackgerrit | Istvan Imre proposed openstack/mistral master: Dynamic workflow name evaluation. https://review.openstack.org/434106 | 06:38 |
*** tuan_ has joined #openstack-mistral | 06:51 | |
tuan_ | Morning folks | 06:52 |
*** mgershen has quit IRC | 06:53 | |
*** mgershen has joined #openstack-mistral | 06:57 | |
rakhmerov | tuan_: hi | 06:57 |
*** d0ugal has joined #openstack-mistral | 06:58 | |
tuan_ | rakhmerov: Hi There | 07:00 |
tuan_ | :) | 07:00 |
rakhmerov | d0ugal: good morning Dougal, seems like our CI is down | 07:01 |
rakhmerov | trying to figure out why | 07:01 |
tuan_ | Hi guys, if you have time, could you take a look to the refresh token expired of other clients (nova, neutron, etc.) in mistral | 07:01 |
d0ugal | rakhmerov: morning | 07:06 |
d0ugal | dang | 07:06 |
* d0ugal looks | 07:07 | |
rakhmerov | d0ugal: all of a sudden all patches coming to review started failing | 07:09 |
rakhmerov | a bunch of tests | 07:09 |
rakhmerov | I have no idea why yet | 07:09 |
*** sharatss has quit IRC | 07:09 | |
*** sharatss has joined #openstack-mistral | 07:10 | |
d0ugal | rakhmerov: yeah, very strange. | 07:10 |
rakhmerov | I run same tests locally, they pass | 07:10 |
d0ugal | oh, even more strange! | 07:10 |
d0ugal | I just started them locally | 07:10 |
d0ugal | 32 failures in CI! | 07:12 |
d0ugal | rakhmerov: They fail for me | 07:14 |
d0ugal | rakhmerov: I guess your tox env is old | 07:14 |
d0ugal | $ tox -r | 07:14 |
d0ugal | and if they then start to fail for you, that means it is a issue with one of our requirements. | 07:14 |
*** shardy has joined #openstack-mistral | 07:14 | |
d0ugal | rakhmerov: so wait, don't run tox -r fist | 07:14 |
rakhmerov | ooh, hm.. | 07:15 |
d0ugal | run $ .tox/py27/bin/pip freeze > saveit.txt | 07:15 |
d0ugal | then re-create the tox env | 07:15 |
d0ugal | then we have a starting point for comparison | 07:15 |
rakhmerov | yeah, ok | 07:15 |
d0ugal | Tests have still not finished for me, but I have seen lots of errors so far | 07:16 |
rakhmerov | yes | 07:17 |
d0ugal | hah, I actually got 50 failues for py34 | 07:18 |
rakhmerov | aha | 07:18 |
therve | d0ugal, rakhmerov: Looks like SQLAlchemy | 07:19 |
d0ugal | orly | 07:19 |
d0ugal | therve: has there been a recent sqlalchemy release? I don't see one. | 07:19 |
d0ugal | oh, yes | 07:20 |
d0ugal | 1.1.7, 3 days ago | 07:20 |
therve | We were blocked on < 1.1 until recently too | 07:20 |
rakhmerov | ok | 07:20 |
d0ugal | Yeah, 1.1 was allowed here. | 07:22 |
d0ugal | https://github.com/openstack/mistral/commit/95cf6bcaef88892548c050825b8d8d5a657ab126 | 07:22 |
d0ugal | I am just running the tests again with that reverted | 07:22 |
rakhmerov | ok, good | 07:22 |
d0ugal | ugh, for some reason pinning it in the requirements isn't working | 07:26 |
d0ugal | I keep getting a newer version in the venv | 07:27 |
rakhmerov | how come? Do you just change requirements.txt and run tox again? | 07:28 |
rakhmerov | d0ugal: ^ | 07:28 |
d0ugal | rakhmerov: yeah, I did - not sure why it wasn't picked up. | 07:30 |
d0ugal | ./.tox/py27/bin/pip install SQLAlchemy==1.0.17 | 07:30 |
d0ugal | I just used that to downgrade - running tests now :-D | 07:30 |
rakhmerov | ok, yes | 07:30 |
d0ugal | I am still seeing errors | 07:31 |
rakhmerov | I found a ML thread about SQLAlchemy 1.1, reading.. | 07:31 |
d0ugal | Waiting to see if it is the same number. | 07:31 |
rakhmerov | I updated my env, same thing, a bunch of errors | 07:32 |
openstackgerrit | Dougal Matthews proposed openstack/mistral master: Revert "Updated from global requirements" https://review.openstack.org/451681 | 07:35 |
d0ugal | There seem to be less errors with a downgraded sqlalchemy | 07:35 |
d0ugal | but there are still errors. | 07:35 |
rakhmerov | how many? | 07:37 |
d0ugal | py27 3 errors, py35 18 errors | 07:37 |
*** zhurong has joined #openstack-mistral | 07:38 | |
rakhmerov | hm... | 07:38 |
d0ugal | py35 had 50 failures without it | 07:40 |
d0ugal | not sure about py27 | 07:41 |
d0ugal | brb | 07:43 |
rakhmerov | ok | 07:43 |
rakhmerov | d0ugal: revert patch also failed with the same errors | 07:48 |
*** jpich has joined #openstack-mistral | 07:48 | |
rakhmerov | seemingly there's issues with yaql but I'm not sure yet.. | 07:48 |
d0ugal | rakhmerov: the revert didn't work. | 07:55 |
d0ugal | http://logs.openstack.org/81/451681/1/check/gate-mistral-python27-ubuntu-xenial/26587bb/console.html#_2017-03-30_07_46_43_325685 | 07:55 |
rakhmerov | yeah, I know ) | 07:55 |
rakhmerov | I see issues with yaql | 07:55 |
rakhmerov | don't know yet if it's a yaql problem though | 07:55 |
d0ugal | but I wonder why reverting that doesn't change the sqlalchemy version? | 07:55 |
d0ugal | :/ | 07:55 |
rakhmerov | ooh, same version was installed for the tests? | 07:56 |
rakhmerov | 1.1.0? | 07:56 |
d0ugal | yeah, see the link ^ | 07:56 |
d0ugal | 1.1.7 | 07:56 |
rakhmerov | d0ugal: https://github.com/openstack/requirements/blob/master/upper-constraints-xfails.txt | 07:57 |
rakhmerov | https://github.com/openstack/requirements/blob/master/upper-constraints.txt | 07:58 |
d0ugal | huh, what does that file do? | 07:58 |
rakhmerov | d0ugal: I don't know really.. | 07:58 |
*** amoralej|off is now known as amoralej | 07:58 | |
d0ugal | it even lists mistral! | 07:58 |
rakhmerov | yes | 07:58 |
rakhmerov | I believe 1.1.7 gets installed because of upper-constraints.txt | 07:58 |
d0ugal | I see | 07:59 |
rakhmerov | it pins the version | 07:59 |
rakhmerov | d0ugal: so seems like someone knows more than us about our failures :) | 08:00 |
d0ugal | This patch passed with 1.1.7 https://review.openstack.org/#/c/420687/ | 08:00 |
rakhmerov | I'll probably need to read that email thread to the end | 08:00 |
d0ugal | https://github.com/openstack/requirements/commit/141abfb14d0f6f2a4d69cc9d3c1d0dd6eab312d3 | 08:00 |
d0ugal | The link in that commit might be relevant? | 08:01 |
rakhmerov | which link? | 08:01 |
rakhmerov | d0ugal: no, that commit installed SQLAlchemy==1.0.17 | 08:02 |
rakhmerov | http://logs.openstack.org/87/420687/3/check/gate-mistral-python35/f05cc31/console.html#_2017-03-06_11_00_52_728448 | 08:03 |
*** openstackgerrit has quit IRC | 08:03 | |
d0ugal | oops, I read the wrong tab | 08:03 |
rakhmerov | it's weird because I see a problem locally which doesn't seem to be related with SQLAlchemy.. | 08:05 |
rakhmerov | brb | 08:05 |
sharatss | d0ugal, rakhmerov hi | 08:09 |
d0ugal | sharatss: hi | 08:10 |
sharatss | d0ugal, as of now we are mapping the actions from respective clients of other projects and executing the actions right? | 08:11 |
d0ugal | yeah | 08:11 |
sharatss | d0ugal, what about the projects who have deprecated their cli and moved to openstackclient | 08:12 |
sharatss | ?? | 08:12 |
d0ugal | sharatss: hah, that is a good question :) | 08:12 |
d0ugal | sharatss: They still have Python bindings right, they only deprecate the CLI I think | 08:12 |
sharatss | d0ugal, but there will be no updates on the pythonclients | 08:14 |
d0ugal | really? | 08:14 |
d0ugal | sharatss: which projects have said they wont do that? | 08:15 |
sharatss | d0ugal, in neutron we had raised a BP for CLI and we were asked to move it to OSC since they were migrating everything to there | 08:15 |
sharatss | d0ugal, projects like senlin and congress have completely deprecated the CLI | 08:16 |
d0ugal | sharatss: sure, but have they deprecated their Python bindings? | 08:16 |
d0ugal | They are different things. | 08:16 |
sharatss | d0ugal, i was thinking why dont we map actions directly from OSC? | 08:17 |
d0ugal | sharatss: is OSC a library? | 08:18 |
d0ugal | I thought it was just a CLI | 08:18 |
sharatss | d0ugal, i think they still have the bindings as u said | 08:20 |
rakhmerov | sharatss, d0ugal: I believe bindings won't go away any time soon | 08:20 |
rakhmerov | otherwise, show the evidence.. | 08:21 |
rakhmerov | all projects currently have OSC plugins, but only plugins | 08:21 |
rakhmerov | sharatss: and, as we've discussed lately, we'll be refactoring all actions anyway | 08:21 |
rakhmerov | hopefully soon | 08:21 |
rakhmerov | we may consider to use OSC somehow | 08:22 |
therve | sharatss, d0ugal: neutron uses openstacksdk for bindings nowadays | 08:23 |
therve | (Somewhat) | 08:23 |
d0ugal | openstacksdk would make more sense I guess | 08:23 |
therve | d0ugal, Not sure I agree, because it's yet another bottleneck of reviews | 08:23 |
d0ugal | true | 08:24 |
therve | If you use it as a library to build your client, ok | 08:24 |
therve | But neutron seems to stuff everything in there, doesn't make much sense to me | 08:24 |
d0ugal | lol | 08:24 |
therve | (Especially since they actually don't put everything and you still have to use neutronclient anyway) | 08:24 |
*** gongysh has joined #openstack-mistral | 08:27 | |
rakhmerov | therve: we've discussed this before with d0ugal. To me it seems like OSC is kind of limited because it forces to follow a certain structure of commands whereas many projects may choose do more. So, as far as I understand it, we can have a number of "typical" commands in CLI but those who want more advanced capabilities we'll still need to use our own client | 08:29 |
therve | rakhmerov, What do you mean by "more" ? | 08:29 |
therve | OSC seems fairly flexible to me | 08:29 |
d0ugal | many projects so just provide OSC integration with their python client | 08:30 |
rakhmerov | therve: something that doesn't fit into "osc object verb params" structure | 08:30 |
d0ugal | like mistral :) | 08:30 |
therve | rakhmerov, Right, but what does fit? :) | 08:30 |
rakhmerov | making it up now... "osc workflow create my_wf" seems ok for OSC, but "osc analyze wf=my_wf filter=.." does not | 08:32 |
rakhmerov | not sure if I'm clear on that.. | 08:32 |
rakhmerov | maybe we're talking about different things | 08:32 |
d0ugal | lol | 08:33 |
d0ugal | I think most things can fit in with OSX | 08:33 |
d0ugal | OSC | 08:33 |
rakhmerov | maybe | 08:33 |
* d0ugal says, having abused OSC a few times | 08:33 | |
rakhmerov | we'll see | 08:33 |
rakhmerov | my point here is the following: we may come up with something very cool that it will be problematic to squeeze into OSC concepts | 08:34 |
d0ugal | that maybe sounds like a problem :) | 08:35 |
rakhmerov | generally, standardization is OK unless it kills creativeness | 08:35 |
rakhmerov | :) | 08:35 |
rakhmerov | d0ugal: what sounds like a problem? | 08:36 |
d0ugal | haha, I was just joking | 08:36 |
d0ugal | nevermind :) | 08:36 |
therve | rakhmerov, "osc workflow analyze" works though? | 08:36 |
rakhmerov | therve: yeah, but there may not be any "object", for example | 08:37 |
rakhmerov | not sure how it's addressed in OSC now | 08:37 |
rakhmerov | or a command may work with different object types | 08:37 |
rakhmerov | or we'll want to specify params in some tricky non-standard way | 08:38 |
therve | Well, that last thing is not nice for your users | 08:38 |
therve | And "object" can be "namespace" when appropriate | 08:38 |
rakhmerov | therve: anyway, I have to admit that I'm not well familiar with OSC now so my opinion is not a strong opinion (yet) | 08:39 |
rakhmerov | that's ok | 08:39 |
d0ugal | lol | 08:39 |
therve | rakhmerov, Yeah, I'm changing my opinion over time as well. The plugin interface works ok | 08:39 |
rakhmerov | I'll be much more interesting person to talk to about it once I'll have a closer look at OSC :) | 08:39 |
therve | If we didn't have the overlap in naming, I'd love it | 08:39 |
rakhmerov | I'm not getting rid of you though :) it's just true | 08:39 |
d0ugal | This is all a bit hypothetical - we should try and work with OSC but if we get blocked by something we will deal with it then | 08:40 |
d0ugal | We have bigger issues now :) | 08:40 |
rakhmerov | d0ugal: that's where I'm getting to :) | 08:40 |
therve | Totally | 08:40 |
rakhmerov | therve: we can get back to this conversation later | 08:40 |
rakhmerov | therve: that was useful for me anyway, thanks | 08:41 |
rakhmerov | d0ugal: any new ideas on our issue? | 08:50 |
d0ugal | rakhmerov: no, not really :/ | 08:53 |
rakhmerov | ok | 08:53 |
rakhmerov | d0ugal: I'm observing one really weird thing. If you run test test_task_defaults.test_task_defaults_retry_policy, for example, you'll see that 'fail' action runs many many times | 08:55 |
rakhmerov | although it should run only 3 times | 08:55 |
rakhmerov | d0ugal: my hypothesis is that something is broken in RPC | 08:55 |
d0ugal | rakhmerov: that sounds likely. Unfortunately I don't know that part well yet | 09:00 |
*** zhurong has quit IRC | 09:01 | |
rakhmerov | or actually DB :) | 09:01 |
rakhmerov | I've almost found a place.. | 09:01 |
rakhmerov | yeah, DB | 09:02 |
rakhmerov | d0ugal: I guess something has changed in how SQLAlchemy works with graph updates | 09:03 |
rakhmerov | what happens is: in Retry policy we store iteration # in DB, task_ex.runtime_context, which is JSON string | 09:04 |
rakhmerov | but it doesn't get updated when we increment it | 09:04 |
rakhmerov | so policy runs forever | 09:04 |
rakhmerov | d0ugal: and I know why only Mistral is suffering from this change :) | 09:12 |
d0ugal | rakhmerov: oh cool, why? | 09:15 |
rakhmerov | nobody else uses this feature ) | 09:15 |
d0ugal | haha, makes sense | 09:15 |
rakhmerov | d0ugal: remember you were surprised that not many other projects use transactions explicitly | 09:15 |
rakhmerov | it's a part of the same thing.. | 09:16 |
rakhmerov | ok, I'll tell more when I find the exact issue.. But at least it's clear now that it's because of SQLAlchemy | 09:17 |
d0ugal | rakhmerov: oh, interesting | 09:19 |
d0ugal | I guess I'll wait and see the patch :) | 09:19 |
*** sharat has joined #openstack-mistral | 09:21 | |
*** sharatss has quit IRC | 09:21 | |
*** sharat has quit IRC | 09:31 | |
*** vienin has joined #openstack-mistral | 09:41 | |
*** sharat has joined #openstack-mistral | 09:41 | |
*** shardy has quit IRC | 09:47 | |
rakhmerov | d0ugal: so yes, I'm sure now about what happens but still don't know if it's a bug in SQLAlchemy or we just need to tweak something on our side | 10:04 |
rakhmerov | anytime when we deal with json strings SQLAlchemy doesn't track state of these fields | 10:04 |
rakhmerov | and doesn't see that the field has changed and therefore doesn't issue an SQL | 10:05 |
rakhmerov | that doesn't happen with other fields | 10:05 |
rakhmerov | that's why mostly 'with-items' and 'policy' tests fail, they all use these json strings | 10:05 |
rakhmerov | what's interesting about it is that these fields are configured with custom SQLAlchemy types in the code | 10:06 |
rakhmerov | and they do conversion on read/write to DB | 10:06 |
rakhmerov | from dict to string and back | 10:06 |
rakhmerov | maybe that's where the problem is.. | 10:06 |
rakhmerov | d0ugal: I know exactly where the problem is, thinking how to fix it.. | 10:35 |
rakhmerov | may take a while | 10:36 |
rakhmerov | I'm off tomorrow so will try to fix it today | 10:36 |
d0ugal | rakhmerov: :) | 10:36 |
d0ugal | Where is it? | 10:36 |
rakhmerov | d0ugal: hold on, I'll give you a link | 10:37 |
rakhmerov | https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/ext/mutable.py#L642 | 10:41 |
rakhmerov | d0ugal: ^ | 10:41 |
rakhmerov | I wonder how it worked before actually.. | 10:41 |
rakhmerov | so here is the problem: if we have a dict like {'key1': {'nested_key1': 'nested_value1'}} then SQLA doesn't track deep changes properly | 10:42 |
rakhmerov | as stated in this docstring | 10:43 |
rakhmerov | I kind of understand what to do in order to fix it but not precisely.. | 10:43 |
rakhmerov | here's where it's defined on our side: https://github.com/openstack/mistral/blob/master/mistral/db/sqlalchemy/types.py#L107 | 10:45 |
d0ugal | Interesting | 10:47 |
d0ugal | Maybe it never really worked, only now we know it really doesn't :) | 10:47 |
d0ugal | I need to go out for a bit, back later. | 10:48 |
rakhmerov | me too | 10:49 |
*** gongysh has quit IRC | 11:03 | |
*** openstackgerrit has joined #openstack-mistral | 11:06 | |
openstackgerrit | XieYingYun proposed openstack/mistral master: Remove unnecessary setUp function in testcase https://review.openstack.org/451760 | 11:06 |
*** amoralej is now known as amoralej|lunch | 11:08 | |
*** jkilpatr has quit IRC | 11:25 | |
*** thrash has quit IRC | 11:37 | |
*** thrash has joined #openstack-mistral | 11:41 | |
*** thrash has quit IRC | 11:41 | |
*** thrash has joined #openstack-mistral | 11:41 | |
*** rbrady-afk is now known as rbrady | 11:45 | |
*** dprince has joined #openstack-mistral | 11:49 | |
*** sharatss_ has joined #openstack-mistral | 11:54 | |
*** sharat has quit IRC | 11:54 | |
*** catintheroof has joined #openstack-mistral | 12:21 | |
*** shardy has joined #openstack-mistral | 12:49 | |
*** shardy is now known as shardy_mtg | 12:50 | |
*** amoralej|lunch is now known as amoralej | 12:52 | |
*** shardy_mtg is now known as shardy | 12:56 | |
*** gongysh has joined #openstack-mistral | 13:02 | |
openstackgerrit | Anastasia Kuznetsova proposed openstack/mistral master: Fix work of task() without task name within on-clause cases https://review.openstack.org/451340 | 13:29 |
*** chlong has joined #openstack-mistral | 13:34 | |
*** bobh has joined #openstack-mistral | 13:35 | |
*** jaosorior is now known as jaosorior_away | 13:37 | |
*** tuan_ has quit IRC | 13:52 | |
*** tuan has joined #openstack-mistral | 13:54 | |
*** szaher has quit IRC | 14:14 | |
*** szaher has joined #openstack-mistral | 14:14 | |
d0ugal | rakhmerov: any luck? | 14:57 |
therve | https://bitbucket.org/zzzeek/sqlalchemy/issues/3646/mutabledict-associatess-only-with-first sounds kind of worrying | 15:00 |
d0ugal | therve: yeah :/ I wonder what might have been missed due to this | 15:02 |
therve | Yeah | 15:03 |
therve | To be fair I think that using mutable is a horrible idea | 15:03 |
d0ugal | yup | 15:03 |
*** xavierhardy has joined #openstack-mistral | 15:03 | |
xavierhardy | Hi everyone, I have already asked the question but is it possible to authenticate to Mistral without Keystone, nor OpenID. We don't want to use keystone nor a third party website for authentication. Basic auth (username/password) would be enough. | 15:08 |
xavierhardy | being able to support custom authentication mechanism would be enough | 15:11 |
d0ugal | xavierhardy: yeah, it is possible | 15:11 |
d0ugal | you just need to set auth_enable = False | 15:11 |
d0ugal | then you need to add basic auth with apache etc. | 15:11 |
xavierhardy | but how do I get the users in Mistral then ? | 15:11 |
xavierhardy | I want to apply policies then. | 15:12 |
xavierhardy | with custom tenants, not coming from Keystone | 15:12 |
d0ugal | well, you can't ask for no auth but with auth :) | 15:13 |
xavierhardy | Basic auth is not no auth | 15:13 |
xavierhardy | We have our own system, something not standard at all | 15:13 |
xavierhardy | If I have an option "auth_plugin" where I can define in Python what to do, I'm fine | 15:14 |
xavierhardy | auth_plugin = my.custom.python:AuthenticationClass | 15:15 |
d0ugal | no, I don't think there is a way to do that now | 15:15 |
xavierhardy | :( | 15:15 |
*** gongysh has quit IRC | 15:17 | |
*** vienin has quit IRC | 15:31 | |
*** thrash is now known as thrash|biab | 15:31 | |
*** weshay is now known as weshay_mtg | 15:43 | |
*** Kimamisa has quit IRC | 15:46 | |
*** sharatss_ has quit IRC | 15:59 | |
*** thrash|biab is now known as thrash | 16:00 | |
rakhmerov | xavierhardy: that work was started by someone some time ago but it wasn't finished | 16:09 |
rakhmerov | d0ugal: I didn't come up with a fix yet | 16:10 |
rakhmerov | sorry | 16:10 |
rakhmerov | will try to find time tomorrow to fix it | 16:10 |
xavierhardy | OK | 16:14 |
xavierhardy | I guess you have some kind of abstraction for the authentication since you support both Keystone and OpenID, could I plug my code there ? | 16:14 |
xavierhardy | It would be to support custom authentication mechanisms in general. | 16:15 |
rakhmerov | xavierhardy: yes, you can plug it there but we don't have any plugin architecture now, it's mostly hardcoded | 16:17 |
rakhmerov | btw, I don't think there's too much work to generalize it and make it pluggable | 16:18 |
rakhmerov | xavierhardy: I'll talk to the person who was working on it, I believe he's mostly completed it but just didn't push upstream | 16:18 |
*** jaosorior_away is now known as jaosorior | 16:19 | |
rakhmerov | because they had the same requirement internally and AFAIK they addressed it | 16:19 |
xavierhardy | OK | 16:19 |
*** shardy has quit IRC | 16:20 | |
rakhmerov | d0ugal: I have a pretty simple fix in mind, will try to check it tomorrow. In fact, we don't need nested structures, we can try to use plain dicts | 16:20 |
rakhmerov | d0ugal, therve: weird, I just tried to remove extra level when using MutableDict, just left a simple dict with 1 level (i.e. {'k1': 'v1'}), and that doesn't work too | 16:29 |
rakhmerov | as if there was actually a but in the new SQLA | 16:29 |
*** weshay_mtg is now known as weshay | 16:32 | |
*** jaosorior has quit IRC | 16:50 | |
*** chlong has quit IRC | 17:36 | |
*** tuan has quit IRC | 17:37 | |
*** tuan has joined #openstack-mistral | 17:41 | |
*** FL1SK has quit IRC | 17:59 | |
*** chlong has joined #openstack-mistral | 18:02 | |
*** chlong has quit IRC | 18:11 | |
*** tuan has quit IRC | 18:22 | |
*** d0ugal has quit IRC | 18:24 | |
*** chlong has joined #openstack-mistral | 19:00 | |
*** chlong has quit IRC | 19:07 | |
openstackgerrit | Toure Dunnon proposed openstack/mistral-specs master: [WIP] Workflow Error Analysis https://review.openstack.org/443217 | 19:37 |
*** FL1SK has joined #openstack-mistral | 19:56 | |
therve | rakhmerov, I pinged Mike Bayer, I hope he was some idea | 19:59 |
*** chlong has joined #openstack-mistral | 20:36 | |
*** toure is now known as toure|gone | 20:55 | |
*** catintheroof has quit IRC | 21:03 | |
openstackgerrit | Thomas Herve proposed openstack/mistral master: Workaround SQLAlchemy 1.1 issue https://review.openstack.org/451985 | 21:05 |
*** dprince has quit IRC | 21:05 | |
*** jpich has quit IRC | 21:08 | |
*** chlong has quit IRC | 21:09 | |
*** harlowja has quit IRC | 22:02 | |
*** bobh has quit IRC | 22:13 | |
*** harlowja has joined #openstack-mistral | 23:24 | |
*** bobh has joined #openstack-mistral | 23:41 | |
*** openstack has joined #openstack-mistral | 23:44 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!