14:00:49 <dhellmann> #startmeeting oslo
14:00:50 <openstack> Meeting started Fri Oct 11 14:00:49 2013 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:51 <markmc> cool
14:00:52 <jd__> nop, just here for fun
14:00:53 <openstack> The meeting name has been set to 'oslo'
14:01:03 <dhellmann> how about a show of hands for the record
14:01:05 <dhellmann> o/
14:01:08 <luisg> here
14:01:13 <mrodden> o/
14:01:17 <jd__> o/
14:01:21 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
14:01:29 <bpokorny> o/
14:01:37 <luisg> o/
14:01:44 <markmc> hey
14:02:19 <dhellmann> ok, the main topic today is the delayed translation feature in openstack.common.gettextutils
14:02:22 <beekneemech> \o
14:02:43 <dhellmann> we should start with a quick summary of the original requirements
14:02:55 <dhellmann> who can provide that?
14:03:21 <mrodden> there were a few issues with the way localization worked in the projects before
14:03:34 <mrodden> mainly that API messages and log messages were tied to the locale of the system
14:04:31 <mrodden> the goal was to untie them
14:04:32 <dhellmann> ok
14:04:48 <mrodden> i can find the original blueprint...
14:05:03 <dhellmann> do we need the log messages untied too, or is it just that log messages are another place we do translation?
14:05:16 <mrodden> https://blueprints.launchpad.net/oslo/+spec/delayed-message-translation
14:05:49 <mrodden> well there was a requirement to have english logs alongside the localized ones
14:05:59 <mrodden> that we had internally
14:06:10 <dhellmann> "we"?
14:06:10 <mrodden> more for debugging and support purposes
14:06:18 <markmc> personally, I think we should focus on properly translated REST API responses
14:06:29 <markmc> logs in different languages seems bizarre to me
14:06:49 <dhellmann> yeah
14:06:55 <jd__> +1
14:07:00 <mrodden> markmc: yes thats why we wanted a way to change them back to english and make them independent of the system locale
14:07:11 <dhellmann> ok, so we need to have a way to delay translation of messages until right before they are output, and then at that point select the locale for the translation
14:07:23 <mrodden> thats a good summary yes
14:07:23 <markmc> well, that's one way
14:07:36 <markmc> the other way is that you know what language you want when you create the message
14:08:06 <beekneemech> Can you do that for api calls?
14:08:14 <markmc> i.e. a lot of the logic here is about retaining _("%s" % (foo, )) so that we don't have to know the language when making the substitution
14:08:14 <dhellmann> doesn't that push info about the locale all over the code, though?
14:08:17 <beekneemech> You could have users with multiple locales requesting the same message.
14:08:30 <markmc> (didn't explain that very well)
14:08:51 <dhellmann> here's what I'd like to see: make Message a container, but *not* something that pretends to be a string. Then handle the translation explicitly at the point of output.
14:08:51 <markmc> i.e. it's not about, at runtime, knowing what language you want _() to return
14:09:08 <markmc> it's about allowing that language decision to be made long after _() is called
14:09:18 <beekneemech> dhellmann: I was thinking along the same lines.
14:09:34 <dhellmann> markmc: right, that's where I'm going, too, I think
14:09:41 <dhellmann> so _() returns a Message, that's fine
14:09:51 <markmc> dhellmann, I think that's overcomplicating all of this
14:10:14 <dhellmann> markmc: oh?
14:10:14 <markmc> I'm not sure that if we ignore the "logs in multiple languages" thing, we couldn't simplify this greatly
14:10:33 <markmc> e.g. if the language is part of the request context, that's all over the place already
14:10:35 <dhellmann> the other place where the % operator is used is building exception messages
14:10:41 <markmc> yes
14:10:59 <markmc> exceptions are probably the main way that messages end up in REST API responses
14:11:12 <mrodden> for the most part thats true yes
14:11:12 <beekneemech> I don't see how you do this without some sort of object returned by _ to encapsulate the original message for later translation.
14:11:31 <markmc> beekneemech, pass the required language to _()
14:12:03 <markmc> anyway
14:12:07 <dhellmann> that would work, but require passing knowledge of how to get that language throughout a *lot* of code
14:12:15 <beekneemech> All of it. :-)
14:12:15 <markmc> just giving my "are we *sure* we're not overcomplicating this" perspective
14:12:28 <markmc> dhellmann, it's in the request context
14:12:43 <dhellmann> is all code that throws an exception aware of the request context?
14:13:04 <beekneemech> ^
14:13:15 <markmc> if you call a function that throws exceptions and you don't pass it a context, then catch all exceptions and raise a new exception with translated message
14:13:43 <beekneemech> Heh, that's a whole new can of worms.
14:13:46 <markmc> perhaps with the original message as a non-translated detail
14:13:53 <beekneemech> Something that needs to be done anyway though.
14:13:56 <jd__> so the WSGI framework used could do that, catching Message and rebuilding them with the right language?
14:14:09 <dhellmann> jd__: right, that's what I was thinking
14:14:18 <dhellmann> rather than making every openstack developer understand how this works
14:14:24 <beekneemech> That's essentially where it's happening right now.
14:14:35 * dims says belated o/
14:14:36 <beekneemech> The delayed translation happens in wsgi.py for each project.
14:14:40 <mrodden> except for RPC requests
14:14:51 <beekneemech> We're translating RPC requests?
14:14:54 <dhellmann> we have a few other requirements to consider
14:15:06 <mrodden> well... RemoteError in Nova
14:15:14 <mrodden> wraps other exceptions basically
14:15:23 <dhellmann> I'm not sure updating all of the apps and API implementations to pass a lang val to _() everywhere or translate exceptions and reraise is practical :-/
14:15:36 <dhellmann> I'm not sure expecting every drive-by developer to get that right, either
14:15:37 * jd__ agrees with dhellmann
14:15:53 <jd__> there's a lot of place that we'll be missed in the future with such an approach
14:16:07 <dhellmann> that's why I like the approach of a catch-all handler at the point of output
14:16:25 <jd__> are there any downside to a catch-all?
14:16:46 <beekneemech> There's a lot of code that expects a str/unicode from _ that is now getting a Message.
14:16:55 <dhellmann> it complicates exception handling at that point a little, because not every exception is going to have a translatable message
14:16:58 <beekneemech> That's basically what led to this discussion.
14:17:11 <dhellmann> yeah, that was the other thing I wanted to understand better
14:17:19 <dhellmann> what code is expecting a string-like object now?
14:17:46 <mrodden> well, python logging kind of
14:17:54 <mrodden> which is where we hit the issue
14:17:57 <dhellmann> ok, we can address that in our adapter
14:18:01 <dhellmann> was there something else?
14:18:09 <luisg_> just want to say the way the Message was implemented, it look and feeld very much like a string
14:18:20 <mrodden> but i haven't run into much else than can't be tweaked to account for Messages
14:18:24 <luisg_> so all the places that do "An error happened": "The actual error"
14:18:36 <luisg_> still work and both strings are translatable
14:18:42 <dhellmann> what would happen if we made Message.__str__ and Message.__unicode__ raise an exception?
14:18:47 <dhellmann> explicitly
14:18:56 <mrodden> dhellmann: we actually talked about that here : https://etherpad.openstack.org/bug-1225099
14:18:57 <dhellmann> like, you can't turn these objects into a string-like thing using these methods?
14:19:13 <dhellmann> #link https://etherpad.openstack.org/bug-1225099
14:19:14 <mrodden> we = luisg, bpokorny and i
14:19:26 <dhellmann> what conclusion did you reach?
14:19:38 <luisg_> i think we need to do approach 2 ilsted there ^
14:20:07 <mrodden> well there are options but i like the one where if we can't str() a message (since it has non-ascii bytes) then we raise the UnicodeError and let the code deal with it
14:20:21 <beekneemech> Well, the logging issue is a bug in the logging module IMHO.
14:20:34 <mrodden> instead of trying to determine what the best encoding is
14:20:34 <beekneemech> So I'd say the adapter fix addresses that to my satisfaction.
14:20:41 <dhellmann> well, the other thing we need to do is ensure that Message is always just returning unicode values (never byte strings)
14:20:48 <luisg_> beekneemech: take a look at the link
14:21:10 <luisg_> i think they actually handled it well, they try to str() it, but if it doesn't work they defer
14:21:13 <dhellmann> beekneemech: yeah, we should verify that python3's logger works properly in that case
14:21:30 <luisg_> dhellmann: yeah that is the other option
14:21:34 <dhellmann> luisg_: but what happens when that unicode error is raised? can the caller figure it out?
14:21:45 <dhellmann> or do we just get unicode errors in the log files and API responses?
14:21:49 <luisg_> dhellmann: u mean in the logger?
14:22:06 <dhellmann> anywhere
14:22:08 <mrodden> API responses should be using unicode already
14:22:11 <luisg_> it is actually not raised, the try to str() if it's not possible they leave the object alone
14:22:15 <mrodden> i think there was a bunch of work around that in Nova anyways
14:22:40 <dhellmann> luisg_: doesn't that introduce extra cases, then? sometimes it works and sometimes it does not, so you always have to be able to handle either
14:22:49 <dhellmann> it seems better to be explicit
14:23:03 <dhellmann> say that a Message instance is not a string and cannot be converted to a string without providing a locale
14:23:18 <mrodden> if they unicode(message) that will always work
14:23:20 <luisg_> it actually just makes it look more like a str in that if u try to str non0-ascii it won't let u
14:23:20 <dhellmann> so no __str__ or __unicode__, only an explicit method call
14:23:43 <dhellmann> mrodden: it will always work, but what language will the message be in?
14:23:48 <luisg_> dhellmann: i think we need to at least have unicode, b/c everybody expects unicode out of _()
14:24:03 <dhellmann> the point of Message is not just to handle the encoding, it's also to handle the translation
14:24:23 <dhellmann> luisg_: who is everybody?
14:24:31 <luisg_> consumers of _()
14:24:52 <dhellmann> I mean, who in this case is expecting a unicode object that we can't update to handle Message instances?
14:25:02 <mrodden> i would expect unicode(message) to return it in a default locale, probably the system locale
14:25:06 <dhellmann> what else consumes _() responses other than logging and API handlers?
14:25:06 <jd__> dhellmann: if you force __init__ to have a locale with default to system, you can have __str__ or __unicode__, no?
14:25:23 <dhellmann> jd__: that's back to markmc's suggestion of passing locale to _()
14:25:40 <jd__> dhellmann: yay but by default you pass nothing, and the WSGI catcher rebuild them with the locale set
14:25:48 <dhellmann> mrodden: that's a reasonable default, but where is it useful that we could not require an explicit locale?
14:26:07 <beekneemech> The problem is that if you call str() on a Message that translates to un-str-able characters it fails.
14:26:10 <beekneemech> As it should, of course.
14:26:18 <mrodden> beekneemech: corect
14:26:19 <luisg_> beekneemech: +!
14:26:22 <jd__> dhellmann: or just set the .locale (or so) attribute of the message
14:26:22 <luisg_> +1
14:26:23 <mrodden> thats what i realized
14:26:23 <dhellmann> the reason for disallowing implicit conversion is it avoids cases of failing to explicitly handle the translation
14:26:47 <mrodden> right i see what dhellmann is saying...
14:26:48 <dhellmann> so we don't have cases where sometimes the caller gets english and sometimes they get their language
14:27:03 <jd__> dhellmann: I don't see how avoiding implicit helps?
14:27:04 <dhellmann> so we force *ourselves* to handle all of those cases by uncovering exceptions
14:27:27 <dhellmann> because anything that tries to treat a Message as a str() or unicode() ends up with an exception immediately
14:27:36 <dhellmann> rather than leaking the wrong language
14:27:45 <mrodden> those might take awhile to flush out
14:27:46 <luisg_> dhellmann: r u proposing we go with option 3?
14:27:52 <mrodden> but that would be nice to do
14:28:04 <dhellmann> luisg_: no, I am suggesting that both __str__ and __unicode__ should raise a RuntimeError
14:28:24 <luisg_> a RuntimeError for unicoding a message?
14:28:26 <dhellmann> "you must translate Message objects explicitly before outputting them"
14:28:47 <beekneemech> The problem I see there is we end up with special-case code all over the place for lazy vs. not-lazy translation.
14:28:48 <dhellmann> luisg_: there are 2 concerns: encoding and language
14:28:48 <luisg_> still not getting why the system default is not a good one
14:28:53 <markmc> here's a thought - if there is an error translating at runtime, can we gracefully fall back to no translation
14:28:54 <beekneemech> Which I guess is okay.
14:29:00 <dhellmann> beekneemech: we're going to have that anyway, no?
14:29:05 <markmc> i.e. the same fallback as if there is no translation available
14:29:11 <beekneemech> As long as we understand that means we can't go back by just switching lazy=True to lazy=False like we just did.
14:29:13 <luisg_> markmc: +1
14:29:16 <dhellmann> markmc: don't raise from __unicode__
14:29:24 * markmc concerned about people hitting a public API, requesting obscure languages and tickling bugs
14:29:46 <beekneemech> Which is pretty much what happened with the logging bug. :-)
14:29:48 <mrodden> dont raise from unicode?
14:29:54 <luisg_> dhellmann: with a default locale Message works just like if there was not message class at all
14:30:01 <dhellmann> beekneemech: that switch will still turn off the use of Message objects, which would make _() return unicode objects, which wouldn't need special cases
14:30:31 <dhellmann> luisg_: isn't the point of the API requirement that there is no default locale?
14:30:49 <luisg_> the logging bug actually happened because we are forcing utf-8 encoding on strings that are later handled used with sys.getdefaultlocale() like other strings
14:30:55 <luisg_> no
14:31:03 <luisg_> the point is that u can translate from the default locale to others
14:31:06 <dhellmann> markmc: gettext handles an unsupported language, doesn't it?
14:31:15 <dhellmann> doesn't it just return the original string?
14:31:19 <markmc> yes
14:31:26 <markmc> that's not the case I'm talking about
14:31:28 <markmc> I mean e.g.
14:31:44 <beekneemech> dhellmann: But if we're going to say you can't call str or unicode on Messages, then we need some other way to get the value out, which won't work if we turn off lazy translation and start returning unicode again.
14:31:44 <markmc> _("%(flavour)s") % flavor
14:31:56 <markmc> "no key 'flavour' found"
14:31:59 <markmc> or whatever
14:32:18 <dhellmann> beekneemech: not every string is going to be wrapped in our _() (third party libraries, esp.) so we have to handle strings as a case anyway
14:33:03 * jd__ ponders if it wouldn't be easier to teach english to everyone
14:33:05 <luisg_> i think the first concern should be enabling that to happen for our strings (our=from opentack)
14:33:09 <luisg_> lol
14:33:14 <beekneemech> Okay, so we're looking at a bunch of if isinstance Message stuff then, right?
14:33:24 <beekneemech> jd__: +1 :-)
14:33:27 <dhellmann> basically, yes, but in 2 general places
14:34:13 <dhellmann> markmc: I think I get what you're saying. That exception wouldn't be raised by our code, so the exception would have a real string in it not a Message, so the output code would just pass it along.
14:35:15 <markmc> dhellmann,  (_("%(flavour)s") % flavor) returns a Message, right?
14:35:23 <mrodden> yeah
14:35:39 <markmc> dhellmann, in __unicode__(), if there's an exception, try again with the untranslated string
14:35:49 <dhellmann> markmc: oh, yeah, sorry, was misreading the location of %
14:36:15 <dhellmann> markmc: yes, that makes sense
14:36:46 <mrodden> i dont follow?
14:36:59 <dhellmann> mrodden: translation has 3 steps
14:36:59 <mrodden> where would __unicode__() be called in that exapmle
14:37:08 <dhellmann> first, translate the message and try to combine it with the args
14:37:25 <dhellmann> calling unicode() on the Message returned from that expression
14:37:29 <mrodden> ok
14:37:42 <dhellmann> if the first attempt fails, take the original untranslated string and combine it with the args
14:37:47 <mrodden> we actually run the % internally in message just as a sanity check
14:37:59 <dhellmann> if that fails, which error do we report?
14:38:02 <mrodden> and let any KeyError raise from there
14:38:22 <dhellmann> mrodden: yeah, the Message object still needs to support % to hold onto its arguments
14:38:24 <mrodden> since its another developers error usually
14:38:30 <dhellmann> mrodden: right
14:38:38 <beekneemech> So we would throw an exception before getting to the unicode step, right?
14:38:43 <beekneemech> During the % operation.
14:38:44 <mrodden> correct
14:38:53 <dhellmann> our error needs to include the untranslated message so they have some hope of finding where it came from in the code, because the traceback won't point there
14:39:01 <dhellmann> oh, sure, that's a way to do it
14:39:33 <dhellmann> although there is still a chance that the untranslated format string will work, but the translated one will not
14:39:43 <mrodden> that is another concern
14:39:48 <mrodden> yes
14:39:52 <dhellmann> we can log that case, and then return the untranslated message
14:40:11 <dhellmann> but if __mod__ raises when the untranslated string doesn't work, that would point right to the problem line
14:40:22 <dhellmann> nice, beekneemech
14:40:43 <beekneemech> That's how it works now, isn't it?
14:40:47 <mrodden> it actually does it now
14:40:48 <mrodden> yeah
14:40:54 <dhellmann> even better
14:40:59 <beekneemech> So credit to mrodden :-)
14:41:06 <dhellmann> what changes do we need to make to Message, then?
14:41:13 <mrodden> except we don't distinguish between translated to untranslated we just attempt the translated one
14:41:14 * dhellmann tips hat in mrodden's direction
14:41:22 <mrodden> we can fix that though
14:41:28 <luisg_> the problem is in the str() method
14:41:34 <luisg_> described in the link mrodden pasted above
14:41:46 <beekneemech> How would you do the translated string at % time?
14:41:52 <beekneemech> You don't know the locale yet, do you?
14:41:57 <dhellmann> right, you can't
14:42:05 <mrodden> we use the system locale
14:42:09 <mrodden> if available
14:42:19 <mrodden> that is what is returned from the original _()
14:42:51 <dhellmann> I think we're focusing too much on making Message behave like a string. It really shouldn't need to do that.
14:43:08 <dhellmann> it only needs to be a thing we can turn into a string
14:43:15 <mrodden> right
14:43:18 <beekneemech> +1
14:43:19 <luisg_> y
14:43:29 <dhellmann> we have about 15 minutes, let's summarize the changes we want to make
14:43:34 <luisg_> i does not need to be basestring or unicode
14:43:43 <dhellmann> 1. change the base class of Message to just object?
14:43:50 <mrodden> __str__ should raise RunTime errors
14:44:05 <luisg_> yeah make Message str() raise like any other str() would with non-ascii
14:44:10 <mrodden> (i think thats what we concluded)
14:44:13 <luisg_> that is the main change and would solve the bug
14:44:20 <beekneemech> That makes sense to me.
14:44:24 <dhellmann> luisg_: it should raise a RuntimeError that the operation isn't permitted, I think
14:44:37 <luisg_> i thought we would just raise a UnicodeError
14:44:41 <luisg_> that is whawt the logger is expeceting
14:44:45 <luisg_> or any consumer
14:44:47 <beekneemech> Catch this sort of problem up front, rather than wait for someone to request the problem locale.
14:44:52 <dhellmann> the logger will never get a Message object
14:45:14 <dhellmann> that's the main change: we are NEVER going to pass a Message to code outside of OpenStack
14:45:33 <dhellmann> we will always handle the translation at the point where a Message would have been passed, and then pass the resulting string
14:45:38 * beekneemech wonders how many places that will require changes.
14:45:52 <beekneemech> Investigating that is probably a todo from this.
14:45:56 <mrodden> yeah
14:45:58 <dhellmann> yes
14:46:03 <mrodden> shoudl be easy to throw warnings for now
14:46:08 <dhellmann> we expect it to be logging (handled already) and API
14:46:10 <mrodden> to find the problem points
14:46:23 <dhellmann> ok, back to the changes
14:46:53 <dhellmann> add an explicit translation method to Message that takes a required locale argument (maybe we have that already?)
14:47:10 <beekneemech> It was proposed, but not merged yet.
14:47:14 <dhellmann> no, it looks like we're sticking the locale into the message and then calling unicode
14:47:15 <dhellmann> ok
14:47:21 <mrodden> we kind of do, but it needs to be fixed up
14:47:24 <mrodden> yea
14:47:40 <mrodden> there is a module level one we use essentially
14:47:43 <dhellmann> can we remove the _locale attribute and locale property?
14:47:47 <mrodden> it should probably just be a function on the object
14:47:52 <dhellmann> mrodden: right
14:47:57 <dhellmann> translate()?
14:48:03 <mrodden> get_localized_message
14:48:09 <dhellmann> ok
14:48:13 <mrodden> is what it is now
14:48:24 <mrodden> translate() would be a good candidate for the new one
14:48:45 <dhellmann> do we need the data property?
14:48:55 <mrodden> probably not any more
14:49:01 <mrodden> unsure though
14:49:46 <dhellmann> I saw some recursive handling of Message in the locale setter, so that will need to move to translate()
14:50:05 <mrodden> yep
14:50:13 <mrodden> most of that will move to translate i'd imagin
14:50:14 <mrodden> e
14:50:19 <dhellmann> the methods for adding messages together can probably go, right?
14:50:35 <dhellmann> most of the operator methods, I guess
14:50:38 <mrodden> that would be tricky
14:50:41 <dhellmann> __add__, __mul__, etc.
14:50:50 <dhellmann> because we're not going to pretend a Message is a string
14:50:51 <mrodden> requires quite a bit of cod changes
14:50:52 <mrodden> yeah
14:50:56 <mrodden> code*
14:51:47 <mrodden> assuming this is all Icehouse work we are planning ?
14:51:48 <dhellmann> do you think we still need them?
14:51:52 <dhellmann> mrodden: yes
14:51:54 <mrodden> ok
14:52:06 <luisg_> so just trying to take a step back for a second
14:52:08 <mrodden> we can work on migrating away from them
14:52:15 <dhellmann> are we adding Messages and strings (or messages) anywhere? I'm not sure how those are used
14:52:24 <luisg_> that sounds like we want to re-design what markmc beekneemech mrodden had done at the beginning of havana
14:52:26 <luisg_> which we know works
14:52:36 <luisg_> would it be possible for us to just fix the bug
14:52:37 <mrodden> concatenation
14:52:46 <luisg_> that caused all this, and try it for a little bit
14:52:59 <markmc> (I'm in favour of re-thinking this if we think it'll get us too a better place - too much magic currently IMHO)
14:53:04 <dhellmann> mrodden: hmm, ok, maybe we need to keep that stuff
14:53:12 <beekneemech> It works, but it's complicated and prone to third-party bugs.
14:53:27 <beekneemech> markmc: +1
14:53:45 <luisg_> i think in the case of the logger
14:53:50 <dhellmann> mrodden: but it may need to be updated in light of the "we are not a string" approach :-)
14:53:53 <luisg_> the reason why it broke was becuase we were forcing an encoding
14:54:01 <beekneemech> I like the idea of making the delayed translation more explicit.
14:54:02 <luisg_> but it has worked in all other places other than that
14:54:15 <beekneemech> luisg_: No, logging failed because it was calling str() on an object that resolves to unicode.
14:54:32 <beekneemech> Which it shouldn't be doing.
14:54:33 <dhellmann> luisg_: what is setting the locale of the Message objects in the API?
14:54:37 <mrodden> dhellmann: yeah, i don't see any issues with it currently, but if we are going to not be a string-like anymore it shouldn't be around then
14:55:07 <luisg_> it fialed because we let the logger str() a non-ascii
14:55:12 <dhellmann> mrodden: ok, we can leave that for last, just in case
14:55:13 <luisg_> instead of reaising a unicode saying it cant be done
14:55:43 <mrodden> logging doesn't try any special encodings, it only knows about the default 'ascii'
14:55:53 <luisg_> correct
14:55:57 <mrodden> which is why it was choking on utf8 encoded str we were giving it
14:56:04 <luisg_> it actually jsut uses the default, which is normally ascii
14:56:11 <dhellmann> we're almost out of time here
14:56:22 <luisg_> but it does know that if that dos not work it does not encode
14:56:45 <dhellmann> other changes: find the spot(s) in the API code where explicit translation is needed and update the way it works (or add it)
14:57:06 <mrodden> that should be pretty easy
14:57:14 <mrodden> i have to catch almost everything going out that endpoint already
14:57:30 <dhellmann> luisg_: I hear what you're saying, but I'm just not comfortable with turning the current implementation back on.
14:57:58 <dhellmann> something else to consider: is there any reason not to have this on all the time, once we get it working smoothly?
14:58:12 <mrodden> it was on all the time in Nova
14:58:17 <mrodden> even in tests
14:58:21 <beekneemech> Yeah, the lazy value was already hard coded.
14:58:25 <dhellmann> mrodden: we'll have to look at the pecan/wsme APIs, too, but those should be relatively easy as well
14:58:30 <mrodden> (we actually found a bunch of localization issues with it on)
14:59:02 <mrodden> well i guess i did
14:59:41 <dhellmann> ok, good, so we can re-enable the feature with a change in oslo, then, instead of touching each project
15:00:07 <dhellmann> anything else, before we wrap up?
15:00:28 <dhellmann> I should ask, who will be working on this? :-)
15:00:48 <mrodden> good question...
15:01:25 <dhellmann> I can put some basic details about what we agreed to today into a blueprint, but you guys know more about the implementation than I do
15:01:44 <mrodden> it'll probably end up being our team (luis, bpokorny and myself)
15:02:01 <dhellmann> ok, thanks
15:02:03 <mrodden> yeah i was just thinking a blueprint woudl be the first start
15:02:16 <mrodden> starting point
15:02:24 <dhellmann> yes, definitely -- would you like me to do that, or do you want to handle it?
15:02:40 <mrodden> i can take what we decided in the meeting and BP-ify it
15:02:48 <dhellmann> excellent, thank you again
15:03:10 <dhellmann> ok, we're a couple of minutes over, so I think we should wait for the BP before continuing the discussion
15:03:15 <beekneemech> +1
15:03:24 <dhellmann> thank you all, I appreciate everyone's help on this
15:03:28 <markmc> thanks doug!
15:03:28 <mrodden> thanks
15:03:40 <luisg_> ty
15:03:46 <bpokorny> Thanks all
15:04:02 <dhellmann> #endmeeting