08:04:35 <d0ugal> #startmeeting mistral
08:04:35 <openstack> Meeting started Fri Jun  1 08:04:35 2018 UTC and is due to finish in 60 minutes.  The chair is d0ugal. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:04:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:04:38 <openstack> The meeting name has been set to 'mistral'
08:05:17 <d0ugal> Friday office hour!
08:05:20 <d0ugal> Hows everyone doing?
08:05:36 <d0ugal> rakhmerov, apetrich, bobh, mcdoker181818: PING
08:05:44 <rakhmerov> I'm here
08:05:51 <d0ugal> https://etherpad.openstack.org/p/mistral-office-hours
08:05:51 <rakhmerov> but don't have much to update with )
08:05:56 <d0ugal> As usual, add your name to the ping list on line 16 if you want reminders ^
08:06:00 <rakhmerov> btw, I'm on vacation next week
08:06:01 <d0ugal> rakhmerov: sure, that is fine :)
08:06:37 <d0ugal> Nice :)
08:06:47 <d0ugal> Are you going away somewher?
08:07:09 <rakhmerov> yeah
08:07:11 <rakhmerov> Turkey
08:07:22 <d0ugal> oh, nice and warm I bet.
08:08:21 <d0ugal> rakhmerov: did you manage to resolve the tripleo gate failure?
08:08:32 <rakhmerov> not yet
08:08:45 <rakhmerov> I added a debug line to see what I'm dealing with
08:08:57 <rakhmerov> I thought I fixed it but it occurred again
08:10:05 <rakhmerov> d0ugal: but it seems as if TripleO took an old yaml_dump() function
08:10:11 <d0ugal> oh, strange
08:10:13 <rakhmerov> not likely, I understand though..
08:10:14 <rakhmerov> yeah
08:10:30 <d0ugal> Could be possible, but I'm not sure how :)
08:13:14 <apetrich> o/
08:13:45 <d0ugal> rakhmerov: Can you set the Importance on https://bugs.launchpad.net/mistral/+bug/1774164 ?
08:13:47 <openstack> Launchpad bug 1774164 in Mistral ""Create execution" API request may lead to creation of more than one workflow execution object" [Undecided,Confirmed]
08:14:02 <rakhmerov> yes
08:14:02 <d0ugal> It is our only untriaged bug :)
08:14:59 <d0ugal> opetrenko_: Are you around? Did you want to chat about EBNF?
08:16:10 <opetrenko_> yes, want to chat about all the staff that can help newcomers quickly take apart mistral
08:16:37 <d0ugal> staff? do you mean stuff?
08:17:24 <rakhmerov> :))
08:18:12 <d0ugal> I am not very familiar with EBNF. I have never written it before at least, just read it a few times.
08:19:16 <opetrenko_> Yeah, stuff :)
08:20:37 <opetrenko_> I would like to document mistral dsl as detailed as possible
08:21:28 <d0ugal> Yeah, that makes sense
08:21:37 <rakhmerov> opetrenko_: usually EBNF is requested by someone who wants to write a parser for a language
08:21:53 <rakhmerov> why do you think you need EBNF to understand the Mistral workflow language?
08:22:02 <d0ugal> I wonder if we could generate something
08:22:21 <rakhmerov> I think the spec is pretty detailed. Although I agree that there are some gaps
08:22:46 <mcdoker181818> Hi, all. Please take a look https://review.openstack.org/#/c/499790/ and https://review.openstack.org/#/c/569643/
08:23:03 <opetrenko_> Probably, if we describe our dsl, adding new abilities to it will become much easier I guess
08:23:38 <d0ugal> It does change sometimes, but not very often now.
08:25:49 <opetrenko_> Well, if you think it's not needed it's ok. We can just skip this topic.
08:26:01 <d0ugal> I'm not sure we need EBNF exactly
08:26:17 <d0ugal> However I do think a better description of the syntax would be useful.
08:26:28 <d0ugal> I found it difficult originally and relied on looking at examples.
08:26:30 <rakhmerov> opetrenko_: well it's kind of nice to have it (and I thought about adding it at some point) but haven't seen strong reasons so far
08:26:40 <rakhmerov> d0ugal: yes
08:26:43 <rakhmerov> agree
08:27:56 <opetrenko_> So we can discuss what should be documented
08:28:31 <d0ugal> EBNF has a very specific purpose and it is good for that, but I don't think it will be easy for most new users to understand.
08:28:37 <d0ugal> Are there any alternatives?
08:31:32 <rakhmerov> d0ugal: yes, I think you're right :) From what I've seen, only computer science guru ever look at it )
08:32:19 <rakhmerov> so generally, we have a task to improve our doc and it also includes improving the language spec
08:32:25 <d0ugal> Yeah
08:32:47 <rakhmerov> we know that it has a number of issues: gaps, not the same style everywhere, not the best structure etc.
08:33:03 <rakhmerov> but someone needs to volunteer to fix it at the end of the day )
08:33:18 <d0ugal> Indeed
08:33:46 <opetrenko_> agree
08:34:20 <opetrenko_> We can restructure our docs to make them more structured and verbose
08:34:45 <d0ugal> Fixing the documentation is difficult.
08:34:54 <rakhmerov> yeah
08:35:12 <d0ugal> I have been trying to think of a prgamatic way to start working through it, but I don't have any great ideas.
08:35:20 <d0ugal> We have a legacy documentation problem, it is hard to refactor :)
08:35:29 <rakhmerov> the challenge is that it doesn't make a lot of sense to fix individual sections, we rather need to look at the docs as a whole and restructure it first
08:35:40 <rakhmerov> and come up with the unified style etc.
08:35:54 <d0ugal> rakhmerov: You were going to write a guideline for that style.
08:35:56 <opetrenko_> We would rather not refactor our docs but write new one
08:35:58 <d0ugal> :)
08:36:04 <rakhmerov> no, not for that style :)
08:36:26 <rakhmerov> I was going to write a guideline for coding style )
08:36:54 <opetrenko_> We can discuss the structure of docs, than create skeleton and after that fill out everything as verbose as possible
08:37:09 <d0ugal> opetrenko_: true, do you want to propose a structure? :)
08:37:25 <rakhmerov> opetrenko_: that may be a good idea. Write a structure of the new doc first, then start moving individual sections into it step by step applying the new rules
08:37:39 <opetrenko_> Wow, not so fast)
08:37:44 <d0ugal> rakhmerov: for code style, I wish we just used Black https://pypi.org/project/black/) and then didn't have to worry about code style!
08:37:50 <d0ugal> lol
08:37:53 <rakhmerov> opetrenko_: what do you mean by "as verbose as possible"?
08:38:04 <d0ugal> brb
08:38:17 <d0ugal> "as detailed as possible" perhaps
08:38:33 <rakhmerov> I mean "can you give an example where our docs are not verbose enough"?
08:39:06 <opetrenko_> I mean that we should write our docs the way that student of 3rd year comes looks at it and will understand how he can use it
08:39:13 <opetrenko_> afk for 5 mins
08:39:26 <rakhmerov> d0ugal: I'll look at Black, may be it's ok
08:40:18 <rakhmerov> opetrenko_: the goal is good, yes. Agree. I just found that the idea of the project itself is often hard to explain
08:40:23 <rakhmerov> not even to students
08:41:12 <rakhmerov> anyway, we've always had this idea in mind too. And we've actually improved docs significantly over the last 1-1.5 years
08:41:40 <rakhmerov> so we keep improving it but yes, I agree, we need to restructure it soon
08:42:21 <d0ugal> I keep wanting to propose a new documentation structure
08:42:26 <d0ugal> but never get to doing it
08:47:10 <opetrenko_> I have an idea
08:47:50 <opetrenko_> Lets keep the structure of documentation that way
08:49:13 <opetrenko_> The first topic is quick overview of the project. Idea, purpose of the project. Some examples of what can you do with mistral, with some aka screenshots of results.
08:49:49 <opetrenko_> Next, we provide topics for each group of users. For devs, operators etc
08:50:06 <d0ugal> Yup
08:50:20 <d0ugal> We have talked about this a few times - we just need somebody with the time and motivation to do it :)
08:50:52 <opetrenko_> The first thing we should describe it the overview of the project. It can help encourage new user, devs  to participate in life of mistral
08:51:42 <opetrenko_> IMO, the second thing should be dev guide. It's the crucial part to devs
08:52:17 <opetrenko_> If you come to project and cant get an idea of what's going on there, you are 50% to leave the idea to join
08:52:24 <d0ugal> Sure
08:52:48 <d0ugal> I think we all agree the documentation can and should be better.
08:53:10 <d0ugal> The question is, how do we start working on it instead of just talking about it?
08:53:15 <opetrenko_> The dev guide should contain architecture of the project, explanation of project structure
08:53:16 <d0ugal> and who can do the work?
08:53:42 <opetrenko_> I can try, but I'll need a lot of help, because I'm not familiar with mistral yet :)
08:53:53 <d0ugal> Right
08:54:03 <d0ugal> but being new also gives you a better insight into the problems.
08:54:21 <opetrenko_> Yeah, that's why I started doc topic
08:54:45 <d0ugal> I think the first step is for somebody to try writing a documentation outline
08:55:00 <d0ugal> What sections there should be and what should be in them
08:55:09 <d0ugal> Then we can discuss that and hopefully agree on a structure
08:55:24 <opetrenko_> Yeah I can try do this, but still need some help from you guys
08:55:28 <d0ugal> Sure
08:56:02 <opetrenko_> So where should I start describing skeleton?
08:56:51 <opetrenko_> probably some visualization feature can help in that
09:01:02 <opetrenko_> maybe we can try out some conference tool with ability to speak, make remarks and draw
09:02:02 <d0ugal> opetrenko_: usually when we want to propose larger ideas like this we would propose a patch to the mistral-specs repo
09:02:07 <d0ugal> https://github.com/openstack/mistral-specs
09:02:18 <d0ugal> and then the discussion would happen via gerrit and code review.
09:03:46 <opetrenko_> ok
09:06:33 <d0ugal> #endmeeting