16:00:43 #startmeeting oslo 16:00:44 Meeting started Mon Jul 25 16:00:43 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:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:47 The meeting name has been set to 'oslo' 16:00:49 o/ 16:00:53 howddddy! 16:00:55 o/ 16:00:56 o/ 16:00:59 o/ 16:00:59 courtesy ping for amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dims 16:00:59 courtesy ping for dougwig, e0ne, flaper87, garyk, gcb, GheRivero, haypo 16:01:00 courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz 16:01:00 courtesy ping for lifeless, lintan, lxsli, Nakato, ozamiatin, rbradfor, redrobot 16:01:00 courtesy ping for rpodolyaka, sergmelikyan, sileht, spamaps, sreshetnyak, sreshetnyak, stevemar 16:01:00 o/ 16:01:01 courtesy ping for therve, thinrichs, toabctl, viktors, zhiyan, zzzeek 16:01:04 o/ 16:01:06 bye 16:01:06 o/ 16:01:09 o/ 16:01:10 0/ 16:01:12 * stevemar sneaks in the back 16:01:13 rossella_s, bye 16:01:15 harlowja_at_home: please change my nick in the list, it does not hilight :) 16:01:18 o/ Kind of. 16:01:20 o/ o/ o/ 16:01:44 kk, ihrachys https://github.com/openstack/oslo.tools/blob/master/ping_me.py if u want also ;) 16:01:47 o/ 16:01:51 additions/removals welcome ;) 16:01:55 cool 16:02:10 *super crappy ping script 16:02:11 lol 16:02:25 #topic Red flags for/from liaisons 16:02:31 so whats happening with folks??? 16:02:38 Nothing to report 16:02:47 i have a red flag, that one should not use southwest airlines last week (like i did) 16:02:47 lol 16:03:00 Nothing from Cinder. We talked about Oslo during our mid-cycle but nothing concrete from it. 16:03:08 Ouch, yeah, I saw the line for SW... 16:03:12 nothing from murano 16:03:20 nothing, all good. I am impressed how stable we are in terms of oslo these days. 16:03:33 hi 16:03:40 No red flags from keystone that I know of 16:03:50 other than we've got a team member having a problem with an oslo.context change. 16:03:52 ihrachys, ha, well sorta, the check periodics stuff is still busted for nova, at least if i release oslo.context (or unblock it) :-/ 16:03:57 bknudson, right 16:04:00 nova need https://review.openstack.org/#/c/343694/ to fix oslo.context 2.6 in Nova side 16:04:08 gcb, thx 16:04:19 harlowja_at_home: nimby! 16:04:21 https://review.openstack.org/#/c/343694/ is -1 16:04:30 * harlowja_at_home will check that one out 16:04:39 but thanks I'll also add it to my short list 16:04:39 but nova guys dislike the way , I and dough add +1 16:04:45 :( 16:04:50 ya, seeing some of the comments there 16:04:51 hmmm 16:05:05 jamie lennox also proposed https://review.openstack.org/#/c/345633/ 16:05:35 man, what a pita, lol 16:05:47 but ok, will check both of those out 16:05:57 (and thats not like pita bread, ha) 16:06:20 pitas are great for gyros 16:06:29 bknudson, ;) 16:06:53 #topic Releases for newton 16:07:08 i'll get out a release list later today (minus oslo.context for now) 16:07:17 anyone want me to add/remove anything from said potential list? 16:07:31 speak now or forever hold your peace 16:07:32 lol 16:07:58 harlowja_at_home: sadly I can't validate if we have any breakage with oslo master 16:08:12 harlowja_at_home: because our grafana dash went south 16:08:17 kk 16:08:22 * amrith sneaks in behind stevemar 16:08:26 is that going north soon? 16:08:44 amrith: just don't sit behind me, that'll be a bad view 16:08:57 harlowja_at_home: just noticed, will run the case right now. if you don't hear from us in 2h go ahead and break us 16:09:07 if you're not the lead dog the view is always the same. 16:09:11 * 16:09:18 ihrachys, ok, i'm quoting u ;) 16:09:23 (if anything breaks), lol 16:09:32 haha 16:09:43 I will be voted of that role 16:09:49 :) 16:09:49 no take backs 16:10:41 #topic Reviews needing discussion/attention 16:11:10 anyone want to highlight any reviews we can (try) to bring attention to (besides the nova oslo.context ones)? 16:11:19 16:11:24 (nearly any reviews, ha) 16:11:42 if someone gets bored https://review.openstack.org/#/c/343857/ :-P 16:12:55 harlowja_at_home, I saw your bot post the result in oslo channel ,cool 16:13:06 ya, nothing special, ha, but hopefully useful to someone :-P 16:13:12 harlowja_at_home, at some point: maybe the taskflow container engine discussion we kicked off with you and sputnik13? 16:13:16 u can also private message that bot and do !help and such 16:13:33 jimbaker, ah yes 16:13:50 jimbaker, how about we discuss/overview that next weeks for folks here 16:13:55 since i sorta missed that one 16:14:01 it'd be nice to catch folks up, get ideas... 16:14:08 harlowja_at_home, sounds good about that timing 16:14:14 cool 16:14:46 something something, taskflow + containers (for those wondering) 16:14:46 lol 16:15:09 Is anybody attending OpenStackEast in NYC http://www.openstackeast.com/ 16:15:24 rbradfor, yes 16:15:31 woah, there is a 'Playstation Theater' now? 16:15:45 damn corporate branding, lol 16:16:01 harlowja_at_home, branding. it's all about the branding. but it's a great concept combo 16:16:41 rbradfor, not me, sadly to far away :-P 16:17:00 although http://www.openstackeast.com/speakers/ looks like some people i know 16:17:10 understand, it's really only for locals, or those in northeast 16:17:23 #topic Open discussion 16:17:55 Keystone midcycle was last week 16:18:05 bknudson, oh ya, how'd that go? 16:18:06 we talked about some oslo.policy changes. 16:18:11 cool 16:18:15 zookeeper yet? 16:18:15 lol 16:18:30 no mention of zookeeper 16:18:33 durn 16:18:38 I don't know what all specs are already proposed. 16:19:08 https://review.openstack.org/#/c/296785/ could merge at anytime (if its useful) 16:19:27 * harlowja_at_home will poke adam on that 16:19:40 #action harlowja poke adam on https://review.openstack.org/#/c/296785/ 16:21:01 guess its a short-meeting-day 16:21:01 lol 16:22:06 jamielennox was going to dial into the Nova midcycle. I never saw a response in -oslo of his experience, re oslo.context 16:22:33 nova midcycle was also last week? 16:22:46 i think so 16:23:10 let me see if i can find jamie later to talk about what happened there 16:24:18 * harlowja_at_home might have to find folks to resolve that one 16:24:48 it does make me wonder if we should set better expectations on apis in general 16:25:11 perhaps do an audit, make sure people really understand what the public api(s) actually are 16:25:22 harlowja_at_home, I believe having more defined docs may help. 16:25:56 Are the docs for the oslo.context API something we can reference in the example of the nova issue. 16:26:26 rbradfor, we can, but they don't mention anything saying "don't do direct dict comparisons" 16:26:49 http://docs.openstack.org/developer/oslo.context/api/context.html#oslo_context.context.RequestContext.to_dict 16:26:50 https://review.openstack.org/#/c/345633/2 is W+1 already 16:27:07 harlowja_at_home, agreed, however is there a higher level Oslo API docs that should. 16:27:07 bknudson, oh nice 16:27:26 or is oslo.context the only library that does from_dict/to_dict 16:27:37 rbradfor, nah its not, taskflow has some of that to 16:27:38 it might also turn out that nova has a reason to require a specific value for the dict. If so, we need to document that 16:27:58 Makes you wonder what we should be adding in comments to better document see http://docs.openstack.org/developer/oslo.context/api/context.html 16:28:04 for example, maybe they don't want too much in the dict if it gets serialized. 16:28:11 it's not really endorsing any contract 16:28:26 bknudson, fair point 16:28:44 rbradfor, ya, i can take a stab at adjusting that doc 16:28:48 in this case I think all we added is a boolean 16:29:11 bknudson, actually no, we added 5 new attributes over 2 pages 16:29:23 but there were multiple issues with nova. 16:29:47 2 commits, no idea how autocorrect got pages!!! 16:30:07 lol 16:30:12 when I say issues, there were multiple things nova were specifically doing in their tests 16:30:42 that may/may not be advantageous to Oslo extending it's APIs without specific breakages. 16:31:05 I'm surprised by their reaction to the test failures. It's happened several times that projects had tests that were testing the library rather than their use of the library. 16:31:15 ya, i think one thing i did learn is that projects would be helped(?) by having some general guidelines around testing 16:31:18 1. having an expected dictionary, and comparing with context.to_dict() will never enable new attributes 16:31:43 2. there is some to_dict(from_dict()) subclass issues needing to be resolved. 16:31:48 right, i'd more expect projects to test deltas, or subsets (if they add anything to the dicts) 16:31:59 3. nova does a zero warnings test, this doesn't bode for future deprecation warnings 16:32:28 i think keystone also does that same zero warnings test? 16:32:39 (but my memory might be fuzzy there) 16:32:41 these types of project tests, restrict API development flexibility 16:32:43 yes, in keystone if we're using deprecated behavior we want to know about it. 16:32:59 rbradfor, agreed 16:33:03 this doesn't restrict API development flexibility at all 16:33:33 bknudson, using deprecated behavior and breaking the gate when a something is not deprecated should be independent tasks, not dependent tasks 16:33:35 if we get a failure because of using deprecated function then we need to change the code. 16:33:57 bknudson, i think rbradfor is more of saying, that there is no time between release and break 16:34:03 bknudson, the purpose of deprecation is to support migrating to it over time, not immediately. 16:34:03 so its hard to do that release without a break 16:34:09 *right the migration part 16:34:37 it hasn't been an issue though i will say with keystone (at least one i can recall) 16:34:38 and without the periodical check, there would be zero foresight of release and break 16:35:28 it happens way too often that something is deprecated without any actual replacement. I think the test for deprecation helps us find that. 16:35:32 right, the pray and release days of past 16:35:55 bknudson, I wish all projects were that proactive. 16:36:15 * harlowja_at_home me to 16:36:58 also, we can just ignore the deprecation for that test to prevent the gate breaking. 16:37:33 did the fixture for those warnings ever get merged into oslotest, or was it going into fixtures (can't remember) 16:37:47 I proposed it to upstream fixtures 16:37:49 k 16:37:58 but I haven't been working on it. 16:38:05 the changes got more complicated 16:38:10 :-P 16:38:15 why does that always seem to happen, ha 16:39:07 I agree we could improve the deprecation warnings. 16:39:20 But the warnings module also has a pre-deprecation warning that could be used. 16:39:35 https://docs.python.org/2.6/library/exceptions.html#exceptions.PendingDeprecationWarning 16:39:38 pre-pre-pre-deprecation 16:39:46 ya, i propose we put that warning on al lfunction calls 16:39:47 just incase, ha 16:40:12 (that's a joke) 16:40:35 I meant "I agree keystone could improve the checks for deprecation warnings" -- not sure what form that would take 16:40:52 would be nice if jenkins had a "warnings" result, not just -1. 16:40:57 ya, def 16:40:58 that'd be nice 16:41:12 * harlowja_at_home i'll poke infra about that 16:41:16 it really does seem useful 16:41:28 a non-voting(?) warnings only job 16:41:33 that just exists to capture those 16:41:39 the only way I can think of doing it now is a periodic job or extra non-voting. 16:41:44 ya 16:41:46 seems like a lot of overhead 16:41:47 afaic warnings are failures 16:42:02 lxsli, what do u mean 16:42:09 they are failures (like exceptions?) 16:42:12 or they fail in life? 16:42:13 lol 16:42:22 well if my C program says "warning: you maybe freed something you shouldn't have" I should fix that 16:42:35 same if "warning: your syntax isn't conventional" 16:42:36 16:42:37 lol 16:43:00 that's what keystone deprecation warning fixture does. Causes the "build" to fail. 16:43:04 I just mean, anything we have to fix goes in the same bucket, no point differentiating a "warning" from a failure 16:43:34 ya, i mean "error" can be set for the warnings module 16:43:45 -W "error" i think to the python runtime 16:43:51 and that will cause warnings ---> exceptions 16:44:07 OK maybe I missed something, catching up 16:44:08 just might be hard to get a listing using such mechanism 16:44:23 lxsli: that's what people are complaining about here. I'm fine with how it's working, but the complaint is that our check is somehow causing problems for releases. 16:45:15 bknudson, i don't think it is just yet, rbradfor i think was just making the point that having such check (without proper updating when it happens) can make releases hard that actually do deprecate things (with a grace period) 16:45:51 those same checks as u said do make sure there is a migraiton path that is created 16:45:52 which is good 16:46:26 the gate system doesn't easily support a more strict test case of a non-voting failure for deprecated warnings. this gives the projects grace periods 16:46:52 with current gate testing, it is SUCCESS or FAILURE, there is no WARNINGS capability 16:47:15 right, or FAILURE if warning has existed for > 3 months 16:47:28 but if warning < 3 month, then WARNING (only) 16:47:33 that'd be even nicer 16:48:00 but i'm dreaming, i'll talk with infra about what we can brainstorm on here 16:48:04 we'd never see the warning. 16:48:30 so is that because people only pay attention to failures? 16:48:32 we get lots of warnings from our tests already if you know where to look. 16:48:53 test output is gobbled up by something. 16:48:57 right, so its a visibility problem 16:49:12 and FAIL makes it really visible ;) 16:49:52 (even though perhaps, in theoretical gate/dimension) this could be resolved differently 16:49:53 FAIL can also freak people out, especially say if the gate breaks a few days before a midcycle meeting of a project 16:50:16 right 16:50:34 perhaps we getting to theoretical though :-P 16:50:46 lol 16:50:53 no releases a few days before a midcycle 16:51:04 no releases for the last few months of the cycle 16:51:10 eventually, no releases ever. 16:51:12 lol 16:51:21 took ma job 16:51:22 lol 16:51:44 or we hold up everthing we want to do, and release it day 1 of a new cycle, that way all projects know in advance our scope 16:52:06 bknudson: didn't know you worked on Nova 16:52:31 all my code is perfect, never needs further changes 16:52:33 obviously, lol 16:52:43 anyways, perhaps we to far off in the weeds :-P 16:53:08 rejoin in #openstack-oslo if people want to continue this?? ;) 16:53:54 silence means approval, lol 16:54:10 #endmeeting