16:02:11 #startmeeting oslo 16:02:12 Meeting started Mon Apr 6 16:02:11 2015 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:16 The meeting name has been set to 'oslo' 16:02:16 sorry, local distraction 16:02:19 np 16:02:24 :-) 16:02:27 o/ 16:02:28 our agenda: 16:02:28 #link https://wiki.openstack.org/wiki/Meetings/Oslo 16:02:28 courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka, zzzeek, sileht, kgiusti, dansmith 16:02:28 courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith 16:02:29 o/ 16:02:35 o/ 16:02:36 hi 16:02:36 o/ 16:02:38 o/ 16:02:47 o/ 16:02:47 o/ 16:02:48 yo yo 16:03:00 o/ 16:03:14 good turnout today :-) 16:03:15 o/ 16:03:21 #topic Review action items from previous meeting 16:03:35 thanks to dims for running the meeting last week 16:03:51 looks like there were 2 actions: 16:03:52 #info dims to find schedule for session planning 16:04:01 #info zzzeek to add oslo.db enginefacade to nova agenda - https://etherpad.openstack.org/p/liberty-nova-summit-ideas 16:04:18 dims: did you see ttx's email to the list about session planning? 16:04:48 #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/060503.html 16:04:54 thanks dhellmann 16:05:02 there's a wiki page mentioned there, https://wiki.openstack.org/wiki/Summit/Planning 16:05:09 and I added our etherpad to that page today 16:05:44 I see the enginefacade mentioned on line 17 of the nova etherpad, so I think both items are done 16:05:44 dhellmann: do they ask us how many slots we need? 16:05:55 dims: ages ago, when we first started putting our list together 16:06:14 :) 16:06:18 unfortunately our list grew beyond the number of slots at the time, which was an optimistic number. We can negotiate with ttx to see how many we can get 16:07:16 quotas would be real nice to talk about (as a group/community) 16:07:41 harlowja_at_home: at this point I think the consensus is we need a quota project, rather than a lib, because there's a database component 16:07:56 harlowja_at_home: nova folks had a lot of feedback from ops folks recently about quota issues 16:08:02 ya :) 16:08:07 I agree it would be good to discuss, though. Maybe we can find a way to set up a new project slot 16:08:12 where are quotas implemented now? 16:08:20 well i'm not so much concerned about it technically honestly; it just requires a crap ton of cooridation 16:08:26 people seem to think keystone should own it for whatever reason. 16:08:35 harlowja_at_home: yeah, I just meant it wasn't going to be an oslo problem :-) 16:08:37 ^ and the coordination/reviews/chopping up code is the hardest part (not imho the solution) 16:08:38 bknudson: nova has an impl 16:08:53 dhellmann, agreed ; it can't really be an oslo thing 16:09:06 cool, so let's move on then 16:09:15 #topic PTL election 16:09:27 bknudson, at this point i'd rather anyone own it and there be a common API.... (i don't care anymore if its keystone, boson, blahblah project) 16:09:29 nominations are now open for PTL election 16:09:35 I sent email announcing that I'm not running 16:09:41 I saw a nomination from dims 16:09:42 and the world shed a tear 16:10:00 dhellmann: Whaaaat!?! 16:10:10 and jungleboyj shed a tear 16:10:10 I think nominations end this week, let me find the date 16:10:24 :-) 16:10:28 #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/060472.html 16:10:45 jungleboyj: I'm not going anywhere, but I want to give others a chance to lead 16:10:59 yep, nominations are open until the 9th 16:11:26 gooooo dims :) 16:11:29 dhellmann: Cool. 16:11:32 u da man 16:12:14 yep, I have no doubt dims will do a great job 16:12:24 Agreed. 16:12:42 thanks dhellmann harlowja_at_home jungleboyj 16:12:45 :) 16:13:17 #topic Red flags for/from liaisons 16:13:37 I've been out for about a week, but didn't see any major issues come up while I was gone. Did I miss anything? :-) 16:13:42 None for keystone. 16:13:44 * jungleboyj doesn't have anything right now. 16:13:51 not afaik 16:14:07 maybe we need a library for lazy imports 16:14:15 everyone's complaining about it. 16:14:24 I am going to have to think more about Liberty at this point for Cinder. 16:14:45 bknudson, i start wonder if its just a python upstream issue though; idk 16:15:00 they said the same stuff about php (and it has a bunch of caching now to be better at it) 16:15:02 bknudson: maybe we should just be smarter about where we put the imports in our code? 16:15:32 harlowja_at_home: python caches imports, too, so I think these are cases where we're importing code that is never actually used 16:15:43 *expensive* code -- common stuff like stdlib modules doesn't really matter 16:15:47 dhellmann, k; then i guess its just smarter usage 16:15:49 jungleboyj: understandable 16:16:12 dhellmann: then it becomes an issue of code readability if you're spreading imports all over rather than at the top of the file. 16:16:14 harlowja_at_home: yeah, it would be interesting to see how far we can get with that approach 16:16:27 bknudson: true 16:16:56 I looked for a lazy import lib and didn't see anything that looked good. 16:17:06 * stevemar sneaks in late 16:17:55 bknudson: I'm reluctant to do any hacking on such a fundamental part of python's behavior, but I'm curious to see what you have in mind 16:18:29 bknudson: only when we know we have a lot of issues in certain code paths...like rootwrap - https://review.openstack.org/#/c/170851/ 16:18:46 right? 16:18:50 we've got a LazyImporter now in keystoneclient: http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/__init__.py#n52 16:19:24 sure, but how do you know when there's issues and how do you ensure that they don't come back accidentally? 16:19:31 can we write tests for import time? 16:19:32 doesn't python 3 have a whole bunch of improvements to the importer (or i thought it did); hmmm maybe soem of that got backported? 16:19:48 harlowja_at_home: there were changes/improvements but afaik they were not backported 16:19:53 bknudson: true 16:19:55 dhellmann, k 16:20:18 seems like it's really easy to reintroduce a slow import. 16:20:31 bknudson: performance tests can look at things like startup time, and the work boris-42 and dims did exposed the issue in rootwrap 16:21:36 so that's something to keep thinking about, but I don't think we're going to solve it today 16:21:40 #topic Ongoing work & Review priorities 16:21:47 I backported the performance fix in oslo.policy: https://review.openstack.org/#/c/170863/ 16:21:51 That should only need one other core reviewer, as a backport 16:22:00 dhellmann, thanks for that 16:22:14 It looks like there was some discussion of backports last week while I was out. Do we have others we need to propose? Do we have anything that needs to be released? 16:22:33 I don't have +2 on stable branches. 16:22:41 stevemar: np at all 16:23:11 bknudson: I think there's a separate stable maint team for oslo, but not per library. I'll fix that for policy. 16:23:23 #action dhellmann set up stable-maint teams for oslo repos, esp. policy 16:23:53 unless we want to just add people to the existing team, I guess? 16:24:15 who does the release of stable olso.policy? 16:24:27 I can do that, when we're ready 16:24:39 I think anyone who can already do releases can release from any branch 16:25:04 dhellmann, yes, that's correct 16:25:17 actually... 16:26:11 dims, sileht: did we have any messaging backports? I'm thinking of that heartbeat fix 16:26:42 stevemar: I know I can do them, because I have, but I'm on all the acl lists so I don't know which lets me do it :-) 16:26:53 looks like there are individual release groups for each project 16:27:10 ah, yes, we did set that up for a lot of the libs 16:27:20 not the stable teams, though 16:27:21 dhellmann: i think we released everything we needed (cc sileht) 16:27:30 dims: great! 16:27:51 dhellmann: there was a log issue with a review this morning, we may want that one 16:28:01 s/with/in/ 16:28:07 dims: ok, I missed that, do you have a link handy? 16:28:20 digging 16:28:59 #link https://review.openstack.org/#/c/170856/ 16:29:50 for the stable maint issue, we could fix that a couple of ways - we could have separate stable teams for libs where we have separate review teams; we could add everyone to the global stable team for oslo and trust them to use that carefully; or we could make the core team for each lib the same as the stable team - thoughts? 16:30:21 the 3rd option is simplest, but I don't have an issue with adding everyone to the global team if the rest of the group agrees 16:30:54 2nd seems good to me dhellmann, whoever is responsible for master is responsible from stable. right? 16:31:05 dims: we should probably just change the format string to use %s instead of removing the retry value entirely 16:31:24 dhellmann: +1 16:31:27 dims: that sounds like option 3? 16:31:36 1 - separate stable teams for libs 16:31:46 2 - add everyone to global oslo stable team 16:32:04 3 - give core teams stable acls on libs (not using a separate team) 16:32:37 hmmmm; up to u guys (all seem fine with me) 16:32:39 I think 3 makes the most sense? 16:32:45 i'd go with #3, simple to explain and understand 16:32:51 3 sounds the best 16:33:14 Don't think separate stable teams are necessary. 16:33:17 ok, sounds good 16:33:21 1 seems like an overkill of 3 16:33:32 #action dhellmann replace stable teams with review teams on oslo libs 16:33:47 stevemar: yeah, I was trying to be complete but I don't like that option 16:33:52 and 2 seems like it'll cause overlap 16:34:05 2 just means we need more trust, but I'm not that worried about it 16:34:28 it does feel a bit weird to have +2 on the stable branch for a lib where you don't have +2 on master, though :-) 16:34:46 we one big happy family right :-P 16:34:47 Yeah, that doesn't make sense. 16:34:51 harlowja_at_home: ++ 16:35:01 :) 16:35:09 poppa dhellmann 16:35:10 lol 16:35:15 harlowja_at_home: not for long! 16:35:16 hahaha 16:35:24 poppa dims 16:35:25 lol 16:35:27 :) 16:35:43 * harlowja_at_home no more fooling around, lol 16:35:46 and I think markmc would be surprised to be called grandpa, so we should all remember to do that at the summit 16:35:52 lol 16:36:08 or is it great-grandpa now/soon? 16:36:11 and dhellmann is grandpa 16:36:12 hmmm 16:36:14 heh 16:36:20 * dhellmann regrets bringing that up 16:36:23 lol 16:36:43 * dhellmann only responds to Uncle Doug 16:36:55 :-) 16:37:01 moving on, we already talked a bit about the next topic 16:37:05 #topic liberty planning 16:37:05 We've been collecting topics for the summit for a while. We have more than I think we'll have slots for, so we'll need to do some work to prioritize. 16:37:05 #link https://etherpad.openstack.org/p/liberty-oslo-summit-planning 16:37:05 We also have a bunch of specs up for review, and we should start the discussion on those before the summit 16:37:06 #link https://review.openstack.org/#/q/project:openstack%2Foslo-specs+is:open,n,z 16:37:30 it would be good to have some consensus about specs going into the summit, so we can at least identify the ones where we need more discussion 16:38:15 I know there's at least one spec that I think we probably don't need as a spec at all - the one on writing examples for the library docs - so we should keep that in mind, too 16:38:31 it's important to agree to plans, but let's try not to go overboard :-) 16:39:44 :) 16:39:59 https://review.openstack.org/#/c/169944/ could be something once i flush it out more 16:40:00 that's all from the formal agenda for this week 16:40:01 #topic open discussion 16:40:06 is anyone going to pycon? 16:40:15 negative, some other guy from y! is though 16:40:18 to much traveling :-P 16:40:47 if you're going complain about import speed. 16:40:55 although i should go one day to pycon 16:41:08 harlowja_at_home: next year it's in portland, so the same tz for you 16:41:19 dhellmann, oh, that might be perfect then; not to far.... 16:41:25 * zzzeek missing pycon this year 16:41:28 bknudson: I have a strong sense that the response will be "we can work on that in python 3" which won't help us for a while 16:41:31 dhellmann, its yearly? or biyearly? 16:41:51 harlowja_at_home: it's held around the same time every year, in the same place 2 years in a row 16:41:56 k 16:42:02 this is the 2nd year in montreal, and so the next 2 are portland 16:42:13 oh hey FYI SQLAlhcemy is almost ready for 1.0.0 final, in case anyone’s been testing… 16:42:20 zzzeek, congrats! 16:42:21 zzzeek: nice! 16:42:42 I do run it against a small subset of openstack test suites including all of oslo.db, parts of keystone, nova and neutron and so far so good 16:42:57 zzzeek: is 1.0.0 backwards compatible? 16:43:04 zzzeek: that's good to know, too 16:43:07 bknudson: ermmmm yesish 16:43:24 it's capped: http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n147 16:43:33 SQLAlchemy>=0.9.7,<=0.9.99 16:43:35 zzzeek, where we going to try that 'depends-on' stuff to try to see if we can get 1.0 tested in the gate (against the projects...) 16:43:37 OK just so folks know I always put the big list of things that might be surprising in http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html 16:43:44 dims, i think was going to write that up or something, can't remember 16:44:04 ^ maybe that was for something else, ha 16:44:05 harlowja_at_home: y, haven't done that yet 16:44:10 Right so, in the months ahead what would get that cap to move to 1.0.x ? 16:44:19 bulk operations in ORM \o/ 16:44:23 harlowja_at_home: for a requirements bump it should be enough to just update the global-requirements.txt file, right? 16:44:31 well, not for unit tests I guess 16:44:39 yeah I added a lot of stuff specific to waht OSP projecvts are looking for 16:44:50 dhellmann, rights; dims had some process that i think might allow it to be tested (in unit tests) 16:44:59 *without getting merged... 16:45:19 ^ wizardry lol 16:45:19 should be able to just do depends-on a change in nova or wherever. 16:45:29 bknudson: right 16:45:33 review in nova depends on the g-r change. 16:45:44 harlowja_at_home: yeah, submitting a patch by hand to the projects to update them with a depends-on of the g-r patch would work 16:46:44 on a completely unrelated topic, I was thinking about the "you send too many release notices to the mailing list" problem. What do you all think about adding a blog to our specs repository, where anyone on the team can post progress reports and other notices? 16:46:54 ohhh nice 16:46:55 we could make it a separate repo, too, but that felt like overkill 16:47:09 I have a sphinx-based blogging tool that I could try to integrate with the repo 16:47:11 can i write about taskflow and such there :-P 16:47:21 dhellmann: or send 1 update every week? 16:47:41 +1 to blogs as well 16:47:46 dims: yeah, my idea was for blog posts we would just let anyone approve them as long as the post showed up as being authored by them 16:47:53 People want to know right away when we release, so I don't think weekly works. 16:48:02 so no "review" needed, we'd just piggy-back on the tool we already have 16:48:10 +1 to release blog 16:48:10 bnemec: true 16:48:16 bnemec: right 16:48:42 dhellmann: was it a public complaint? 16:48:45 my concern about a “blog” is some folks will use it a lot and others not really use it or remember where it is, so it would be lopsided. couldnt the blog have an estalbished “curator” ? 16:48:55 dims: yeah, fungi mentioned it on the mailing list a couple of weeks ago 16:49:03 I can’t keep track of all the places I’m supposed to write things these days 16:49:21 I wonder if we could work with infra to create an RSS feed of releases or something. 16:49:44 bnemec: yeah, this would be a team blog, and releases would only be one of the things we would talk about 16:49:56 a tag would work, but i wonder what the intersection is between people using tags and people complaining about too much on the ML 16:50:04 progress reports on major initiatives might be another 16:50:11 probably not a lot of cat pictures, except around april 1 16:50:41 Aww, now we'll have to wait almost a whole year for cat pictures. ;-) 16:50:44 i don't recall mentioning it on the ml. though i do recall the thread 16:50:45 stevemar: that discussion, and a book I'm reading, made me think about this as an alternative communication tool. So it's not just about cutting down on mailing list traffic 16:50:50 are the release notices only so that infra knows about it? 16:50:58 if that's the case then maybe sent the email to them. 16:51:02 fungi: sorry, I thought that was you but maybe it was someone else 16:51:11 or post in their irc channel 16:51:11 oh, well, i do recall replying that i like having release announcements published to a mailing list somewhere 16:51:14 awww man no cat pictures, lol 16:51:21 bknudson: No, it's also for people debugging problems in case we broke something with a new release. 16:51:38 bknudson: no, it's actually for all developers to know in case they see changes in behavior, and for our downstream packagers so they know there is a new version of something to package 16:51:59 bknudson: afaik, infra doesn't actually care about the releases :-) 16:52:01 expecially if release managers for projects are signing their release announcements and including names of git tags or checksums of tarballs or something 16:52:04 I actually like the notices to -dev. 16:52:20 * dims seconds bknudson 16:52:21 bknudson, would u say u are stoked? 16:52:27 lol 16:52:33 announcements to mailing lists are for the most part immutable (write once read many model) so it's hard to revise history 16:52:35 harlowja: sometimes chuffed. 16:52:43 ;) 16:52:51 though committing to a git repo sort of fits that requirement too 16:53:36 it would be neat if releases of libs was done in git... update the projects.yaml with the version # and commit hash and it's tagged automagically. 16:53:58 then anyone could propose it. 16:53:59 and then https://github.com/openstack-infra/release-tools/blob/master/release_notes.py gets activated and put somewhere 16:54:03 that'd be neat 16:54:06 bknudson: yeah, I would like that, too 16:54:11 sounds like a larger discussion not specific to oslo? 16:54:16 dims: right 16:54:58 +1 16:56:12 So did anyone actually object to the idea of an Oslo blog? 16:56:23 not me, i'd like it; sounds sorta fun 16:56:34 I don't think so, but it sounded like we still want to post release messages to the ML 16:56:35 bnemec: +1 to an Oslo blog 16:56:59 but +1 to post release messages to ML as well 16:57:09 I don't follow a lot of blogs so don't know how easy it is. 16:57:25 * zzzeek is +1 to more information distribution channels but +0 to more information “production” channels 16:57:35 having the blog be just another repo that we upload RST file to would be cool 16:57:48 bknudson: http://planet.openstack.org/ for example? 16:57:49 *or post for review, not upload... 16:58:08 I'm fine with that. I thought the mailing list discussion basically concluded that we would keep the ML announcements anyway. 16:58:16 harlowja_at_home: yeah, that's how I thought we'd do it, using tinkerer. I'll propose the changes we'll need to the specs repo 16:58:21 dhellmann, nice 16:58:23 bnemec: it did 16:59:21 bnemec: that was just one of the triggers that made me think we might want to look at alternative tools 17:00:03 ok, we're out of time 17:00:05 thanks everyone 17:00:09 #endmeeting