17:01:51 #startmeeting CongressTeamMeeting 17:01:53 Meeting started Tue Nov 25 17:01:51 2014 UTC and is due to finish in 60 minutes. The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:57 The meeting name has been set to 'congressteammeeting' 17:02:04 hi 17:03:00 hi 17:03:07 rajdeep: isn't it really late your time? A heroic effort to attend! 17:03:19 banix: hi! 17:03:20 yeah ..it is 17:03:37 somehow made it this time 17:03:59 Hi 17:04:10 I just heard from someone else saying this meeting is at an odd time for them. 17:04:37 Once we get people signed up for blueprints, we'll look into rescheduling to make sure everyone who has signed up can make the meetings. 17:04:47 If that's possible. 17:05:01 Let's start with status updates. 17:05:03 #topic status 17:05:21 sarob: want to start? 17:06:08 Sure 17:06:46 We have a bunch of people that have expressed 17:07:09 The desire to commit code from bp at the summit 17:07:19 Which is awesome 17:07:39 I'm going to work on getting most of them 17:07:54 Attending this meet weekly 17:08:20 And pushing code and reviews weekly 17:08:47 Thinrichs anything for me? 17:09:18 Of the people who said they would push code for the next cycle, how many of them have put their name down on a blueprint? 17:10:21 me :) 17:10:40 We have 9 people assigned 17:10:52 I think it's the right time 17:11:03 To start assigning bp 17:11:24 To those people who have committed 17:11:37 To pushing the code 17:11:48 I'll follow up with them 17:12:15 Do we have timeframes as well so we can assign blueprints to milestones? 17:12:19 And assigning milestones would be helpful 17:12:51 Huawei and Plexxi have 17:13:12 The people who sign up for the blueprint are the ones who can tell us when they can get them done. 17:13:32 Right 17:14:00 We have that with Plexxi, Huawei, hp, Mirantis so far 17:14:25 If possible 17:14:36 Got it. And you're going to follow up with the others. 17:14:38 We should bring up 17:14:54 Which bp need to be done sooner 17:14:57 Than others 17:15:11 Thinrichs right 17:15:38 A preference for which bp get done in kilo 17:15:42 And when 17:15:49 Is good info 17:15:58 If I remember right there aren't so many dependencies. 17:16:18 Hopefully today I'll go through the blueprints, mark the dependencies, and assign priorities. 17:16:28 So maybe just thinking about how many patches 17:16:35 Can be reviewed 17:16:36 (My bad that didn't get done before this meeting.) 17:16:55 And how much testing mods 17:17:05 To support new 17:17:18 Code 17:18:27 Okay, so it sounds like we have some action items for getting blueprints assigned to people and to milestones. 17:18:51 #action thinrichs will add dependencies, priorities to blueprints 17:19:15 I'd like to do a first pass today if you have time 17:19:28 18 dec is looming large 17:19:32 #action sarob will follow up with people who volunteered for work to get estimates for time 17:19:49 sarob: I already volunteered to make a pass today. 17:20:24 Sorry, I'm volunteering to help 17:20:34 Wasn't clear 17:20:47 sarob: got it. 17:21:23 I'll let you know when I make a pass, and then you can take a look. 17:21:30 Cool 17:21:33 I'm done 17:21:39 Thanks! 17:21:59 banix: want to go next? 17:22:18 I know that last time you asked for priorities on blueprints. 17:22:32 And I didn't get that done in time. :( 17:22:56 thinrichs: we are still trying to figure out our priorities with kudva and see how best we can contribute 17:23:17 I had a chat with kudva and rayv last week. 17:23:44 It sounds like rayv is interested in working on policies that define different notions of isolation (e.g. network isolation, compute isolation, etc.) 17:24:17 So it sounds like they've got at least one concrete thing to work on. 17:24:25 I also heard from kudva that he's thinking about delegation. 17:24:45 thinrichs: right, beyond that we have had more discussions to see if we can have a more focused effort 17:25:16 banix: that would be great! 17:25:44 I'd love to see a group of people take ownership of some feature-set or functionality. 17:26:00 Let us know if you'd like to brainstorm. 17:26:09 Or if there's anything else we can do to help. 17:26:18 thinrichs: sounds good. We are a bit slow but we are getting there :) 17:26:24 :) 17:26:59 rajdeep: how are things going for you? 17:27:31 good almost done with horizon integration and reviews 17:27:47 waiting for final approval from janet 17:28:01 Great! Could you remind us what functionality you're adding to Horizon? 17:28:19 rajdeep: i will review it again today 17:29:12 yes integrating datasources details - list of data sources, list of tables in each data source and tuples supported in each table 17:29:40 all this will should in horizon panels 17:29:48 show* 17:30:24 That sounds great! Another thing that would be nice to show in Horizon is the status for every datasource. 17:30:28 Obviously a separate change. 17:30:58 But the status is really useful when you're debugging because it shows the error, if there was one. 17:31:41 ok when you say status it means it is available or not 17:31:53 And we also have the schema for each datasource: the names of the columns for each table. 17:32:23 The status API call returns a dictionary. 17:32:45 I think there are 2 key/value pairs right now: last_updated_time and error. 17:33:29 But that status will be extended over time, so we'd probably just want to display the status as a dictionary (maybe a 2-column HTML table where the left column is the name of the key and the right column is the value). 17:33:41 thinrichs: there's a bug open to split the data source rows into columns https://bugs.launchpad.net/congress/+bug/1379565 17:34:08 rajdeep: do you want to add the status info in your patch, or we can do it separately? 17:34:14 ok will add that after this CL completes it will be another panel / table 17:34:44 jwy : would prefer as a separate patch :) 17:35:06 rajdeep: sure 17:35:07 A separate patch seems good to me too. 17:35:09 i will fix that bug also 17:35:32 rajdeep: i had already started on it 17:35:42 ok.. 17:35:43 jwy: I *think* the rules are formatted when they get returned from the API. 17:36:19 thinrichs: yeah i noticed recently that the rules include newlines when output 17:36:33 need to convert those to breaks 17:36:54 Not sure if that's the ideal way to do it, but it's really easy to do that kind of pretty-printing on the server-side since it already parsed the rules. 17:37:00 hrm i think our api should probably not be doing that on the server imo 17:37:19 i think we should parse the rules but probably not insert the \n's 17:37:26 arosen: then we'll end up writing a parser in the CLI. 17:37:54 We're just returning json thou? 17:38:00 It's much easier to strip the \n than it is to add them. 17:38:10 Yes, we're returning JSON, but rules are strings. 17:38:29 ah okay i see. Yea that's probably fine then sorry. 17:39:03 rajdeep: anything else? 17:39:24 thats it from my side 17:40:14 I can go next. 17:40:19 Great! Horizon is really important and it will become moreso in the not too distant future. 17:40:34 arosen1: okay 17:40:35 So last week we merged a few patches that re-factored the datasource driver base class. One in particular https://review.openstack.org/#/c/135099/ . 17:40:51 This now adds a small requirement on datasource drivers in which they can call self.register_translator(translator). This method ensures that the translator is valid when the datasource driver is loaded. This logic was being handled in convert_obj() before. 17:40:52 17:41:14 In addition, it also allows us to remove the method get_translators() from each datasource driver which was done here: https://review.openstack.org/#/c/135471/ and this now handled via the base class. 17:41:23 I missed something there. 17:41:40 The register_translator is something that you must call for anything to work? 17:41:53 Or…what happens if you don't call register_translator? 17:41:54 thinrichs: no this is called in the __init__ of a datasource driver 17:42:16 thinrichs: for example, here's what had to change for the neutron driver: https://review.openstack.org/#/c/135099/7/congress/datasources/neutron_driver.py 17:42:49 thinrichs: this fixes several things. 1) self.state is populated by register_translator() 17:43:17 also now the base class will know the full schema of a datasource driver when it loads. 17:43:29 What happens if we don't call register_translator in init? 17:43:44 Will it still work but there's no validation performed? Or will it just not work? 17:44:18 thinrichs: one would need to do the validation themselves then. 17:44:52 Doing it this way allows us to have the base class to do all the validation. 17:45:20 and the validation of the translators should only need to be done once on load which is done now if one class register_translator() 17:46:09 thinrichs: alternatively one can call validate_translator() in the base class here (https://review.openstack.org/#/c/135099/7/congress/datasources/datasource_driver.py) if they don't want to call register() though I don't really see any reason why one wouldn't want to use this method. 17:46:37 Got it. Is it also correct to say that if we see that something is missing from the datasource schema that we may have forgotten to call this method? 17:47:20 thinrichs: totally :) that was what happened here: https://review.openstack.org/#/c/136133/ with the servers table that jwy reported 17:48:04 adding tempest tests though for get_schema() will ensure we catch these though in the future. 17:48:17 Maybe we should add a note to our troubleshooting guide. 17:48:29 thinrichs: sure, i can push a patch that does that not a bad idea. 17:48:41 arosen1: anything else? 17:48:43 i'm also planning on rev'ing our writting a datasource driver docs to include this. 17:48:49 nope that's it. Thanks 17:49:05 alexsyip: were you also planning to revise the datasource driver docs? 17:49:21 I did a bit. 17:49:24 It’s on gerrit. 17:49:29 I think I added aaron as a reviewer 17:49:34 ah cool i'll check those out. 17:49:42 thanks 17:49:53 alexsyip: anything to report? 17:50:16 I did a bunch of code reviews. 17:50:43 and I’ve been working on a bug related to a demo. 17:51:02 I ran into some behavior I didn’t understand, maybe aaron can help me with that. 17:51:25 When I restart congress, there are some policy rules that congress loads from somewhere. 17:51:38 But I don’t know where they’re coming from, and I cannot delete them using the CLI tool. 17:52:07 arosen1: Where does the snapshot live? Is it in /etc/congress/snapshot ? 17:52:35 I think this may be a longer conversation than we have time for. 17:52:53 alexsyip: i think that code is stuff that should be removed now that we have a database. 17:52:54 ok, lets move it to the congress irc. 17:52:59 sounds goood to me. 17:53:06 That'd be great! 17:53:17 I want to be sure we get through statuses for everyone. 17:53:32 jwy: how are things going? 17:53:45 all right 17:54:16 jwy: Anything to report? 17:54:29 finished the spec for policy creation in horizon, fixed formatting in the tutorial, made some changes to the congress-specs testing (which needs review btw :)) 17:54:33 did a few reviews 17:55:20 Great! 17:55:23 https://review.openstack.org/#/c/136537/ 17:55:40 that's it 17:55:44 I've been out of action for a while. I'll try to make a round of reviews today/tomorrow. 17:56:00 Did I miss anyone? 17:57:18 Okay 3 minutes for open discussion. 17:57:21 #topic open discussion 17:58:34 Radu_: anything to report this week? 17:59:32 Let's call that the end. 17:59:36 Thanks everyone! 17:59:40 #endmeeting