02:33:43 #startmeeting congressteammeeting 02:33:44 Meeting started Fri Nov 3 02:33:43 2017 UTC and is due to finish in 60 minutes. The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot. 02:33:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 02:33:47 The meeting name has been set to 'congressteammeeting' 02:34:01 hi all! first meeting of the new time! 02:34:18 topics here as usual: https://etherpad.openstack.org/p/congress-meeting-topics 02:34:24 ekcs: hi 02:34:28 hi ramineni_ 02:36:06 ok let’s move along. 02:36:28 why don’t we start with the generic push driver topic 02:36:33 #topic generic push driver 02:36:47 did you put that in ramineni_ ? 02:37:03 ekcs: yes, i just want to understand if there any design discussion happened at PTG 02:37:09 regarding this topic 02:37:53 interested to contribute to the saem 02:39:03 ah. we talked briefly about it. but didn’t necessarily make a lot af progress. 02:39:21 the main difficulty in figuring out and deciding how to specify the schema. 02:39:46 oh , ok .. yes , 02:40:11 1. does the schema get fixed on datasource instantiation? or can congress deal with unfixed schema (probbaly not, but haven’t looked deeply)? 02:40:41 ekcs: first option looks feasible , specifying while datasource create 02:40:48 ekcs: ok, then let me think about it more and get back to u 02:40:53 2. if the schema gets fixed on datasource instantiation, how does that get accomplished? specified in in driver config? 02:41:03 yea that’s the line we were going down. 02:41:10 sounds great! 02:41:27 do you have case in mind that’d want to use the generic driver? 02:42:20 ekcs: yes, its useful when some moitoring tool sends event to congress , 02:42:35 right now , schema is fixed , cannot be used by every monitoring tool 02:42:49 so thought generic would be ideal way 02:43:45 got it. that’s great. hope we can make good progress this cycle then. let me know if you think it should move up in priority. 02:44:08 ekcs: sure, thanks 02:44:44 weird got disconnected. 02:44:45 anyway anything else on this topic? 02:44:55 ekcs: no, we can move on 02:45:03 ok. 02:45:07 #topic gate status 02:45:40 we kept having one issue after another that blocked gate for a while. we finally have a clear gate now. the replicated non-voting jobs are still having issues. 02:45:59 ekcs: i checked the same yesterday 02:46:13 i too havent found any difference between normal/replicated 02:46:35 only difference found is the path in log file 02:47:21 yea I see the discussion going on there but I haven’t read Andreas Jaeger’s comments. 02:47:34 hopefully we can figure it out soon. 02:48:03 ekcs: but should we merge it , before replicated gets fixed? 02:48:23 ekcs: it used to work fine before migration, may be issue with job configuration file? 02:48:45 or recheck should work :) 02:49:27 otherwise patch looks good to go 02:49:49 I’m not sure what we should do. So far I’m leaving it outstanding while we work on it because it may get more attention that way. 02:50:17 ekcs: ok 02:50:18 yes it worked on jenkins. 02:50:52 but when infra people converted jenkins jobs to legacy zuulv3 jobs somehow the replicated things all stopped working in that very weird manner. 02:51:30 and this patch is meant to simply move the legacy zuulv3 jobs from infra repo to congress repo. 02:51:32 https://review.openstack.org/#/c/509697/ 02:51:33 patch 509697 - congress - Migrate to Zuul v3 02:51:51 ekcs: ya , hopefully infra guys should be able to help, as the failure is in devstack cloning only 02:51:53 My hope is that we can also figure out how to write the job differently to have working replicated jobs. 02:52:47 yea I’ve been busy with other things like summit but if we ping them over ML or IRC we’ll probably get some help. 02:53:16 ekcs: ok, ill check with infra guys 02:53:51 we can also decide just to merge and work on it later. another step after that is converting these legacy jobs to new zuulv3 jobs. so it cuold also make sense to solve the problem then. 02:53:56 got it thanks! 02:54:26 #topic ceilometer driver 02:54:42 another thing we had to do to unblock gate is remove ceilometer driver from tempest tests. 02:54:49 it’s part of this patch https://review.openstack.org/#/c/515212/ 02:54:50 patch 515212 - congress - Fix test mocking and disable ceilometer tempest test (MERGED) 02:55:11 because v2 api has been deprecated and is now finally removed by ceilometer. 02:55:43 one thing we need to decide is what to do with ceilometer driver. 02:55:51 ekcs: oh, i didnt notice that 02:56:01 so is there v3 api or anything? 02:56:24 basically whether we want to make a version based on ceilometer v3 api or not. 02:56:28 I’m assuming there is. checking now. 02:58:06 it’s weird I don’t see v3. 02:58:19 ya , me too, let me check on that :) 02:59:36 https://review.openstack.org/#/c/512286/ 02:59:37 patch 512286 - ceilometer - Remove Ceilometer API (MERGED) 02:59:51 maybe the entire ceilometer API is deprecated. like in the future there is simply no ceilometer API. 03:00:32 ok here it is: https://docs.openstack.org/releasenotes/ceilometer/ocata.html 03:01:02 Ceilometer API is deprecated. Use the APIs from Aodh (alarms), Gnocchi (metrics), and/or Panko (events) 03:01:21 ekcs: oh, ok got it 03:01:31 So I guess the first step for us is just remove ceilometer driver for Queens release. 03:02:01 Then we can decide whether to add Gnocchi and Panko drivers. 03:02:02 ekcs: ya, respective data , we should get from diffrent projects 03:02:19 great good to have that figured out. 03:02:35 ok I don’t have anything else planned to discuss. 03:02:53 anything else we want to talk about? 03:03:29 pacthes? 03:04:03 #topic patches 03:04:18 sure any patches we want to discuss? 03:04:22 https://review.openstack.org/#/c/516631/ 03:04:23 patch 516631 - congress-dashboard - List rules for library policies 03:04:48 do u think adding would help more readability , because formt rule is from befoer , i didnt change existing behaviour 03:05:54 oh I see. well I’d prefer to have small indent for readability. but it’s not a big deal either way. 03:06:22 when I worked on a similar thing on server side I added a two-space indent and it seemed to work well. 03:06:30 it is used by plicies tab already , just moved its place to common so that library policy 03:06:41 also can use that function 03:07:04 I see. you can make the call. I was just suggesting. 03:07:06 ok, if you think more readable that , we can add the same on gui as well 03:07:16 ekcs: ok 03:07:39 ekcs: https://review.openstack.org/#/c/516842/ 03:07:40 patch 516842 - congress - Make include rules configurable from API 03:08:19 its fairly trivial change , i havent thought perormance issues or anything , its from usability perspective , if user doesnt to list rules, he should have option 03:08:44 otherwise i dont have more comments on that patch 03:09:44 got it. 03:10:04 I’m pretty much in the middle on this issue. 03:10:37 on one side, I always prefer to minimize things we promise to support long term by exposing in API. but in this case it’s pretty small. 03:11:04 its already supported in code , i dont think we change that , its also trivial change 03:11:16 u can take call 03:11:59 I feel like the option is not really NEEDED, because it’s easy enough to ignore a field in API return. usability to me isn’t a huge issue especially because API is usually consumed by program not human. 03:12:14 but it’s small enough I can go either way. 03:12:22 but i think this change is more useful in get_items because ight now api call throws clutter of information by including rules 03:13:08 instead all programs make changes , its better to support in API 03:13:45 I see right I wasn’t thinking about get_items. I only was thinking about get_item. 03:14:00 I think you can make the call because you’re actually using the API for something. 03:14:13 you have more context on what’s helpful to consumer. 03:14:24 i dont think list policies , will always require , to show rules , they just want to see policies , like horizon does 03:15:07 showing rules is unnecessary in more places, if user doesnt require, i think we should support it 03:15:12 I just want to point out that in general, having something implemented in code is different from exposing something through API. We can change the code whenever we feel like, but exposing through API means a promise and commitment to long term support. 03:15:33 great 03:16:13 in this case the extra support we promise is very small and especially in the list case I’d agree it’s outweighed by usability. 03:16:49 ekcs: great, 03:17:01 will make the changes 03:17:10 awesome. 03:17:43 ekcs: have a good time at summit 03:17:47 no meeting next week right 03:17:50 yups. 03:17:52 oh 03:18:17 I’m available for meeting. not sure about masahito. 03:18:36 I was going to keep it anyway. but we can also cancel. 03:18:41 ekcs: im available, not going to summit this week 03:18:47 thsi time ** 03:18:58 ekcs: let me know if you plan to cancel 03:19:27 ok then. i’m expecting to have meeting. 03:19:50 anything else to discuss today? 03:19:59 ekcs: no , done from my side 03:20:22 ok i don’t have anything either. 03:20:31 let’s end meeting then. have a great weekend! 03:20:48 ekcs: bye 03:20:54 bye! 03:20:56 #endmeeting