21:04:05 <ttx> #startmeeting project
21:04:06 <openstack> Meeting started Tue Feb  4 21:04:05 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:04:07 <lifeless> o/ but otp too
21:04:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:04:09 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:04:10 <openstack> The meeting name has been set to 'project'
21:04:18 <ttx> #topic icehouse-3 progress
21:04:41 <ttx> We reviewed this on various 1:1s, progress doesn't look too bad
21:04:46 <ttx> But you should definitely take advantage of the calm queue to finalize a few blueprints
21:04:55 <ttx> neutron should be back in the game soon, which will create load
21:04:58 <hub_cap> howdy
21:05:03 <ttx> so I'd recommend to review and approve what you can *now*
21:05:24 <ttx> gate 9-deep at 2100 UTC, that's been a long time
21:05:38 <ttx> so take advantage of it
21:06:01 <ttx> #topic icehouse velocity compared to previous cycles
21:06:17 <ttx> I looked into icehouse-2's velocity
21:06:27 <ttx> It appears that icehouse-2 was not that catastrophic, if you compare it with last year's grizzly-2
21:06:36 <ttx> Keystone, Glance and Horizon in particular did a lot better this year
21:06:48 <ttx> So I think we just need to acknowledge that the second milestone in October-April cycles is not that busy
21:06:57 <ttx> learn from history, which repeats itself
21:06:59 <dolphm> define catastrophic?
21:07:33 <ttx> dolphm: some were thinking we did less than 33% of what we expected
21:07:43 <ttx> based on blueprint targets
21:08:07 <ttx> We usually catch up that little 2nd milestone with a very busy 3rd milestone though, compared to April-October cycles
21:08:15 <ttx> So we'll see how it goes
21:08:16 <jeblair> oy
21:08:20 <ttx> comments on that ?
21:08:38 <dolphm> "based on blueprint targets" is basing a statement on a LOT of variables :)
21:08:45 <jeblair> so i think that's what's driving sdague's proposal to slim the gate down; hopefully we'll move that along soon
21:09:10 <jeblair> (also, zuul and nodepool scaling improvements are in progress), hopefully should help with i3 gate load
21:09:38 <ttx> dolphm: right. But it created a feeling. Which we had to address before it became a rumor
21:09:58 <jeblair> ttx: because after rumor is truth...
21:10:11 <ttx> especially when picked up by lazy journalists
21:10:28 <ttx> anything else on that topic ?
21:10:36 <annegentle> ttx: snort
21:10:55 <ttx> jeblair: btw there are a bunch of tripleo things stuck in the queue pipe, I suppose that's a known issue ?
21:11:22 <jeblair> ttx: yes, tripleo cloud is offline, tripleo ops are working on it
21:11:36 <jeblair> lifeless: is on it
21:11:53 <ttx> ack
21:12:03 <ttx> #topic log translation plan (dhellmann)
21:12:07 <ttx> dhellmann: around?
21:12:10 <dhellmann> here
21:12:11 <dhellmann> Log translations came up on the mailing list recently
21:12:14 <ttx> #link https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain
21:12:15 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/025572.html
21:12:22 <dhellmann> I will be writing all of this up on the LoggingStandards wiki page, but wanted to cover it briefly here to make sure all of the PTLs understand the approach we’ve settled on so there are no surprises.
21:12:26 <dhellmann> We have requests to separate the log message translations from other translations.
21:12:31 <dhellmann> We’ve recently added the ability to log in multiple languages as part of this.
21:12:38 <dhellmann> Next, we are going to add separate translation marker functions similar to _() with names like _LE and _LW to allow us to extract the messages into different catalogs.
21:12:42 <dhellmann> Having separate catalogs will let each translation team prioritize which, if any, log messages they translate for their operators.
21:12:47 <dhellmann> We are going to skip debug messages, for this phase of the project, and focus only on messages at INFO or higher levels.
21:12:52 <dhellmann> When we’re ready, reviewers should ensure that log messages are translated using the function for the level associated with the log output (info, warning, etc.).
21:12:57 <dhellmann> The _() marker should only be used for end-user messages from exceptions and API calls.
21:13:00 <dhellmann> issues or questions?
21:13:21 <hub_cap> lol
21:13:39 <markwash> _LE => error, _LW -> warn ?
21:13:43 <ttx> processing...
21:13:46 <dhellmann> markwash: yes
21:14:20 <dhellmann> unfortunately, we can't just pick up messages from the LOG.foo() calls directly, so we have to have marker functions for them
21:14:27 <ttx> dhellmann: Like this plan. Been talking about it for some time now
21:14:29 <bknudson> _() is for debug?
21:14:36 <dhellmann> _() is for user facing messages
21:14:40 <dhellmann> we aren't translating debug messages
21:14:41 <markwash> "" is for debug ;-)
21:14:45 <dhellmann> right
21:14:46 <ttx> it's the only way to get decent i18n coverage anyway
21:14:51 <devananda> ++
21:15:01 <bknudson> so if we've got _() on debug message, remove it?
21:15:01 <dhellmann> ttx:  yeah, I think we *finally* have agreement on an approach
21:15:08 <dhellmann> bknudson: yes, eventually
21:15:15 <Daisy> Yes. Translators want t focus on high priority messages to translate.
21:15:22 <devananda> dhellmann: is this written up somewhere yet?
21:15:31 <dhellmann> bknudson: once all of the tools are in place, I'll announce all of this on the dev mailing list and encourage people to make the updates
21:15:42 <dhellmann> it will be up to the individual projects to decide how they do that, of course
21:15:48 <devananda> ^ answerd my question, thanks
21:16:03 <dhellmann> at this point I'm mostly looking for +0 or -2 votes :-)
21:16:04 <hub_cap> works for me (/me looks into actually getting the i18n set up in trove)
21:16:26 <bknudson> choosing _() for user facing seems like it will wind up catching a lot of debug unless we go through and remove _() from all debug
21:16:32 <ttx> all seem in agreement
21:16:34 <bknudson> since that's what they are now
21:16:43 <dhellmann> bknudson: yes, all messages are marked like that now
21:17:12 <dhellmann> I recommend updating all messages in a given file to the right translation marker at the same time, but not necessarily doing it for all files in a projects in one patch because of merge conflicts
21:17:25 <Daisy> messages marked with _() was around 7000+ in Havana.
21:17:44 <jd__> so we would have to change debug from _() to "" ?
21:17:45 <dhellmann> Daisy: wow
21:17:50 <dhellmann> jd__: right
21:17:53 <notmyname> translating log messages seems weird to me. but I'm a native English speaker, too, so I feel I'm probably biased
21:18:09 <dhellmann> notmyname: yeah, this is a specific request we've had from some operators
21:18:25 <jd__> dhellmann: I don't like that, can't we teach log to ignore _() if the level is debug?
21:18:27 <dhellmann> the previous approach of using _() for everything overwhelmed translators for languages where the operators didn't care about this
21:18:29 <kgriffs> my only reservation is it may make it harder for an operator to google and find help
21:18:39 <kgriffs> but, I think that is solvable by writing error codes
21:18:41 <ttx> ok, next topic ?
21:18:46 <dhellmann> kgriffs: the logs can actually output in multiple languages at the same time
21:18:55 <kgriffs> dhellmann: gtk!
21:18:56 <dhellmann> ttx: that's all I had
21:19:07 <markwash> kgriffs: I think its optional to decide to run with logs in a given locale, no?
21:19:13 <dhellmann> markwash: also true
21:19:16 <notmyname> kgriffs: ya, that was my concern too
21:19:32 <notmyname> dhellmann: so log in different languages for twice the fun?
21:19:40 <notmyname> and by fun I mean log volume
21:19:57 <dhellmann> notmyname: sure, it's a balance between knowing exactly what the error means and being able to deal with it, and having to look everything up because you don't read english
21:20:22 <dhellmann> notmyname: and pick as many languages as you like, to multiply the fun ;-)
21:20:56 <dhellmann> ttx: I think we can move on
21:21:11 <ttx> #topic discuss the move to unversioned endpoints in the service catalog (annegentle/dolphm)
21:21:19 <jd__> dhellmann: I had a question if you missed it but that can wait :)
21:21:21 <dolphm> o/
21:21:24 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026079.html
21:21:24 <annegentle> here
21:21:35 <ttx> so there seem to be a need for discussion here
21:21:36 <dolphm> there's also a second thread about this on list; one sec
21:21:40 <dhellmann> jd__: sorry, I did, I'll come back to it during open discussion
21:21:58 <dolphm> http://lists.openstack.org/pipermail/openstack-dev/2014-February/026177.html
21:22:00 <dolphm> #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026177.html
21:23:00 <dolphm> this second thread is quite long and just picked up momentum today
21:23:42 <dolphm> our goal for keystone is to allow our client to support unversioned auth_url's, and authenticate according to the available API (and that's done as of the current release)
21:23:54 <dolphm> e.g. http://paste.openstack.org/raw/62480/
21:24:20 <dolphm> we also want to move from /v2.0/ for identity endpoints in the service catalog, directly to an unversioned endpoint
21:24:51 <dolphm> which has brought up a few questions
21:25:31 <dolphm> one of the questions brought up in the second thread was whether or not the community had any interest in supporting older clients
21:26:13 <dolphm> if, for example, keystone immediately dropped the versioned endpoint in the service catalog, we'd break clients from the pre-havana timeframe -- is that a problem?
21:26:55 <ttx> dolphm: well, we said in the past that you should always be running the latest client
21:27:08 <ttx> a.k.a. we don't maintain stable branch of clients
21:27:12 <markmc> ttx, could be a different language
21:27:16 <ttx> or "the mordred rule"
21:27:20 <markmc> my instinct is that yes, it's an issue
21:27:25 <markmc> without a lengthy deprecation period
21:27:55 <dolphm> we've been operating under the assumption that we want to support the last year or so of client releases as much as possible, which has been challenging/frustrating
21:28:01 <ttx> but i agree that we should avoid breaking if we can
21:28:07 <annegentle> dolphm: I think you'd need at least a year of deprecation warnings
21:28:22 <markmc> it's not just client releases - think about raw usage of the API, without client libraries published by us
21:28:42 <kgriffs> yes, SDK authors everywhere would be up in arms
21:28:49 <dolphm> markmc: so that brings up another subtlety...
21:28:51 <annegentle> dolphm: but so much of the onus of the warnings would be on the deployers themselves?
21:29:05 <dolphm> this isn't an API change, it's a default configuration / documentation change that has impact on clients
21:29:31 <markwash> it seems a shame that the goal of excellence (providing integrated CI for stable supported stuff) gets in the way of the goal of good (providing a fix version like keystoneclient 0.X.1 as a fix for 0.X.0)
21:29:39 <dolphm> the API stays the same, it's just the value being returned by the API is new, and requires a new client respond to it correctly
21:29:51 <markmc> dolphm, then perhaps recommend that ops change from the default if they themselves don't care about older clients?
21:30:01 <dhellmann> dolphm: what if instead of http://host/ returning the list of versions, we add "/versions" to the published endpoint and if that URL is under a version it only returns itself?
21:30:02 <markmc> dolphm, and warn them we're going to change the default ourselves in N releases ?
21:30:19 <annegentle> markmc: that's my thinking too, we change the install guide to indicate how to set up your catalog differently
21:30:40 <annegentle> markmc: then the providers are responsible for communicating endpoint changes (which still sounds awful)
21:30:48 <dolphm> markmc: what do we do in devstack in the mean time? the new recommended value? or continue with the pending-deprecation value?
21:31:09 <markmc> annegentle, yeah
21:32:14 <annegentle> I think you have to communicate pending deprecation for a while, year at least (2 releases I really mean)
21:32:17 <ttx> markmc: oh, so that would amount to stable API change ? Yeah. Bad.
21:32:21 <markmc> dolphm, yeah, I don't know - sorry, I'm just blindly saying "this does sound like the kind of breaking change we don't want"
21:32:34 <markmc> dolphm, without understanding the issue in full detail
21:32:43 <annegentle> markmc: dolphm: it still seems tied into changing Identity v3 API, right?
21:33:07 <markmc> dolphm, changing the default in devstack may be fine
21:33:24 <dolphm> it is... so what i don't want to do is publish the /v3/ endpoint in the catalog as well, which is just confusing and sets a terrible precedent for other projects
21:33:37 <annegentle> dolphm: and I don't yet understand if the python-keystoneclient supports Identity v3 API?
21:34:19 <ttx> dolphm: sounds like this thread could see some more aging
21:34:29 <ttx> it's not ready to be drunk yet
21:34:31 <dolphm> annegentle: the client library fully support the v3 API, however v3 is not exposed at all to the CLI
21:34:41 <dolphm> ttx: i'm in the same boat, i'm actually not caught up on the second thread yet
21:34:52 <annegentle> dolphm: ok that's useful
21:34:55 <dolphm> but happy to warm everyone up to the topic :)
21:35:04 <ttx> ok, let's continue discussion on that thread, because without more context it's difficult to say more than "change is bad"
21:35:07 <dolphm> annegentle: the goal is to transfer responsibility for CLI exposure to python-openstackclient
21:35:16 <annegentle> ttx: dolphm: this thread also matters for projects like heat that want to go completely to Identity v3
21:35:28 <dolphm> annegentle: ++
21:35:34 <annegentle> so I'm good with percolation for a while
21:35:47 <dolphm> ttx: bring it up again in a week or two?
21:35:53 <ttx> dolphm: sure
21:36:06 <ttx> #topic discuss Glance scope expansion (markwash)
21:36:09 <markwash> o/
21:36:17 <ttx> markwash: want to introduce the subject ?
21:36:19 <markwash> sure
21:36:50 <markwash> we're looking at adding on to the v2 api to make glance a suitable place to catalog other types of resources
21:37:19 <markwash> things like whole instance specifications (in terms of block device mapping, etc), heat templates, murano packages, what-have-you
21:37:45 <markwash> the idea is sort of, if an openstack service uses a certain artifact as a starting point for users, it would be nice to have it in a catalog like images
21:37:51 <markwash> and track dependencies
21:38:02 <markwash> anyway, this could be seen as scope expansion
21:38:10 <markwash> in my view, its more of refining the original scope
21:38:28 <markmc> "launchable resources"?
21:38:31 <markwash> so I wanted to bring it up with other folks to see if the idea initially makes sense to you
21:38:40 <markwash> markmc: something like that
21:39:10 <david-lyle> markwash: and then just filter by type in the API call?
21:39:21 <markwash> yeah something along those lines
21:39:31 <markwash> david-lyle: ^^
21:39:45 <hub_cap> so do u see Trove's heat templates it uses to generate clusters as falling under that
21:39:54 <markwash> we don't have an established api spec yet
21:40:20 <kgriffs> markwash: what is an example of something that would NOT be appropriate to store in Glance under this project scope refinement?
21:40:21 <devananda> markwash: would you see that catalog containing references to only launchable things, or also buildable things (eg, diskimage-builder elements), or components of things (eg docker) ?
21:40:24 <ttx> catalog, index...
21:40:25 <hub_cap> i think its valid, we are currently storing a ton of stuff in /etc
21:40:40 <hub_cap> kgriffs: ice cream
21:40:44 <kgriffs> w00t
21:40:48 <markwash> hub_cap: hmm, I might have to get back to you on that one, it depends sometimes on who the consumer of the resource is
21:40:54 <ttx> markwash: I certainly prefer to see those in Glance than in separate projects
21:41:02 <david-lyle> +1
21:41:04 <markmc> markwash, have you heard any concerns or disagreements about the idea from others that you could summarize?
21:41:12 <annegentle> markwash: I'm with ttx in collecting
21:41:17 <markwash> kgriffs: well, for example, keypairs probably wouldn't
21:41:21 <markwash> maybe that's not a great example
21:41:31 <kgriffs> I guess my point is, it may be helpful to specify some things that are out of scope to help avoid this getting out of hand.
21:41:53 <hub_cap> yea and how is this diff from say, config aas?
21:42:01 <annegentle> markwash: and from a docs standpoint it'll be a bit of a tough transition to 'splain what all can be stored in a glance catalog
21:42:01 <kgriffs> otherwise, people might start storing ice cream, pop-tarts, and all kinds of goodies in there. :p
21:42:13 <hub_cap> kgriffs: ice cream is not allowed :)
21:42:19 * kgriffs sad panda
21:42:20 <markwash> kgriffs: lol well they'd have to be somehow openstack affiliated pop-tarts :-)
21:42:51 <markwash> kgriffs: but your point is taken
21:42:59 <kgriffs> cool beans
21:43:00 <markwash> scrolling back
21:43:30 <dhellmann> some of these things could also be thought of as belonging in an object store, though having a catalog query api on front is definitely nice -- that might be another area where you could talk about differences
21:43:39 <markwash> devananda: I'll have to think a bit more about buildable things. . that sounds like it might be more of a workflow
21:44:11 <markwash> markmc: no big concerns yet but we've been in a bit of a silo
21:44:36 <markwash> but I think making the class of artifacts clear is an obvious concern
21:44:40 <ttx> markwash: next step: ML thread, then you can propose a mission statement for the TC
21:44:52 <ttx> long overdue anyway
21:44:56 <markwash> annegentle: good point
21:45:25 <markwash> okay, thanks for the feedback folks
21:45:28 <markmc> ttx, I'd suggest a mission statement for the current scope
21:45:29 <hub_cap> markwash: do u think that this could get into a config aas system ? wasnt something recently propsed?
21:45:30 <markwash> sorry if I missed some questions
21:45:37 <hub_cap> u can answer tha toffline
21:45:39 <hub_cap> *that
21:45:44 <markmc> and then, later, when the details of the proposal for a new API is fleshed out ...
21:45:44 <ttx> markmc: as a first step ?
21:45:46 <hub_cap> im channeling ttx's keyboard today
21:45:46 <markwash> hub_cap: I'm not really familiar with config aas
21:45:51 <markmc> revisit expanding the scope in the mission
21:45:57 <markwash> hub_cap: maybe we can discuss over sours
21:46:00 <ttx> hub_cap: I switched mine with yours
21:46:07 <markmc> i.e. don't lead scope expansion simply with a mission statement tweak
21:46:09 <hub_cap> lol ttx :)
21:46:19 <ttx> hub_cap: works a lot better.
21:46:31 <hub_cap> markwash: first sour sunday in berkeley is at the start of beer wk. i expect to see u there
21:46:58 <ttx> markwash: maybe start with the current mission statement, like markmc said
21:47:06 <markwash> well, in a way you could see this idea coming out of the question "what is our mission exactly?"
21:47:29 <ttx> markwash: so far I'd say that was serving disk images
21:47:33 <markwash> well
21:47:40 <markwash> we don't serve them, we prefer you download them directly
21:47:45 <markwash> and they're often not jsut disk images
21:47:46 <markwash> so yeah
21:47:47 <markwash> :-)
21:48:02 <markwash> considering container format can be ovf etc
21:48:03 <ttx> or registry
21:48:16 <ttx> feel free to prepare the terrain
21:48:21 <markwash> sounds good
21:48:45 <ttx> #topic Red Flag District / Blocked blueprints
21:48:56 <ttx> heat/x-auth-trust (Low, shardy, icehouse-3) depends on keystone/trusts-chained-delegation (Undefined, No assignee, No milestone)
21:49:09 <ttx> do we have shardy, zaneb or stevebaker ?
21:49:24 <dolphm> both of these are assigned to shardy -- and i believe i've seen progress on the keystone side?
21:49:38 <dolphm> there's nothing linked in the review though
21:49:46 <dolphm> in the bp*
21:49:47 <ttx> dolphm: question was about the lack of targeting on the keystone one
21:50:02 <annegentle> dolphm: yeah that keystone bp is without work on it so far I think?
21:50:07 <ttx> dolphm: you could consider making it low/icehouse-3 ?
21:50:27 * ttx digs for reviews
21:50:43 <dolphm> ttx: happily, but i'd like to follow up with shardy :)
21:52:10 <ttx> hah
21:52:12 <zaneb> sorry :(
21:52:16 <dolphm> ah, the specification was proposed, but not the implementation
21:52:37 <zaneb> shardy is not around atm
21:52:47 <zaneb> but this is not a bp I have heard much about
21:52:54 <zaneb> so we can probably defer
21:53:07 <zaneb> I don't think we'd consider it a blocker
21:53:16 <ttx> dolphm/zaneb: ok. If it comes back, make sure you sync first
21:53:17 <dolphm> the keystone bp was started in https://review.openstack.org/#/c/57481/
21:53:21 <mordred> o/
21:53:52 <ttx> dolphm: same thing ?
21:54:15 <dolphm> ttx: yes; it's proposing the API mechanism for this feature
21:54:37 <dolphm> i'll follow up with Matthieu Huin as well
21:55:02 <dolphm> (for some reason i thought the keystone bp was assigned to shardy; it's not assigned at all)
21:55:06 <ttx> zaneb: move it off i3 for the moment, and maybe sync with shardy when you have a chance
21:55:18 <zaneb> ttx: ok, will do
21:55:25 <ttx> Any other inter-project blocked work that this meeting could help unblock ?
21:55:37 <dolphm> zaneb: actually it looks like this has merged against a wishlist bug: https://review.openstack.org/#/c/57481/
21:56:33 <zaneb> dolphm: ok, I just bumped the bp to next and I will add it to the project meeting agenda for tomorrow
21:56:49 <ttx> ack, please unconfuse soon thx
21:56:55 <ttx> #topic Incubated projects
21:56:56 <markmcclain> ttx: just wanted to update that the nova team has patch in the merge gate which will unblock neutron
21:56:59 <SergeyLukjanov> o/
21:57:02 <dolphm> zaneb: i've marked the keystone bp as Implemented, even though it's sort of obsolete!
21:57:12 <ttx> markmcclain: great news !
21:57:14 <zaneb> lol, OK :D
21:57:26 <dhellmann> markmcclain: \o/
21:57:28 <SergeyLukjanov> savanna is going to setup async gating - https://review.openstack.org/#/c/68066/
21:58:09 <SergeyLukjanov> ttx, https://launchpad.net/savanna/+milestone/icehouse-3
21:58:25 <ttx> looks good to me
21:58:36 <devananda> o/
21:58:51 * ttx busily converts "unknown" to "not started"
21:59:10 <SergeyLukjanov> ttx, will do
21:59:27 <devananda> as of a few hours ago, our gate is finally unblocked :-D
21:59:27 <ttx> done
21:59:33 <SergeyLukjanov> ttx, thx
21:59:37 <ttx> devananda: cool
21:59:41 <devananda> I've also proposed adding some more -core so we can increase the rate of merges
22:00:00 <devananda> i3 is very aggressive for us ... hopefully that will help
22:00:23 <ttx> #topic Open discussion
22:00:28 <ttx> anything else in that last minute ?
22:00:37 <SergeyLukjanov> not from my side
22:01:02 <ttx> ok then
22:01:04 <ttx> #endmeeting