21:01:14 <mestery> #startmeeting crossproject 21:01:14 <openstack> Meeting started Tue Aug 11 21:01:14 2015 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:16 <tpatil> Hi 21:01:19 <openstack> The meeting name has been set to 'crossproject' 21:01:23 <elmiko> o/ 21:01:24 <SergeyLukjanov> o/ 21:01:27 <mestery> #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting Agenda 21:01:27 <loquacities> o/ 21:01:34 <kzaitsev_mb> o/ 21:01:36 <boris-42> hi 21:01:36 <mestery> Looks like a fair bit of carry over from last week and some Open Discussion is in order for today 21:01:55 <Rockyg> o/ 21:01:56 <mtreinish> o/ 21:02:06 <mestery> #info Meeting Chairs needed for September 1, September 29, and October 13 21:02:13 <mestery> Signups appreciated! 21:02:22 <johnthetubaguy> o/ 21:02:49 <mestery> #topic Horizontal Team Announcements 21:03:02 <mestery> Anyone have anything today? 21:03:07 <david-lyle> o/ 21:03:17 <david-lyle> just here, nothing to add 21:03:27 <mestery> david-lyle: :) 21:03:53 <hogepodge> o/ 21:03:56 <Rockyg> how about a reminder of the ops midcycle next week? 21:04:03 <mestery> Rockyg: Please, #info it! :) 21:04:18 <Rockyg> OK, lemme get the info again... 21:04:28 <mestery> Rockyg: Thank you 21:04:44 <mestery> Rockyg: I believe it's next week, but would be great to get it officially into here :) 21:05:34 <mestery> OK, while we wait for Rockyg, lets move on in the agenda 21:05:36 <Rockyg> ok. There's also the Product wg right after. I'm on that page, so that one first... 21:05:43 * mestery waits 21:06:15 <Rockyg> ok. There's also the Product wg right after. I'm on that page, so that one first...WG midcycle 8/20-21 at Cisco, San Jose 21:06:52 <Rockyg> link to etherpad: https://etherpad.openstack.org/p/productwg-liberty-midcycle-meetup 21:06:58 <mestery> #link https://etherpad.openstack.org/p/productwg-liberty-midcycle-meetup 21:07:33 <mestery> OK, now lets keep rolling 21:07:41 <mestery> #topic API Guildelines Ready for Final Review 21:07:49 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071791.html More Details Here 21:07:52 <Rockyg> #info Operatortor Midcyle: 8/18-19 in Palo Alto, CA 21:07:57 <elmiko> not much to say here, please review =) 21:08:07 <mestery> elmiko: lol :) 21:08:12 <mestery> elmiko: I'll add the links at least 21:08:15 <mestery> #link https://review.openstack.org/#/c/186526/ 21:08:19 <elmiko> i think 21 of these is a rework that got passed back after the first go around 21:08:22 <elmiko> er 1 21:08:27 <mestery> #link https://review.openstack.org/#/c/181912/ 21:08:30 <mestery> #link https://review.openstack.org/#/c/181784/ 21:08:31 <elmiko> thanks mestery ! 21:08:36 <mestery> elmiko: No worries. 21:08:48 <mestery> #info Review of these is encouraged by all cross project people! 21:08:50 <Rockyg> Thanks elmiko and mestery 21:09:01 <mestery> Any other comments on these API reviews by anyone? 21:09:29 <elmiko> they are planned to merge next tuesday, aug 18 if no comments are received by then 21:10:09 <mestery> #info These API reviews are expected to merge by August 18 if no comments are received by then 21:10:27 <mestery> Thanks elmiko! 21:10:27 <mestery> Moving along in the agenda 21:10:37 <mestery> #topic Return request-id to caller 21:10:39 <mestery> #link https://review.openstack.org/156508 21:10:45 <tpatil> As per Doug's suggestion we have subclassed tuple and it’s possible to store request_ids in tuple object 21:10:48 <mestery> I believe this was discussed last week, the spec is still open 21:10:57 <mestery> tpatil: Very nice! 21:10:57 <tpatil> Also, we have fixed all Brant’s review comments and uploaded new PS for review 21:11:05 <tpatil> For consistency purpose request_ids attribute of type “list” is added to all types of return values 21:11:06 <mestery> tpatil: I see that, nice work 21:11:15 <tpatil> Another question 21:11:19 <tpatil> In the last meeting, there was discussion to mark oslo-incubator as private 21:11:26 <tpatil> I want to understand what changes are required for marking oslo-incubator.openstack as private 21:11:39 <tpatil> for example, when syncing oslo-incubator.openstack with python-glanceclient, it should be synced as glance client._openstack and wherever python modules from openstack package are imported it should be refactored to the new path. correct? 21:12:08 <johnthetubaguy> tpatil: thats what I remember folks suggesting 21:12:15 <tpatil> ok 21:12:19 <tpatil> So, these changes needs to be done in all python-*clients using oslo-incubator/openstack code which seems to be a big activity. 21:12:27 <tpatil> IMO, these changes should be done in a separate new blueprint or should we include these changes in our specs? 21:12:36 <johnthetubaguy> the key bit was so python-*client users didn't think that stuff was a stable interface by accident 21:12:44 <mestery> johnthetubaguy: ++ 21:13:22 <johnthetubaguy> tpatil: its maybe worth adding in the spec, as its how this common code will get imported, so it feels part of the same effort 21:13:43 <tpatil> johnthetubaguy: OK, we will add it to the specs then 21:14:05 <mestery> Awesome 21:14:07 <tpatil> That's all I wanted to update at this point 21:14:12 <mestery> Thanks tpatil! 21:14:27 <mestery> And that brings us to 21:14:27 <mestery> #topic Open Discussion 21:14:37 * mestery thinks we may finish this meeting in record time today 21:14:39 <kfox1111> I've got 2. 21:14:44 <mestery> kfox1111: Shoot! 21:15:01 <kfox1111> one's quick. Please review: 21:15:01 <kfox1111> #link https://review.openstack.org/#/c/186617 21:15:10 <kfox1111> could use more eyes, and it seems dead in the water. 21:15:22 <kfox1111> number 2. 21:15:29 <kfox1111> Question for the individual ptl's out there. I'm working on the app-catalog project, trying to increase the contributions. Its been hard due to lack of features from a lot of the individual projects. 21:15:40 <kfox1111> Reviews seems to be one of the main capitals in OpenStack, but the number of reviews seems to only count within a project? How does one gain capital to get faster reviews when your time is spend fixing issues across lots of different projects? 21:15:57 <mestery> kfox1111: Excellent question 21:16:33 <kfox1111> don't need an answer right now. just something to think about. :/ 21:16:36 <johnthetubaguy> kfox1111: we are totally not doing many nova-spec reviews right now, we are focused on code reviews right now 21:16:41 <mestery> kfox1111: One way is by building that capital with people who cross between projects (if that makes sense) 21:17:22 <kfox1111> johnthetubaguy: Yeah, I realize that. Not singling out nova in particular. there's other cases. 21:17:27 <mestery> kfox1111: But I see your point with the challenges of working across this 21:17:29 <kfox1111> mestery: ah. interesting. 21:18:13 <johnthetubaguy> kfox1111: its no worries, just right we are generally ignoring everyone, so its not personal as such 21:18:37 <johnthetubaguy> cross project stuff is hard right now 21:18:41 <kfox1111> for example, unit testing. each project requires it for a patch, and each does it diferently, and worse, each has changing requirements not documented in existing code. so you copy an existing test, tweak it, and its not acceptable usually. 21:18:47 <johnthetubaguy> this meeting is the place to get traction I guess 21:19:31 <mestery> johnthetubaguy: ++ 21:19:32 <kfox1111> johnthetubaguy: Yeah. understood. just wanted to raise the topic so we could think about how to make it easier to deail with features that need to cross projects. 21:19:35 <johnthetubaguy> kfox1111: yeah, I think we agreed on mock vs mox in a cross project sense, was that what you mean? 21:19:42 <gordc> kfox1111: what are you doing that spans different projects? 21:20:09 <elmiko> i've had the best success reaching out to projects individually, usually by pestering people in irc. it's very time consuming though 21:20:12 <gordc> i'd say getting buy in from individual projects hopefully gets you a resource there to either help or guide you. 21:20:36 <kfox1111> gordc: trying to smooth off the rough edges between projects so you can write generic heat templates for example. 21:20:55 <kfox1111> right now, its very difficult to make a truely cloud scale app that is generic enough to put in the app catalog. 21:21:32 <kfox1111> part of the problem is, most projects push back and say "why is it our projects issue" its the users problem. 21:21:56 <kfox1111> the problems tend to exist in the bounderies between projects when you use them together. 21:22:03 <johnthetubaguy> kfox1111: so this will sound familiar, but did we ever got to the bottom of the discussion with keystone about the instance user thing, I remember discussing this late one day in IRC 21:22:22 <johnthetubaguy> kfox1111: honestly, I think adhoc meeting between all the parties in IRC is the way forward with this 21:22:39 <johnthetubaguy> but adhoc, I mean arranged by email 21:22:43 <kfox1111> johnthetubaguy: I think the barbican/keystone folks are on board with the current spec. I think its the nova freeeze that's stalled it now. 21:22:45 <mestery> One suggestion is to try and put these types of things on the cross-project meeting agenda 21:22:51 <mestery> And make sure it's early enough so it's announced 21:23:04 <mestery> Also, johnthetubaguy's idea is good as well 21:23:06 <kfox1111> johnthetubaguy: yeah. could be. or the summit. I'm still trying to arange to get there. 21:23:29 <kfox1111> mestery: Ok. sounds good. 21:23:39 <johnthetubaguy> kfox1111: the summit is often the best way, but its best to have the discussion started before then anyways, we are getting there 21:23:46 <Rockyg> kfox1111, if it's a user issue, maybe you can have a usercommittee slot in the summit, but grab project devs 21:24:13 <johnthetubaguy> kfox1111: to be clear, there is no freeze on specs right now, mitaka has been open for a week or two now, just we don't have anyone who is free to review the specs 21:24:43 <kfox1111> Rockyg: sounds doable. Part of the issue too is definitions. In my world, cloud application developer != user. while in most openstack projects they are treated the same. And that's lead to some issues. 21:24:44 <johnthetubaguy> kfox1111: thats in the nova sense, and I know thats not very helpful right now :( 21:25:24 <kfox1111> johnthetubaguy: thats an ugly situation. :( I understand though. 21:25:36 <Rockyg> kfox1111, this could also be good for the Ops "burining Issues" session at the midcycle. That tends to get devs' attention 21:25:49 <johnthetubaguy> kfox1111: we need more reviews, if you spot any hanging around, do send them my way :) 21:25:55 <kfox1111> Rockyg: hmm.. good idea. thanks. 21:25:58 <johnthetubaguy> I mean reviewers 21:26:13 <kfox1111> johnthetubaguy: will do. :) 21:26:41 <johnthetubaguy> kfox1111: I think the key issue was mapping the per instance cert to some user, I need to sync up to work out where that got to 21:27:06 <kfox1111> johnthetubaguy: I think that parts all done. I think the outstanding issue 21:27:25 <kfox1111> is how to verify the vm is the one that should get the cert. 21:27:34 <kfox1111> in the most recent iterations, that changed a lot. :/ 21:27:57 <kfox1111> I'd really like nova's perspective on that bit. since it was influenced by nova's reviewers a lot once they finally started reviewing. 21:28:08 <johnthetubaguy> kfox1111: yeah, we don't really have anything to do that in Nova right now 21:28:35 <kfox1111> can we prioritize it for when reviewers free up? :) 21:29:31 <johnthetubaguy> kfox1111: so in all honesty, all my reviewer are likely to be slammed until liberty-3 is tagged, at this point, at that point I hope to assign priorities to specs, this is an important ish one (medium ish) 21:29:49 <kfox1111> ok. good enough. Thanks. :) 21:30:05 <johnthetubaguy> kfox1111: remind me I said that the week after liberty-3! 21:30:12 * kfox1111 chuckles 21:30:15 <kfox1111> will do. :) 21:30:30 * kfox1111 edits his calendar.... 21:31:35 <Rockyg> Speaking of liberty-3 and deadlines and foci, I wanted to remind PTLs and other dev types of the China Bugfest next week. 21:31:57 <mestery> #info China Bugfest is next week, reminder for PTLs for reviews 21:31:57 <mestery> Thanks Rockyg 21:32:10 <Rockyg> https://etherpad.openstack.org/p/2015_8_Prc_Hackthon 21:32:30 <mestery> #link https://etherpad.openstack.org/p/2015_8_Prc_Hackthon 21:32:34 <Rockyg> That etherpad also has space for a list of bugs you want them to focus on. Hint, hint 21:32:35 <mestery> Thanks Rockyg! 21:33:12 <mestery> Anything else this week from anyone before we close up shop? 21:34:08 <mestery> OK, thanks everyone! 21:34:11 <mestery> See you all next week! 21:34:13 <mestery> #endmeeting