16:00:11 #startmeeting Mistral 16:00:12 Meeting started Mon Feb 16 16:00:11 2015 UTC and is due to finish in 60 minutes. The chair is NikolayM. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:15 The meeting name has been set to 'mistral' 16:00:21 hi everyone! 16:01:16 anyone else here? 16:01:58 hi. 16:02:25 hi dzimine 16:02:36 hey 16:02:49 ok, let's start 16:02:59 Renat is absent today 16:03:06 yes 16:03:12 #topic Review Action Items 16:03:26 1. rakhmerov, dzimine: capture everything in blueprints 16:03:52 not yet done on my site :( 16:04:00 will complete this week. 16:04:08 ok 16:04:19 I just leave new AI :) 16:04:41 #action rakhmerov, dzimine: capture everything in blueprints 16:04:55 2. rakhmerov, dzimine: review existing bugs and assign them to the scope 16:05:11 It seems it's done 16:05:34 3. rakhmerov: talk to solum folks (Roshan) and find out what version of Mistral they depend on 16:05:51 ooh, I forgot to ask Renat about it 16:06:03 he's not around, I gather? 16:06:10 Renat didn't talk about it on our sync-ups 16:06:40 #action rakhmerov: talk to solum folks (Roshan) and find out what version of Mistral they depend on 16:06:54 yes, we didn't hear from him about it 16:06:56 probably he forgot about it 16:07:19 4. all: think if we need to keep v1 code base 16:07:56 I guess StackStorm guys ready to drop v1 16:08:30 And since we don't know how about Solum, leave this action item on next meeting. 16:08:53 #action all: think if we need to keep v1 code base 16:09:22 #topic Current status 16:10:00 let's tell about our progress 16:10:08 my status: 16:10:26 worked on YAQL expressions and its escaping 16:11:25 I am working on OpenStack actions simple integration tests 16:11:53 and did some research about keystone/trusts, how we can do heat/mistral integration. So, created new thread in ML: "How trusts should work by design?" 16:15:02 the next topic is kilo-3 planning 16:15:26 #topic Kilo-3 planning 16:16:34 We need to redesign our engine 16:17:07 it is a big work and Renat already started on it 16:17:34 sorry I had to step out. 16:17:58 back now. 16:18:12 We think about how to share this work between us 16:18:26 the engine redesign? yes. 16:18:32 yes 16:18:47 And it seems it will take a lot of time to do it 16:19:16 NikolayM, we want to add 'action handler', am I correct ? 16:19:28 so, we can't do some too serious things to kilo-3 16:20:20 no, AFAIU we want to add something like on_action_result 16:21:01 On my side: we got strong negative feedback from the field on our changes to YAQL syntax. The crux of the problem is quoting expressions the ansible way like "{1+1}" is confusing, but not quoting it is impossible as {} are core YAQL syntax symbols (dictionary). 16:21:13 so, we will add ActionExecution model and Task will be compound thing 16:21:41 dzimine, yes 16:21:53 let's discuss this 16:21:57 dzimine, we are thinking about other syntax 16:22:05 I spoke to Renat on this and we realized that we can't continue using YAML syntax for expressions no matter what others (salt, ansible) do. 16:22:12 I know we want to change YAQL syntax 16:22:41 The proposal on the table now is to change {1+1} to <% 1 + 1 %> and it solves a bunch of problems. 16:22:47 And I heard you suggested the syntax like <% %> 16:22:53 I am preparing email to the thread. 16:23:27 dzimine, why did you choose such syntax ? 16:23:30 The reason for this particular syntax is our target user's familiarity: many of them do Puppet and Chef and it's common Ruby pattern one sees in Puppet and Chef. 16:24:21 <% %> construction look not good, what about discussion on other syntax? 16:24:26 the critera for the choice is "plays well in YAML" and "target users are familiar / seen that before " 16:24:50 as for me it looks familiar with xml/html 16:25:12 old JSP also used this. and Ruby. 16:25:33 2 symbols is cool but percent sign is too big for perception 16:26:06 too big for perception - what do you mean? 16:26:25 percent sign is just too big 16:26:45 and overall structure become x2 bigger 16:27:42 visually? 16:27:42 I like something like , I know that it is too big, but as for me it is clear for undestanding 16:27:50 dzimine, yes 16:28:31 we considered HEAT/TOSCA approach for this using functions: similar to what akuznetsova mentioned ^^ 16:29:30 but it seem to get messy when doing complex yaql in combinations with string building and other parameters. 16:29:39 looks better than with % but too long 16:29:48 the two symbols solve the problem of escaping. 16:30:30 Here is the thing: when you or I look at the problems, we look at them differently when the guys whom we want to use this thing. 16:31:16 So it's interesting to listen field folks on what they like/not like. 16:31:31 That's why most of Mirantis products are pretty good: they grew out of the field use. 16:31:47 Mistral - not yet, we just began deploying it to customers. 16:31:58 And their complains are pretty .... unexpected. 16:32:30 I was arguing for Ansible syntax for over an hour, wanted to keep "{1+1}" 16:33:10 but they explained to me why it was confusing to them, on examples. 16:33:11 I also agree we don't use {} due to YAML constraints 16:33:37 the way to come to agreement is to arrive at criteria, and rank the criteria. 16:33:49 That's why I think criteria #1 is "YAML friendly". 16:33:55 #2 is "familiarity". 16:34:44 yes 16:34:45 and there's more in this "familiarity": a number of engines already use {{ or <% so they figured that it's safe to parse / escape / etc. 16:35:07 We need to think about it carefully 16:35:36 it's ok if we invent somethign new, but say if we only do < and > than we need to begin worrying about the other meanings of the symbols, escaping the greater than and less than signs. 16:36:06 But that the guys still find it confusing: say "I don't know the meaning of < > when I see them in a large expression. 16:36:38 We discussed just < and > but all these questions came up. 16:37:31 By now I think <% is a good syntax: not visually as nice as NikolayM pointed out but quite distinct and once we get used to it will be ok. 16:38:19 do bring alternatives but please do find something familiar. 16:39:16 And BTW we need this change ASAP: our recent changes with turning YAQL with "{1+1}" are breaking existing workflows. 16:39:22 so we don't want to break once, than again. 16:40:01 ok 16:40:41 dzimine, let's take a meeting with Renat and discuss all variants 16:40:55 ok. 16:41:08 I'll start a thread on openstack-dev, too. 16:41:35 ok, I also will take part in 16:42:23 anything else to discuss? 16:42:30 we can do like php injection) 16:42:41 yes we can I think. 16:42:59 but again, when you look at your target users, assume they do php? 16:44:25 no 16:46:03 well, if we have no more to discuss, let's wrap up 16:46:49 we'll discuss our new YAQL syntax in ML and (I think) in skype/hangouts with Renat 16:46:58 ok. 16:47:05 thanks all! Till than! 16:47:16 bye dzimine! 16:47:22 bye all 16:47:48 #endmeeting