16:00:47 <rakhmerov> #startmeeting Mistral
16:00:51 <openstack> Meeting started Mon Jun 29 16:00:47 2015 UTC and is due to finish in 60 minutes.  The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:55 <openstack> The meeting name has been set to 'mistral'
16:03:05 <rakhmerov> anyone here?
16:03:10 <rakhmerov> m4dcoder?
16:03:11 <devkulkarni> hi rakhmerov
16:03:17 <rakhmerov> hi
16:03:19 <rakhmerov> how are you?
16:03:21 <ruhe> o/
16:03:28 <devkulkarni> doing fine
16:03:29 <xylan_kong> rakhmerov: hi
16:03:38 <rakhmerov> xylan_kong, hi
16:04:29 <rakhmerov> ok, let's start the meeting
16:04:37 <xylan_kong> ok
16:04:37 <rakhmerov> the agenda is at: https://wiki.openstack.org/wiki/Meetings/MistralAgenda
16:04:48 <rakhmerov> #topic Review action items
16:05:09 <rakhmerov> there was just one AI
16:05:11 <rakhmerov> NikolayM: discuss yaql 1.0 with Murano team
16:05:20 <rakhmerov> NikilayM, you're here?
16:05:55 <xylan_kong> didn't met him today
16:06:23 <rakhmerov> ruhe, do you happen to know where we are going to have YAQL 1.0 in global requirements?
16:06:37 <rakhmerov> ...where -> when ...
16:06:40 <ruhe> rakhmerov: JFYI the main driver of yaql 1.0 adoption in Murano, Stan Lagun, is currently on a long sick leave, so there was not much progress in this area recently in Murano
16:06:55 <rakhmerov> ooh, ok
16:07:07 <rakhmerov> so we'll keep this AI active
16:07:27 <ruhe> yeah. Murano team keeps this item as a must have in Liberty
16:07:32 <rakhmerov> #action NikolayM: talk to Stan Lagun about YAQL 1.0 inclusion into global requirements
16:07:45 <rakhmerov> ruhe, ok, got it
16:07:48 <rakhmerov> that's good
16:08:14 <rakhmerov> we just wanted to switch to it asap because it's kind of a part of Mistral DSL from a user perspective
16:08:19 <rakhmerov> but that's ok
16:08:40 <rakhmerov> #topic Current status (progress, issues, roadblocks, further plans)
16:08:51 <rakhmerov> let's quickly report our statuses, as usually
16:09:13 <xylan_kong> my status
16:09:21 <xylan_kong> * get rid of openstack/common package, to comply with the whole upstream behavior
16:09:31 <xylan_kong> * fix some bugs and review work
16:09:37 <xylan_kong> * write a proposal for removing utils.wf_trace module
16:10:02 <rakhmerov> xylan_kong, is that openstack/common task considered completed?
16:10:09 <xylan_kong> yes, sure
16:10:17 <rakhmerov> ok, perfect
16:10:45 <rakhmerov> as far as that wf_trace module, what's wrong with it?
16:10:54 <rakhmerov> why do you want to replace it?
16:11:08 <rakhmerov> we might have discussed it with you a while ago
16:11:20 <xylan_kong> it's ok :-) just a little redundant IMO
16:11:20 <rakhmerov> I don't remember though
16:11:43 <rakhmerov> ok, so when are you planning to come up with your proposal?
16:11:52 <xylan_kong> just a little weird we add a module to implement a feature that oslo.log has
16:12:16 <rakhmerov> #action xylan_kong: proposal to replace utils.wf_trace with oslo.log
16:12:28 <xylan_kong> ok
16:12:45 <rakhmerov> ok, I think it's more or less clear, just want to see some details on that
16:12:57 <rakhmerov> my status: implemented "Workflow variables" and released Liberty 1 last week, also discussed and reviewed a bunch of changes with the team
16:13:25 <rakhmerov> I made a mistake with client versioning on Friday so had to fix it today
16:13:35 <rakhmerov> spent a lot of time on that
16:13:43 <devkulkarni> +1 rakhmerov
16:13:54 <xylan_kong> yeah, i notice that, nice work
16:14:25 <rakhmerov> nice work?? you kidding? :) I actually deserve a serious punishment :)
16:14:31 <xylan_kong> we correct it anyway
16:14:43 <rakhmerov> anyway, it's ok now
16:14:47 <xylan_kong> :-)
16:15:01 <rakhmerov> devkulkarni: btw, sorry that I can't catch you in our IRC channel
16:15:02 <devkulkarni> rakhmerov: :) is the new client released to global-requirements?
16:15:11 <rakhmerov> you write usually when I'm asleep )
16:15:40 <rakhmerov> devkulkarni: we need to fix and merge this patch: https://review.openstack.org/#/c/195035/
16:15:52 <rakhmerov> hoping it'll be done very soon
16:15:53 <devkulkarni> rakhmerov: no worries.. I am in US Central
16:15:55 <rakhmerov> 1-2 days
16:16:09 <rakhmerov> yeah, I guess I'm 12 hours ahead of you )
16:16:17 <devkulkarni> rakhmerov: ok, will keep an eye out on it
16:16:44 <rakhmerov> devkulkarni: so do you have a problem because of a Mistral client versioning as well?
16:16:56 <rakhmerov> you're working on solum, right?
16:17:04 <devkulkarni> rakhmerov: I guess so.. I had added an open dicussion item
16:17:09 <devkulkarni> yes, I am part of the solum team
16:17:13 <rakhmerov> ok
16:17:33 <devkulkarni> #link http://logs.openstack.org/17/194817/4/check/gate-solum-devstack-dsvm/309c35e/logs/devstacklog.txt.gz#_2015-06-26_13_33_36_869
16:17:44 <devkulkarni> is this issue similar to what you were seeing?
16:17:51 <rakhmerov> give me a sec..
16:17:52 <rakhmerov> I'll check
16:17:54 <devkulkarni> sure
16:18:06 <xylan_kong> i saw it
16:18:11 <rakhmerov> yeah, exact same issue
16:18:17 <rakhmerov> it should be now ok
16:18:32 <NikolayM> hi everyone
16:18:38 <xylan_kong> NikolayM: hi
16:18:38 <rakhmerov> hey, NikolayM
16:18:42 <devkulkarni> rakhmerov: you mean it should not happen after the above mentioned patch is merged, right?
16:19:03 <rakhmerov> I kept that action item for you about figuring our YAQL 1.0 perspectives
16:19:24 <rakhmerov> devkulkarni: nope, it's not related with that patch
16:19:31 <devkulkarni> oh okay
16:19:35 <NikolayM> my status: Implementing new RPC layer, have an idea to not use pika but use kombu instead (because it is already in global-requirements)
16:19:56 <rakhmerov> it was happenning because of wrong tags in git history
16:20:20 <rakhmerov> devkulkarni: so basically I pushed 1.0.0.0b1 by mistake
16:20:48 <devkulkarni> rakhmerov: ok, got it. and you mentioned you fixed that this morning. got it.
16:20:57 <rakhmerov> then I pushed the right one, 0.3.0 but PBR can't build the project for 0.3.0 if there's a greater version (1.0.0.0b1)
16:21:02 <rakhmerov> yes
16:21:22 <rakhmerov> so, devkulkarni: keep in mind that the right version for the client now is 1.0.0
16:21:22 <devkulkarni> rakhmerov: ok, makes sense. thanks for addressing this issue.
16:21:27 <devkulkarni> yes
16:21:31 <rakhmerov> I sent out the info about that in ML
16:21:37 <rakhmerov> ok
16:21:45 <m4dcoder> hey, Renat. sorry i'm late.
16:21:45 <rakhmerov> devkulkarni: btw, I have a question for you
16:21:50 <devkulkarni> rakhmerov: sure
16:21:54 <rakhmerov> m4dcoder: hey! no problem
16:22:15 <rakhmerov> devkulkarni: does Solum still use Mistral API v1.0?
16:22:25 <rakhmerov> or switched to v2?
16:22:29 <rakhmerov> v2 is the latest
16:22:32 <devkulkarni> I think we are still on v1
16:22:36 <devkulkarni> when was v2 released?
16:22:45 <rakhmerov> pretty long time ago actually
16:22:59 <rakhmerov> the thing is that stable/kilo doesn't support v1 anymore
16:23:11 <rakhmerov> the corresponding code has been removed
16:23:16 <devkulkarni> I see.. I will have to go back and check.
16:23:21 <devkulkarni> oh okay. thanks for the heads up
16:23:35 <rakhmerov> so you may want to check that and let us know, we can help you switch to v2
16:23:40 <devkulkarni> I will get with the solum team to check where we are with it
16:23:43 <devkulkarni> sounds good
16:23:46 <rakhmerov> yeah
16:23:54 <rakhmerov> feel free to ask our help
16:24:00 <devkulkarni> sure thing.
16:24:03 <rakhmerov> deal
16:24:08 <devkulkarni> you guys have been pretty helpful :)
16:24:22 <rakhmerov> you're very welcome
16:24:33 <rakhmerov> m4dcoder: can you print your status quickly?
16:25:00 <m4dcoder> sure. working on the "resume" bp.
16:25:31 <m4dcoder> and then right now just waiting for team to help me with the mysql/psql patch (mysql version and deadlock in scheduler)
16:25:52 <rakhmerov> I see
16:26:07 <rakhmerov> sorry, I didn't read your last email carefully
16:26:12 <rakhmerov> about mysql
16:26:34 <rakhmerov> what I understood from it is that MySQL 5.5 doesn't support even milliseconds
16:26:51 <rakhmerov> but I don't know if we even need them
16:26:57 <rakhmerov> what do you think?
16:27:03 <m4dcoder> looks like it unless i'm mistaken.
16:27:07 <NikolayM> can we use different variants with 5.5 and 5.6?
16:27:30 <NikolayM> say, use fractional secs in 5.6 and do not use if 5.5
16:27:32 <rakhmerov> my whole point is: I'd like to be compatible with other OpenStack projects in that regard
16:27:47 <rakhmerov> NikolayM, yes, something like this
16:28:03 <rakhmerov> I just don't want to lose the ability to work on mysql 5.5
16:28:17 <m4dcoder> i think we do need msec at the minimum unless we have no choice.  we can have actions/tasks launched msec about from each other.
16:28:46 <rakhmerov> otherwise, imagine that we installed OpenStack where all projects are tested agains 5.5 but we'll have to have another mysql 5.6 specifically for Mistral
16:29:20 <m4dcoder> if we are sticking with 5.5, then we will have to change how timestamp is compared in the models.  because right now, the unit tests fail at self.assertEqual(created, fetched) where created has fractional seconds in timestamps.
16:29:51 <rakhmerov> I think it's just a wrong test case
16:31:27 <rakhmerov> ok, m4dcoder, in any case we still owe you a review for your last patch
16:31:53 <rakhmerov> as far as the deadlock, it's one of the things I'm going to tackle this week
16:32:07 <rakhmerov> myself or NikolayM
16:32:17 <rakhmerov> he also knows all the pitfalls
16:32:53 <rakhmerov> #action rakhmerov: check Winson's info about deadlocks occurring in scheduler
16:33:13 <rakhmerov> m4dcoder: btw, does that deadlock only happens with mysql?
16:33:44 <m4dcoder> it happends with psql
16:33:54 <rakhmerov> postgres?
16:34:00 <m4dcoder> postgresql
16:34:01 <m4dcoder> yes
16:34:04 <rakhmerov> ooh
16:34:16 <rakhmerov> msql is fine?
16:34:20 <rakhmerov> mysql
16:34:38 <m4dcoder> i don't recall.  i was testing that mostly on postgresql.  but i can try and let you know later today.
16:34:43 <rakhmerov> it's a usefull info actually
16:34:48 <m4dcoder> ok
16:35:00 <rakhmerov> yeah, the thing is that we run Mistral with mysql all the time and scheduler works
16:35:02 <rakhmerov> ok
16:35:18 <rakhmerov> then can you pls send us your configuration for both Mistral and Postgres?
16:35:30 <m4dcoder> sure i'll sent that to you later today
16:35:50 <rakhmerov> so that we could see all TX properties applied to your operations
16:35:51 <rakhmerov> ok, thanks
16:36:06 <NikolayM> I think it is by the reason of using engine directly in tests
16:36:28 <NikolayM> in tests, we even don't use the engine client but use engine
16:36:54 <NikolayM> and in end of each test we delete all stuff from the DB, right?
16:37:10 <rakhmerov> #action m4dcoder: send conf files for Mistral and Postgres to investigate deadlocks in scheduler
16:37:12 <NikolayM> isn't it a block for DB?
16:38:06 <NikolayM> what do you think, guys?
16:38:10 <rakhmerov> NikolayM: it's supposed to be but if it really happens only for Postgres then I believe Winson's Postgres DB is not just propertly configured
16:38:15 <rakhmerov> as we require in scheduler
16:38:44 <NikolayM> ooh, I guess it also happens for mysql
16:38:54 <rakhmerov> may be
16:38:59 <m4dcoder> If that's the case, then you'll need to provide some instruction on how to properly configure it.
16:39:12 <rakhmerov> m4dcoder: yes, our fault
16:39:33 <rakhmerov> NikolayM: your assumption about not using engine client also looks interesting
16:39:40 <m4dcoder> no one's fault.  just need some clarification and i'm reporting what i'm observing.
16:40:12 <rakhmerov> #info Do we need to use engine client in unit tests instead of engine directly?
16:40:21 <rakhmerov> m4dcoder: yes, sure
16:40:24 <rakhmerov> thanks
16:40:33 <rakhmerov> anyway, I'm sure we'll get it done soon
16:40:41 <devkulkarni> my topic in open-discussion has been already covered. need to run.. signing-off. thanks rakhmerov for the help.
16:40:56 <rakhmerov> it's the interesting and important issue but the fix should be simple
16:41:06 <rakhmerov> devkulkarni: thanks for coming!
16:41:39 <rakhmerov> ok, what else do we have on a plate...
16:41:50 <rakhmerov> #topic Duplicating messages on executors
16:42:17 <rakhmerov> unfortunately, we don't have the author of this topic today with us
16:42:24 <xylan_kong> rakhmerov: what's that mean?
16:42:32 <xylan_kong> do you know that?
16:42:34 <rakhmerov> but I'd like to ask you wether you faced it or not?
16:42:40 <rakhmerov> yeah, xylan_kong, let me explain
16:42:45 <xylan_kong> ok
16:43:27 <rakhmerov> so folks from alcatel lucent (Limor, Moshe, Noa) say that when Mistral engine puts a message into MQ (to run action) then more than one executor can poll it from MQ
16:43:38 <rakhmerov> e.g. 2
16:43:54 <rakhmerov> I don't really know how the heck that may happen
16:44:05 <rakhmerov> but maybe you came across this issue
16:44:09 <rakhmerov> m4dcoder: did you?
16:44:49 <xylan_kong> rakhmerov: i can test it tomorrow with the latest code
16:45:01 <rakhmerov> oooh, wait a second
16:45:16 <rakhmerov> I actually got an email from them with their configuration and topology
16:45:23 <rakhmerov> it says they use QPID
16:45:26 <rakhmerov> not RAbbit
16:45:46 <xylan_kong> i heard from Limor about this issue, but i don't meet in fact
16:46:20 <rakhmerov> ook, looks like it's qpid
16:46:23 <rakhmerov> not rabbit
16:46:23 <xylan_kong> yes, they use qpid, i guess rabbitmq doesn't have this problem
16:46:37 <rakhmerov> yep, then it should be tested with qpid
16:46:54 <rakhmerov> maybe qpid should be tuned somehow, dunno
16:47:24 <rakhmerov> alright, anyway, we could spend some time investigating it
16:47:37 <xylan_kong> i'm not familiar with qpid, are you?
16:47:45 <rakhmerov> I'm not either
16:47:52 <rakhmerov> just heard about it briefly
16:48:14 <rakhmerov> I think it should be rather a BP than a bug though since we've never even thought about using qpid
16:48:17 <xylan_kong> anyway, i will test it again with rabbitmq to ensure it's ok with the latest code
16:48:35 <xylan_kong> maybe
16:49:01 <rakhmerov> well, as far as rabbit we would have noticed that because we run it mostly every day
16:49:19 <xylan_kong> yes, actually
16:49:32 <rakhmerov> what I mean is that we need to aim to make it work with qpid intentionally
16:49:34 <rakhmerov> it's a BP
16:49:59 <rakhmerov> #action rakhmerov: create a BP to make Mistral work with qpid behind oslo.messaging
16:50:34 <rakhmerov> ok, don't know what else to say on this topic
16:50:41 <rakhmerov> needs to be tested and investigated
16:51:10 <rakhmerov> I guess eventually we need to create a new gate that would run functional tests with qpid
16:51:33 <rakhmerov> #topic Liberty-2 planning
16:52:05 <rakhmerov> guys, also I was going to talk about Liberty 2 plans but looks like we're running out of time today
16:52:36 <rakhmerov> so my suggestion is to send a list of BPs and bugs that are most important for you
16:52:53 <rakhmerov> either to myself or even better to openstack-dev
16:53:13 <xylan_kong> ok, no problem
16:53:19 <rakhmerov> so that I could collect them, assign them etc. etc.
16:53:51 <rakhmerov> I, of cource, have a high-level picture but also want to hear from you
16:54:37 <rakhmerov> #action xylan_kong, m4dcoder, NikolayM, LimorStotland: send a list of desired BPs and bugs for Liberty-2 so that we could plan
16:55:03 <rakhmerov> #topic Open Discussion
16:55:16 <rakhmerov> m4dcoder: how is that pause/resume thing going?
16:55:32 <m4dcoder> rakhmerov: i have not seem the problem with multiple executors getting same action from rabbitmq.
16:55:57 <rakhmerov> ok, yes
16:56:29 <m4dcoder> good progress with pause/resume.
16:56:45 <rakhmerov> does that patch on review completes it?
16:56:57 <rakhmerov> you're planning to do something else?
16:57:33 <m4dcoder> however, my colleagues and i are debating (just now) whether we should let users change input data on resume.  the patch was WIP to let dmitri see where i'm at.  no need to review yet.
16:58:01 <m4dcoder> patch is WIP not complete yet.
16:58:21 <rakhmerov> yeah, I know
16:58:28 <rakhmerov> ok, keep us posted please
16:58:47 <rakhmerov> ok, guys, I think it's time to end our meeting
16:58:56 <rakhmerov> thanks a lot for coming!
16:59:00 <rakhmerov> see you next time
16:59:03 <xylan_kong> ok, see you
16:59:05 <rakhmerov> bye
16:59:08 <NikolayM> bye!
16:59:15 <rakhmerov> #endmeeting