21:01:35 <ttx> #startmeeting project
21:01:36 <openstack> Meeting started Tue Mar 25 21:01:35 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:39 <openstack> The meeting name has been set to 'project'
21:01:46 <SergeyLukjanov> ttx, yup
21:01:50 <ttx> Agenda:
21:01:51 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:01:51 <SergeyLukjanov> ttx, it helps ;)
21:02:01 <ttx> SergeyLukjanov: that calls for a cron script
21:02:07 <stevebaker> \o
21:02:19 <ttx> #topic Progress towards RC1s
21:02:55 <ttx> We are slowly making progress to wards the first release candidates
21:02:59 <hub_cap> hi ttx
21:03:09 <ttx> Let me list the ETAs
21:03:16 <hub_cap> ttx we have one more we put in trove, fyi
21:03:19 <ttx> #info Keystone expected tomorrow
21:03:43 <ttx> #info Trove also expected tomorrow
21:03:52 <ttx> #info Cinder, Glance expected Thursday
21:03:56 <hub_cap> maybe thr ttx ;)
21:04:13 <ttx> #info Nova, Ceilometer expected Friday
21:04:29 <ttx> #info Neutron, Swift, Horizon expected early next week
21:04:38 <stevebaker> and heat
21:04:54 <ttx> #info Heat also expected early next week
21:05:08 <ttx> I think I have everyone
21:05:43 <ttx> That also doubles as dates we expect to open Juno development on
21:05:56 <ttx> and un-feature-freeze the frozen projects
21:06:32 <ttx> Then if new release-critical issues are found we open RC windows and spin new release candidates
21:06:41 <ttx> ...until release day
21:06:56 <dolphm> using backports from master to milestone-proposed?
21:07:03 <ttx> dolphm: exactly
21:07:33 <ttx> That's why it's important to nail the release-critical bugs now. After, it's more painful to do so with backports and reviewers distracted by Juno
21:07:52 <ttx> (nothing impossible, just more painful)
21:08:05 <ttx> Questions on that ?
21:08:08 <dolphm> ++ everyone is chomping at the bit to land changes for juno
21:08:23 <hub_cap> understatement :)
21:08:41 <ttx> #topic Dependency freeze
21:08:47 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/030729.html
21:08:58 <ttx> In summary we'll soft-freeze openstack/requirements changes to master until we cut all the RC1s
21:09:08 <ttx> At which point we'll cut a milestone-proposed branch there for release branches to consume
21:09:23 <ttx> We are cleaning up the requirements-core group and will make sure the core reviewers are aware of this policy
21:09:32 <sdague> yeh, I think everything that we need for the release besides the saraha client change is in
21:09:50 <sdague> so I'd recommend no other changes at this point unless there is an rc bug they are attached to
21:10:14 <ttx> yes, will send an email about this early tomorrow to requirements-core
21:10:27 <ttx> Questions on that ?
21:10:52 <dolphm> i haven't gotten a clear understand of how this affects dependencies ON clients
21:11:11 <dolphm> specifically, horizon's dependency on a minimum keystoneclient version?
21:11:26 <sdague> dolphm: that should be frozen at this point
21:11:32 <sdague> unless it's an rc bug
21:11:44 <dolphm> i believe there's an RC bug for this issue
21:11:52 <ttx> dolphm: I think david-lyle un-RCed it
21:12:03 <ttx> the change password thing ?
21:12:05 <dolphm> regardless, it'd be an exception if we release a keystoneclient tomorrow (0.7.0) and horizon wanted to require it?
21:12:10 <dolphm> ttx: yes
21:12:13 <sdague> dolphm: yes
21:12:18 <ttx> dolphm: I would consider that an exception yes
21:12:20 <sdague> because that forces the new version on everyone
21:12:25 <dolphm> ttx: i think the RC target got restored this afternoon
21:12:41 <ttx> we must just weigh the benefits with the drawbacks, and make sure packagers are aware of it
21:12:49 <ttx> dolphm: hah!
21:12:58 <ttx> things happen while I have dinner
21:13:18 <sdague> dolphm: so the minimum client issue is something we need a better story on
21:13:23 <dolphm> #link https://bugs.launchpad.net/horizon/+bug/1239757
21:13:24 <uvirtbot> Launchpad bug 1239757 in python-keystoneclient "Let users update their own password with Identity API v3" [Wishlist,Fix committed]
21:13:26 <dhellmann> ttx: the sun never sets on openstack
21:13:31 <dolphm> sdague: ++
21:13:37 <sdague> because it seems like every time there is a client bump, everyone wants to pull up min version
21:13:45 <sdague> even if it will work perfectly fine with the old version
21:13:53 <sdague> or as fine as it used to, with known bugs
21:14:08 <ttx> sdague: in that case it probably wouldn't, but agree on the general case
21:14:28 <sdague> sure so this is a major bump
21:14:32 <ttx> this is the first time we do this freeze, so there may be some rough edges and dark areas left
21:14:41 <dolphm> sdague: generally, i assume the community wants to consume new client features across projects, right?
21:14:55 <sdague> dolphm: sure, but you can let users upgrade
21:15:05 <sdague> we don't dump the min on sqla every time a new release comes out
21:15:07 <ttx> sdague: they want to rely on a new feature of the client and expose it -- it's even arguably a feature
21:15:18 <ttx> sdague: which is why I supported un-RCing it
21:15:22 <dolphm> conversely, i could see keystoneclient wanting to *push* new features to be consumed by other projects (say, a new implementation of something under the hood)
21:15:25 <sdague> ttx: relying on a new feature is a different thing
21:15:37 <sdague> and actually something we shouldn't be doing at this point in the cycle
21:15:40 <ttx> that said it's really a gap with some security impact
21:15:52 <ttx> so it's a bit grey
21:15:55 <ttx> david-lyle: around ?
21:16:11 <david-lyle> this would be nice functionality to have in Horizon for Icehouse, but we've supported keystone v3 since Havana without it
21:16:15 <dolphm> ttx: i'd like to understand the less-gray area first :)
21:16:43 <ttx> david-lyle: would you consider it a new feature ?
21:16:56 <dolphm> i mean, keystoneclient 0.7.0 is coming this week whether horizon requires it or not
21:17:05 <david-lyle> it's a descrepency between v2.0 and v3
21:17:09 <dolphm> ttx: technically, it's restoring a feature that was available in grizzly
21:17:19 <ttx> dolphm: and it will contain a security fix that everyone will want to have anyway
21:17:29 <dolphm> ttx: ++
21:17:36 <ttx> so in that case the min dep bump might be warranted for security reasons
21:17:47 <david-lyle> but we won't enable it without bumping the required client version
21:18:07 <sdague> david-lyle: and there is no way to conditionally support it?
21:18:15 <ttx> I think in that case we'll just accept the bump, but it's a bit of a special case (new version to close a CVE)
21:18:21 <dolphm> if keystoneclient.__version__ > (0, 7) ?
21:18:23 <dhellmann> david-lyle: are you checking the version of the installed client to see whether to enable it, or are you removing the code if the version doesn't go up?
21:18:30 <sdague> dolphm: yeh
21:18:56 <david-lyle> we have the functionality blocked now, would reenable
21:19:29 <david-lyle> we could add such a check if that's what it comes down to
21:20:32 <ttx> anyway, let's move on. By thursday everything should be clearer there
21:20:57 <ttx> dolphm: let's try this and come up with updated rules once we're done
21:21:02 <dolphm> ttx: ack
21:21:10 <ttx> #topic keystone v3 and plans for v2 (and how that affects other projects)
21:21:15 <ttx> russellb: floor is yours
21:21:37 <russellb> ah yes
21:21:46 <russellb> so there was confusion in our last nova meeting, so i figured i'd bring it up here
21:21:55 <russellb> i was able to catch up with dolphm a bit async from that
21:22:10 <russellb> but basically, there was confusion about the lifecycle of the keystone APIs and what it meant for projects like nova
21:22:24 <russellb> v2 deprecated?  if so, what does that mean for other projects, as well as deployers?
21:22:28 <russellb> is that written out anywhere?
21:22:59 <russellb> basically hoping dolphm can provide some clarity on what keystone folks have been thinking on this topic
21:23:00 <annegentle> I share these concerns
21:23:31 <dolphm> so, i think most of our strategy has gone undocumented so far, but our highest goal is to not break everyone :)
21:23:32 <david-lyle> I'm concerned v2 is deprecated but v3 support is minimal
21:23:46 <sdague> david-lyle: similar concerns
21:23:59 <sdague> especially as it moves us from something we test a ton in the gate
21:24:00 <russellb> i have a general bad feeling toward ever calling something deprecated unless you have a very specific timeline defined for when it can go away
21:24:05 <dolphm> at russellb's suggestion, i filed https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition to follow up on that early in juno so we have something to share & talk about
21:24:12 <sdague> being unsupported, and something we only test a little being official
21:24:26 <dolphm> sdague: deprecated != unsupported
21:24:28 <stevebaker> fwiw, heat is fully on v3
21:24:43 <dhellmann> dolphm: is it "frozen" then?
21:24:47 <dolphm> sdague: i consider v2 to be fully supported, and will continue to be fully supported until it's removed -- likely in pieces
21:24:49 <david-lyle> stevebaker: in the default domain only, I assume?
21:24:56 <russellb> frozen different than deprecated to me
21:25:00 <russellb> sends a different message
21:25:02 <dolphm> dhellmann: save for serious issues, yes
21:25:20 <dhellmann> russellb: right, I thought this might be a word-choice issue
21:25:41 <russellb> dhellmann: yeah, sounds like it could be ...
21:25:41 <dolphm> russellb: we freeze v3 at milestone 2 every cycle as well... so i agree
21:25:44 <stevebaker> david-lyle: sort of, we also have a special domain and create a project per stack, and a user per (some) resources
21:26:04 <dhellmann> dolphm: maybe frozen isn't quite right either -- you're just not adding new features to v2?
21:26:11 <russellb> so, 1) v2 still fully supported, 2) no timeline yet for when v2 would go away
21:26:13 <russellb> is that correct?
21:26:18 <dolphm> dhellmann: correct
21:26:40 <dhellmann> I would call that "normal". Why is it marked as deprecated?
21:26:46 <russellb> heh
21:26:54 <morganfainberg> russellb, isn't the typical nomenclature, deprecated -> obsoleted -> removed?
21:27:14 <russellb> we typically use "deprecated" to mean that it has been replaced and is scheduled to go away
21:27:17 <dolphm> russellb: 1) correct 2) one of our motivations for deprecating v2 in icehouse was that A) v3 has parity with v2, B) that gives us two full releases until we have the option to *start* removing unused bits
21:27:39 <jogo> russellb: Deprecated: v2 API is deprecated as of Icehouse in favor of v3 API and may be removed in K.
21:27:43 <jogo> http://logs.openstack.org/55/82255/4/gate/gate-tempest-dsvm-full/b819624/logs/screen-key.txt.gz?level=WARNING
21:27:49 <russellb> i don't see how it could be called deprecated when the majority of openstack itself doesn't use the new thing yet
21:27:52 <dolphm> i expect things like public-facing auth to be supported in some capacity for quite a while, even if under the hood it's just middleware rewriting requests for the v3 app
21:28:25 <russellb> just all sounds premature i guess
21:28:27 <russellb> and confusing
21:28:39 <devananda> dolphm: is marking it deprecated more a way to encourage projects to start moving away from it, rather than indicate that projects have already done so?
21:28:50 <dolphm> devananda: ++
21:29:06 <devananda> i think that disticntion is confusing some people, since AIUI, nova uses the latter terminology
21:29:06 <russellb> fwiw, i consider the primary burden of that move to be on keystone itself
21:29:08 <ttx> dolphm: I think there are other ways to encourage openstack projects to move away from it
21:29:10 <jogo> I think that is backwards
21:29:10 <russellb> i don't think a stick is helpful here
21:29:12 <dolphm> russellb: agree
21:29:24 <ttx> deprecation is more for users we don't control
21:29:36 <ttx> not for projects we can encourage to move internally
21:29:47 <dolphm> russellb: fwiw, keystoneclient 0.7.0 will finally let us start replacing code in other clients/services with much less code that will likely be accepted by those projects :)
21:30:02 <ttx> I think we should have a cross-project workshop on aligning to latest versions of APIs internally
21:30:14 <ttx> ISTR other projects also being hit
21:30:19 <russellb> so i think most people think of the status of the API as you describe it as not actually deprecated
21:30:30 <russellb> and we shouldn't call it that until we have a specific timeline for when *external* users will be affected
21:30:36 <annegentle> stevebaker: can heat not use v2 due to a need for domains? or roles?
21:30:36 <russellb> including a clear timeline and migration plan for them
21:30:49 <sdague> well the current deprecation does state "may be removed in K"
21:30:54 <sdague> so that's pretty specific
21:30:54 <annegentle> stevebaker: and how does heat use v3 when nova doesn't?
21:31:20 <sdague> perhaps we remove that part of the deprecation message at least?
21:31:23 <lifeless> annegentle: you can use v2 and v3 concurrently
21:31:35 <david-lyle> horizon had to back from having v3 as the default because of lack of cross service support
21:31:38 <annegentle> lifeless: so it's a matter of service catalog config?
21:31:43 <lifeless> annegentle: heat needs domains to let non-admins use waitconditions
21:31:45 <jogo> lifeless: only the v3 logic that was from v2
21:31:49 <lifeless> annegentle: yes, list both.
21:31:55 <ttx> dolphm: I tend to agree with russellb on that one. Would rather remove the deprecation message and then advocate for v2->v3 moves at Juno design summit
21:32:20 <ttx> then deprecate when you want users of the Api (not internal services) to move on
21:32:37 <sdague> at least until the official clients get support
21:32:55 <dolphm> ttx: on that note, what v2 *doesn't* have yet, is a way to advertise it's deprecated status to api end users -- i consider that a potential blocker to removing support later on that needs to be seriously considered
21:32:56 <dolphm> for example, a deprecated HTTP header in responses
21:32:56 <dolphm> all the deprecation advertising we're doing is really only within the openstack community, and for deployers
21:33:00 <russellb> largely a terminology / communication issue
21:33:00 <russellb> different uses of the terminology has caused some confusion here i think
21:33:00 <stevebaker> annegentle: we need it for domains. There is a v2 shim which has the old limitation of requiring the stack launching user to be an admin
21:33:00 <russellb> require it?
21:33:00 <russellb> or can use it?
21:33:00 <russellb> i think we've failed at some coordination here for some project(s) to require it, and others to not support it at all
21:33:17 <dolphm> (lots of sudden IRC lag for me)
21:33:22 <russellb> dolphm: same here
21:33:22 <ttx> dolphm: same here
21:33:28 <ttx> echo, too
21:34:01 <dhellmann> dolphm: does any API have a way to advertise its deprecated status?
21:34:03 <annegentle> stevebaker: lifeless: thanks, that's helpful
21:34:04 <stevebaker> annegentle: the credentials we use in the non-default domain are only for a very few heat API operations (for nova server -> heat communication)
21:34:12 <ttx> dolphm: if it's not targeted to users, should we remove that deprecation message ?
21:34:19 <david-lyle> you can't use non-default domain users with services that don't support v3
21:34:38 <annegentle> dolphm: yes I think the user-facing communication needs to not mention deprecation
21:34:42 <dolphm> dhellmann: i've seen proposals to alert clients at runtime, but haven't worked with anything functional myself
21:35:04 <dhellmann> dolphm: ok, I wasn't sure if you were worried about following some sort of precedent
21:35:25 <ttx> david-lyle: everything openstack should absolutely move to v3. But marking it deprecated for openstack admins to see won't really make that happen
21:35:31 <dhellmann> dolphm: I do like the idea of communicating with the client somehow, fwiw
21:35:40 <russellb> ttx: i think that's the crux of this conversation
21:35:49 <jogo> ttx: playing devils advocate here, why should we adopt keystone v3?
21:36:02 <ttx> jogo: because users like things like domains ?
21:36:04 <david-lyle> my argument is, you can't really use v3 fully so to mark v2.0 deprecated is flat wrong
21:36:08 <jogo> what benifits does it provide? (re: incentive vs stick)
21:36:26 <SergeyLukjanov> jogo, trusts support
21:36:30 <dolphm> ttx: the deprecation message is still relevant... and i don't think it's doing any harm. the choice of language in it was fairly careful as well (*may* be removed)
21:36:34 <SergeyLukjanov> (not related to domains)
21:36:40 <jogo> ttx: what about the hierarchial militancy? thats what I want
21:36:53 <morganfainberg> SergeyLukjanov, trusts are in V2.
21:36:54 <dolphm> dhellmann: i'd love to have a precedent to follow, if there's a good one :-/
21:36:56 <dhellmann> dolphm: how often does the deprecation message show up in logs?
21:37:05 <SergeyLukjanov> morganfainberg, oops
21:37:06 <dolphm> dhellmann: should be once
21:37:11 <david-lyle> jogo: so move from v2 directly to v4 bypassing v3?
21:37:15 <dhellmann> dolphm: no, but the sdk team might want to collaborate on setting up a protocol
21:37:16 <ttx> dolphm: maybe "deprecated" is an overloaded term in that message
21:37:16 <russellb> dolphm: thoughts on all this?  willing to drop the deprecation title for now to avoid the mass confusion?
21:37:24 * russellb curses irc lag
21:37:27 <dolphm> dhellmann: that'd be great
21:37:29 <jogo> I bring this up becasue of the recent nova v3 discussion -- where we had trouble coming up with a strong reason to make a major API rev
21:37:36 <dolphm> dhellmann: also great for a cross-project workshop :)
21:37:44 <dhellmann> dolphm: +1
21:37:47 <david-lyle> +1
21:37:52 <ttx> dhellmann: one on API versions ?
21:37:54 * dhellmann is looking forward to cross-project day in atlanta
21:37:58 <ttx> in general ?
21:38:02 <morganfainberg> dhellmann, ++
21:38:03 <dhellmann> ttx: on advertising api version deprecation
21:38:11 <dolphm> russellb: ttx: is there a better choice of words than "deprecated"?
21:38:13 <russellb> and what deprecation means?  :)
21:38:17 <dolphm> "pending deprecation"?
21:38:22 <russellb> i don't think it's actually deprecated based on the discussion
21:38:29 <ttx> +1 for on API version deprecation in general
21:38:30 <russellb> it's a fully supported thing even if you're not adding stuff
21:38:39 <russellb> we just have work to do across openstack to migrate to it
21:38:45 <dhellmann> yeah, it really seems like it's "stable" and we're still doing v3 development
21:38:46 <ttx> dhellmann: file while you think about it
21:39:06 <ttx> dolphm: "we are migrating away" ?
21:39:07 <dhellmann> ttx: I'll leave that to dolphm, I don't want to run that session :-)
21:39:24 <morganfainberg> dhellmann, i would classify v3 as stable, it is receiving new features, but it's not being broken.
21:39:30 <ttx> it's almost 11pm here don't expect me to get creative
21:39:37 <morganfainberg> dhellmann, stable, deprecated, etc all overloaded terms at this point
21:39:47 <russellb> and once *that* is done, we can talk deprecation
21:39:47 <russellb> deprecation means people outside of openstack itself have to take some action
21:39:47 <russellb> some migration path
21:39:47 <russellb> and i don't think we're quite at that point yet right?
21:39:47 <russellb> i'm a little sore on marking things deprecated without a schedule to actually remove, i guess
21:39:48 <dolphm> if there's a summit session on this, i'd like to start by defining "deprecated" :)
21:39:48 <dhellmann> morganfainberg: true
21:40:01 <devananda> russellb: ++
21:40:04 <ttx> russellb: ++
21:40:15 <dhellmann> but a schedule was given, right? K?
21:40:25 <jogo> dhellmann: heh yup
21:40:26 <ttx> dhellmann: was it?
21:40:29 <dhellmann> the question is, is that a real schedule because the other projects are going to be ready?
21:40:31 <morganfainberg> dhellmann, that is the default, it would be easy to change that.
21:40:34 <dolphm> dhellmann: havana shipped v2 and v3 side by side, both being labeled as "stable" (grizzly may have too)
21:40:38 <morganfainberg> dhellmann, (default is +2)
21:40:56 <jogo> ttx "Deprecated: v2 API is deprecated as of Icehouse in favor of v3 API and may be removed in K."
21:41:05 <ttx> basically, the deprecation mechanism woirks for end user migration, not so well for internal API migration
21:41:05 <jogo> http://logs.openstack.org/55/82255/4/gate/gate-tempest-dsvm-full/b819624/logs/screen-key.txt.gz?level=WARNING
21:41:12 <russellb> ok well step back, we need to remove that schedule
21:41:12 <russellb> because if stuff isn't migrated, that's unreasonable
21:41:12 <russellb> IMO
21:41:28 <dhellmann> it sounds like what we're asking is for the keystone team to *not* deprecate the V2 API until the rest of us are consuming it
21:41:39 <dhellmann> and so we need to see about making *that* a priority
21:41:40 <ttx> internal API migration has to happen prior to user-side deprecation
21:41:42 <jogo> dhellmann russellb: ++
21:41:52 <jogo> that is the model glance is taking as well
21:42:03 <jogo> they are deprecating old API after nova switches over
21:42:07 <devananda> i was just trying to word that well
21:42:15 <devananda> seems odd for keystone to set a schedule before other projects have migrated
21:42:16 * markwash nods
21:42:28 <ttx> devananda: hence the "may"
21:42:46 <ttx> devananda: because they have no real control over that
21:42:49 <devananda> the deprecation message is telling users "you need to migrate by K becayse we may remove it"
21:42:58 <ttx> which is why I think internal API migration has to happen prior to user-side deprecation
21:43:03 <morganfainberg> dhellmann, i lied, can't remove the "removed in" part, need to update oslo-incubator for that.
21:43:06 <morganfainberg> dhellmann, sorry.
21:43:20 <ttx> because otherwise you just can't have a realistic schedule
21:43:30 <morganfainberg> dhellmann, easy fix in either case.
21:43:38 <dhellmann> morganfainberg: we can update the incubator :-)
21:43:55 <morganfainberg> dhellmann, yesh.
21:43:56 <ttx> russellb: looks like you could argue that in a thread, I'm pretty sure there will be suggestions of alternate wording there
21:44:09 <ttx> russellb: it's kind of urgent though since keystone was about to tag RC1 tomorrow
21:44:40 <ttx> markwash: your input for how you do glance will be wanted on that thread -- consistency is good
21:44:58 <markwash> sounds fair
21:44:59 <dhellmann> morganfainberg: I'd even consider a concurrent change, rather than changing the incubator and then syncing
21:45:08 <morganfainberg> dhellmann, ++
21:45:23 <morganfainberg> dhellmann, was going to recommend that for ease of getting this through for RC.
21:45:25 <dolphm> russellb: is K* not a reasonable schedule?
21:45:27 * dolphm is about to give up due to IRC lag
21:45:31 <dhellmann> morganfainberg: just mention it in the commit message
21:45:37 <russellb> i think a documented migration plan + implementation of replacement across openstack is a prerequisite to setting that timeline
21:45:46 <dhellmann> russellb: +1
21:45:47 <lifeless> dolphm: its not reasonable to spam operator logs for a year
21:45:51 <jogo> russellb: +1
21:45:54 <markwash> in that vain I'm a bit concerned about running "both v2 and v3 in the catalog" since that seems. . inconsistent with what glance is doing. . but that's a different can of worms
21:45:59 <lifeless> dolphm: whether the timeframe is reasonable is entirely separate
21:46:01 <ttx> Hopefully we'll get better at communicating cross-project priorities -- classic deprecation mechanism is not the way to push internal API migrations imho
21:46:13 <markwash> and maybe I'm confused
21:46:54 <ttx> russellb: continue on ML thread ?
21:47:25 <ttx> ah, we lost russell
21:47:35 <ttx> ok, let's quickly move on
21:48:00 <dhellmann> ttx: that reminds me, I do have something to mention quickly when we get to open discussion
21:48:08 <ttx> #action russellb to quickly start a thread on keystone v2 deprecation
21:48:17 <ttx> quick let's action russellb and dolphm on plenty of things
21:48:26 <morganfainberg> ttx ++
21:48:30 <ttx> as lonas the bot is on my side of the split
21:48:41 <ttx> arh, he's back
21:48:54 <ttx> russellb: fyi #action russellb to quickly start a thread on keystone v2 deprecation
21:49:09 <ttx> #topic Red Flag District / Blocked blueprints
21:49:22 <ttx> Any other inter-project blocked work that this meeting could help unblock ?
21:49:30 <dhellmann> is anyone waiting on anything to land in oslo-incubator?
21:49:37 <ttx> that's a good one
21:49:48 * russellb stabs IRC
21:49:52 <russellb> I got the action
21:51:01 <ttx> dolphm: fwiw we moved to next topic, russell will start a thread asap to continue the discussion
21:51:23 <ttx> netsplit rt: Any other inter-project blocked work that this meeting could help unblock ?
21:51:41 <ttx> netsplit rt: <dhellmann> is anyone waiting on anything to land in oslo-incubator?
21:51:42 <dhellmann> esp. oslo-incubator changes
21:51:58 <ttx> Looks like not
21:52:01 <jogo> dhellmann: https://review.openstack.org/#/c/82675/
21:52:07 <jogo> just responded to your comment as well
21:52:15 <sdague> jogo: did you get the oslo.messaging log=INFO patches around?
21:52:17 <dhellmann> jogo: ack
21:52:26 <markwash> I think we got our oslo-db utf8 stuff in, so glance is good AFAICT
21:52:54 <dhellmann> jogo: +2 and sent to the rest of oslo-core for review
21:53:11 <jogo> sdague: nova landed, cinder and ceilo are pending .. neutron doesn't use oslo.messaging yet
21:53:16 <ttx> Oh, makes me think
21:53:16 <sdague> ok
21:53:18 <jogo> dhellmann: thank you
21:53:35 <ttx> All: don't forget to sync relatively recent translations before cutting RC1s
21:53:41 <stevebaker> heat not using oslo.messaging yet
21:54:42 <ttx> dolphm: do you have translations merges in keystone ?
21:54:50 <jogo> so I am a bit concerned about ceilometer's polling of APIs  ( http://openstack-in-production.blogspot.com/2014/03/cern-cloud-architecture-update-for.html )
21:55:27 <ttx> dolphm: answering my own quetsion: https://review.openstack.org/#/c/78525/
21:56:30 <ttx> jogo: maybe that would make a valid bug to bring to ceilo folks attention
21:56:40 <ttx> jogo: not sure it's been turned into a bug yet though
21:56:42 <dhellmann> ttx: +1
21:56:47 * jogo files a bug
21:57:04 <ttx> jogo: ping jd__ when done and start discussion there ?
21:57:17 <ttx> it's not completely too late yet :)
21:57:27 * ttx quickly moves on
21:57:28 <ttx> #topic Incubated projects
21:57:29 <sdague> honestly, I think it's too late to work on that for release :)
21:57:34 <SergeyLukjanov> o/
21:57:39 <SergeyLukjanov> re sahara https://launchpad.net/sahara/+milestone/icehouse-rc1
21:57:41 <ttx> devananda, SergeyLukjanov, kgriffs: o/
21:57:54 <SergeyLukjanov> renaming finished, we'll be ready for rc1 next week
21:58:00 <ttx> you still have a couple weeks before you really need to cut RC1s
21:58:09 <ttx> but as always the sooner the better
21:58:28 <SergeyLukjanov> ttx, yup, I think next week should be ok, Thu is the plan
21:58:37 <SergeyLukjanov> ttx, Apr 3
21:58:39 <ttx> just ping me when you want them
21:58:46 <ttx> i'll be around
21:58:49 <SergeyLukjanov> ttx, yup, thank you
21:58:53 <ttx> #topic Open discussion
21:59:00 <ttx> anything anyone?
21:59:08 <dhellmann> I plan to send a message to the ML tomorrow about the plan for oslo library releases in juno
21:59:12 <dhellmann> #link https://wiki.openstack.org/wiki/Oslo/JunoGraduationPlans
22:00:14 <SergeyLukjanov> dhellmann, sounds interesting
22:00:17 <ttx> wow more complex than I'd have thought :)
22:00:45 <dhellmann> there are still some issues to resolve about alpha releases, but I think we have everything else worked out
22:00:47 <ttx> dhellmann: sounds good (the message)
22:00:51 <SergeyLukjanov> ttx, ++
22:00:54 <kgriffs> ttx: we are close on rc1, have one more bug that I am checking on
22:00:59 <kgriffs> it may slip to juno
22:01:10 <ttx> kgriffs: you have plenty of time, your callreally
22:01:17 <ttx> ok, we need to clear the room
22:01:28 <ttx> thanks everyone!
22:01:35 <ttx> #endmeeting