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