21:02:03 <agentle> #startmeeting crossproject
21:02:04 <openstack> Meeting started Tue Jun 30 21:02:03 2015 UTC and is due to finish in 60 minutes.  The chair is agentle. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:08 <agentle> ttx: yep
21:02:09 <openstack> The meeting name has been set to 'crossproject'
21:02:09 <lifeless> is now
21:02:14 <edleafe> agentle: Cross Project :)
21:02:15 <thingee> we need to have a meeting topic before we can decide that :)
21:02:17 <dhellmann> o/
21:02:19 <notmyname> here
21:02:19 <mestery> rofl
21:02:19 <thingee> o/
21:02:20 <dims> o/
21:02:22 * mestery waves
21:02:24 <tpatil> o/
21:02:24 <ttx> http://eavesdrop.openstack.org/#OpenStack_Cross-Project_Meeting  says crossproject
21:02:24 <edleafe> o/
21:02:24 <j^2> o/
21:02:27 <jokke_> o/
21:02:27 <elmiko> o/
21:02:31 <agentle> Agenda is here:
21:02:32 <agentle> #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
21:02:34 <ttx> man I love this Gerrit-driven agenda thing.
21:02:42 <fungi> totally
21:02:42 <gordc> o/
21:02:46 <SlickNik> o/
21:02:46 <agentle> sweet
21:02:54 <ttx> I should do a lightning talk about it
21:03:10 <agentle> Any team with an announcement?
21:03:14 <ttx> o/
21:03:16 <agentle> #topic Team announcements
21:03:18 <agentle> go ttx
21:03:19 <ttx> On the release management side, we pushed liberty-1 last week
21:03:24 <agentle> grats!
21:03:25 * Rockyg is still lurking
21:03:26 <ttx> I think it went relatively well despite all the things we changed in the process
21:03:35 <ttx> and is more fluid overall
21:03:42 <ttx> We'll likely summarize the plan for Kilo and Liberty stable point releases on a thread this week
21:03:49 <ttx> dhellmann: anything to add ?
21:03:54 <fungi> oh, yeah icehouse branch eol this week
21:03:54 * devananda lurks as well
21:04:07 <etoews> o/
21:04:07 <dhellmann> ttx: no, I think that covers it well
21:04:08 <ttx> icehouse branch on ice
21:04:16 <dhellmann> fungi: ++
21:04:23 <fungi> i'll be tagging and deleting stable/icehouse branches in all repos with the release:managed tag (which just got updated last meeting slot!)
21:04:36 <ttx> fungi: just in time
21:04:39 <fungi> challenges of the bigtop
21:04:39 <agentle> #info liberty-1 release pushed last week, Thurs Jun 25 2015
21:04:41 <agentle> #link http://lists.openstack.org/pipermail/openstack-announce/2015-June/000391.html
21:04:54 <ttx> that is all I had
21:05:01 <agentle> #info icehouse stable branch end-of-life this week
21:05:19 <edleafe> icehouse to melt this week
21:05:27 <agentle> ttx: nice post at http://ttx.re/new-versioning.html
21:05:33 <ttx> edleafe: I blame global warming
21:05:35 <agentle> #link http://ttx.re/new-versioning.html
21:05:41 <fungi> to be fair, the branch already reached eol when 2014.1.5 was tagged a little over a week ago, this is just cleanup
21:05:51 <agentle> Docs? Quality? Translation?
21:06:03 <agentle> Security?
21:06:19 <TravT> o/
21:06:37 <agentle> any announcements or general info to share?
21:06:39 <fungi> security team got a specs repo this week i think
21:06:47 <fungi> not sure that's especially newsworthy
21:06:49 <elmiko> \o/
21:07:41 <agentle> Now I want to know what a diagonal team is
21:07:45 <agentle> Anyone else?
21:07:54 <fungi> orthogonal teams next
21:08:01 <dims> :)
21:08:22 <dhellmann> everyone loves a good geometry joke
21:08:29 <agentle> For docs, we are making progress on API reference info: https://review.openstack.org/#/c/177934/
21:08:40 <agentle> Lots of goodness in there.
21:09:05 <agentle> Okay, next up.
21:09:12 <fungi> dhellmann: i'll strive to keep my jokes as non-euclidian as possible
21:09:25 <agentle> #topic Translation for non user facing messages
21:09:27 <ttx> notmyname: any release date in sight ?
21:09:31 <ttx> oops too late
21:09:36 <agentle> Looks like yamamoto is not here?
21:09:45 <agentle> we can go back ttx if notmyname is around
21:09:51 <notmyname> ttx: no, not yet
21:09:56 <ttx> ack thx
21:09:57 <dhellmann> ttx: same question for devananda & ironic, I guess?
21:10:11 <ttx> dhellmann: well, I suspect that spec is blocking
21:10:16 <dhellmann> ah, right
21:10:40 <ttx> but yeah, swift will likely no longer be special soon.
21:10:42 <devananda> dhellmann: not imminent, but I believe we'd like to try out the new release model soonish, say, within the next month
21:11:12 <dhellmann> devananda: ok. We're going to have to do some special work at that point, so we'll want some notice and to coordinate live with you when it happens.
21:11:21 <devananda> dhellmann: so that we can get more comfortable with that process before the end of liberty
21:11:24 <devananda> dhellmann: certainly
21:11:46 <agentle> ok
21:11:58 <dhellmann> devananda: tl;dr is we need to remove the version from setup.cfg as the next patch after the tag, so we need to make sure your gate doesn't have anything else in it at that moment, etc.
21:12:14 * dhellmann is done
21:12:17 <agentle> without yamamoto does anyone else want to talk about marking internal interface docstrings as not translatable?
21:12:27 <agentle> Discussion here:
21:12:28 <agentle> #link https://review.openstack.org/#/c/185300/1//COMMIT_MSG
21:12:57 <ttx> question in the agenda is:
21:13:02 <ttx> "messages like the following should be translated or not, where the exception is merely a part of internal api and will never reach users? "
21:13:05 <lifeless> and I'm back
21:13:09 <ttx> raise ValueError("message")
21:13:15 <devananda> agentle: we're translating python docstrings??
21:13:18 <bknudson> if the string isn't going to wind up in logs or getting returned to the user then no reason to mark it for translation
21:13:29 <ttx> I guess we can discuss that question at least, even if he is not around
21:13:29 <dhellmann> I'm not sure it's always easy to tell when an exception is guaranteed not to be put in front of a user
21:13:44 <dhellmann> and I think that's garyk's point with the patch
21:13:44 <bknudson> exceptions have a way of getting in logs or returned when you don't expect it.
21:13:49 <dhellmann> bknudson: right
21:13:52 <lifeless> agentle: do you mean 'docstring' - the specific docs attached to python objects, or 'strings that provide documentation' which is quite different
21:14:03 <devananda> oh - exceptions, not doc string
21:14:12 <agentle> devananda: ah sorry, right.
21:14:12 <dhellmann> yeah, those are exception messages
21:14:17 <devananda> ++ to always translating them, even if you dont think they'll get logged
21:14:24 <ttx> Personally I'm always for limiting translations scope and increase quality over a smaller scope
21:14:42 <ttx> ie. 99% of A rather than 20% of A+B+C
21:14:47 <lifeless> I don't see value in translating that one in a thousand case
21:14:53 <lifeless> if its not intended for users
21:15:09 <ttx> so that sounds like a bad trade-off to me. But then I'm not the target user
21:15:14 <dhellmann> so which is worse, missing one because we think it's going to be internal-only or translating one that no one sees?
21:15:19 <devananda> agentle: aiui, we hve a policy right now that all exception messages should get translated
21:15:24 <bknudson> for the specific exceptions in https://review.openstack.org/#/c/185300/1/neutron/ipam/__init__.py -- they look like they would be returned to the user.
21:15:24 <lifeless> then its likely a) hard to explain well to translators, b) likely to change a lot, c) having good google-juice on the original is key to help folk find solutions
21:15:41 <ttx> dhellmann: if we routinely had 100% translations I'd say "missing one"
21:15:47 <bknudson> but this is in neutron so I have no idea
21:15:54 <lifeless> if its intended for users, its part of the UI and should be translated.
21:15:58 <ttx> but since we don't, I'd say "translating one that no one sees"
21:16:01 <dhellmann> ttx: good point, I don't know what level of coverage we have with translations
21:16:07 <lifeless> tl;dr: I don't think being an exception, or not being one, is criteria for translation-or-not.
21:16:43 <agentle> Looking at https://wiki.openstack.org/wiki/Translations/Infrastructure#Marked_for_translation I'm not sure what the policy is.
21:16:43 <devananda> loosening that to "well, only the ones you think users will see" is just going to muddy the waters and lead to untranslated exceptions eventually bubbling up
21:16:44 <dhellmann> lifeless: right, I think the point with that general policy is that a developer working on a local bit of code can't always tell if an exception is going to be presented to someone or not, so we were trying to make a simple rule that could be followed
21:17:06 <agentle> dhellmann: I'm with you on simple rules
21:17:14 <lifeless> devananda: do we translate the api ?
21:17:18 <dhellmann> although ttx's counter-argument is also compelling
21:17:21 <lifeless> e.g. is /servers/ in nova translated?
21:17:22 <ttx> dhellmann: 100% is pretty rare
21:17:23 <agentle> lifeless: no
21:17:36 <lifeless> so, we /don't/ have a rule that says 'everything users see is translated'
21:17:40 <agentle> how would we communicate the policy?
21:17:41 <bknudson> if they want to say that this string is never going to be seen then they can add a comment to the code that explains why it's not translated
21:17:53 <lifeless> -> I don't see any specific concern about a user seeing a given untranslated string or not.
21:18:08 <agentle> lifeless: other than the timewaste by translators
21:18:14 <agentle> lifeless: which is I think the concern listed
21:18:20 <lifeless> agentle: right - translating things that aren't intended for users is waste
21:18:26 <lifeless> agentle: *I* think we're agreeing
21:18:31 <agentle> lifeless: yeah I think so
21:18:32 <lifeless> erm I *think* ...
21:18:36 <agentle> so, how to communicate back?
21:18:41 <agentle> on the review or?
21:18:48 <devananda> lifeless: that's a straw man. human-readable exception and log messages are not API semantics
21:18:48 <agentle> just in the notes of this meeting?
21:18:54 <bknudson> let's clarify the policy if we have one
21:18:59 <bknudson> then point to the policy
21:19:03 <dhellmann> we have some policy-like statements in http://docs.openstack.org/developer/oslo.i18n/guidelines.html as well
21:19:40 <lifeless> devananda: but so is 'some random exception might bubble up'. Its a corner case
21:20:05 <devananda> lifeless: that guideline, last time I read it, clearly said all exception messages should be translated
21:20:13 <dhellmann> agentle: I can update the oslo.i18n docs with a statement about minimizing translator burden vs. following simple rules for identifying translatable strings
21:20:23 <agentle> dhellmann: was just going to suggest something like that!
21:20:31 <johnthetubaguy> seems like we should not translated exceptions, then stop them getting to users, but I guess its never that clear cut sadly
21:20:34 <lifeless> devananda: which guideline?
21:20:37 <devananda> feedback from developers within Ironic is that having a clear policy for when to mark strings for translation is helpful, especially for reviewers
21:20:38 <johnthetubaguy> dhellmann: +1 that plan
21:20:47 <agentle> #action dhellmann to update the oslo.i18n docs with a statement about minimizing translator burden vs. following simple rules for identifying translatable strings
21:20:49 <devananda> lifeless: the one dhellmann linked on eminut eago
21:20:57 <lifeless> devananda: ack; so it doesn't now.
21:21:07 <dhellmann> devananda: were you referring to a policy written down somewhere other than the oslo.i18n docs or the wiki?
21:21:08 <lifeless> devananda: it documents how to do it, but not when
21:21:30 <johnthetubaguy> I like the describing why
21:21:38 <johnthetubaguy> projects can then work out what that means for them
21:21:42 <lifeless> the policy is I think at the first line
21:21:45 <lifeless> Text messages the user sees via exceptions or API calls should be translated using ....
21:21:47 <devananda> huh...  my DNS is failing because VPN, so I'm having trouble finding the reference that I'm thinking of
21:21:57 <agentle> I like "lead with the why"
21:21:59 <lifeless> which is entirely reasonable IMO
21:22:12 <lifeless> johnthetubaguy: agentle: I support leading with why, too.
21:22:28 <lifeless> anyhow, the neutron review seems to be user error strings
21:22:32 <agentle> ok, so I'll keep that action.
21:22:34 <lifeless> its in an argument validation function
21:22:39 <johnthetubaguy> ah
21:22:40 <devananda> dhellmann: it was in the portion of docs (or wiki) which explained the difference between _LE, _LW, _LI, etc
21:22:40 <agentle> any other discussion or action to take?
21:23:10 <lifeless> so I think we should say:
21:23:15 <lifeless> - that neutron patch is doing the right thing
21:23:39 <lifeless> - projects can set their own specific rules, but our broad intent is only that strings intended for the user should be translated
21:23:58 <devananda> lifeless: to clarify, end-user or operator?
21:24:00 <lifeless> - (and if thats too hard to track in a given project, by all means say 'translate all' - but be aware of the load that imposes on reviewers
21:24:02 <thingee> devananda: http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html
21:24:07 <lifeless> devananda: good question
21:24:33 <johnthetubaguy> thingee: I was thinking about debug logs vs exceptions here, thats a good thing to raise
21:24:38 <lifeless> devananda: I don't know the prior discussions here, but I think an inclusive approach (end-user-or-operator) makes sense.
21:24:59 <bknudson> http://docs.openstack.org/developer/oslo.i18n/guidelines.html says debug is not translated
21:25:02 <lifeless> exceptions for internal state signalling for instance are not intended for either of those users.
21:25:22 <thingee> dhellmann: perhaps our log guideline should be updated rather than the oslo doc? http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html
21:25:28 <agentle> thingee: perhaps both
21:25:38 <dhellmann> thingee: this isn't about logging, though
21:25:38 <thingee> or reference each other
21:25:57 <thingee> logging guidelines not about logging?
21:26:03 <bknudson> translated messages also get returned to users
21:26:05 <dhellmann> we put the guidelines in the i18n docs because that's the tool we were using for translation
21:26:25 <agentle> dhellmann: +1
21:26:41 <bknudson> e.g., for a keystone request if you set the accept-language you can get error messages back in your favorite language
21:27:04 <agentle> bknudson: nice
21:27:19 <thingee> dhellmann: I think it's good to talk about the tool and the modules then? I'm unsure if it's the right place for guidelines as the doc I raised which is about guidelines.
21:27:31 <agentle> We should also consider where the translation team will look for guidelines, perhaps the wiki?
21:28:47 <agentle> I'll let the i18n team look at these notes to see if they want to add anything to their wiki pages.
21:28:49 <agentle> Ok, moving on
21:28:59 <agentle> #topic API WG spec review: Clarifications on state-conflicting requests
21:29:18 <agentle> #link https://review.openstack.org/#/c/180094
21:30:01 <agentle> This is in freeze.
21:30:39 <elmiko> assuming no arguements it will be merged on friday, iirc
21:30:40 <agentle> so the API WG will use lazy consensus to merge if there are no objections
21:30:48 <agentle> elmiko: that sounds right
21:31:13 <dhellmann> updated translation policy for review: https://review.openstack.org/197339
21:31:14 <etoews> all the gory details of the api wg merge process are here. http://specs.openstack.org/openstack/api-wg/process.html
21:31:27 <agentle> thanks etoews
21:32:01 <agentle> Ok, next topic
21:32:07 <agentle> #topic Return request ID to caller (tpatil): Spec review
21:32:11 <agentle> tpatil: around?
21:32:15 <tpatil> yes
21:32:16 <tpatil> #link: https://review.openstack.org/#/c/156508/
21:32:22 <tpatil> Doug has given +2 on our spec
21:32:28 <tpatil> Need one more +2 from core reviewer, then I will request respective python clients PTL to approve blueprint so that we can start pushing patches
21:32:30 <agentle> thanks tpatil!
21:32:42 <tpatil> We would be ready with implementation for python-glanceclient, python-cinderclient and python-neutronclient by end of this week and would start with python-novaclient early next week
21:33:04 <tpatil> Once get_previous_request_id method is available in all python client libraries then we can move on step 2 (another spec in future) of logging caller and caller request ids on the same log message if osprofiler doesn’t work out well
21:33:08 <dhellmann> I'm pretty happy with that spec now. We should put it on the TC agenda for review, too.
21:33:17 <thingee> dhellmann: +1
21:33:23 <agentle> dhellmann: ok
21:33:23 <tpatil> Thanks Doug for reviewing the specs
21:33:51 <tpatil> That's all I wanted to update here
21:34:09 <agentle> okay, sounds good tpatil
21:34:19 <agentle> bknudson: did you have any discussion points (looking at the review)
21:34:32 <bknudson> agentle: I commented in the review
21:34:45 <agentle> bknudson: ok
21:35:06 <agentle> who adds to the TC agenda, ttx?
21:35:14 <agentle> (I'm guessing)
21:35:30 <tpatil> bknudson: We will reply to your comment soon
21:35:54 <agentle> Okay that was it for the Agenda topics, did anyone else have anything or should I open it up for open discussion?
21:35:56 <bknudson> tpatil: thanks
21:36:00 <etoews> 1 thing
21:36:08 <jokke_> tpatil: ping me when you need review for the glanceclient
21:36:21 <tpatil> jokke_: Sure
21:36:33 <etoews> i'm thinking it's time to put the python openstack sdk in the big tent.
21:36:42 <johnthetubaguy> tpatil: looks good from a nova point of view, good step forward
21:36:46 <Rockyg> +1
21:37:15 <agentle> etoews: +1
21:37:17 <ttx> agentle: if not in a governance review, post to -tc list
21:37:28 <agentle> ttx: ok, thanks
21:37:33 <etoews> i'd raise a review to the governance repo
21:37:44 <edleafe> etoews: it's wayyyy past time
21:38:03 <etoews> i just wanted to "check the temperature" on that here. any thoughts or feedback?
21:38:20 <bknudson> I thought it was already in the big tent
21:38:23 <agentle> #action agentle to post to -tc list to add Return request ID to caller openstack-specs to TC meeting agenda
21:38:29 <ttx> agentle: in the case of a cross-project spec I just pick them up when they collected a large number of +1s
21:38:53 <ttx> i.e. when we can assume they have reached community consensus
21:38:54 <johnthetubaguy> etoews: FWIW, I would like to see it official, like bknudson I kinda assumed it was already
21:38:54 <agentle> bknudson: the openstackclient is
21:39:04 <johnthetubaguy> ah...
21:39:19 <Rockyg> etoews: just create the patch and it should happen PDQ
21:39:20 <edleafe> yeah, this is the pure Python SDK
21:39:24 <edleafe> not a CLI
21:39:36 <johnthetubaguy> edleafe: agreed
21:39:49 <bknudson> can we kick the other clients out of the tent?
21:39:56 <etoews> :)
21:39:58 <edleafe> bknudson: don't be mean!
21:39:59 <fungi> at one point osc and the unified sdk devs had sort of joined forces, but it's not clear that continued and it's at least not formalized
21:40:06 <fungi> dtroyer: ^ ?
21:40:08 <dtroyer> bknudson: not _quite_ yet…
21:40:36 <dtroyer> it wasn't until YVR that we felt SDK was ready to be included in a shipping client
21:40:55 <etoews> we've got a roadmap to 1.0 now
21:41:03 <dtroyer> that hasn't started yet but we plan to start soon
21:41:32 <bknudson> we need to get our keystoneauth library out
21:41:53 <etoews> that would be helpful
21:41:57 <agentle> is keystoneauth a dependency though?
21:42:02 <agentle> or nice-to-have
21:43:06 <etoews> okay. so the temperature is warm. :)
21:43:06 <dtroyer> it will be a dependency
21:43:10 <agentle> dtroyer: ok
21:43:17 <agentle> etoews: lukewarm? :)
21:43:30 * etoews dips hand in again
21:43:33 <etoews> warm
21:43:34 <agentle> etoews: texas-summer-warm
21:43:43 <agentle> ok, I'll open it up
21:43:44 <dtroyer> agentle: +1
21:43:51 <agentle> #topic Open Discussion
21:43:58 <agentle> thanks etoews and dtroyer
21:44:30 <agentle> I don't know how many heard in the TC meeting we're still awaiting M name, 1 and 2 are trademark, 3 is looking up.
21:44:36 * agentle hasn't even looked up 3 yet
21:44:50 <dtroyer> m3 is taken by BMW
21:45:10 <johnthetubaguy> dtroyer: lol
21:45:23 <dhellmann> that's an unrelated field, though, so I think we're ok
21:45:26 <bknudson> performance release for that release
21:45:28 <agentle> heh
21:45:33 <bknudson> focus on performance for that release
21:45:47 <agentle> Alright do I get a cookie if we finish early?
21:45:48 <Rockyg> dtroyer: I thought there was actually a trademark fight over that between BMW and someone else?
21:45:51 <johnthetubaguy> I want to do 5 milestones...
21:45:57 <agentle> Or a penalty flag?
21:46:07 <etoews> cookie cookie cookie
21:46:08 <dtroyer> Rockyg: I wouldn't be surprised, don't recall
21:46:09 <Rockyg> Cookie!
21:46:12 <johnthetubaguy> I have been told its called an early mark
21:46:17 <johnthetubaguy> no idea what that is
21:46:35 <agentle> I have never heard of an early mark in all my word nerdery days.
21:46:44 <ttx> cookie.
21:46:48 <agentle> alrighty then!
21:46:51 <agentle> Thanks everyone.
21:47:12 <agentle> Looking for someone to run this meeting next week, let ttx know if you're interested. He sends training guides AND reminders.
21:47:12 <ttx> Thanks agentle!
21:47:18 <agentle> #endmeeting