16:01:45 <rakhmerov> #startmeeting Mistral
16:01:49 <openstack> Meeting started Mon Aug 22 16:01:45 2016 UTC and is due to finish in 60 minutes.  The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:52 <openstack> The meeting name has been set to 'mistral'
16:02:04 <rakhmerov> hi
16:02:06 <d0ugal> Hello! o/
16:02:08 <rbrady> hello
16:02:26 <jpeeler> hey
16:03:37 <rakhmerov> I was actually thinking to cancel the meeting because a number of folks said that the wouldn't be here
16:03:57 <rakhmerov> but let's quickly discuss any hot topics, if any
16:04:03 <d0ugal> Sounds good :)
16:04:05 * jpeeler just wants reviews
16:04:15 <rakhmerov> :)
16:04:20 <rakhmerov> #topic Current status
16:04:37 <rakhmerov> let's quickly provide status updates
16:05:28 <d0ugal> I spent a bit of time looking at https://bugs.launchpad.net/mistral/+bug/1411868 and I think it can be closed as it is becoming a non-issue. (mysql now supports precise datetimes)
16:05:28 <openstack> Launchpad bug 1411868 in Mistral "list of tasks for an execution from API is out of order" [Medium,In progress]
16:05:34 <rakhmerov> my status: still working on performance/deadlocks issues. Basically, as far as performance, all major issues were fixed, now I'm struggling with one DB deadlock that occurs in case of using 'join' tasks
16:05:44 <rakhmerov> hoping to finish it this week
16:06:03 <rakhmerov> d0ugal: ok, I see
16:06:17 <d0ugal> and now I am spending some time looking at database migrations (https://bugs.launchpad.net/mistral/+bug/1611036) but mostly kept bust by TripleO Mistral work.
16:06:17 <rakhmerov> jpeeler: as far as reviews, you mean caching, right?
16:06:18 <openstack> Launchpad bug 1611036 in Mistral "Automatically test database migrations" [Undecided,Confirmed] - Assigned to Dougal Matthews (d0ugal)
16:06:30 <rbrady> custom actions api: I started implementing feedback.  it seems odd to move the context and utils into an api namespace.  The current patch has the api namespace removed.  I'm porting over tests today
16:06:56 <jpeeler> rakhmerov: client caching, and the external access to cached clients one (could be way off target - that's why i need reviews!)
16:07:19 <rbrady> I've been busy with some TripleO Mistral work, but focusing today and tomorrow on getting the custom actions completed
16:07:21 <rakhmerov> #action rakhmero: review client caching patches
16:07:34 <rakhmerov> #action rakhmerov: review client caching patches
16:07:58 <jpeeler> thanks renat
16:08:13 <rakhmerov> jpeeler: last time I looked at your patches they were mostly fine as far as I remember, I just didn't have a chance to finish my review
16:08:17 <rakhmerov> np
16:08:41 <rakhmerov> rbrady: can you please quickly explain what concerns you on moving stuff under 'api'?
16:09:17 <d0ugal> What value does "api" provide?
16:09:27 * d0ugal questioned why we had it in the review
16:09:48 <rbrady> rakhmerov: while the exceptions and base action seem to fit there, the utils/keystone.py and context.py files would seem out of place to me to be placed in api
16:10:15 <rakhmerov> rbrady: I totally agree
16:10:53 <rbrady> d0ugal: I think the original intent was to have the api namespace to be the public contract with custom action developers
16:11:06 <rakhmerov> rbrady: yes, 100%
16:11:31 <d0ugal> I think it would be better to have everything public unless it starts with a "_"
16:11:36 <rakhmerov> rbrady: I just want to clarify. Is there a still a reason to put them under api?
16:11:37 <d0ugal> Like the oslo libs do
16:11:48 <rakhmerov> is somebody proposing it or something?
16:12:08 <rbrady> d0ugal: but the more I've been adding things and then testing them out by changing tripleo-common, the more it seems like maybe the entire mistral-lib would be a good candidate for public contract
16:12:28 <rakhmerov> d0ugal: I kind of disagree on it, because even libraries can have their implementation part and API
16:12:35 <d0ugal> rbrady: Yup, with the exception of a few things we can underscore like they do here: https://github.com/openstack/oslo.cache/tree/master/oslo_cache
16:12:49 <d0ugal> rakhmerov: hmm, it seems weird. No other library I know of does this.
16:13:37 <mgershen> o/
16:13:37 <rakhmerov> #action rakhmerov: find an example of library where 'api' and 'implementation' part are explicitly separated
16:13:38 <rakhmerov> :)
16:13:41 <d0ugal> haha
16:14:07 <d0ugal> I am not going to argue the point further - but I think the norm for Python libraries is to default to public and mark private with underscores.
16:14:19 <rakhmerov> I mean.. I've seen this all around in other languages
16:14:23 <rakhmerov> java, cpp
16:14:26 <rbrady> d0ugal: does the underscore denote "private to mistral_lib" or "private to mistral_lib and mistral" ?
16:14:55 <rakhmerov> maybe it's another funny 'we simply don't need this' kind of thing in python :)
16:15:13 <rbrady> d0ugal: some of the things we want to keep private from custom action devs, we would need to use in mistral
16:15:20 <d0ugal> rbrady: That's a fair point, normally it probably does mean private to mistral_lib - but given it's the same devs on both I think expanding that to mistral is fine.
16:15:32 <rakhmerov> d0ugal: yeah, as far as using underscore it's ok to me
16:15:41 <rakhmerov> I'm just elaborating on the principle itself
16:15:44 <d0ugal> Sure
16:15:54 <d0ugal> Anyway, I don't mind what colour the bikeshed is really :)
16:16:09 <rakhmerov> it totally makes sense to me to have some very internal module implementing a certain function exposed outside
16:16:21 <rakhmerov> ok, that's clear
16:16:39 <rbrady> d0ugal, rakhmerov: the other idea I had was to keep only public things in mistral_lib, e.g. exceptions
16:17:29 <rakhmerov> rbrady: ok, I think I see your concern now
16:17:43 <rbrady> only the base exceptions and action exception would need to be in mistral_lib, the other exceptions could stay in mistral proper
16:17:54 <rakhmerov> d0ugal, rbrady: I think we just should clearly separate two things in this whole story
16:18:15 <d0ugal> +1
16:18:25 <rakhmerov> mistral_lib is a library (and python project) with two types of clients (users)
16:18:46 <rakhmerov> #1. Other mistral subprojects
16:19:08 <rakhmerov> #2. Mistral users, action developers
16:19:40 <rakhmerov> so, for #1 I don't see any problems to just being able to use everything from mistral-lib
16:19:49 <rakhmerov> even what's not under actions.api
16:20:21 <rakhmerov> that's fine to me because it's all internal inter-mistral relationship
16:20:22 <d0ugal> Sounds good.
16:20:46 <rakhmerov> we can change this part easily w/o having to notify anyone else outside
16:21:20 <rakhmerov> as far as #2, we have the responsibility to keep it stable enough so it can be treated as some sort of API
16:21:26 <rakhmerov> because it's related to our users
16:21:43 <rakhmerov> that's at least how I understand it
16:21:49 <rakhmerov> what do you think?
16:22:39 <rakhmerov> rbrady, d0ugal?
16:22:50 * rbrady typing
16:22:57 <rakhmerov> ok
16:23:08 <d0ugal> I would still prefer we put only public code in mistral-lib
16:24:11 <d0ugal> I just don't understand why we want to move private code to another repo
16:24:31 <d0ugal> If nothing else, it would make working on Mistral harder as you need to use depends-on and do updates in two places etc.
16:24:48 <rbrady> rakhmerov: I understand the points laid out.  If we intend a for mistral_lib to be heavily relied on from other mistral sub-projects I think mistral-lib might be larger.  Only having public code in mistral-lib will keep it smaller
16:25:29 <rakhmerov> yeah, I understand all this
16:25:30 <rakhmerov> but
16:25:46 <rakhmerov> this purely public code will have to rely on some implementation part
16:25:57 <rakhmerov> where is it going be?
16:26:16 <rakhmerov> it obviously can't be in mistral, for example
16:26:34 <rakhmerov> mistral can (and will) depend on mistral-lib but not the way around
16:26:38 <rbrady> yes...the context and its dependency - the threading, ends up living in the public space
16:26:57 <d0ugal> Why are we having mistral depend on mistral-lib and not the other way around?
16:27:28 <d0ugal> I guess we have discussed this, but I have forgotten.
16:27:47 <rbrady> d0ugal: smaller dependency for custom action devs.
16:27:58 <d0ugal> rbrady: Oh yeah, obvious. Sorry.
16:28:03 <rakhmerov> d0ugal: regarding your point about updating things in two places, I agree. However, I think it's a trade-off we can accept. We should try to keep mistral-lib as stable as possible
16:28:07 <rakhmerov> even not api part
16:28:41 <rakhmerov> if it stays relatively stable then it won't give us too much pain with having to make updates in different repos
16:29:24 <d0ugal> Right
16:29:28 <rakhmerov> d0ugal: yes, it
16:29:34 <rakhmerov> it's like the following:
16:29:44 <rbrady> rakhmerov: looking at the execution.py file in the initial code import - aren't these methods that will somehow have to query the db for information?
16:29:56 <rakhmerov> mistral -> mistral-lib <- mistral-extra (OpenStack actions)
16:30:08 <rakhmerov> where arrows means 'depends on'
16:30:16 <d0ugal> rakhmerov: oh, I didn't know mistral-lib would depend on mistral-extra.
16:30:30 <rakhmerov> d0ugal: no, no
16:30:35 <d0ugal> oh
16:30:39 <d0ugal> Other way around
16:30:39 <rakhmerov> the way around )
16:30:43 <rakhmerov> yes
16:30:45 * d0ugal is tired
16:30:54 * rakhmerov renat too
16:31:26 <rakhmerov> rbrady: ha! that's a good point...
16:31:27 <d0ugal> Okay, so I don't really mind. We can just go ahead with the ".api." thing, but I still think it is going to be a strange choice for a python lib
16:32:23 <rakhmerov> f...k
16:32:33 <d0ugal> rbrady: Where is that?
16:33:08 <rbrady> d0ugal: https://github.com/openstack/mistral-lib/blob/master/mistral_lib/actions/api/execution.py
16:33:09 * rakhmerov last rbrady's point made renat very unhappy
16:33:23 <d0ugal> lol, rbrady look what you did! ;)
16:33:39 * rbrady ducks
16:34:27 <rakhmerov> yeah... this is really weird
16:35:04 <rbrady> rakhmerov: is there a use case for an action needing to know what execution_id is?
16:35:21 <rakhmerov> yes, indeed
16:35:24 <rbrady> rakhmerov: I've used execution info in a workflow, but not an action yet
16:35:33 <rakhmerov> any asynchronous action
16:35:59 <rakhmerov> rbrady: ok, here's what I think
16:36:14 <rakhmerov> those methods may not actually need DB
16:36:51 <rakhmerov> this data like execution id etc. maybe just a contextual information always available in the current execution thread
16:37:02 <rakhmerov> and those methods can be just extracting it
16:37:23 <rakhmerov> for this particular case it maybe enough
16:37:38 <rakhmerov> but you raised a good concern actually
16:37:43 <rakhmerov> in general
16:37:47 <rbrady> rakhmerov: so would the execution info be added to the context?
16:38:20 <rakhmerov> yes, it's pretty much what we do now passing this info under special parameter 'context' that actions can optionally have
16:38:34 <rakhmerov> but in a slightly different form
16:39:02 <rakhmerov> I was just thinking, for example, about other things like custom YAQL functions
16:39:10 <rakhmerov> I know we're not there yet but anyway
16:39:25 <rakhmerov> for custom YAQL functions we need kind of API as well
16:39:48 <rakhmerov> but in that case I would expect that YAQL functions devs may want to query something in DB
16:39:54 <rakhmerov> through some interface
16:40:47 <rakhmerov> I dunno, I need to think about it
16:41:24 <rakhmerov> but I would suggest we keep moving forward with this anyway and see what we're getting
16:41:45 <rbrady> rakhmerov: okay.  I will continue adding tests for the code that there and discuss the other bits later.
16:41:58 <rakhmerov> yeah, ok
16:42:00 <rakhmerov> thanks
16:42:32 <rakhmerov> rbrady: btw, do you have to use a stable mistral release or you can use just latest master version?
16:42:40 <rakhmerov> I might have asked you, I don't remember..
16:42:56 <rbrady> tripleo has been using master
16:43:00 <rakhmerov> ok
16:43:41 <d0ugal> Keeps things intersting :)
16:43:46 <rakhmerov> rbrady: I'm asking because it seems like we won't finish this BP in N-3. Partially because I had to switch to performance issues which are also important
16:43:58 <rakhmerov> and because it's our internal priority
16:44:15 <d0ugal> TripleO will have to use a released version for N
16:44:20 <rbrady> rakhmerov: ack.  if this doesn't make N3, can we roll it over to the next cycle and continue it?
16:44:27 <rakhmerov> and in any case, I would prefer that don't hurry with it
16:44:43 <rakhmerov> rbrady: yes, that's what I'm proposing
16:44:45 <d0ugal> +1, it is turning out to be quite complex :)
16:44:50 <rbrady> rakhmerov: ack
16:44:51 <rakhmerov> yep
16:44:53 <rbrady> +1
16:45:18 <rakhmerov> it will remove pressure from us (which I already have more than enough)
16:45:32 <rakhmerov> my only concern was if you need it in N-3 or not
16:45:32 <d0ugal> I think that would be fine for TripleO - it isn't actually blocking anything is it rbrady?
16:45:55 <rbrady> d0ugal: nope.  it is not blocking TripleO
16:46:02 <rakhmerov> okay
16:46:23 <rakhmerov> ok, then let's keep discussing and working on it w/o a rush
16:46:53 <rakhmerov> I'll pay more attention to this once I'll unblock my colleagues with performance
16:47:17 <rakhmerov> it should happen soon I believe
16:47:29 <rbrady> ack
16:48:04 <rakhmerov> ok
16:49:08 <rakhmerov> anything else?
16:49:47 <rakhmerov> btw, are there any mysql experts on the meeting? :)
16:50:25 * d0ugal is thankfully not a mysql expert
16:50:30 <rakhmerov> :))
16:51:09 <d0ugal> rakhmerov: Do we define which database versions we support?
16:51:38 <rakhmerov> I'm now deep in all transactional/locking/timeouting/whateverelse stuff and pretty often I lack mysql expertise actually, so I thought if somebody could help with this it'd be great
16:52:36 <rakhmerov> d0ugal: not officially yet, but practically it's mysql (>=5.6) and postgres (~ > 9.2)
16:53:30 <d0ugal> rakhmerov: right, I ask because 5.7 solves https://bugs.launchpad.net/mistral/+bug/1411868
16:53:30 <openstack> Launchpad bug 1411868 in Mistral "list of tasks for an execution from API is out of order" [Medium,In progress]
16:53:42 <rakhmerov> I've been learning about differences between these two for the last month and a half every day and there's such huge gap between them actually
16:53:44 <d0ugal> as far as I can tell, I have not had a chance to test.
16:54:12 <d0ugal> rakhmerov: haha, yeah. I have been a heavy postgres user and mysql confuses me :)
16:54:21 <rakhmerov> I can 100% say that making Mistral compatible with something else would require enormous efforts
16:54:57 <rakhmerov> d0ugal: I think we can pin it to 5.7 and greater
16:55:33 <rakhmerov> d0ugal: well, if you ask me, I don't really understand why mysql is a choice of OpenStack
16:55:47 <rakhmerov> although sometimes ago I had a different opinion
16:56:05 <rakhmerov> I found a crazy amount of things that are completely not supported by mysql
16:56:30 <d0ugal> hah :)
16:56:33 <rakhmerov> maybe I'm misinterpreting though for what use cases mysql has been design
16:56:36 <rakhmerov> designed
16:56:41 <rakhmerov> specifically innodb engine
16:56:52 <d0ugal> It's an interesting beast :)
16:57:13 <rakhmerov> dunno, but yeah... I don't know. I can tell in details what findings I made once we have a chance
16:57:46 <rakhmerov> for example, a simple example: repeatable read transactions in mysql are not true repeatable read :)
16:57:48 <d0ugal> That would be really interesting to hear
16:57:52 <rakhmerov> yeah
16:57:59 <rakhmerov> tons of things, no kidding
16:58:24 <rakhmerov> in some case mysql even doesn't release locks acquired by some TXs after TXs are rolled back
16:58:29 <rakhmerov> it's in their docs
16:58:30 <rakhmerov> :)
16:58:57 <rakhmerov> only 200 TXs maximum waiting for a lock
16:58:58 <d0ugal> :/
16:58:59 <rakhmerov> etc etc
16:59:27 <rakhmerov> ok, again, I'm not a DB expert and may not understand something yet
16:59:42 <rakhmerov> but for some reason, postgres doesn't have all those limitations
17:00:00 <rakhmerov> we have to end the meeting
17:00:05 <rakhmerov> thanks for joining
17:00:05 <rbrady> rakhmerov: do you have a list of the bugs?
17:00:14 <rakhmerov> rbrady: which bugs?
17:00:27 <rbrady> mysql perf
17:00:53 <rbrady> rakhmerov: will ask in #openstack-mistral
17:00:54 <rakhmerov> ooh, no actually, maybe just some of them but I'm not sure
17:01:00 <rakhmerov> yes
17:01:02 <rakhmerov> #endmeeting