16:01:51 <jgriffith> #startmeeting cinder
16:01:51 <openstack> Meeting started Wed Jul 16 16:01:51 2014 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:55 <jgriffith> geesh
16:01:56 <openstack> The meeting name has been set to 'cinder'
16:02:00 <kmartin> jgriffith: lol
16:02:01 <bswartz> lol
16:02:03 <eharney> :)
16:02:05 <glenng> Grretings
16:02:06 <flip214> that needs a few aliases.
16:02:13 <xyang2> hi
16:02:15 <jgriffith> kmartin: bswartz it's been a while but today I did it :)
16:02:24 <asselin> hi
16:02:24 <bruff> hi
16:02:26 <jkremer> hi
16:02:27 <thingee> o/
16:02:28 <jecarey> hi
16:02:35 <akerr> o/
16:02:35 <jungleboyj> o/
16:02:39 <bswartz> flip214: it's an inside joke -- he does it on purpose
16:02:42 <jgriffith> We've got a fairly full list of topics today
16:02:44 <jungleboyj> Wow, thingee is here.
16:02:48 <flip214> bswartz: oh, okay.
16:02:53 <jgriffith> I do want to start with one quick reminder
16:03:10 <jgriffith> J-2 is scheduled for next week!!!!
16:03:30 <jgriffith> If you have work you were planning on getting in and it's not under review already you're probably too late
16:03:50 <jgriffith> BP/Spec proposal freeze is also upon us (tomorrow)
16:04:05 <jgriffith> but at this point I'm inclinded to reject anything that shows up anyway
16:04:12 <navneet> jgriffith: BP for whole juno?
16:04:35 <navneet> or just J2
16:04:48 <jgriffith> navneet: no, but we get really restrictive after J2 remember
16:05:01 <navneet> jgriffith: ok...makes sense
16:05:16 <jgriffith> navneet: we're *supposed* to focus on stability, testing and bug fixes
16:05:20 <jgriffith> ok...
16:05:29 <jgriffith> #agenda https://wiki.openstack.org/wiki/CinderMeetings
16:05:36 <jgriffith> let's get started
16:05:38 <jungleboyj> We should basically consider BP submissions frozen at this point.
16:05:44 <jgriffith> #topic fun contributing to cinder
16:05:50 <jgriffith> DuncanT-: you're up
16:05:56 <DuncanT-> Hey
16:06:13 <DuncanT-> So, as the agenda item says, we've had lots of really nitty reviews
16:06:27 <DuncanT-> White space, docstring comment format etc
16:07:03 <flip214> is there some lint tool, like "indent" for C, that can reformat some sources completely? such a commandline could be used a precommit hook, and everything would be good.
16:07:11 <DuncanT-> My suggestion is 1) We stop doing those sorts of reviews unless the code is truely ugly b) For things like docstrings, fix the hacking check or STFU
16:07:24 <DuncanT-> flip214: None that are very good IMO
16:07:46 <flip214> DuncanT-: okay. 1+ for I)
16:07:46 <thingee> DuncanT-: you know what's a bummer, is I have to keep reminding the same people
16:07:50 <thingee> DuncanT-: lets start there
16:07:51 <bswartz> how about for people that really want to be format nazis -- upload a new patchset yourself
16:08:18 <asselin> I agree we shouldn't waste time reviewing those nitpicks
16:08:18 <DuncanT-> thingee: Can we just fix the hacking checks to spot it or stop caring?
16:08:22 <navneet> DuncanT: agree.....but untill we fix hacking.rst what should we do?
16:08:27 <eharney> are people going to be annoyed if people submit cleanup patches?
16:08:34 <jgriffith> flip214: pep8/flake8 and hacking
16:08:35 <asselin> or at least, no -1's for it.
16:08:42 <jgriffith> flip214: and if those don't catch it we shouldn't care IMO
16:08:43 <eharney> because at some point we have to make things tidy either in the review process or in later changes
16:08:54 <thingee> DuncanT-: my effort is to stop it. If you don't like me reminding people and would prefer a script to people remind people, by all means.
16:08:55 <jgriffith> eharney: you know I will be :)
16:08:59 <thingee> I'm doing my part by keeping it out
16:09:22 * thingee can be replaced by a shell script
16:09:28 <DuncanT-> thingee: I don't see the details as important, I'd suggest that people who do should script it ratehr than doing it in reviews
16:09:28 <jgriffith> thingee: I think the point is kinda being missed
16:09:32 <eharney> so the proposal is really: we will be ok with some level of inconsistency/messiness
16:09:32 <flip214> well, if there's a script to do that, it should be automatically done *at some, fixed points in time*.
16:09:46 <jgriffith> If I could interrupt for a second
16:09:50 <flip214> so that there are not that many merge conflicts because of whitespace changes.
16:09:55 <jgriffith> I think the sort of thing that's a bit troubling is
16:10:07 <jgriffith> for example when there are 5 +1's or +2's
16:10:08 <DuncanT-> thingee: If you thing it is important and can script it, please please please do
16:10:29 <jgriffith> then someobdy throws a -1 or even a -2 because somebody used "theres" instead of "their's"
16:10:37 <jungleboyj> jgriffith: +1 ...
16:10:40 <jgriffith> or becasue there was an extra whitespace in a docstring or comment
16:10:47 <DuncanT-> We have a 1 week window per milestone for cleanup patches, so we can clean it up
16:11:05 <akerr> if you remember that it needs cleaned up
16:11:08 <jgriffith> typos in comments should be fixed up but I don't think a patch should be rejected because of them
16:11:12 <jungleboyj> jgriffith: I have been not worrying about minor misspellings in commit messages.  If it is early in the review I comment on typos or formatting but not if it is close to being merged.
16:11:26 <jgriffith> think I was lost in the noise
16:11:29 <thingee> DuncanT-: I'm fine with helping reupload people's patches who make small mistakes. I'm not ok with making an exception on the style guides.
16:11:41 <eharney> jungleboyj: commit messages are different... they are permanent and people need to be able to search for terms in them
16:12:11 <akerr> you can change commit messages right in gerrit now, right?
16:12:15 <thingee> I think if I had enough bandwidth, I would help with the hacking scripts.
16:12:28 <DuncanT-> Thingee: The style guides are guides, it is there in the name... anything hacking enforces I'm fine with, but people -1ing on them is costing openstack contributers and not improving the code noticably
16:12:43 <jgriffith> DuncanT-: +1
16:12:47 <flip214> +1, move on?
16:12:51 <asselin> +1
16:13:05 <jungleboyj> thingee: Problem there is then we have to all agree on what to enforce.  :-)
16:13:21 <navneet> DuncanT: +1
16:13:28 <DuncanT-> Thingee: I'd rather let them slide until the hacking script is fixed then fix them up at the same time as fixing the script - all future cases will get cause by the script
16:13:40 <navneet> I got depressed too with reviews on my code sometimeback
16:13:48 <jgriffith> Can we just agree to lighten up a bit....
16:13:59 <DuncanT-> jgriffith: +1
16:14:07 <jgriffith> for example: if you review a patch make a comment *hey could you fix this up*
16:14:20 <jgriffith> but quit holding up the queue for nits?
16:14:26 <jgriffith> it's subjective, but we're all adults
16:14:30 <jgriffith> we can do this
16:14:32 <jungleboyj> jgriffith: +1  fair enough.
16:14:36 <eharney> there are also some places that this gets a lot trickier such as in text descriptions for config options etc...
16:14:37 <xyang2> jgriffith: +1
16:14:46 <navneet> jgriffith: +1
16:14:46 <jgriffith> and if you want to -1 that's fine
16:14:49 <jgriffith> it's your right
16:14:59 <DuncanT-> eharney: If it looks important, -1. That's fine
16:15:01 <glenng> Makes sense
16:15:03 <jgriffith> but it may get ignored :)
16:15:17 <navneet> fair enough
16:15:20 <jgriffith> but PLEASE for the love of whatever, no -2's for nits!
16:15:45 <jungleboyj> jgriffith: That hasn't been happening, has it?
16:15:53 <jgriffith> thingee: you ok with that?
16:16:08 <jgriffith> jungleboyj: it's happened in the past, but it's been a while luckily
16:16:25 <jungleboyj> :-)
16:16:30 <jgriffith> ok... thingee may have left us
16:16:37 <jgriffith> shall we move on?
16:16:39 <jgriffith> DuncanT-: you good?
16:16:55 <bswartz> thingee is busy replacing himself with a shellscript
16:17:02 <thingee> jgriffith: it's usual make exceptions. i get it
16:17:07 <jgriffith> bswartz: perl script I think
16:17:20 <jgriffith> thingee: what's that supposed to mean?
16:17:22 <jungleboyj> Ooooh, we could use PERL?
16:17:34 <thingee> jgriffith: we can take it offline
16:17:52 <jgriffith> thingee: I think we should, I'll ping you after meeting
16:18:08 <jgriffith> DuncanT-: anything else?
16:18:37 <jgriffith> DuncanT-: .... you fall asleep?
16:18:54 <jgriffith> ok then
16:18:57 <jungleboyj> jgriffith: Left for the pub.
16:19:10 <jungleboyj> :-)
16:19:10 <DuncanT-> Sorry, connection froze up
16:19:14 <jgriffith> #topic how to proceed with openstack-req's
16:19:19 <jgriffith> DuncanT-: DOH
16:19:22 <DuncanT-> I'm done
16:19:27 <jgriffith> hopefully you were good
16:19:30 <jgriffith> ok..
16:19:40 <jgriffith> flip214: what ya got here?
16:19:52 <flip214> In https://review.openstack.org/99013 I'm trying to get a DBUS library into the dependencies.
16:19:56 <flip214> but that's quite awful...
16:20:18 <flip214> while for production setups there are packages available (RHEL, SUSE, Debian/Ubuntu),
16:20:29 <flip214> devstack wants to use a tarball from pypi.python.org
16:20:43 <flip214> and that is a) old b) not pip compatible and so c) doesn't work for devstack.
16:21:10 <DuncanT-> flip214: Then that tarball needs fixing up.... should eb easy enoguh to do
16:21:12 <flip214> using a single python library from system libraries seems to be hard in devstack - or at least might influence many other things
16:21:22 <flip214> DuncanT-: not that easy, said the maintainer.
16:21:37 <flip214> dbus needs libraries and so compiles some bits via a C compiler
16:21:44 <flip214> so autotools are needed etc.
16:21:58 <eharney> do dbus basically isn't maintaining a release on pypi?
16:22:01 <eharney> so dbus*
16:22:05 <flip214> IMHO we should just use the available packages...
16:22:11 <DuncanT-> flip214: There are loads of things on pypi that do that...
16:22:12 <flip214> eharney: not "maintaining" as such, no.
16:22:37 <DuncanT-> flip214: Openstack wants to be able to run all the python stuff from a venv. There are good reasons for that desire
16:22:39 <flip214> well, if anyone knows enough autotools and pip and python etc. to help the maintainer fix that, I'd be very happy.
16:22:40 <eharney> this sounds like a situation where we may need to do something like a fake_dbus, similar to what Nova does with libvirt for similar reasons
16:22:58 <jgriffith> flip214: honestly this brings me back to my earlier rants
16:23:02 <navneet> flip214: are you suggestng devstack uses available packages as per distribution and installs them which might not be appening rt now?
16:23:08 <jgriffith> flip214: perhaps just don't put your stuff in req's
16:23:10 <DuncanT-> flip214: Send me a link to the library, I'll see if I can find a volunteer
16:23:16 <jgriffith> flip214: it's a seperate config step for your users
16:23:29 <flip214> http://dbus.freedesktop.org/doc/dbus-python/
16:23:31 <jgriffith> flip214: only other option is do things the way everybody else has to
16:23:54 <flip214> well, in production we'll have RPMs/DEBs for our stuff, with the correct dependencies. No problem there.
16:24:16 <jgriffith> flip214: I'm still pretty adimentn that I shouldn't have to download a boat load of packages/libs in my test env when I'm not even using your stuff
16:24:23 <flip214> resp. http://cgit.freedesktop.org/dbus/dbus-python/
16:24:25 * avishay sneaks in and sits in the back
16:24:27 <eharney> jgriffith: that is avoided with my suggestion above
16:24:27 <navneet> flip214: devstack can add similar mechanism ? it knows the platform
16:24:38 <jgriffith> eharney: sorry... I missed it?
16:24:40 <eharney> basically you make a fake dbus module that has stubs for the methods you want to unit test against
16:24:49 <jgriffith> eharney: +1000
16:24:50 <eharney> nova does this for libvirt unit tests because it's a similar mess
16:24:53 <bswartz> jgriffith: why do I have to download hp3parclient to get cinder unit tests to run then?
16:24:59 <eharney> this sounds like the same problem and should have the same solution
16:25:01 <jgriffith> eharney: that's what i asked HP and everybody else to do
16:25:10 <navneet> bswartz: +1...good question
16:25:19 <eharney> bswartz: supposedly that was fixed
16:25:21 <jgriffith> bswartz: cuz hemna__ refuses to help me out on this
16:25:32 <bswartz> eharney: that would be good news
16:25:34 <eharney> bswartz: https://review.openstack.org/#/c/92266/
16:25:42 <jgriffith> bswartz: as much as gripe and complain to him about it :)
16:25:53 <jgriffith> bswartz: eharney and yes it was
16:25:56 <bswartz> oh I will change my setup script and try this
16:26:02 <jgriffith> bswartz: eharney IIRC 3par, lhn both
16:26:17 <flip214> yes, for testing on devstack some fake_dbus is needed anyway. but what if I want to test the cinder driver *in real operation* within devstack?
16:26:17 <bswartz> +1 for not requiring weird libraries if you're not using a vendor's stuff
16:26:32 <DuncanT-> flip214: Does that make sense to you?
16:26:41 <eharney> flip214: in devstack it will just load the system dbus driver because nothing will be mocking it out
16:26:49 <navneet> flip214: install as per the platform manually as was done for hp3par before
16:26:58 <jgriffith> navneet: +1
16:26:58 <flip214> DuncanT-: I'll need some more details on how to provide the fake library for devstack, but basically yes.
16:26:59 <DuncanT-> flip214: At least until pypi is fixed up
16:27:13 <jgriffith> flip214: I think the bottom line is this
16:27:16 <DuncanT-> flip214: That isn't too hard, we can talk offline
16:27:24 <navneet> flip214: its your driver so you can take responsibility of testing it
16:27:27 <flip214> ok thanks, then I'm done with that issue.
16:27:29 <jgriffith> 3'rd party libs for "drivers" don't belong in requirements
16:27:39 <jgriffith> if you want them there you need to go with the rules they have
16:27:52 <flip214> jgriffith: okay, will cancel the proposal then.
16:27:52 <eharney> jgriffith: eh... they have to be vetted for licensing though
16:28:10 <jgriffith> eharney: I don't think so
16:28:21 <jgriffith> eharney: that's the beauty of leaving them out I thought
16:28:37 <jgriffith> eharney: if you suck them in that's *your* problem
16:28:38 <eharney> jgriffith: not sure how that would work out but i'll go with it -- not important for now
16:28:56 <jgriffith> eharney: I certainly could be wrong
16:29:00 <jgriffith> eharney: INAL
16:29:01 <DuncanT-> We can burn that bridge when somebody is standing on it...
16:29:06 <jgriffith> LOL
16:29:07 <DuncanT-> Shall we move on?
16:29:15 <avishay> DuncanT-: :)
16:29:20 * jungleboyj is enjoying that mental image.
16:29:21 <jgriffith> #topic code-churn
16:29:42 <jgriffith> flip214: what are you thinking of exactly here?
16:29:50 * jungleboyj just accidentally typed 'code church' in my notes.
16:29:53 <flip214> thanks, mine again. I'd like to do some work - both for an implementation of the replication API, and for a cinder volume driver.
16:30:25 <flip214> I'm just not sure whether the code churn will make all that obsolete even before I complete a draft version.
16:30:39 <jgriffith> flip214: so first... volume driver?
16:30:41 <eharney> that shouldn't generally be a problem for a driver
16:31:02 <jgriffith> flip214: you mean add a "new" volume driver for your product?
16:31:09 <flip214> jgriffith: yeah, using DRBDmanage below, for replicated storage, but without cinder having to know about that detail.
16:31:22 <DuncanT-> Most drivers haven't been broken by code changes very often at all...
16:31:32 <jgriffith> DuncanT-: we'll see if I can change that :)
16:31:38 <flip214> but as the backend/connector layers are being rewritten I'm not sure whether it's a good time right now.
16:31:52 <jgriffith> flip214: we're pretty good about keeping the API calls consistent
16:32:05 <jgriffith> flip214: you're kinda too late anyway :(
16:32:18 <jgriffith> typically we frown upon new drivers after J2
16:32:24 <jgriffith> err... second milestone
16:32:38 <flip214> I may be completely off-track, but I feel that there are too many git HEADs running around, each changing some substantial portion of the code base ...
16:32:40 <DuncanT-> jgriffith: That's days away yet....
16:32:46 <navneet> jgriffith: or simply ignore the driver :)
16:32:51 <jgriffith> DuncanT-: LOL
16:33:04 <flip214> jgriffith: the BP is available since a month, and the first draft implementation was done in May.
16:33:06 <DuncanT-> flip214: That's perfectly normal for openstack I'm afraid.... CI should help
16:33:18 <flip214> now it's just to implement all needed things - like snapshots and so on.
16:33:22 <jungleboyj> flip214: what DuncanT- said.
16:33:24 <jgriffith> flip214: *just*
16:33:25 <DuncanT-> flip214: But this is massively parallel development
16:33:28 <flip214> achieving "stability", if you like
16:33:39 <jgriffith> flip214: welcome to OpenStack :)
16:33:49 <flip214> thanks, I enjoy my ride ;)
16:33:51 <jgriffith> flip214: that's fine, work on your code
16:33:56 <jgriffith> flip214: just be sure to test it
16:33:58 <jungleboyj> flip214: It is iterative.
16:34:03 <flip214> but if it's just a wrong feeling on my side, then thanks - I'm done.
16:34:07 <jungleboyj> Don't have to get everything in at once.
16:34:07 <jgriffith> flip214: this is why we want 3'rd party CI so badly
16:34:17 <jgriffith> jungleboyj: ummmm not true
16:34:23 <jgriffith> jungleboyj: for drivers you sure do
16:34:27 <DuncanT-> flip214: Once you're merged and plugged into CI, most obvious breakage will be the job of the breakee to fix in most cases
16:34:33 <jungleboyj> jgriffith: Well, all the required function, yes.
16:34:47 <jungleboyj> jgriffith: Thought he was worried about the newer functions.
16:34:58 <jungleboyj> jgriffith: I.E. replication.
16:35:37 <jungleboyj> jgriffith: That is still a moving target and can be added for his driver at a later point.
16:36:06 <jgriffith> ok... shall we move on?
16:36:09 <jgriffith> flip214: you good?
16:36:16 <jgriffith> flip214: we can talk more in cinder if you want
16:36:41 <jgriffith> flip214: sorry but a big part of the answer on both of your topics today is "sorry, this is kinda how things roll"
16:36:43 <flip214> thanks, I'm done.
16:36:53 <jgriffith> flip214: there's always a ton of parallel dev work
16:36:58 <flip214> jgriffith: that's cool, I'll have to find out how things work here.
16:37:07 <jgriffith> and that's not going to change for a driver submission
16:37:11 <flip214> it's a bit different than sitting with the 3 other developers in the same room ...
16:37:23 <DuncanT-> flip214: But far more fun
16:37:27 <jgriffith> flip214: yeah... it's a steep curve, but I think you've got it pretty well
16:37:30 <jungleboyj> DuncanT-: +2
16:37:42 <jgriffith> okie dokies
16:37:48 <jgriffith> #topic hitachi driver update
16:37:58 <jgriffith> do we have a hitachi rep here?
16:38:09 <tsekiyama> jgriffith: yep
16:38:15 <jgriffith> tsekiyama: ahh... hello!
16:38:20 <tsekiyama> hi all
16:38:52 <tsekiyama> we've uploaded our recent patch on https://review.openstack.org/#/c/90379/, and passed the unit tests
16:39:11 <tsekiyama> and urrently it has -2 because there was multiple reviews opening in the past (v2, v3, etc.)
16:39:31 <tsekiyama> but old ones are marked 'Abandoned' now
16:39:45 <tsekiyama> So I'd like to know how we can move this driver forward to be merged
16:39:48 <jgriffith> tsekiyama: I'll fix that
16:39:54 <jgriffith> tsekiyama: can you also clean up the bp
16:40:02 <tsekiyama> jgriffith: thanks
16:40:04 <DuncanT-> TBH I skipped reviewing it because of the -2, I'll put it back on my list
16:40:11 <jgriffith> tsekiyama: my concern was that there were "v1, v2, v3..." patches all submitted
16:40:16 <jgriffith> none dependencies etc
16:40:33 <jungleboyj> Me too.
16:40:36 <tsekiyama> ah ok, we'll cleanup the BPs too
16:40:41 <avishay> only 5700 LOC, no biggie
16:40:58 <jungleboyj> Doh!
16:41:05 * jgriffith vomits a bit
16:41:10 <DuncanT-> I'm wondering how much of that trace infrastructure we can generalise
16:41:13 <jgriffith> tsekiyama: thank you
16:41:16 <navneet> avishay: :)
16:41:17 <avishay> cert test results?
16:41:30 <DuncanT-> avishay: cert test results are in the review comments
16:41:36 <jgriffith> thingee: I removed the -2, my only concern was you had 3 versions of that in process
16:41:46 <jgriffith> didn't know which one you actually *wanted* :)
16:41:50 <avishay> DuncanT-: okey dokey
16:41:56 <xyang2> jgriffith: Do all drivers have to be merged next week, J2?
16:41:56 <tsekiyama> avishay: the link to result is in the threadd
16:42:08 <avishay> tsekiyama: ok no problem
16:42:17 <jgriffith> xyang2: they're supposed to be
16:42:26 <xyang2> EMC has several drivers that need be reviewed too.  Any help appreciated!
16:42:47 <jgriffith> there are a ton of reviews to be done... and a large number of them are drivers
16:42:50 * thingee missed something
16:42:52 <jgriffith> xyang2: we'll get it worked out
16:43:01 <xyang2> jgriffith: thanks!
16:43:02 <DuncanT-> thingee: Tab completion error, don't worry
16:43:05 <jgriffith> thingee: my comment about drivers?
16:43:24 <sonea> jgriffith, if alle drivers have to be merged next week what about the openattic driver? - can we  still upload our code?
16:43:26 <jgriffith> thingee: OHHH
16:43:27 <jgriffith> sorry
16:43:32 <jgriffith> yeah, tab completion
16:43:33 <thingee> :)
16:43:49 <jgriffith> sonea: we should talk about that
16:43:57 <jgriffith> sonea: I was inclined to not merge that
16:44:00 <nileshb> IBM NAS driver extension for GPFS over NFS needs review: https://review.openstack.org/#/c/106040/
16:44:10 <jgriffith> sonea: it's a straight up duplicate of drivers that already exist in Cinder
16:44:10 <nileshb> Any help much appreciated
16:44:25 <jgriffith> Please stop asking for reviews on your driver patches
16:44:59 <jgriffith> sonea: I'm trying to understand the benefit
16:45:09 <jungleboyj> nileshb: That has been reviewed and there are comments to address.
16:45:14 <jgriffith> sonea: you offer an LVM driver and ZFS etc
16:45:24 <jgriffith> sonea: all drivers that exist in Cinder natively
16:46:19 <jgriffith> sonea: grab me in #openstack-cinder
16:46:23 <jgriffith> we're runnign out of time
16:46:43 <jgriffith> #topic crazy a**ed logging
16:46:43 <sonea> jgriffith, yes thank you
16:46:47 <jgriffith> jungleboyj:
16:46:54 <tsekiyama> we'd also like to know about 3rd party CI status, maybe discuessed in next topic?
16:46:56 <jgriffith> err DuncanT-
16:47:13 <DuncanT-> Ok, so
16:47:42 <DuncanT-> I can only see one thing we can do to avoid needing the _LW etc bits, as noted in the agenda
16:48:00 <DuncanT-> Or we can say we don't care, and let the translation leams suck it up
16:48:15 <DuncanT-> Or somebody smarter than me can come up with a better idea
16:48:41 <jgriffith> DuncanT-: yeah, as much as I think not using msg variables can be painful, it's not as bad as the crazy "LW_" blah blah
16:48:52 <jgriffith> DuncanT-: I'm inclined to vote for that as an option
16:48:53 <navneet> DuncanT-: smarter than you....not true
16:48:55 <DuncanT-> If we want go with the first option, then I've got a load of time sat in an airport on Friday so I'll work up a patch
16:48:57 <jungleboyj> DuncanT-: When I brought this up with jgriffith and hemna__ the initial response was to say we don't care.
16:49:15 <jgriffith> DuncanT-: BTW, I'm assuming you didn't mean to omitt the LOG.warning(*_*(
16:49:26 <jgriffith> jungleboyj: what?
16:49:52 <eharney> can we not write some log method ourselves like LOG_warning() that would handle the categorization as well as logging?  i'm not sure how to do this but there must be some way...
16:49:54 <jgriffith> jungleboyj: you brought up the two options?
16:50:01 <jungleboyj> jgriffith: We talked about this last Thursday when I asked about the process for getting the _Lx() implemented and it sounded like we were going to ignroe it for now.
16:50:01 <jgriffith> eharney: that what I asked
16:50:04 <DuncanT-> jgriffith: I absolutely intended to, though I'm now not sure that is right.... I was going to make the string extraction understand that LOG.xxxx() should be treated like _()
16:50:11 <jgriffith> eharney: I was told *no* but I'm still not convinced
16:50:19 <jgriffith> eharney: I wrote my own version in utils
16:50:27 <eharney> jgriffith: it does seem hard but i'm not really convinced either
16:50:29 <jgriffith> eharney: and it did the whole crazy LW prefix thing
16:50:45 <jgriffith> eharney: but the argument was that is messes up with imported libs
16:51:00 <jgriffith> eharney: which led me back to my "quit using libs, they are a PITA"
16:51:14 * jungleboyj is confused.
16:51:31 <eharney> it shouldn't if you make a new LOG_warning() method instead of overwriting lower-level ones..
16:51:41 <eharney> but i dunno.  i suggest we poke around for alternatives.
16:51:42 <jgriffith> DuncanT-: ahh...
16:51:46 <jungleboyj> DuncanT-: You are going to write something up that makes LOG.xxx automatically do LOG.xxx(_( ?
16:51:49 <jgriffith> DuncanT-: so that's the *other* issue
16:51:57 <jgriffith> eharney: I fully agree
16:52:22 <jgriffith> eharney: the problem is folks like Doug Hellman came up with this and hes' WAYYY smarter than me about python internals and tricks
16:52:40 <jgriffith> if that's what he came up with I'm a bit discouraged in what I can do :(
16:52:44 <jungleboyj> Are we mixing two discussions here?
16:52:53 <jgriffith> jungleboyj: yes *your* are :)
16:53:06 * jungleboyj blushes
16:53:12 <DuncanT-> Basically the thing that consumes these macros is the string extraction machinery.... which runs offline, so I *think* I can teach that to be smarter
16:53:16 <jgriffith> jungleboyj: they're very much related
16:53:26 <DuncanT-> The actual translation works fine with _
16:53:48 <jungleboyj> DuncanT-: Ok, I see.  So you think we can avoid having to add in _Lx() ?
16:54:01 <DuncanT-> jungleboyj: In most cases, yes
16:54:08 <jungleboyj> DuncanT-: That would be fabulous!
16:54:23 <DuncanT-> jungleboyj: We'd still need it for msg = "blah" cases, but there are far fewer of those
16:54:35 <jungleboyj> DuncanT-: Do we have a better solution than explicitly adding the import of _ in each file that uses _() ?
16:54:43 <DuncanT-> jungleboyj: No
16:54:45 <jgriffith> DuncanT-: so people like me just quit using that form :)
16:55:03 <DuncanT-> jgriffith: Or use _Lx() - either will work
16:55:07 <jungleboyj> DuncanT-:  Ok, I need to get that review through then.
16:55:19 <jgriffith> sigh
16:55:25 <jgriffith> it's so silly
16:55:43 <jungleboyj> DuncanT-: I prefer not to have msg = used anyway.  That seems easy enough to enforce.
16:56:06 <DuncanT-> jgriffith: I suspect you could catch all your cases with static analysis, but I won't have that done by the weekend :-)
16:56:12 <navneet> jungleboyj: msg = is required for long ones....better visible
16:56:14 <jgriffith> there's serious downsides to that, as much as I'd be inclined to say OK
16:56:35 <jgriffith> navneet: +1
16:56:48 <akerr> so the example in the agenda confuses me, should it not have LOG.warning(_(...?
16:57:02 <jungleboyj> jgriffith: navneet That is in limited cases though.
16:57:08 <DuncanT-> akerr: Looks like it will need to
16:57:15 <jgriffith> jungleboyj: huh?
16:57:18 <jungleboyj> akerr: Yes.
16:57:21 <DuncanT-> akerr: To get translation domains right
16:57:23 <navneet> jungleboyj: we use it for that purpose otherwise dont
16:57:31 <jgriffith> haha!
16:57:38 <jgriffith> that just seems funny
16:57:43 <jungleboyj> DuncanT-: +2
16:57:47 <DuncanT-> Looks like it is worth putting some effort into..... I'll post a patch
16:57:47 <jgriffith> "use that in cases that you need it, otherwise don't use it"
16:57:51 <jgriffith> that's what we do now :)
16:57:58 <jgriffith> DuncanT-: thanks!
16:58:02 <jungleboyj> jgriffith: +2
16:58:13 <akerr> 2 minute warning
16:58:16 <jgriffith> alright...
16:58:16 <jungleboyj> So msg = "my short message" is bad
16:58:18 <xyang2> DuncanT_: should I still ask people to change LOG.warning() to LOG.warning(_(...?
16:58:30 <jgriffith> jungleboyj: pick which of your topics you want
16:58:32 <jungleboyj> xyang2: I would say yes.
16:58:37 <DuncanT-> xyang2: Ask me on Monday when I've got something working
16:58:41 <jgriffith> seems we kinda covered the first a bit
16:58:43 <DuncanT-> xyang2: But probably
16:58:55 <navneet> jungleboyj: yes... and we need to use msg + "long msg" for extreme cases?
16:59:05 <xyang2> DuncanT-, jungleboyj: ok, thanks
16:59:08 <jungleboyj> jgriffith: Yes, so I just want to clarify what is going to happen on 7/24 as far as diver removal.
16:59:12 <jgriffith> bahh... we're out of time
16:59:20 <jgriffith> #topic driver removal for no 3'rd party ci
16:59:24 <jgriffith> jungleboyj: tomorrow
16:59:28 <DuncanT-> jungleboyj: I start shouting louder!
16:59:29 <jgriffith> I'll start removing drivers
16:59:31 <jgriffith> Kidding!
16:59:39 <jungleboyj> jgriffith: We can take it to #cinder
16:59:43 <navneet> jgriffith: u promised juno 3
16:59:43 <jungleboyj> jgriffith: I know.
16:59:52 <jgriffith> navneet: I didn't, others did
16:59:53 <jgriffith> :)
16:59:57 <navneet> :)
17:00:03 <DuncanT-> jungleboyj: Anybody who I don't have a maintainer email for or who isn't answering might get a rude patch in
17:00:04 <jgriffith> let's chat in openstack-cinder
17:00:15 <jgriffith> #endmeeting