16:00:20 #startmeeting oslo 16:00:22 Meeting started Mon May 9 16:00:20 2016 UTC and is due to finish in 60 minutes. The chair is harlowja_at_home. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:26 The meeting name has been set to 'oslo' 16:00:29 o/ 16:00:33 hi 16:00:35 courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dims, dougwig, e0ne, flaper87, garyk, haypo, 16:00:39 courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, spamaps 16:00:41 o/ 16:00:43 courtesy ping for sergmelikyan, sreshetnyak, sileht, sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek, gcb, Nakato 16:00:43 ./ 16:00:55 howday 16:01:09 yo! 16:01:13 welcome to oslo, the place where all your dreams come true, lol 16:01:23 o/ 16:01:28 o/ 16:01:39 You ended up with the winning lottery ticket 16:01:40 0/ 16:01:42 time to make oslo great again 16:01:45 lol 16:01:51 go trump :-P 16:01:51 lol 16:01:51 ha 16:01:53 #topic Red flags for/from liaisons 16:02:05 anything from a liason to report? 16:02:09 o/ 16:02:11 none for keystone. 16:02:12 Nothing to report in the LBaaS world 16:02:29 we're going to need to bump requirment version for oslo.log and oslo.policy 16:02:31 cool, a bunch of releaes just happened (like all of them for oslo) 16:02:44 o/ 16:02:46 nothing from trove 16:02:51 https://review.openstack.org/#/c/311812/ (all these just happened) bknudson 16:03:03 amrith, thx 16:03:08 flaper87, yo 16:03:23 right, they were released but now we need to set the required version for oslo.log>=3.6.0 so we can use the new symbols. 16:04:02 harlowja_at_home, I would like to discuss https://bugs.launchpad.net/oslo.config/+bug/1577450 16:04:05 Launchpad bug 1577450 in oslo.config "Allow transparent fallback to DEFAULT group" [Undecided,New] 16:04:06 bknudson, kk, https://review.openstack.org/#/c/311813/ is next in line 16:04:07 but maybe later in the meeting 16:04:23 harlowja_at_home: ok, so it's proposed already. Thanks! 16:04:49 harlowja_at_home: oh, that's upper-constraints. 16:04:50 amrith, sounds good, let's move that to a little later 16:04:55 we still need global-requirements.txt updated. 16:05:07 o/ 16:05:12 bknudson, yup, i think that happens after uc, like a 3-step process :-P 16:05:39 rbradfor, yo 16:06:08 https://review.openstack.org/#/c/311813/ didn't go well. 16:06:29 harlowja_at_home, we need a ping list for oslo, and liasons (you get caught up and miss the start of the party) 16:06:33 and there's also https://review.openstack.org/#/c/314168/1 which does the same thing 16:07:01 rbradfor, yes, +1 right now its in various places and i think maybe it'd be better to have the ping list in source control 16:07:18 harlowja_at_home, nova just uses wiki, you add/remove yourself. 16:07:43 https://wiki.openstack.org/wiki/Meetings/Oslo has the base-template 16:07:49 maybe can just expand that/add it there rbradfor 16:08:11 bknudson, https://review.openstack.org/#/c/311813/ should be rechecked (it was proposed before the libraries were released) 16:08:25 #topic Releases for newton 16:08:37 so just fyi for folks 16:08:40 #link https://review.openstack.org/#/c/311812/ merged 16:09:03 it has most/all of the oslo libraries 16:09:08 o/ 16:09:14 if any code was merged in the last week, it probably won't have those in it 16:09:29 i'll make a new update to requirements to catch up those later today 16:10:17 using my handy dandy https://review.openstack.org/#/c/308029/ thing for the release repo 16:11:06 #topic Austin summit 16:11:24 since this is our first meeting since the summit, i'd like to thank everyone for coming and bearing with me :-P 16:11:53 nice work organizing the summit sessions, most of them went quite smoothly 16:11:57 and to the family of Australians who came to (michael ...) 16:12:03 rbradfor, ^ ;) 16:12:29 ^ (that was a joke) 16:12:46 not really! 16:12:50 :) 16:12:56 #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/093713.html 16:13:35 harlowja_at_home, how did I miss reading that email before? 16:14:06 to much awesome in one email 16:14:16 that's usually the answer, when to much awesome, people don't read? 16:14:16 lol 16:14:26 so that thread has a bunch of little 'things to do' in it, which i've been trying to go through and get on 16:14:53 if people want to help (or i missed some to-dos) please feel free to respond/add your own 16:16:48 in an ideal world there would be a way to say have a top level 'newton work-items' and then link that to all the projects for these things discussed, but i don't think thats possible 16:17:28 can't you do that in launchpad blueprints? 16:18:03 there's some more discussion of task tracking at https://review.openstack.org/#/c/314185/1 16:18:04 i don't think u can have cross project blueprints right? (like a top level one for newton summit work items and child ones in each project)? 16:18:24 dhellmann, nice, is storyboard ready for large adoption? 16:19:27 harlowja_at_home : that's part of the discussion, I think 16:19:30 o/ Sorry I am late. 16:19:45 dhellmann, ok, will put that on my reading list :) 16:19:52 jungleboyj, any cinder issues? 16:20:11 Not at the moment. :-) 16:20:25 kk :) 16:20:36 I have issues, but that is a different discussion. :-) 16:20:38 bunch of oslo libraries just got released, hopefully there won't be any new issues :-P 16:20:48 jungleboyj, ya, we can talk about those later, lol 16:21:02 #topic Newton specs 16:21:09 * jungleboyj lays down on the leather couch 16:21:28 #link https://review.openstack.org/#/q/project:openstack/oslo-specs 16:21:43 so there are a few new specs in there that it'd be nice for folks to start looking over 16:22:10 especially the policy ones (oslo.policy related and actual policy) 16:22:21 #link https://review.openstack.org/#/c/312233/ 16:22:35 that one is hopefully some agreement on how new libraries can get created (in the larger community) 16:22:59 and https://review.openstack.org/#/c/288720/ from rbradfor would be nice also to finalize (so that we can have a more uniform deprecation process) 16:23:11 soooo if people want to do some reading, please read those (and others ) :) 16:23:18 and i'll give u a cookie if u do read them 16:23:51 harlowja_at_home, it would be good to discuss more the versionedobjects v debtcollector use cases as krotscheck was uncovering last week 16:24:00 rbradfor, agreed 16:24:24 rbradfor, shall we do that in the spec or here? 16:24:49 just add me as reviewers of these two specs, where is the cookie lol 16:25:45 the spec should cover it (incomplete now) its a discussion I'd also like to have, perhaps we can table it for next week. 16:26:16 rbradfor, let's see if perhaps we can update the spec with the situation, then see if people read it (and get cookie) and then we can discuss next week? that seem ok? 16:26:50 ok 16:27:00 * lxsli creeps in late 16:27:53 #topic Oslo.config defaults for trove 16:28:00 ./ 16:28:05 amrith, yo yo :) 16:28:08 the stage is yours 16:28:17 * harlowja_at_home hands mic 16:28:24 thanks 16:28:27 * amrith drops the mic 16:28:29 lol 16:28:34 the bug which was entered is ... https://bugs.launchpad.net/oslo.config/+bug/1577450 16:28:35 Launchpad bug 1577450 in oslo.config "Allow transparent fallback to DEFAULT group" [Undecided,New] 16:28:41 so the situation is this ... 16:28:45 trove has many datastores 16:28:55 and we have config parameters for thing slike timeouts 16:29:02 we'd like to have a default (for something) 16:29:06 and say the value is 900 16:29:16 but give us the ability to override for some db 16:29:19 keystone has some options like this, too. There's a default in the DEFAULT group and it's overridden in the driver. 16:29:22 and say make it 1200 or 120 or something 16:29:32 so you do that in your code; same as we do right now 16:29:42 yes, it's handled in the code 16:29:43 we look first in the specific db's seciton 16:29:45 right, seems useful (i thought this was the default configparser behavior in python, maybe not in oslo.config?) 16:29:46 and if not in default 16:30:07 * amrith looks for code 16:30:47 http://git.openstack.org/cgit/openstack/trove/tree/trove/common/cfg.py#n1407 16:30:52 I wonder if there's a way to do this with interpolation values already 16:30:53 so this is what we have now 16:31:12 did we ever implement the change to let interpolation values express the group name? 16:31:32 * amrith hands mic to dhellmann and steps back 16:31:49 amrith : line 1424 refers to a variable that doesn't exist 16:31:58 oh, nevermind, I can't read 16:32:05 big comment block... 16:32:25 * amrith puts down defibrilator paddles 16:32:27 anyway, I think you can do something like set the default for an option to '%(DEFAULT.foo)s' and it will look for the value 16:32:28 * harlowja_at_home hands dhellmann glasses 16:32:40 harlowja_at_home : I have 3 pair. I need a new prescription. ;-) 16:32:44 :) 16:33:26 amrith, maybe that would work for u, although i think u are wanting automatic fallback to the default group? 16:33:28 i see 16:33:29 sorry, wrong format '${DEFAULT.foo}' 16:33:44 so maybe what you do is setup each database specific thing to be ${DEFAULT.xyz} 16:33:54 and if you specify it in the config file, it takes that value 16:34:01 http://docs.openstack.org/developer/oslo.config/cfg.html#option-value-interpolation 16:34:03 if not it takes the default from the DEFAULT section 16:34:04 ok 16:34:07 right 16:34:27 or you could have a group called "default_connection_settings" or something instead of just DEFAULT 16:34:41 thanks, let me give that a whirl. if it works, I'll closeout the bug. thanks dhellmann harlowja_at_home ... 16:34:50 np 16:35:29 * harlowja_at_home steals mic back 16:35:44 * amrith plugs microphone in again 16:35:52 :) 16:36:24 #topic Retirement policy 16:36:38 so something i just wanted to also get rolling, maybe volunteers out there want to help 16:36:51 but the idea is to have a understood (not tribal knowledge) about lib retirement 16:36:57 and the process involved there-in 16:37:18 for example, pylockfile would make a good use-case/example 16:37:34 anyone want to work on said policy? 16:37:47 Is retirement another word for deprecation (at a lib level) 16:38:04 i think its post-deprecation perhaps 16:38:20 like, u get deprecated first, then u go to retirement, then u ??? (nobody knows) 16:39:10 it could just be forever deprecated (at the lib-level) 16:39:35 but i'd also like for oslo not to be the cemetery of libs that have no owner 16:39:36 OpenStack has a policy to retire a project 16:39:38 people complain if something is deprecated and unmaintained 16:39:41 #link http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project 16:39:51 however this is likely not applicable for a library 16:39:59 cool rbradfor that's part of it i think 16:40:21 bknudson, ya, although in the case of pylockfile, i haven't heard much of anything (complaints or other) 16:40:47 we should include a step in there somewhere for removing the library from our list of official projects 16:40:53 dhellmann, agreed 16:40:57 maybe after deprecation? 16:41:12 seems fair to me 16:41:33 could you apply an approach similar to OpenStack were you create a new release that is the "Deprecated Notice", and the functionality is hobbled. 16:41:47 this causes uses to pin to a previous know library version 16:41:51 rbradfor, ya, that seems to be similar to what we did for pylockfile 16:42:01 it seems painful verses just leaving it as no more versions. 16:42:27 we/me(?) put a big warning on https://raw.githubusercontent.com/openstack/pylockfile/master/doc/source/index.rst that says deprecated a while ago 16:43:27 harlowja_at_home, do you throw a warnings() message if it's used in this version with the deprecation README 16:43:37 hmmm 16:44:00 don't think i did add that 16:44:13 but that'd be a good thing to do 16:44:19 * rbradfor I have never used or even reviewed this project, so I'm just winging it 16:44:22 :) 16:44:49 nah, i think having a more concrete list of steps would be a good thing, including warning() and docs adjustments 16:45:14 and then retirement and then attic (or heaven or...?) 16:45:38 so, I'm guessing one motivation here is just to retire a project to another home (i.e. outside of openstack projects, namespace, CI/CD etc) 16:45:58 were do projects go now there is not -attic? 16:46:26 wouldn't we just leave the mostly empty repo where it is? 16:46:26 https://github.com/openstack-attic should exist, i don't think any oslo libs have ended up there (yet) though 16:46:47 https://github.com/openstack-attic/oslo.version 16:47:18 ya, look at that, ye olde oslo.version is there 16:48:29 anyways if anyone wants to work on formalizing the steps, that'd be cool, if not i'll eventually do it :-P 16:49:07 it would be good to have that written down 16:49:10 yup 16:49:15 I'm surprised that oslo-incubator isn't in the attic 16:49:27 we had some tools there that we were still using 16:49:32 perhaps it should be (after we make a oslo-tools repo?) 16:49:33 although I might be the only user these days 16:49:43 i use some of them to 16:49:46 2 users, lol 16:50:15 but maybe time to move tools elsewhere and put incubator in atti 16:50:16 I use incubator script it to sync my code. 16:50:18 *attic 16:50:21 3 users 16:50:59 do we have time to talk about logger names? I'm not sure if all of the folks interested in that are here now. 16:51:12 https://review.openstack.org/#/c/303581/ and https://review.openstack.org/#/c/307873/ 16:51:14 #topic Logger naming 16:51:18 * harlowja_at_home hands dhellmann the mic 16:51:36 this is the . v _ namespace problems with oslo libs? 16:51:42 this was about the tweaking periods right 16:51:50 when we got rid of the oslo namespace package, we said we would keep the loggers oslo.foo instead of renaming them, to support deployers who were using those names in their logging configs 16:52:07 that wasn't handled right, so now we're in a state where some libs use "." and some use "_" 16:52:22 we need to pick one, and then make oslo.log translate the names for the others somehow 16:52:25 I hope the libraries aren't doing non-debug logging anyways 16:52:30 the issue is, some of our libs don't use oslo.log 16:52:47 so we can't just say "oslo.log will rename the logger you ask for" 16:52:54 right 16:53:06 or even "oslo.log will rename the logger you configure" 16:53:21 since the configuration may be coming from an external config file that we don't read 16:53:35 so we need someone to puzzle through all of that and pick a direction 16:53:37 doesn't sound safe to have oslo.log magically changing names 16:53:51 yeah, it would be better if it didn't 16:54:08 we may want to configure 2 loggers, though, so we get both oslo.foo and oslo_foo 16:54:23 but only I think if the default logging level option is being used, and not if the config file is used 16:54:34 but then we also have to standardize on the naming scheme we use within the libraries 16:54:57 the simplest there for us would be to use getLogger(__name__) like everything else, but I have no idea how many logger names that is going to change 16:55:15 and before we start changing logger names we need reno set up for all of the libs so we can tell deployers about the change via release notes 16:55:23 I think we have it for a lot, but not all 16:55:57 does anyone want to take that on? 16:56:05 I don't know Kirill's irc nick 16:56:24 so, if thinking end user impact, what happens if we choose one way, and a deployer uses the deprecated approach (logging just isn't set right as they thing) and they fix it. 16:58:14 rbradfor : by "and they fix it" do you mean they fix their config file? 16:58:44 Can a library detect that someone set a logger and warn them? 16:58:59 yes, there is somewhere that can find info (release notes) and they update accordingly. 16:58:59 Maybe just send a warning to the logger and if it's configured they'll see it. 16:59:04 I don't know. I think getLogger() creates the logger if it doesn't exist. 16:59:27 so sending a warning would cause that to always be emitted 16:59:51 rbradfor : yeah, ideally we wouldn't break things in the first place, but if it's going to break we definitely need to have a fix documented 17:00:03 is there any multiplexing logger that we can use that will just use both (the oslo. name and the oslo_ name) 17:00:24 harlowja_at_home : I don't think we want that. We would end up with duplicate messages by default. 17:00:52 what we want is for our code to use one name, always, and then to do the best we can to morph any configuration for the other set of names into the "right" new names 17:01:36 so if we decide to stop using "." then we need oslo.log to look at the option for default log levels and turn "oslo\..*" into "oslo_.*" 17:01:47 ya, i'd be nice to use the __name__ in all the code, minimize the renaming of __name__ -> something else as much as we can 17:01:50 or vice versa 17:01:54 I guess you could save the handlers, formatter and level of "oslo_x" before loading log config, then if they change, config was reg'd 17:02:00 how many projects can we cover by doing this in oslo.log and how many not ? 17:02:11 yeah, I resisted using the . because I thought folks might want to set log levels for all of oslo, but I think that's not really the case 17:02:42 crap we out of time, i just noticed 17:02:45 * harlowja_at_home takes mic back, lol 17:02:57 ok, something to think about -- I can't drive it, but I can help 17:02:59 +1 for being consistent with always using __name__ 17:03:04 :) 17:03:18 let's move this over to openstack-oslo (and any other items people want to talk about) 17:03:31 * dhellmann has another meeting 17:03:33 * harlowja_at_home drops mic 17:03:35 #endmeeting