16:00:35 #startmeeting Mistral 16:00:36 Meeting started Mon Sep 8 16:00:35 2014 UTC and is due to finish in 60 minutes. The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:39 The meeting name has been set to 'mistral' 16:00:41 hi 16:01:26 hi 16:01:28 hello) 16:01:50 let's wait for others a little bit 16:02:11 hi! 16:02:38 hi 16:02:44 ok, let's start 16:03:36 #topic Action Items 16:04:15 we didn't actually have action items for the last week except the same ongoing thing related to discussion different workflow types 16:04:40 one thing that Fuel folks want us to do is implement a workflow type based on task priorities 16:05:09 Hard priorities or weighting? 16:05:12 Just curious 16:05:13 it's when basically we specify a bunch of tasks with priorities and Mistral figures out the order of execution 16:05:21 hi all. 16:05:46 bhavenst, it's just a general idea 16:05:50 Sounds pretty non-deterministic 16:05:52 cool 16:05:56 details are to be discussed :) 16:06:16 most likely next week I'll be able to tell more exactly 16:06:28 when I get familiar with what they do in Fuel 16:06:32 hi Dmitri ) 16:06:40 ok, so let's move on 16:06:57 #topic Current status (progress, issues, roadblocks, further plans) 16:07:18 let's quickly report everyone's status 16:08:16 Started looking into our (Ericsson) blueprints for mistral. Haven't managed to discuss w/ author, but found a little more doc. Have a few questions and plan to discuss a bit today. 16:08:26 my status: designed how policies and engine instructions (like 'pause', 'fail') should work, made a bunch of changes related with policies, a lot of bug fixes and reviews 16:08:50 I have written suite of integration tests for CLI v2, i'm planning to stark working on test for API v2 16:08:57 bhavenst, cool, I included a topic about that, we'll get to it 16:09:02 great 16:09:34 akuznetsova, were you able to find out what the problem was with v2 tests? 16:09:46 'no reply on topic..' thing 16:10:05 <_nmakhotkin> last week I finished work on client v2 and CLI 16:10:24 rakhmerov, me not, Nikolay can tell more about it 16:10:41 <_nmakhotkin> also I implemented policies: wait-before, wait-after and retry 16:10:57 ok 16:11:21 rakhmerov, I asked _nmakhotkin to help me and he said that he knows what the problem is 16:11:25 _nmakhotkin, can you briefly tell about that? Do we know exactly what happens? 16:11:53 <_nmakhotkin> fake rpc_backend doesn't work as expected 16:11:59 <_nmakhotkin> only in engine v2 16:12:05 do we know how to fix it? 16:13:42 _nmakhotkin? 16:13:55 <_nmakhotkin> not yet, but we'll find a way to fix it 16:14:10 ok 16:14:20 I hope there's nothing serious 16:15:11 dzimine, all client related patches have been merged in 16:15:23 good. 16:15:24 can we borrow Kirill for a couple of days now? :) 16:15:43 later this week, yes. 16:15:48 ok 16:16:04 #topic Release 0.1 progress (go through the list of what's left) 16:16:34 https://launchpad.net/mistral/+milestone/0.1 16:16:53 this is a page with information about the release we're now working on 16:17:21 basically, the only thing we haven't touched so far is https://blueprints.launchpad.net/mistral/+spec/mistral-engine-instructions 16:17:33 which is on me, I'm planning to start working on it tomorrow 16:17:48 it should take about two days 16:18:15 <_nmakhotkin> I forgot to say - guys who work on UI for actions/tasks ask me today and they need endpoint for actions 16:18:35 and the second one which we've only scratched a little bit is https://blueprints.launchpad.net/mistral/+spec/mistral-ui 16:18:51 hopefully, it won't take too long as well 16:19:41 _nmakhotkin, I've already made some changes related to this. May be I'll do it tomorrow, it should take about an hour or less 16:20:13 <_nmakhotkin> yes :) 16:20:26 <_nmakhotkin> just for information 16:20:37 anyways, we can spread it between two of us so that everything is ready by the moment Kirill starts working on UI changes 16:20:43 will I have enough time to test it? cause i've never seen our ui ) 16:20:56 :))) 16:20:58 sure 16:21:30 it's good 16:21:39 so the overall picture now is that we're mostly on target with the release 16:22:21 but I assume we may not be able to finish everything up 16:22:41 by the end of the week 16:22:59 mostly I mean some docs, all the testing, maybe small bugs 16:23:18 so it may take 2-3 days longer 16:23:21 <_nmakhotkin> .. and demo :) 16:23:51 yeah 16:24:30 on REST API/Client/CLI I guess the only thing that left is actions, correct? 16:24:40 _nmakhotkin, akuznetsova? 16:24:52 <_nmakhotkin> yes, correct 16:25:00 rakhmerov, "maybe small bugs" - you are optimistic) 16:25:12 :) I am 16:26:00 #action rakhmerov, nmakhotkin, enykeev: Add action into REST API/Client/CLI 16:26:33 Nikolay, did you have time to look at action params etc.? 16:26:40 you know what I mean.. 16:27:19 so that we could see some info on actions when we type 'mistral action-list' or more specifically 'mistral action-get nova.servers_get' for example 16:27:57 <_nmakhotkin> yes, I try to do it 16:28:02 info about their parameters and, if possible, short description taken from docstrings 16:28:04 <_nmakhotkin> maybe tomorrow 16:28:07 ok 16:28:34 <_nmakhotkin> Merlin guys also asked me about it ) 16:28:52 #action nmakhotkin, we should see action parameters and description (if possible) when calling API 16:29:02 yeah, Timur asked me about that too 16:29:23 otherwise, it will be a nightmare to work with all this huge number of actions 16:29:34 we should be able to help somehow 16:29:40 do what we can do 16:29:58 ok, workflow policies are mostly done, right? 16:30:13 btw, folks from Fuel asked us about one more policy 16:30:17 _nmakhotkin, will we have filters in actions? for example mistral action-list type=nova ? 16:30:21 which should be pretty simple to implement 16:30:25 timeout 16:30:40 akuznetsova, yes, good call 16:30:47 currently they're not implemented 16:30:50 oh yes, timeout as a task policy, especially on async tasks. 16:31:00 dzimine, yep ) 16:31:21 it actually escaped from my head somehow even though it's very important 16:31:44 <_nmakhotkin> if we want it, it will be 16:31:49 _nmakhotkin, is it the same like tags in workflow/workbook? 16:32:07 i mean implementation 16:32:14 #action nmakhotkin, enykeev: Implement filters on REST API endpoints which work with multiple items (such as /tasks, /workbooks etc.) 16:32:33 no, it's not really the same 16:32:57 tags are not used anywhere now 16:33:17 <_nmakhotkin> we can use tags in our UI 16:33:24 but I see what you're going to akuznetsova 16:33:30 ...where... 16:33:34 yep 16:33:48 and potentially we can do filtering based on them too 16:34:00 a little bit different type of filtering 16:34:07 rakhmerov, should i create a blueprint for filters or it is part of some existing? 16:34:27 well, I guess it should be a part of existing BPs 16:34:29 I suggest a blueprint - so we can prioritize it. 16:34:33 but let's check real quick.. 16:34:54 no, it's not a part of BPs 16:35:05 akuznetsova, can you create it for us pls? 16:35:18 dzimine, agree 16:35:39 yes, sure 16:35:44 thanks a lot! 16:36:17 so other than that I think we're good 16:36:46 except Nikolay found some bugs with action/workflow parameters 16:36:51 not even bugs 16:37:06 we just need to do some enhancements 16:38:07 #action nmakhotkin, rakhmerov: make it possible to use different data types in action/workflow params (None, False/True, numbers, expressions) 16:38:19 ok, we have about 20 mins left 16:38:38 guys, I included an item to discuss Metrics Collector BPs 16:38:45 let's switch to it now 16:39:28 #topic Metrics collector BPs 16:39:53 so basically we have two BPs: 16:39:57 1. https://blueprints.launchpad.net/mistral/+spec/mistral-metrics-collector 16:40:06 2. https://blueprints.launchpad.net/mistral/+spec/mistral-metrics-collector-api 16:40:36 submitted by folks from Ericsson 16:41:31 The idea seems to be pretty interesting to me and I think at this point we could let Bryan (or anyone else) start working on them 16:42:08 so I would ask all of you to take a look at them, leave your comments/remarks/questions 16:42:18 Yeah, would definitely appreciate that 16:42:56 the main thing here is to stay consistent with the rest of the system in terms of design, terminology etc. 16:43:06 The way it's written, it would persist nothing in Mistral db, but use Ceilometer for that. So that's one question I have. 16:43:11 if that's best 16:43:13 I got the general idea but I think we just need to polish details 16:43:28 ok 16:43:33 sounds good to me 16:43:36 And then architecture of either a) fixed set of measurements or b) some way to create custom measurement 16:43:56 and finally for API, should there be a new endpoint or put it on top of the existing endpoints 16:44:38 yes 16:44:51 at this point I see it as a new endpoint 16:44:56 OK 16:45:25 I think it makes sense to separate this because it's sort of special functionality 16:45:33 reporting 16:47:02 which may not be even related with individual objects but rather providing averages and other integral (not sure it's the right word :) ) information 16:47:15 so I'm 99% sure it should be separate 16:47:48 as far as set of measurements it's a little hard to tell now 16:48:35 I would suggest that we start digging into that first and may be create some more detailed spec (a simple etherpad would be fine) 16:48:54 with description of what exactly we're going to implement 16:49:23 OK will do 16:49:45 and then let our imagination do a job of improving, polishing and making it more flexible etc etc 16:49:50 Like I said, I'll talk to the author as well. It's mostly obvious but maybe he can give some more details regarding intended purpose etc 16:49:54 Sounds good 16:50:01 btw, https://blueprints.launchpad.net/mistral/+spec/mistral-items-filtering 16:50:12 ok, thanks :) 16:50:26 bhavenst, you mean Sergey? 16:50:32 yeah exactly 16:50:36 is he from Ericsson too? 16:50:39 Yes 16:50:45 ok 16:51:00 He might have had an @conceptwave.com mail address or something earlier, but Ericsson now. 16:51:40 Oh I see was @gmail 16:51:45 yeah, he's in our project 16:51:47 #action bhavenst: start working on Metrics Collector, the first step is to make the requirements more detailed and capture them in a specification document (e.g. etherpad) 16:52:31 btw, there are other folks who asked us about similar thing 16:52:38 from Rackspace 16:53:01 it was one of their major requirements for some reason ) 16:53:22 but it was around 10 months back when we just started the project 16:53:29 ok good to know 16:53:33 yeah 16:53:55 btw, I can actually share a document they've written with you 16:53:58 I guess they didn't formulate any 16:54:00 oh great 16:54:07 it was a detailed whitepaper 16:54:23 Then I can try to merge the two as part of the action pt 16:54:26 but I have to ask their permission first though 16:54:28 sure 16:54:31 no problem 16:54:42 yes, merging I think is a good idea 16:56:03 from my perspective, I don't clearly see how it should be integrated with Ceilometer 16:56:47 but I'm not a Ceilometer expert, I just may need to digg some info on that 16:57:03 or we could discuss it either personally or in IRC 16:57:15 I have to dig into it as well :) 16:57:21 :) 16:57:24 it's normal 16:57:29 OpenStack is huge 16:57:32 almost endless 16:57:36 We have one of the core ceilometer folks here in E/// so can talk to her too 16:57:45 great 16:58:16 ok, bhavenst, please keep us posted on this work and feel free to ask anything you want 16:58:18 will do 16:58:19 thanks 16:58:31 we have a couple of 'ceilometer' guys in our location (me and _nmakhotkin ) 16:58:42 ok, good to know! 16:58:53 ooh, you know Ceilometer well? 16:59:10 ok, we've almost done here hah? ) Have to free the room 16:59:10 me - no) i know who knows 16:59:18 ooh, alright 16:59:21 ok, guys 16:59:28 thanks for coming! 16:59:30 <_nmakhotkin> bye! 16:59:33 bye 16:59:33 bye 16:59:34 have a good one ) 16:59:37 same to you 16:59:39 bye 16:59:45 #endmeeting