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