16:00:20 <harlowja_at_home> #startmeeting oslo
16:00:21 <openstack> Meeting started Mon Dec  7 16:00:20 2015 UTC and is due to finish in 60 minutes.  The chair is harlowja_at_home. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:24 <amrith> ./
16:00:26 <openstack> The meeting name has been set to 'oslo'
16:00:33 <johnsom_> o/
16:00:34 <harlowja_at_home> howdy
16:00:36 <bknudson> hi
16:00:36 <ozamiatin> o/
16:00:44 <rpodolyaka> o/
16:00:49 <harlowja_at_home> (let's see if dims shows up, he's traveling so I might be taking over, but he said he might be on)
16:00:53 <gcb> o/
16:01:21 <harlowja_at_home> courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dougwig, e0ne, flaper87, garyk, haypo,
16:01:25 <dhellmann> o/
16:01:27 <harlowja_at_home> courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, spamaps
16:01:47 <harlowja_at_home> ok, i guess we'll just see if dims arrives late, if not thats ok to
16:01:54 <haypo> hello
16:01:59 <harlowja_at_home> hola
16:02:04 <harlowja_at_home> #topic Red flags for/from liaisons
16:02:11 <johnsom_> This just popped up on my radar, so I haven't had time to search, is oslo going to go through and rename tenant->project like neutron is doing?  i.e. oslo_context
16:02:44 <rbradfor> o/
16:02:53 <bknudson> Nothing from keystone as far as I know
16:02:59 <harlowja_at_home> johnsom_, seems like we should, how about we bring that up in a little
16:03:03 * amrith listens intently to the answer to johnsom_ question as it would impact Trove.
16:03:12 <johnsom_> Otherwise I don't have anything
16:03:33 <amrith> I have a question re: oslo.db and downgrades
16:03:37 <amrith> but that's not a 'red flag'
16:03:40 <harlowja_at_home> :)
16:03:41 <amrith> I will wait.
16:04:18 <harlowja_at_home> so seems like nothing to raise, which is great :)
16:04:25 <harlowja_at_home> less red the better :-P
16:04:46 <harlowja_at_home> #topic Releases for Mitaka
16:04:59 <harlowja_at_home> so dims seems to have put up https://review.openstack.org/#/c/253860/
16:05:17 <harlowja_at_home> so check that out if you need a release, or if you don't need one...
16:06:23 <harlowja_at_home> seems like dhellmann wanted confirmation about 2.6 dropping on some of those, hopefully that got resolved though (but just incase folks check that out)
16:06:47 <dhellmann> yep, I'm happy with that. I left the request there for dims to process, but I can do it if he'd like since he's traveling
16:07:24 <harlowja_at_home> cool
16:07:36 <haypo> gcb: ^^
16:07:57 <bknudson> we do a lot of releases.
16:08:04 <gcb> haypo, yes will do that better
16:08:05 <haypo> dhellmann: if i recall correctly, recent 2.6 changes were restricted to unit tests
16:08:28 <gcb> and remove python 2.6 work around
16:08:37 <harlowja_at_home> bknudson, we def do
16:08:37 <dhellmann> haypo : yes, that has been confirmed. I asked for more descriptive commit messages in the future to cut down on the heart-attack factor when reviewing release requests ;-)
16:08:46 <harlowja_at_home> lol
16:09:33 <jungleboyj> Hello all.
16:09:39 <harlowja_at_home> jungleboyj, hello
16:10:32 <harlowja_at_home> #topic Rename tenant->project idea
16:10:47 <bknudson> oslo_context should use tenant rather than project
16:10:49 <harlowja_at_home> johnsom_, so whats the whole status of this discussion
16:10:58 <johnsom_> Ha!  Not my idea, but trying to keep up.
16:11:10 <bknudson> I was embarrassed to propose use of oslo_context to keystone since it used tenant :(
16:11:51 <dhellmann> to change that we'll have to add an alias in one direction or the other so that both names work
16:11:55 <johnsom_> Neutron is going through and re-naming tenant->project.  I don't have the background link handy.  We were updating Octavia and noticed some of the oslo APIs use tenant.
16:12:10 <johnsom_> We were just wondering if those are going to change and if so when.
16:12:25 <johnsom_> dhellmann +1
16:12:41 <haypo> sorry, i don't know the plan. do you (who?) want to *drop* the tenant name, or just make an alias?
16:13:08 <bknudson> as far as I know nobody proposed the change yet. it's on my todo list (not that I'll likely ever get to it)
16:13:12 <harlowja_at_home> http://docs.openstack.org/developer/debtcollector/api.html#debtcollector.moves.moved_read_only_property (could be the alias mechanism)?
16:13:31 <harlowja_at_home> anyone know how many places use tenant though, probably useful to figure that out also and see how to address each place
16:13:32 <rbradfor> bknudson, I'm happy to pick it up from your list.
16:13:39 <bknudson> (it's not documented as read-only)
16:13:41 <dhellmann> haypo : other teams are trying to standardize on "project" apparently (we seem to change this every other year or so)
16:13:56 <harlowja_at_home> ok http://docs.openstack.org/developer/debtcollector/api.html#debtcollector.moves.moved_property bknudson i guess that then :-P
16:14:05 <dhellmann> haypo : for us to support that, we would have to produce releases that used both names, then deprecate tenant over some period of time
16:14:45 <bknudson> just use the moved_property decorator if you can
16:14:57 <rbradfor> dhellmann, what would you consider as length of deprecation, after M?
16:14:58 <dhellmann> unless someone is really excited about doing that work, I think I'd put it off to see how far the migration gets in other projects
16:15:38 * harlowja_at_home remembers back in the day when this was brought up like 3 years ago, ha
16:15:45 <harlowja_at_home> oh the good ole days
16:15:45 <harlowja_at_home> lol
16:15:48 <gcb> Do we need a openstack-spec for that ?
16:15:59 <dhellmann> rbradfor : well, lifeless wants "never break the API" so maybe "forever"? but we have standard rollout requirements for removing deprecated things http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
16:16:03 <johnsom_> #link http://article.gmane.org/gmane.comp.cloud.openstack.devel/70846/match=rename+tenant+project+discussion
16:16:07 <bknudson> we need to leave it there for all supported releases, so when M goes out of support
16:16:15 <johnsom_> That seems to be the start of the recent neutron thread on the topic
16:16:38 <harlowja_at_home> johnsom_, thanks
16:16:47 <dhellmann> bknudson : ++
16:17:03 <bknudson> ... so I think that means can be removed in the P release
16:17:18 <dhellmann> bknudson : assuming all consuming projects have been updated
16:17:21 <harlowja_at_home> so i'm somewhat agreed with dhellmann if someone really is itching to do this work, sure, but it also might be worthwhile to let that ML discussion bake a little more?
16:17:43 <dhellmann> yeah, let's keep an eye on this but not jump right on it
16:17:45 <bknudson> I'll get around to it eventually if nobody else does
16:17:48 <harlowja_at_home> (i've also seen the project/tenant renaming toggle for the last 3-4 years, ha)
16:18:40 <dhellmann> someone should come up with a 3rd word so we can stop toggling back and forth
16:18:42 <harlowja_at_home> bknudson,  fair enough, if rbradfor u want to, thats ok to
16:18:50 <harlowja_at_home> dhellmann, protenant
16:18:55 <bknudson> if rbradfor does it I'll be happy to review
16:19:11 <rbradfor> harlowja_at_home, bknudson happy to monitor ML discussion and take this on.
16:19:13 <harlowja_at_home> tenaproj
16:19:24 <bknudson> we switched keystone to use unicorn for a while
16:19:29 <harlowja_at_home> :)
16:19:58 <harlowja_at_home> rbradfor, cool, feel free :)
16:20:05 <bknudson> https://review.openstack.org/#/c/97838/
16:20:19 <harlowja_at_home> lol
16:20:25 <rbradfor> lol
16:20:29 <harlowja_at_home> nice
16:21:07 <harlowja_at_home> #topic oslo.db and downgrades
16:21:12 <harlowja_at_home> amrith, yt
16:21:31 <harlowja_at_home> what did u want to bring up?
16:22:22 <harlowja_at_home> ok guess we'll have to skip that :)
16:22:34 <amrith> yes
16:22:39 <amrith> am here, was looking for a link
16:22:39 <harlowja_at_home> ah
16:22:41 <harlowja_at_home> kk
16:22:41 <amrith> can't find it now
16:22:47 <amrith> it is about the cross project spec
16:22:50 <amrith> re: downgrades
16:23:03 <amrith> I was wondering whether all projects are doing this
16:23:11 <amrith> and whether oslo.db couldn't just handle it
16:23:13 <bknudson> keystone doesn't support downgrades
16:23:13 <dhellmann> #link http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html
16:23:15 <amrith> without a change in the projects.
16:23:47 <rpodolyaka> amrith: I believe you would still need to update the projects code
16:23:58 <rpodolyaka> e.g. to modify CLI
16:24:01 <dhellmann> I think the spec is just "stop doing downgrades" right? Do we have to change any code?
16:24:25 <amrith> https://review.openstack.org/#/c/152337/
16:24:31 <amrith> so there's code change
16:24:32 <bknudson> looks like we've got some code for it: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/sql/migration_helpers.py#n152
16:24:41 <amrith> and we have to remove all the downgrade actions
16:24:53 <amrith> I was wondering (a) whether that is required and (b) whether there's abetter way
16:25:08 <amrith> here are mor elinks
16:25:10 <amrith> more links
16:25:11 <amrith> .. [1] https://review.openstack.org/#/c/152337/
16:25:11 <amrith> .. [2] https://review.openstack.org/#/c/167554/2
16:25:11 <amrith> .. [3] https://review.openstack.org/#/c/167834/
16:25:11 <amrith> .. [4] https://review.openstack.org/#/c/167189/2
16:25:11 <amrith> .. [5] https://review.openstack.org/#/c/165740/
16:25:27 <amrith> I get these from a trove spec https://review.openstack.org/#/c/252477/
16:25:42 <amrith> I'm wondering why each project must do this; shouldn't there be an easier and more centralized way of handling this
16:25:45 <amrith> say, in OSLO?
16:25:50 <amrith> that's the question.
16:26:01 <harlowja_at_home> seems like a decent question
16:26:09 <harlowja_at_home> perhaps http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/sql/migration_helpers.py#n152 should live in oslo.db ?
16:26:23 <rbradfor> amrith, I am not part of this discussion but as a person with some large RDBMS experience, removing downgrades is a bad idea. Restore to a known backup has multiple failure points.
16:26:44 <amrith> Ron, hello
16:26:50 <amrith> I think you know who I am ;)
16:27:13 <rbradfor> amrith, of course!
16:27:17 <bknudson> amrith: what code?
16:27:18 <amrith> I'm asking with my Trove hat, not with a "database guy" hat
16:27:32 <rpodolyaka> amrith: harlowja_at_home: so I'd leave this to projects.  IMO, oslo.db should allow one to do downgrades. as it's a library
16:27:56 <harlowja_at_home> rpodolyaka, ya its a tough thing to have oslo.db enforce
16:28:01 <amrith> that's the point rpodolyaka ... if the TC feels that downgrades are not a good idea, why wouldn't oslo.db enforce it?
16:28:02 <bknudson> there's a work item in the spec that says to upgrade oslo.db to return errors on downgrade
16:28:08 <dhellmann> I think we could eventually drop something in oslo.db but as rpodolyaka says we want oslo libs to enable the projects to support the features they want to have
16:28:40 <bknudson> if oslo.db added something we could use it in keystone
16:28:56 <harlowja_at_home> bknudson, right, or maybe its a variation of that thing in keystone, not sure
16:28:57 <amrith> I feel that operationally, projects and deployers are being put in an awkward situation by this change to declare downgrades as "bad".
16:29:04 <dhellmann> amrith : the spec is not "do not ever do downgrades" it says "downgrades do not need to be supported"
16:29:36 <dhellmann> so it's up to the project teams to decide whether they want to support downgrades or not
16:29:37 <rpodolyaka> +
16:29:40 <amrith> dhellmann, this may be semantic
16:29:46 <amrith> but the cross project spec states:
16:29:47 <amrith> * Stop support of migrations with downgrade functions across all
16:29:47 <amrith> projects
16:29:51 <harlowja_at_home> amrith, for that discussion, it would probably be better on the ML, i don't necessarily disagree, but undoing http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html is another can of worms :)
16:29:59 <amrith> I read that as a TC mandate that projects should not support downgrade
16:30:00 <rpodolyaka> :)
16:30:19 <amrith> and since the listed alternative (which is dismissed) is that "Downgrade paths can continue to be supported."
16:30:20 <harlowja_at_home> i'm not saying it can't be undone, its just ummm, a much bigger thing that i'm pretty sure oslo can't resolve :)
16:30:27 <amrith> I interpret it to mean that downgrades SHALL NOT be supported.
16:31:07 <dhellmann> amrith : ok, I didn't read it as such a strongly worded thing. Regardless, I don't think we need oslo.db to enforce that.
16:31:15 <amrith> OK, thanks
16:31:22 <amrith> so it is up to the projects to do it. thanks!
16:31:53 <amrith> will let the guy submitting the code go ahead in that case, and not hold it up expecting an oslo.db solution. that's the (actually, a) resolution I was looking for
16:31:57 <harlowja_at_home> amrith, i think so (and if u feel that the spec should be undone, def start that discussion, software isn't frozen in time)
16:32:02 <bknudson> since we're going to try supporting rolling upgrades in keystone maybe we can do downgrades in a limited way
16:32:49 <bknudson> as in, you can downgrade as long as you haven't started any new keystones
16:32:51 <amrith> harlowja_at_home, bknudson ... I cannot credibly speak as the voice of deployers since I'm not one, and don't play one on TV. I'm sure they have a voice and if and when they feel this is important they will raise it.
16:32:52 <harlowja_at_home> it will always be a tradeoff imho, downgrades, upgrades, correctness of either, where will people spend the time to ensure it works...
16:33:19 <harlowja_at_home> well what do u play on TV?
16:33:21 <bknudson> mfisch is an operator and is a co-author of the no-downgrades spec
16:33:31 <amrith> I got an answer, I'm fine with moving on. On TV I play politician (also in real life).
16:33:38 <amrith> true: am elected
16:33:49 <harlowja_at_home> donald is that u
16:34:01 * amrith searches for hair piece.
16:34:03 <harlowja_at_home> ha
16:34:12 <amrith> fyi: donald is not elected.
16:34:14 <amrith> so no.
16:34:20 <harlowja_at_home> lol
16:34:34 <harlowja_at_home> ok, moving on
16:34:39 <amrith> thanks!
16:34:47 <harlowja_at_home> np
16:34:56 <harlowja_at_home> #topic Open oslo-specs
16:35:11 <harlowja_at_home> sooo just wanted to bring any needed attention to any oslo specs if needed
16:35:19 <harlowja_at_home> #link https://review.openstack.org/#/q/project:openstack/oslo-specs,n,z
16:35:42 <harlowja_at_home> more eyes/views on  https://review.openstack.org/#/c/247902/ i think would be good
16:35:53 <harlowja_at_home> 'Replace incubator with unstable libraries.'
16:36:24 <harlowja_at_home> also I think https://review.openstack.org/#/c/226157/ is nice for oslo folks to look at
16:36:43 <harlowja_at_home> in general its the larger openstack spec for backwards compat by lifeless
16:36:59 <harlowja_at_home> and i think the creator(s) wanted to ensure oslo folks read over it espeically
16:37:07 <harlowja_at_home> 'Backwards compat for libraries and clients.'
16:37:22 <harlowja_at_home> so if people get some time, please checks those out (if u haven't already)
16:38:23 <harlowja_at_home> Any other specs people want to raise besides those?
16:39:09 <harlowja_at_home> ok, assuming not then :-P
16:39:30 <harlowja_at_home> #topic Open discussion
16:39:50 <harlowja_at_home> anything else from folks that they want to bring up?
16:40:01 <harlowja_at_home> (if not that's ok to)
16:40:49 <harlowja_at_home> if people are interested in any etcd or consul stuff feel free to review some of this showing up @ https://review.openstack.org/#/q/status:open+project:openstack/tooz,n,z
16:40:49 * rbradfor hears crickets in the background
16:41:12 <harlowja_at_home> u may want to get your place checked for bugs
16:41:13 <harlowja_at_home> lol
16:41:48 <harlowja_at_home> ok, going one
16:41:54 <gcb> Is there any plan to clean up bugs ?
16:42:09 <harlowja_at_home> sure
16:42:18 <gcb> some bugs were fixed , but still  in progress status
16:42:25 <harlowja_at_home> actually i'm not sure, whats the thoughts there?
16:42:34 <harlowja_at_home> seems like a good idea to clean up bugs
16:42:54 <gcb> I try to triage bug and close some
16:43:05 <harlowja_at_home> gcb, where u just thinking of closing some, changing progress and all?
16:43:39 <harlowja_at_home> i'd be ok with that, maybe let's find dims after this and see what he thinks
16:44:19 <dhellmann> gcb : http://lists.openstack.org/pipermail/openstack-dev/2015-December/081612.html
16:45:15 <harlowja_at_home> gcb, where u thinking of more cleanup than in ^ ?
16:45:41 <gcb> I just did some clean up in oslo.policy
16:46:11 <gcb> and found some bugs were fixed in code , but still in confirmed and other "open" status
16:46:22 <harlowja_at_home> ya, that seems like general cleanup then
16:46:34 <dhellmann> yeah, that's the sort of thing we need to do by hand. thanks for starting that, gcb
16:46:41 <harlowja_at_home> maybe during one of our doc sprints, we should also do a doc/bug sprint
16:46:45 <harlowja_at_home> doc/bug cleanup sprint
16:47:15 <harlowja_at_home> or just do it as u find them
16:47:46 <gcb> yes , maybe I set up  a  etherpad  to record the to-do list
16:47:48 <dhellmann> harlowja_at_home : ++
16:47:58 <harlowja_at_home> gcb, that'd be great
16:49:08 <harlowja_at_home> #action gcb harlowja talk with dims about doc/bug cleanup sprint day (maybe before next year?)
16:49:19 <harlowja_at_home> seems like we could get one of those in before next year
16:49:22 <harlowja_at_home> *maybe*
16:49:22 <harlowja_at_home> lol
16:49:41 <harlowja_at_home> worth a try, but unsure, never know with peoples vacations
16:50:15 <gcb> I didn't have vactions this month :-)
16:50:22 <gcb> I don't
16:50:27 <harlowja_at_home> :)
16:51:25 <harlowja_at_home> okie dokie, i guess for anything else we can move back into #openstack-oslo
16:51:47 <harlowja_at_home> going once
16:52:03 <harlowja_at_home> going twice
16:52:14 <harlowja_at_home> sold
16:52:19 <harlowja_at_home> #end-meeting
16:52:24 <harlowja_at_home> #endmeeting