14:01:07 #startmeeting monasca 14:01:08 Meeting started Wed Jul 12 14:01:07 2017 UTC and is due to finish in 60 minutes. The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:12 The meeting name has been set to 'monasca' 14:01:30 o/ 14:01:36 o/ 14:01:39 o/ 14:01:43 o/ 14:01:44 hello 14:01:55 fujitsu's power :D 14:01:55 o/ 14:01:58 o/ 14:02:02 oh...not entirely ? 14:02:07 https://etherpad.openstack.org/p/monasca-team-meeting-agenda 14:02:13 hi everyone 14:02:39 unofrtunately, i'm going to have to drop off shortly 14:03:33 #topic Monasca fails to meet Pike release goals 14:03:52 https://governance.openstack.org/tc/goals/pike/index.html 14:04:02 ok, I can go through this I guess 14:04:04 so, this sounds like a but of work 14:04:25 recently I managed to make monasca-notificiation 14:04:28 thx kornica 14:04:49 so apart from api (which is a real monster...) and agent (for which we need to agree on just one thing) 14:04:53 everything is I guess green 14:05:04 for notification and transform we need to make gates green 14:05:18 and there's also idea from monasca-transform guys to run tempests under Py3 14:05:28 but that requires having all APIs Py3 compatible 14:05:36 which is a case only for log-api 14:05:43 i had started work on the api, and agree it was more complicated than i originally thought 14:05:54 i believe others had looked at this too 14:06:15 I've tried carrying on in this change > https://review.openstack.org/#/c/349195/ 14:06:36 but despite all the eforts everytyhing keeps going south around expressions and sqlalachemy 14:06:37 parts 14:07:19 not to mention that green Py27 does mean all is as it was...tempest gate is failing 14:07:44 so, unless we get more people into this, I strongly doubt api will meet the goal 14:07:48 there is also monasca-ui which still doesn't has python 3 support 14:07:53 ah, right 14:07:55 that to 14:07:56 thx 14:08:03 we have a story for that: 14:08:07 https://storyboard.openstack.org/#!/story/2000975 14:08:09 thx witek 14:08:15 totally forgot about that 14:10:49 so, it would be great to get some hands on ui and api, right? 14:10:55 and review notification 14:11:21 from my POV, yeah, +1 14:11:27 +1 14:12:53 we don't have that much of menpower (or manpower :/) to keep all covered :(...for api it was just me and some of my free time (same as for other components I took care of) but other stuff comes up and might be that this api won't reach py3 14:13:19 is there someone from HPE that could sit to this maybe ? maybe stratch from scratch, I don't know :/ 14:14:43 i'm not sure there is 14:14:53 i'm wondering about the suse folks 14:14:56 i can check with them 14:15:11 former hpe folks 14:15:50 while there are hpe folks still working on monasca 14:16:12 the problem is getting resources on the upstream related issues 14:16:15 like CI 14:17:51 i'm going to have to drop folks 14:18:00 got to take my dad to airport 14:18:09 didn't realize that needed to be now 14:18:22 ok...anyway, there's just one thing that you could look after 14:18:36 ok, see you next time 14:18:38 I guess I will need PTL+1 for project-config change to move Py35 to voting 14:18:40 please end the meeting later 14:18:43 thx witek 14:18:45 that'd be all from my side 14:18:46 thx 14:18:50 cya 14:19:14 #topic reviews 14:20:01 https://review.openstack.org/#/c/479169/ 14:20:24 ok , so this is me and Tomasz 14:20:29 yeah, for that we'd need rhochmuth :/ 14:20:37 yeah 14:20:56 hopefully he'll read log later and see that cry out for help ^^ 14:21:08 but if anybody else is interested this is a first step for monasca-events-api, cleaning the repository 14:21:09 this change prepares infrastructure for the restart of the events-api 14:21:21 and CI tooling 14:21:31 well...that infra..I guess 14:22:19 anything else on it? 14:22:35 not really...bunch of deletes and couple additions 14:22:42 exactly 14:22:55 https://review.openstack.org/#/c/482443/ 14:23:02 during testing failing py{27,35} and cover are expected, so don't bother with them 14:23:10 they will kick in once there is actual codebase 14:23:18 this is a first draft of new events-api 14:23:37 providing new edpoint with body schema and response codes 14:24:25 nice, the api-ref will be published to developers.o.o, right? 14:24:34 that's the goal 14:24:38 yep 14:24:43 once we clean the repo 14:25:09 arturb_ will, I guess push to project-config to have the same gate situation (apart from tempest) 14:25:14 as in log-api 14:25:31 for now there is only one resource? 14:25:31 14:25:40 an endpoint ? 14:25:48 kornica yes this is the plan after merging the change with clean up the repository 14:25:59 arturb_, what about endpoints ? 14:26:03 just one for start? 14:26:18 there is only one endpoint for start 14:26:26 for colecting events in a bulk mode 14:27:04 might be good idea, to either try and see if specs are still used (there are jobs to build those) or mark that part of api-ref as spec 14:27:09 with the rst note or something 14:27:19 witek, any thoughts on that ? 14:27:38 guess we didn't really reach any agreement on specs for new API endpoints... 14:28:11 we can switch on the infra jobs and then we'll see if they published correctly 14:28:31 they will be published as long as setup is correct 14:28:44 point is that, what arturb_ is doing, is more or less just a spec 14:28:53 drafting new feature 14:29:13 I think it's OK to start like this 14:29:29 arturb_ also starts implementing, right? 14:29:53 yeah, today i started implementing oslo.policies 14:30:21 the change is in review but still a lot of work 14:30:29 https://review.openstack.org/#/c/482837/ 14:30:32 this is the change 14:30:47 if someone has ideas how the events api for collecting notifications should look like, it's good time to review the spec 14:31:19 it would be nice :) 14:31:44 can we move on? 14:31:53 witek, yes we can 14:31:57 https://review.openstack.org/480160 14:32:26 yeah, so that was mentioned before 14:32:38 requires testing inside local VM I guess 14:32:46 as there re no integrating tests for that part 14:32:53 (might be good idea to have them added) 14:33:15 would you like to add some? :) 14:33:35 I can try 14:33:42 actually that's not all that bad 14:33:45 the idea 14:34:05 I think I can start small with simple alarm def, send some metrics and expect that mailbox contains the email 14:34:28 though I am not really sure if I should setup some fake mail server (which will require a lot of work) 14:34:38 or just try and access /var/mail 14:34:46 keep it simple 14:35:03 kiss 14:35:13 forgot stupid 14:35:14 :D 14:35:20 :) 14:35:32 https://review.openstack.org/482892 14:35:35 ok, but does that mean 14:35:43 that we're waiting with this 14:35:50 or manual testing and going further 14:35:50 ? 14:36:18 do you want to add the test, or you don't have time? 14:36:36 I can add the test, but I'd consider that as much have for now 14:36:42 I'm fine with leaving it as is 14:36:49 mailing part (or rather notifying part) and lack of integration tests 14:37:00 is not just a problem of monasca-notification 14:37:48 so we could have it talked over but looking at this change as Pike goal, I'd ask to just review that by hand 14:38:00 works for me 14:38:26 ok then 14:39:08 https://review.openstack.org/482892 14:39:17 jenkins -1 14:39:24 now it isn't :P 14:39:30 (just wait 2-3 minutes) 14:39:37 forgot to remove sth from one plae 14:39:40 :) 14:39:42 s/plae/place/g 14:40:07 ok, will give +1 14:40:18 thx 14:40:32 https://review.openstack.org/#/c/480030/ 14:40:51 in overall same thing as already done for log-api 14:41:08 adding tooling needed to start working monasca-api docs in the same format as in log-api 14:42:05 so what documents would be published? 14:42:20 api-guide 14:42:25 user (developer) docs 14:42:27 api-ref 14:42:29 releasenotes 14:42:47 as far as I checked that's the overall approach for Openstack 14:43:03 looked for specs, but core projects seems not to have them anymore in trees 14:43:35 what is the difference between api-guide and user (developer) docs? 14:44:10 user (dev) docs goes as far as to installing, configuring, dev + review process 14:44:18 some sample code 14:44:28 some project wide policies regarding different activities 14:44:53 so basically, landing page for the project, right? 14:45:21 like here: https://docs.openstack.org/neutron 14:45:22 while api-guides are some sort of an overview (as far as I understand them) regarding usage of api 14:45:28 yeah, like landing page 14:45:37 might be actually the best way to describe it 14:46:08 i am not a monasca folk, but i can comment on doc-migration 14:46:14 yeah ? 14:46:20 amotoki: yes please 14:46:22 the role of user/ or other directories are described here http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html#proposed-change 14:46:56 user/ is for end-users of monasca in your case. 14:47:21 hmmm...might be that we good initial idea for us wrong ? 14:48:21 if you haven't visit the doc-spec, it is better to read it first :) 14:48:32 I mean...is api-guide something that should be covered inside doc/* 14:48:53 for the api guide, it is not in the first step of the doc-migration. 14:49:00 it is an option. 14:49:48 the api guide is optional. IIUC, the API reference is highly recommended (though it is not a part of doc-migration) 14:50:23 you can have the api-guide either in doc/ or in a separate dir. 14:50:23 that's nice feedback on that for sure 14:50:23 so, the new place for API ref is doc/source/api, right? 14:50:58 you can see "Further discussion of the layout of the api/ and releasenotes/ directories is deferred until we are farther along with the initial migration work. " as a note. 14:51:28 so I think that doc, api-ref and releasenotes can stay as it was 14:51:32 currently we don't start the migration of the API reference into doc/ yet. 14:51:36 kornica: exactly 14:51:42 until there's an agreement how to do this 14:52:00 but the point that bugs me is we really need seperate api-guide and seperate jobs 14:52:07 or should the ontent of it be merged into doc/ 14:52:20 we haven't started working on that part 14:52:30 but now I have doubts is it really needed 14:52:55 kornica: I think API guide and API reference are different. 14:53:03 right? 14:53:20 yeah, they are 14:53:36 api-ref is more or less a documented restful api as far as I understand :D 14:53:42 api-guide is though a different beast 14:53:46 for API guide I think having it in doc/ makes things simpler. 14:54:23 witek: guess we'll talk this through and see if that's actually a point of interest for us to have it 14:54:26 for API ref, it currently uses a different sphinx config, so it might be better to have it separately ATM 14:54:42 might be as amotoki says, to have it inside doc/ 14:54:58 kornica: yes 14:55:23 what we definitely should do, is to convert the existing documentation to rst 14:55:32 and publish to docs.o.o 14:56:13 ok, so we'll move as we were with filling doc/ and api-ref (if needed) leaving api-guide in peace for now 14:56:20 fine with that ? 14:56:49 kornica: I guess will still have to discuss it 14:57:02 kk 14:57:14 anyway, amotoki really appreciate the input 14:57:25 kornica: you're welcome 14:57:31 amotoki: thanks a lot 14:57:55 #topic Documentation [monasca-log-api] live 14:58:49 just some live examples ;-) 14:58:51 apart from the fact that there are many empty pages, I like it a lot :) 14:58:57 phew :D 14:59:53 also, I guess the most information should be included in monasca-api and has reference to monasca-log-api 15:00:08 I guess we have to end here 15:00:16 bye everyone 15:00:29 cya 15:00:32 #endmeeting 15:00:37 bye 15:30:45 ttx: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 15:30:56 #endmeeting ?