16:00:18 #startmeeting oslo 16:00:19 Meeting started Mon Jun 6 16:00:18 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:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:24 The meeting name has been set to 'oslo' 16:00:31 o/ 16:00:35 courtesy ping for amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dims 16:00:36 courtesy ping for dougwig, e0ne, flaper87, garyk, gcb, GheRivero, haypo 16:00:36 courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz 16:00:36 courtesy ping for lifeless, lintan, lxsli, Nakato, ozamiatin, rbradfor, redrobot 16:00:36 courtesy ping for rpodolyaka, sergmelikyan, sileht, spamaps, sreshetnyak, sreshetnyak, stevemar 16:00:38 courtesy ping for therve, thinrichs, toabctl, viktors, zhiyan, zzzeek 16:00:45 o/ 16:00:45 o/ 16:00:47 o/ 16:00:48 o/ 16:00:54 * harlowja_at_home needs more coffee, lol 16:01:26 o/ 16:01:44 ./ 16:01:51 hi there, let's get started i suppose 16:02:07 hi 16:02:10 #topic Red flags for/from liaisons 16:02:19 anything folks need to bring up? 16:02:27 nothing for keystone that I know of. 16:02:28 (from a liason perspective) 16:02:34 nothing from the world of trove 16:02:48 nothing from neutron. we were broken in mitaka by config_dir option type change, but we handled it on our side. 16:03:03 cool, good to know 16:04:03 #topic Releases for newton 16:04:16 anyone need anything specifically released ? 16:04:27 otherwise i'll post a larger set of oslo things to get out today 16:04:51 (but let me know if any such thing should wait/or be prioritized sooner) 16:05:06 * ihrachys checks neutron periodic job trend. all clear, 0% failure rate. 16:05:20 ya, i'll look those over as well (need more coffee first, ha) 16:05:28 i do like 0% failure though 16:05:30 +2 16:05:31 ha 16:06:07 :) 16:06:09 0% failure means you're not taking enough risks 16:06:20 lol 16:06:25 true dat 16:06:31 right. it becomes too boring, developers look at greener riskier pastures 16:06:56 like importing from tempest :P 16:06:58 i'll break some stuff so that it isn't 0% 16:06:59 lol 16:07:07 #action harlowja_at_home break some things, lol 16:07:14 attaboy 16:07:34 don't want people getting used to things working u know 16:07:35 lol 16:07:42 (managing expectations ...) 16:08:03 #topic Farewell oslo-incubator 16:08:12 testing is not about showing that your software works, testing is about breaking software. 16:08:22 it's taken a long time to exorcise this. 16:08:30 so just fyi this is nearly done 16:08:36 #link https://review.openstack.org/#/c/320680/ 16:08:40 neutron just removed the last incubator bit the previous week. good timing! 16:08:46 thx gcb for helping there 16:09:05 ya, the repo is being blown up/torn down 16:09:15 nearly there 16:10:30 #topic Specs 16:10:56 so this week i'm gonna try to get all these specs cleaned up (at least my own) 16:11:01 #link https://review.openstack.org/#/q/project:openstack/oslo-specs 16:11:16 seems like other projects are also finalizing there newton specs this week 16:11:33 spec proposal freeze was last week for keystone 16:11:39 right 16:12:13 any specs there in that list people urgently need folks to look over (for some definition of urgent) 16:13:07 ok, assuming not then :-P 16:13:18 hold a sec 16:13:18 i'll clean up all mine and get those in shape 16:13:19 k 16:13:45 I'd like to see some more feedback on deprecation policy -- https://review.openstack.org/#/c/288720/ 16:14:03 ya 16:14:04 +1 16:14:14 there has been some other review about adding another attribute, and it would be good for us to standardize on. 16:14:18 * rbradfor looks for said review 16:14:53 https://review.openstack.org/#/c/288720/ has been a long time coming, so i'll also look over it again 16:15:03 harlowja_at_home, I know you raised comments about versionedutils in comparison to debtcollector usage 16:15:04 see if i can find/think of anything new 16:15:15 ya, likely 16:15:40 https://review.openstack.org/#/c/307671/ 16:15:48 is this trying to set deprecation policy for other projects? That doesn't seem appropriate for an oslo spec. 16:15:57 a proposal to add deprecated_version. 16:16:32 bknudson, it's a policy to be used in all Oslo projects, and then for us to promote adoption of how to deprecate stuff in a consistent and reproducible manner. 16:16:38 some of the goals of the Oslo project. 16:16:44 ah, https://review.openstack.org/#/c/307671/ seems nice, will look over that 16:17:00 in order to use/enforce in all Oslo projects, I'd like to know we are in agreement 16:17:35 https://review.openstack.org/#/c/307671/, only goes part of the way, I'd proposed to ML more detailed info, for example, a deprecated_version and a removal_version. 16:17:54 ya, seems fair to have that 16:18:09 so it's clear which release stuff is to be removed, not just a +2 policy, by adding as an attribute, it gets into all docs, help text etc. 16:18:17 yup 16:18:22 or in the case of some projects, something is deprecated but it's not expected to be removed. 16:19:00 we're looking to add a tool for keystone that will show when deprecated options are used. 16:19:07 rather than having to search the logs 16:19:21 so this might cause changes to oslo.config 16:19:26 bknudson, there is a nice deprecated log file that dims added 16:19:33 for devstack gates 16:19:51 this would be for operators not just devs. 16:20:06 bknudson, e.g. http://logs.openstack.org/36/294136/1/gate/gate-tempest-dsvm-full/b34704d/logs/deprecations.txt.gz 16:20:13 ah, thats nice 16:20:23 bknudson, I agree. 16:20:45 'Its value may be silently ignored in the future' :-/ 16:20:46 lol 16:21:00 (from that log) 16:22:23 ok, let's see if we (as a group) can look over that depreciation standardization work and come to some agreement 16:22:32 i'd like that, pretty sure rbradfor would to ;) 16:22:59 #topic Stuck reviews 16:23:13 any stuck reviews that people want to raise (so that they may get unstuck?) 16:23:21 (raise or discuss) 16:23:39 yes 16:24:04 Oslo Incubator cleanup, these reviews in other projects have been idle 4-8 weeks. Could some Oslo reviewers please +1 so hopefully the respective cores will pick up and get them approved -- https://review.openstack.org/#/c/312175/, https://review.openstack.org/#/c/312171/, https://review.openstack.org/#/c/297330/, https://review.openstack.org/#/c/297329/, https://review.openstack.org/#/c/294730/, https://review.openstack.org/#/c/294775/ 16:24:26 given we are deleting the project, this ongoing cleanup should still be a goal for Newton 16:24:45 yup 16:24:58 i'll give those a good look over today 16:24:59 they have various different topics, so it's hard to provide a single link. 16:25:14 np 16:25:22 harlowja_at_home, thanks. I think your a person that has +1 some already 16:25:41 yup yup, seems like i did find some of those, will look over the rest (that i must of missed or something, ha) 16:25:52 'openstack/sticks-dashboard' 16:25:56 let's get somebody else to help out to. 16:25:57 i wonder what that project is, lol 16:26:26 some projects are very idle, and hence I was able to retire the entire kite project based on proposing incubator cleanup 16:26:39 ya 16:26:41 happy to kill off a few more, so codesearch shows no incubator code 16:26:45 need a GC for projects 16:26:50 rbradfor, the GC 16:26:51 lol 16:27:05 GC? 16:27:12 garbage collector 16:27:42 doh! 16:28:21 He's from NYC/NJ. If I were you, I wouldn't make fun of the garbage collector. Otherwise you may 'become part of the landfill'. 16:28:26 :) 16:29:27 any other stuck reviews from folks? 16:30:26 #topic Open discussion 16:30:54 got a general 'feature branch etiquette" question... 16:31:07 sileht, yt, if u are do u mind responding to http://lists.openstack.org/pipermail/openstack-dev/2016-June/096607.html 16:31:11 I have a q re: 290907 (https://review.openstack.org/#/c/290907/) 16:31:23 and a question about isotime() since everyone misses that ... 16:31:38 kgiusti, whats up (not sure i can answer, but maybe someone can, ha) 16:31:52 * amrith waits for harlowja_at_home to hand me a microphone 16:31:59 * harlowja_at_home hands amrith a mic 16:31:59 lol 16:32:01 Do patches going onto the feature branch need multiple reviewers? 16:32:09 so the first question is about https://review.openstack.org/#/c/290907/ 16:32:30 I'm hoping we can come to a quick decision on it (preferably in line with my review comments). 16:32:36 amrith and I had a dicussion over beer about 290907 16:32:38 I'd hate to see a change to this ... 16:32:49 * amrith nods; was good beer 16:32:49 I'd prefer the same review criteria for feature branches as for master. 16:33:20 unless there's a plan for another review step before the code is merged to master? 16:33:26 my question about isotime(). Does anyone know of a project that actually took the recommended advice of using datetime.datetime.isoformat()? 16:33:28 I wouldn't want to work that way 16:33:44 ya, same here, what have people done that have used feature branches on gerrit previously (i haven't used one yet) 16:33:46 as far as I can tell, everyone just took the code from timeutils and made it their own; warts and all. 16:33:53 * amrith hands microphone to harlowja_at_home 16:34:15 to summarize our discussion, on one side (the spec), proposals standardizing names of arguments because multiple projects just effective duplicate _id versions, and then there is differing code duplicated. So, in Oslo form, our goal should be to reduce, simplify and provide consistent code. 16:34:15 bknudson: It's likely that further work will iteratively modify the code until the feature is finished 16:34:34 on the other side as amrith correctly points out, it's doesn't add any real value. 16:34:58 rbradfor, ironically it will have the same effect as attempting to deprecate isotime :) 16:35:16 so for isotime() some projects as u stated took the code themselves, i've used isoformat() in a library of mine without issue, but i think if a project felt they really needed it (for some reason) that it was ok (but not preferable imho) to just copy over isotime() 16:36:32 or at least i think that was the consensus for that isotime -> isoformat dilemma 16:36:36 my concern in these two cases, when 3 new projects come onboard, do they simply copy said code also. And when somebody modifies 'their' version, when/how do other projects know about it, or determine it's validity, and need to incorporate 16:37:41 if we have a v4 of the identity API I assume we'll go with isoformat for timestamps. 16:37:53 ya, i think that new projects should just use isoformat from the get-go 16:38:12 or maybe we can change it in a microversion 16:38:51 seems silly to have 2x+2 on this: https://review.openstack.org/#/c/325916/ 16:39:25 kgiusti: I don't think you need 2x+2 for administrative reviews like this one. 16:39:57 bknudson: agreed! 16:40:01 kgiusti, i forget, but when that feature branch --> master; does the whole thing get reviewed at that point 16:40:23 harlowja_at_home: I haven't the foggiest - that would be ideal 16:40:41 i thought something like that happened 16:41:31 kgiusti, harlowja_at_home : I think there's a merge commit, but I don't think you want to wait that long to have strong review. It'd be a lot more code if you wait until the end. 16:41:44 right 16:41:47 reviewing large changes doesn't work well. Reviewers get burned out and don't do careful reviews. 16:42:12 gotcha 16:42:16 and you don't want to have to rework everything. 16:42:20 agreed, so i guess kgiusti do your best if u can, for administrative ones, meh, i guess those are fine 16:42:32 bknudson, right 16:42:32 * kgiusti breaks out his 'need a review bat' 16:42:41 lol 16:42:41 no problem 16:42:56 thanks 16:43:03 review cookies might work better. 16:43:05 lol 16:43:18 only if you come to the dark side... 16:43:33 harlowja_at_home, thanks for the clarification re: isotime. I'm wondering which way to go for trove 16:43:51 leaning towards the isoformat() route but unfortunately can't find someones footsteps to follow 16:43:55 amrith, i'd try isoformat first, if u really can't just use it, then we can figure out what u can do 16:44:11 if you're going the typical route you should just pick a new random format 16:44:12 I think it should be fine for Trove 16:44:16 ;) 16:44:37 bknudson, yes. I was thinking pope Gregory had something to say about that ... 16:44:59 the pope uses isotime() ? 16:45:00 lol 16:45:26 seconds since trove 1.0 16:45:31 Since ~1582 16:45:53 ah, ya that gregorian time stuff ( i got the joke now, ha) 16:46:14 but I much prefer bknudson's definition of the epoch 16:46:18 BT and AT 16:46:22 isoformat looks like the way to go. 16:46:24 :) 16:46:41 bknudson, yes. I think so 16:46:48 it should work for Trove 16:47:18 cool 16:47:34 alright, guess we can continue with anything else in #openstack-oslo as needed 16:47:40 unless anything else people want to bring up? 16:47:55 harlowja_at_home, at some point I'd love to have some decision on the review I brought up 16:48:00 to put it to rest, hopefully 16:48:12 it is (at this point) a concern for Trove 16:48:13 agreed 16:48:16 as we use oslo.context 16:48:24 and if the thing changes; then we have a verioning issue 16:48:27 versioning 16:48:50 and since for other reasons (bad ones) trove doesn't yet version it's RPC API (shame, shame) this would be a serious problem for us. 16:48:53 i thought u guys had a happy beer over it, lol 16:48:58 amrith, any changes will always be backward compatible for 1+ versions, however your concern is need for that longer right? 16:49:11 to drown my sorrows on this one would take more than beer 16:49:15 lol 16:49:22 rbradfor, my issue is that we need versions first 16:49:26 before you go make this change :) 16:49:37 and currently that's a big hill 16:49:47 harlowja_at_home, we had a happy discussion, and amrith points are totally valid, and I would agree. 16:50:24 gotcha 16:51:12 I want to add some more specific details to the spec, a code example and also lists of projects duplicating code (in varying ways) 16:51:47 sounds good to me 16:52:50 okie dokie, amrith rbradfor we will come to some conclusion there, i just know it (and hopefully not in a few years, ha) 16:53:30 as per my discussion with amrith, what is the means to justify a change, if we take the true agile approach, we construct ALL functionality for new code to be a user story. i.e. how does it benefit the end user. 16:53:42 well, some incentives would help. I think beer is a good start, don't you rbradfor? 16:53:46 harlowja_at_home, could buy :) 16:53:51 however, a lot of work done in OpenStack does not even start with the basic premise. 16:54:12 the basic premise that beer helps decision making? 16:54:22 :) 16:54:26 or 'how does it benefit the end-user' ? 16:54:30 rbradfor, let's discuss some more 16:54:34 or how does beer benefit the end-user? 16:54:35 lol 16:54:36 ok, beer wins, lets all finish up now and have a beer 16:55:02 ha, ok 16:55:08 until next time! 16:55:14 harlowja_at_home, thanks 16:55:17 toodle-doo 16:55:19 thanks those who showed up for coming :) 16:55:29 #openstack-oslo for further things! 16:55:33 #endmeeting