19:00:33 <briancurtin> #startmeeting python-openstacksdk
19:00:34 <openstack> Meeting started Tue Aug 18 19:00:33 2015 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:38 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:53 <briancurtin> if you're here for the SDK, say hi
19:00:54 <etoews> o/
19:03:00 <briancurtin> terrylhowe: you around?
19:03:38 <terrylhowe> o/
19:03:50 <briancurtin> #topic Release 0.6.2
19:04:22 <terrylhowe> I have a meeting I need to attend, so I need to cut out early today
19:04:38 <briancurtin> terrylhowe: cool, just say when, this is front-loaded with more important stuff first anyway
19:05:12 <briancurtin> i think there's two things to merge and then we should go on with 0.6.2. https://review.openstack.org/#/c/213247/ and https://review.openstack.org/#/c/213278/ (latter depends on former)
19:05:38 <briancurtin> at that point, we'll be able to talk about plugins and actually create objects, so the promotional wheels can start spinning more
19:05:51 * etoews looks
19:06:24 <briancurtin> https://bugs.launchpad.net/python-openstacksdk/+bug/1474478 is proving to be oddly difficult for some reason, so if that's ready when those two go in, great, otherwise it just gets released when it's fixed
19:06:24 <openstack> Launchpad bug 1474478 in OpenStack SDK "Why doesn't create update all attributes" [Critical,In progress] - Assigned to Brian Curtin (brian.curtin)
19:06:30 <terrylhowe> I was just messing with 213247 before the meeting
19:06:56 <terrylhowe> binary_type is str for py2x
19:07:02 <briancurtin> in that create-all-attrs bug, there's a failing test that obj["enabled"] is somehow false, but obj.enabled is true
19:08:10 <briancurtin> terrylhowe: that's why i make the extra attempt to decode to ascii -- if we just skip on all binary_type then on 2.x nearly everything would be dropped (including auth args, which would kind of suck)
19:08:41 <terrylhowe> yeh, my only thought was to use text_type instead or something
19:08:45 <briancurtin> i think the way i did it will make it so only truly binary data, like that in create_object and uploading images, gets ignored
19:08:49 <etoews> briancurtin: regarding logging data. i think we just shouldn't log data at all, regardless of whether or not it's text
19:08:50 <terrylhowe> I really don’t have a complete thought on it
19:09:20 <briancurtin> terrylhowe: i had started with text_type, and that would serve more of what etoews just said
19:09:29 <terrylhowe> Logging data is extremely useful for debugging
19:10:13 <terrylhowe> maybe logging data should be disabled in special cases like object and image upload
19:10:18 <briancurtin> i would like to be able to log reasonable data being sent. really it only ends up being the auth args that are binary data that is decodeable to ascii (in almost all cases)
19:10:37 <briancurtin> terrylhowe: that's effectively what the current change does, although more of an indirect way
19:10:50 <terrylhowe> like I said, I don’t have a complete thought on this, but I was wondering about unicode strings
19:11:00 <briancurtin> unicode would go through just fine
19:11:52 <briancurtin> the hard thing about text_type is that it's str on 3 and unicode on 2, and i think there are zero cases where we're sending unicode anywhere in 2, so the logs serve very different purposes then on 2 and 3
19:11:55 <terrylhowe> madarin characters for example
19:13:00 <etoews> ignore what i said, i incorrectly thought the data arg was always binary.
19:13:19 <briancurtin> terrylhowe: where would mandarin characters come in, what version of python, and where/how are they being sent? if they're auth creds, they just won't be logged here since they can't be decoded to ascii, so we avoid blowing up
19:13:52 <terrylhowe> say a resource description or name
19:14:15 <terrylhowe> anyway, we could leave that for the future.  I like the change just have questions
19:15:12 <etoews> speaking of that logging code, i notice that we log messages in 2 different ways there.
19:15:13 <briancurtin> terrylhowe: yeah, the thing i don't really like about the change as it is, is that there's no tests for writing logs. we should certainly have them, and again i don't really like proposing the change without them, but i did some manual tests on both 2 and 3 with an example script I'm going to use to show how things work and it worked on both
19:16:57 <briancurtin> etoews: what do you mean?
19:17:35 <etoews> there's _logger.debug("%s" % variable) and _logger.debug("%s", variable)
19:18:07 <briancurtin> etoews: the second way does the first way for you behind the scenes. the second way is the more usual one
19:18:38 <etoews> i'm just curious if there was some reason it was being done 2 different ways
19:18:38 <briancurtin> debug's signature is like (msg, *args) and then it does the msg % args
19:19:16 <briancurtin> etoews: probably not. perhaps came from copy/pasting something in, or just not knowing that the logger does it for you
19:19:17 <etoews> (it actually makes a difference when it comes to filtering log messages)
19:20:24 <terrylhowe> performance wise debug(“%s”, variable) is probably faster
19:20:51 <etoews> alright, well i'll make it consistent in the anonimizing patch.
19:23:18 <briancurtin> so in general, is this current log-writing patch ok for the moment for 0.6.2, with a followup for things like mandarin and whatnot...or do that all now?
19:24:16 <terrylhowe> I wanted to bring it up in case you knew an easy way to resolve that.  I’m fine ascii only for now.
19:24:22 <etoews> sgtm
19:24:43 <briancurtin> terrylhowe: i don't have a great one right now, but it is something we should support and have covered in testing
19:25:54 <terrylhowe> the method is just logging, but kidn of important to me, so testing would be awesome
19:26:18 <terrylhowe> I’ll finish looking at those two by tomorrow morning
19:26:32 <terrylhowe> I’ve got to run in a few minutes
19:26:45 <briancurtin> terrylhowe: yep, it's important overall. won't be too hard to test, just a bunch of mocks for stream and file, then send in various types of data and make sure it writes what we expect and/or doesn't blow up
19:26:51 <briancurtin> terrylhowe: cool, thanks for stopping by
19:33:25 <briancurtin> etoews: so for enabling the anon filter stuff, I'm thinking a good entry point for that might be an addition the the Profile class -- say a Profile.anonymous_logs attr -- and then when a Connection is created with a Profile that sets it, we can pass something through to Transport to add the filter. that might be forward looking enough for the upcoming ksa
19:33:25 <briancurtin> stuff without being too much of a burden
19:34:23 <etoews> lemme look. i had considered a couple of other options and that wasn't one of them yet.
19:34:38 <briancurtin> Profile probably then also has to grow something to know whether or not you want logs enabled, as a small front-end to utils.enable_logging, but that would end up passing through nicely
19:37:13 <etoews> right. if that's the case, does it even make sense to have utils.enable_logging anymore?
19:37:35 <etoews> maybe it becomes a private method on Profile?
19:38:49 <briancurtin> etoews: it can maybe just be moved as-is into the Profile class, public and all since you still want to give the flexibility with the arguments we currently take
19:39:20 <briancurtin> and actually at that point, maybe anonymize=bool becomes an arg to that method
19:40:12 <etoews> maybe it becomes set_logging(buncha args) though?
19:40:53 <briancurtin> i would probably keep it enable_logging since it's purpose is enabling logging in some way
19:42:22 <etoews> and it's not you would ever get_logging...so set_logging doesn't make so much sense. i was just thinking consistency wise but i don't think it applies here.
19:43:03 <etoews> i'll play around with that a bit.
19:43:03 <briancurtin> yep. set fits the others but not this
19:43:05 <briancurtin> cool
19:45:07 <etoews> it's weird to me that from_config instansiates profile twice
19:48:45 <briancurtin> etoews: yeah i think there can be some refactoring there as the services= list comprehension is duplicated as well
19:50:05 <etoews> seems like a pretty straight-forward refactoring too
19:56:52 <briancurtin> #endmeeting