16:00:05 <rakhmerov> #startmeeting Mistral
16:00:06 <openstack> Meeting started Mon Nov 28 16:00:05 2016 UTC and is due to finish in 60 minutes.  The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:10 <openstack> The meeting name has been set to 'mistral'
16:00:26 <ddeja> o/
16:00:28 <d0ugal> Hey
16:00:33 <sharatss> hi
16:00:56 <rbrady> o/
16:01:21 <rakhmerov> hi all
16:01:49 <rakhmerov> #topic Review action items
16:02:23 <rakhmerov> 1. rakhmerov: look at https://review.openstack.org/#/c/383617/
16:02:57 <rakhmerov> I did look at it but since then some other comments were left
16:03:03 <rakhmerov> I'll look again
16:03:22 <d0ugal> so this means every retry will try once more than before?
16:04:00 <rakhmerov> well, there's a bug now in retry policy
16:04:01 <rakhmerov> yes
16:04:16 <rakhmerov> it doesn't run at all if count is 1
16:04:28 <d0ugal> Right
16:04:39 <d0ugal> Just checking I understand ddeja's comment
16:04:47 <rakhmerov> so what we need to do is to make it run exactly "count" number of times
16:05:01 <sharatss> rakhmerov: d0ugal previously the first try was considered as retry. but this patch ignores the first unsuccessful run
16:05:02 <rakhmerov> excluding normal initial execution
16:05:14 <d0ugal> Yup, makes sense to me. I think the change is fine.
16:05:33 <d0ugal> I had assumed it was already doing this :)
16:05:53 <rakhmerov> sharatss: I don't understand what you mean by first "try" ?
16:06:00 <rakhmerov> initial task execution?
16:06:05 <d0ugal> yes, I think so
16:06:11 <sharatss> rakhmerov, i mean the initial execution
16:06:19 <rakhmerov> yes, then it's wrong
16:06:42 <rakhmerov> retry is a retry, it works only after initial run
16:07:33 <rakhmerov> ddeja: assuming this, do you think the current patch is ok?
16:07:52 <rakhmerov> yes, this changes the current behavior, but there's a bug in the current behavior
16:08:02 <ddeja> rakhmerov: IMO it is OK
16:08:06 <rakhmerov> ok
16:08:15 <d0ugal> This patch will make the documentation correct too
16:08:47 <rakhmerov> yep
16:09:04 <rakhmerov> ddeja: then please vote again if it's ok for you
16:09:19 <ddeja> rakhmerov: the only remaining is failing dsvm gates
16:09:20 <rakhmerov> or may be you have some other comments
16:09:32 <rakhmerov> is it also related to this change?
16:09:36 <ddeja> I'd like to look on it before voting
16:09:42 <rakhmerov> yes, sure
16:09:46 <rakhmerov> of course
16:09:47 <ddeja> I don't quite remember, but I'd like to be 100% sure
16:09:51 <rakhmerov> right
16:09:53 <rakhmerov> thanks
16:10:00 <rakhmerov> ok, let's move on
16:10:05 <rakhmerov> #topic Current status
16:10:59 <rakhmerov> I've almost finished fixing launching process and refactoring life-cycle of mistral services
16:11:00 <rakhmerov> https://review.openstack.org/#/c/402392/
16:11:31 <rakhmerov> a little bit stuck with fixing tests, I found a problem today with threads, I think I'll fix it tomorrow
16:11:47 <rakhmerov> but it's mainly fixed
16:12:17 <d0ugal> I have been looking into a couple of bugs related that have came up. One with custom actions and the Result class and one now to do with workflow names in workbooks
16:12:23 <rakhmerov> IMO, this was quite important to do because I realized that this aspect of the system was messed up completely
16:12:29 <rakhmerov> and hard to maintain
16:12:34 <rakhmerov> and it had a number of bugs
16:13:11 <rakhmerov> d0ugal: did you find the root cause of that Result(error=..) problem?
16:13:13 <d0ugal> I had a look at the patch, but found it hard to review :)
16:13:20 <ddeja> My status: Done more reviews than in a past few weeks. And I'm looking forward to see the new tasks function to check if it suits my 'preconditions' use case
16:13:26 <rakhmerov> d0ugal: you mean my patch?
16:13:37 <d0ugal> rakhmerov: yeah, your patch :) it is just quite big and complicated.
16:13:46 <d0ugal> and I am not that familiar with some of the code it changes
16:13:47 <rakhmerov> yeah, it's a bit tricky but I had to make it one patch
16:13:53 <d0ugal> sure
16:13:54 <rakhmerov> because it's all entangled
16:14:02 <rakhmerov> d0ugal: I can provide any explanations
16:14:05 <rakhmerov> in IRC
16:14:13 <d0ugal> rakhmerov: okay, I'll look again tomorrow and maybe ask questions.
16:14:17 <rakhmerov> it's just impossible to squeeze everything in the commit message
16:14:17 <d0ugal> thanks!
16:14:37 <rakhmerov> ddeja: yes, ok
16:14:53 <rakhmerov> d0ugal: yeah, sorry, I know it's not easy
16:14:54 <d0ugal> rakhmerov: I didn't finish tracking down the Result(error=... issue. I got distracted as one of the tripleo devs tried to create a workflow with "version" in the name :-)
16:14:56 <rakhmerov> I'll explain
16:15:14 <rakhmerov> ddeja: btw, I actually still have some questions on RPC
16:15:27 <rakhmerov> ddeja: we can discuss it separately tomorrow
16:15:43 <ddeja> rakhmerov: no problem, I'll try to wake up erilier
16:15:45 <rakhmerov> I just noticed several things that I think we need to fix/improve
16:15:51 <ddeja> OK
16:16:01 <rakhmerov> ddeja: yeah, just don't play Civ 5 :)
16:16:17 <rakhmerov> tonight )
16:16:22 * d0ugal recently bought civ 6
16:16:22 <ddeja> :V
16:16:34 <rakhmerov> :))
16:16:43 <rakhmerov> gamers are everywhere
16:16:59 <d0ugal> Otherwise I spoke briefly with rbrady about the custom actions spec. He started to refresh his memory of it all...
16:17:03 <rakhmerov> sharatss: any updates from you?
16:17:06 <rakhmerov> rbrady: ?
16:17:18 <rakhmerov> sharatss: I looked at the i18n BP, approved it
16:17:20 <rakhmerov> looks ok
16:17:35 <rbrady> I looked at our previous conversation and started looking at the code again
16:17:38 <sharatss> rakhmerov, not much this week. not well :(
16:17:46 <rbrady> our previous conversation: http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-08-22-16.01.log.txt
16:18:00 <rakhmerov> sharatss: don't be so shy, I see you're commiting a lot
16:18:10 <rakhmerov> rbrady: ok
16:18:29 <rakhmerov> is it a good time now to discuss this all again?
16:18:29 <rbrady> where we stopped is where we looked at some methods that needed internal access to database info
16:18:36 <rakhmerov> or you'd like to refresh it more?
16:18:44 <rakhmerov> we can leave it till the next meeting
16:18:52 <rakhmerov> but let's try to prepare better
16:18:55 <rakhmerov> (me too)
16:19:09 <sharatss> rakhmerov, haha :) actually i was on leave last week. So, didnt feel i was working :P
16:19:18 <rakhmerov> rbrady: ooh, you mean in mistral-lib, right?
16:19:22 <rbrady> rahkmerov: that's fine.  It might give me more time to work out a proposal for moving forward
16:19:30 <rbrady> rahkmerov: yes
16:20:05 <rakhmerov> what's an example of why we need to get something from DB?
16:20:09 <rakhmerov> I just don't remember
16:20:12 <d0ugal> mistral context?
16:20:16 <rbrady> https://github.com/openstack/mistral-lib/blob/master/mistral_lib/actions/api/execution.py
16:20:31 <rbrady> getting the action_execution_id
16:20:49 <rakhmerov> ooh, no-no
16:21:26 <rakhmerov> I think this part should as follows: all of that is only a contextual information and it should be provided to executor in advance (over RPC)
16:21:45 <rakhmerov> we shouldn't be able to get an arbitrary execution object from DB
16:22:00 <rakhmerov> only those objects that are related to the current action that we're processing
16:22:22 <rbrady> then we'll need to make sure we are adding all of that information to the context (if it's missing)
16:22:40 <rakhmerov> and these are simply helper methods to extract that info so that we don't have to pass that stuff as action params (and thus polluting method signature)
16:22:44 <rbrady> and just use that pattern for all data you want made available to custom actions
16:22:51 <rakhmerov> rbrady: yes, right
16:23:02 <rakhmerov> that's what I was thinking, yes
16:23:35 <rakhmerov> all that is in mistral-lib should be kinda primitive, all needed contextual info should be provided from the engine
16:24:09 <rbrady> rahkmerov: okay.  I'll take some time to update the patch this week following that idea and identify possible context changes
16:24:19 <rakhmerov> yeah, ok
16:24:53 <rakhmerov> my other concern though is that we might have problems with code dependencies, we need to be wise on what should stay in mistral and what should migrate to mistral-lib
16:25:26 <rakhmerov> btw, 'mistral' will depend on 'mistral-lib', right?
16:25:49 <rbrady> rahkmerov: yes
16:25:52 <rakhmerov> ok
16:25:58 <rakhmerov> good
16:26:19 <d0ugal> +1
16:26:33 <rbrady> rahkmerov: IIUC, mistral_lib should be small and contain types and/or expections and a minimum of utility methods required for action development
16:26:48 <rakhmerov> yes
16:26:52 <d0ugal> and maybe yaql/jinja2 function development?
16:26:58 <rbrady> rahkmerov: then mistral and mistra_extra will depend on those features there
16:26:59 <rakhmerov> exactly
16:26:59 <rakhmerov> yes
16:27:12 <rakhmerov> d0ugal: in case of functions it's more tricky though
16:27:19 <d0ugal> rakhmerov: okay, we can do that later :)
16:27:19 <rakhmerov> because they really need DB access
16:27:21 <rakhmerov> :)
16:27:36 <d0ugal> something to think about
16:27:40 <rakhmerov> yes
16:27:51 <rakhmerov> honestly, I don't have a clear picture in mind now
16:27:55 <rakhmerov> as far as functions
16:28:07 <rakhmerov> may be we're missing something here..
16:28:37 <rakhmerov> I would like to move functions to mistral-lib too, but don't know how yet
16:29:18 <rakhmerov> the other problem with functions is that ideally they should not be able to use internal DB API at all
16:29:27 <rbrady> rahkmerov: maybe after dealing with actions we can apply what we've learned to dealing with the functions
16:29:36 <rakhmerov> it seems weird if anyone would be able to use our internal DB API when writing those functions
16:29:51 <rakhmerov> because it wouldn't be just an internal API anymore
16:30:07 <d0ugal> Yeah, I would suggest we focus on custom actions for now
16:30:15 <rakhmerov> rbrady: yes, I think the first iteration could be actions
16:30:23 <d0ugal> but functions should be an eventual goal
16:30:45 <rakhmerov> but I think it makes sense to keep that all experimental until we at least have understanding of how to deal with functions
16:31:28 <d0ugal> Yeah
16:31:41 <rakhmerov> d0ugal, rbrady: maybe the right way to provide a number of functions with DB access in 'mistral' repo itself
16:31:52 <rakhmerov> and deny to use DB API for everyone else
16:32:48 <rakhmerov> so that we declare that: ok, we have a number of useful functions that can help you access all DB objects (workflows, actions, tasks etc.) but if you'd like to write your own function you can't use DB
16:33:04 <rakhmerov> or may be they should be able to reuse those existing functions somehow
16:33:11 <d0ugal> Yeah, that seems reasonable
16:33:15 <rakhmerov> if they want to get some objects from DB
16:33:23 <rakhmerov> yeah, I'm just brainstorming now
16:33:33 <d0ugal> but lets worry about it later :)
16:33:38 <rakhmerov> ok, we need to remember this idea
16:33:47 <rakhmerov> it seems pretty reasonable to me too
16:34:31 <rakhmerov> #info Custom functions (jinja/yaql) that need DB access could re-use built-in functions like executions(), tasks() etc.
16:34:42 <rakhmerov> ok
16:34:56 <rakhmerov> in fact, we've been discussing the next topic in the agenda
16:34:59 <rakhmerov> :)
16:35:03 <rakhmerov> but ok
16:35:16 <rakhmerov> rbrady, d0ugal: let's try to speed it up somehow, I'll participate too in a week or two
16:35:34 <rakhmerov> once I fix a number of other pretty urgent things
16:35:43 <d0ugal> Great
16:35:55 <rakhmerov> this is one of my top priorities to deal with actions
16:36:08 <rakhmerov> ok
16:36:31 <rakhmerov> #topic Open Discussion
16:37:06 <rakhmerov> anything else?
16:37:25 <rakhmerov> sharatss: what are you planning to work next?
16:37:30 <rakhmerov> i18n?
16:37:39 <sharatss> rakhmerov, i have started to work on client docs
16:37:53 <rakhmerov> ooh, that's good
16:38:08 <rakhmerov> as far as i18n, what's the reason you decided to work on it?
16:38:16 <d0ugal> ddeja: You wanted to talk about the version name thing - did you see my discussion with rakhmerov in #openstack-mistral?
16:38:23 <rakhmerov> do you see it as an important thing?
16:38:39 <ddeja> d0ugal: yes, I saw it
16:38:56 <rakhmerov> d0ugal, ddeja: yeah, I agree with you conclusions, I'm pretty sure this is a bug
16:39:09 <ddeja> and I guess there is nothing else to discuss in this matter
16:39:17 <sharatss> rakhmerov, i have one of my colleague who used i18n for some other thing. was quite interesting
16:39:19 <d0ugal> ddeja: cool, I agree. just wanted to check
16:39:21 <rakhmerov> but I didn't understand yet why we need that regex, it seems really weird to me
16:39:29 <d0ugal> ddeja: I just need to figure out the fix :)
16:39:32 <d0ugal> rakhmerov: +1
16:39:50 <d0ugal> rakhmerov: I am reading code to try and figure that out now :)
16:39:50 <sharatss> rakhmerov, it will be good if we can support multiple languages in Mistral too
16:39:52 <rakhmerov> sharatss: yes, I just didn't realize it was so important, we have so many other things to do :)
16:40:03 <rakhmerov> d0ugal: ok, good
16:40:16 <rakhmerov> this piece was written by Nikolay Makhotkin
16:40:25 <rakhmerov> I can try to reach out to him if needed
16:40:35 <rakhmerov> but he is not in OpenStack anymore :(
16:40:55 <sharatss> rakhmerov, its not my priority though. I will be working on the client BP (debug one)
16:40:58 <ddeja> rakhmerov: oh, I saw him doing some reviews in Ocata cycle...
16:41:07 <sharatss> rakhmerov, will try to get it done by next week
16:41:09 <rakhmerov> sharatss: yeah, IMO that's more important
16:41:19 <rakhmerov> I would postpone i18n for a little bit
16:42:15 <sharatss> rakhmerov, hmm... i will ask you some queries tomorrow regarding cli docs as well
16:42:22 <rakhmerov> ddeja: yeah, but AFAIK he is about to find a new job and I don't know if he will be able to contribute into Mistral
16:42:32 <rakhmerov> it would be cool, but life is life
16:42:39 <rakhmerov> sharatss: sure
16:42:43 <ddeja> oh I see
16:43:01 <rakhmerov> ddeja: yeah, he is not at Mirantis anymore
16:43:13 <sharatss> now gate jobs are passing right?
16:43:33 <rakhmerov> sharatss: you mean mysql?
16:43:38 <rakhmerov> or something else?
16:43:50 <rakhmerov> sharatss: btw, thanks for fixing mysql gate
16:43:57 <d0ugal> +1
16:44:05 <rakhmerov> now we are more protected :)
16:44:17 <rakhmerov> ooh, gentlemen, question
16:44:28 <sharatss> rakhmerov, i hate seeing something in red in the jenkins column :))\
16:44:28 <d0ugal> I still need to do something with the devstack check
16:44:44 <rakhmerov> Why the f... do we have to make our unit tests work with sqlite?
16:44:48 <rakhmerov> does anybody know?
16:45:06 <rakhmerov> I know it was a strict requirement but not sure if it's still true
16:45:07 <d0ugal> Because it is easier for people to run them with sqlite?
16:45:15 <sharatss> d0ugal: err.. only one test fails in the devstack check :(
16:45:25 <rakhmerov> sharatss: we're aware of some issues, once in a while they appear
16:45:38 <rakhmerov> for example, d0ugal is about to fix devstack-dsvm
16:45:44 <d0ugal> "about to"
16:45:50 <d0ugal> hah
16:45:52 <rakhmerov> :)
16:45:53 <rakhmerov> yes
16:45:56 <rakhmerov> I believe in you :)
16:46:15 <rakhmerov> d0ugal: ok, as far as sqlite, for me it's a great pain
16:46:17 * d0ugal takes note to look into it tomorrow
16:46:30 <sharatss> rakhmerov, yes. those come because of some commit in some other project :( that's the irritating part
16:46:34 <rakhmerov> I would love to get rid of sqlite support completely
16:46:46 <rakhmerov> for many many reasons
16:46:53 <rakhmerov> which I can tell about separately
16:46:56 <d0ugal> rakhmerov: maybe we can ask with [all] on openstack-dev to see if we can drop sqlite support?
16:47:11 <rakhmerov> but I don't know what community thinks now
16:47:23 <rakhmerov> d0ugal: good idea )
16:47:37 <rakhmerov> I definitely need to use ML more actively
16:47:56 <d0ugal> I have no idea how people will react
16:47:57 <rakhmerov> once in a while I have such questions and for some reason I don't feel like writing to ML
16:48:11 <rakhmerov> but that's ok, it's a good think to ask
16:48:11 <d0ugal> it is hard to keep up with openstack-dev
16:48:28 <rakhmerov> #action rakhmerov: write an email to ML about sqlite support
16:48:35 <rakhmerov> true
16:48:52 <rakhmerov> ok, I don't have anything else for today
16:49:13 <rakhmerov> how about you?
16:49:19 <d0ugal> Nothing else from me
16:49:25 <rakhmerov> ok
16:49:32 <rakhmerov> sharatss, rbrady?
16:49:35 <rakhmerov> ddeja: ?
16:49:35 <d0ugal> oh, actually, did you make any progress with the alternate meeting? or are we meeting at this time again next week?
16:49:41 <rbrady> nothing from me
16:49:46 <ddeja> nothing from my side
16:49:50 <rakhmerov> d0ugal: nope, I wasn't able to catch kong yet
16:49:56 <sharatss> nothing from me too
16:50:05 <d0ugal> rakhmerov: okay, so this time again next week?
16:50:10 <rakhmerov> although he was supposed to come back from vacation (may be I confused the dates)
16:50:22 <rakhmerov> d0ugal: yes, same time for now
16:50:27 <d0ugal> k, thanks
16:50:31 <rakhmerov> yep
16:50:37 <rakhmerov> ok, thanks for joining
16:50:56 <rakhmerov> bye everyone and have a wonderful week
16:51:03 <sharatss> thank you :)
16:51:09 <ddeja> thanks, bye
16:51:17 <rakhmerov> #endmeeting