16:00:20 #startmeeting oslo 16:00:21 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:24 ./ 16:00:26 The meeting name has been set to 'oslo' 16:00:33 o/ 16:00:34 howdy 16:00:36 hi 16:00:36 o/ 16:00:44 o/ 16:00:49 (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 o/ 16:01:21 courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dougwig, e0ne, flaper87, garyk, haypo, 16:01:25 o/ 16:01:27 courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, spamaps 16:01:47 ok, i guess we'll just see if dims arrives late, if not thats ok to 16:01:54 hello 16:01:59 hola 16:02:04 #topic Red flags for/from liaisons 16:02:11 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 o/ 16:02:53 Nothing from keystone as far as I know 16:02:59 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 Otherwise I don't have anything 16:03:33 I have a question re: oslo.db and downgrades 16:03:37 but that's not a 'red flag' 16:03:40 :) 16:03:41 I will wait. 16:04:18 so seems like nothing to raise, which is great :) 16:04:25 less red the better :-P 16:04:46 #topic Releases for Mitaka 16:04:59 so dims seems to have put up https://review.openstack.org/#/c/253860/ 16:05:17 so check that out if you need a release, or if you don't need one... 16:06:23 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 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 cool 16:07:36 gcb: ^^ 16:07:57 we do a lot of releases. 16:08:04 haypo, yes will do that better 16:08:05 dhellmann: if i recall correctly, recent 2.6 changes were restricted to unit tests 16:08:28 and remove python 2.6 work around 16:08:37 bknudson, we def do 16:08:37 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 lol 16:09:33 Hello all. 16:09:39 jungleboyj, hello 16:10:32 #topic Rename tenant->project idea 16:10:47 oslo_context should use tenant rather than project 16:10:49 johnsom_, so whats the whole status of this discussion 16:10:58 Ha! Not my idea, but trying to keep up. 16:11:10 I was embarrassed to propose use of oslo_context to keystone since it used tenant :( 16:11:51 to change that we'll have to add an alias in one direction or the other so that both names work 16:11:55 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 We were just wondering if those are going to change and if so when. 16:12:25 dhellmann +1 16:12:41 sorry, i don't know the plan. do you (who?) want to *drop* the tenant name, or just make an alias? 16:13:08 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 http://docs.openstack.org/developer/debtcollector/api.html#debtcollector.moves.moved_read_only_property (could be the alias mechanism)? 16:13:31 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 bknudson, I'm happy to pick it up from your list. 16:13:39 (it's not documented as read-only) 16:13:41 haypo : other teams are trying to standardize on "project" apparently (we seem to change this every other year or so) 16:13:56 ok http://docs.openstack.org/developer/debtcollector/api.html#debtcollector.moves.moved_property bknudson i guess that then :-P 16:14:05 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 just use the moved_property decorator if you can 16:14:57 dhellmann, what would you consider as length of deprecation, after M? 16:14:58 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 oh the good ole days 16:15:45 lol 16:15:48 Do we need a openstack-spec for that ? 16:15:59 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 #link http://article.gmane.org/gmane.comp.cloud.openstack.devel/70846/match=rename+tenant+project+discussion 16:16:07 we need to leave it there for all supported releases, so when M goes out of support 16:16:15 That seems to be the start of the recent neutron thread on the topic 16:16:38 johnsom_, thanks 16:16:47 bknudson : ++ 16:17:03 ... so I think that means can be removed in the P release 16:17:18 bknudson : assuming all consuming projects have been updated 16:17:21 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 yeah, let's keep an eye on this but not jump right on it 16:17:45 I'll get around to it eventually if nobody else does 16:17:48 (i've also seen the project/tenant renaming toggle for the last 3-4 years, ha) 16:18:40 someone should come up with a 3rd word so we can stop toggling back and forth 16:18:42 bknudson, fair enough, if rbradfor u want to, thats ok to 16:18:50 dhellmann, protenant 16:18:55 if rbradfor does it I'll be happy to review 16:19:11 harlowja_at_home, bknudson happy to monitor ML discussion and take this on. 16:19:13 tenaproj 16:19:24 we switched keystone to use unicorn for a while 16:19:29 :) 16:19:58 rbradfor, cool, feel free :) 16:20:05 https://review.openstack.org/#/c/97838/ 16:20:19 lol 16:20:25 lol 16:20:29 nice 16:21:07 #topic oslo.db and downgrades 16:21:12 amrith, yt 16:21:31 what did u want to bring up? 16:22:22 ok guess we'll have to skip that :) 16:22:34 yes 16:22:39 am here, was looking for a link 16:22:39 ah 16:22:41 kk 16:22:41 can't find it now 16:22:47 it is about the cross project spec 16:22:50 re: downgrades 16:23:03 I was wondering whether all projects are doing this 16:23:11 and whether oslo.db couldn't just handle it 16:23:13 keystone doesn't support downgrades 16:23:13 #link http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html 16:23:15 without a change in the projects. 16:23:47 amrith: I believe you would still need to update the projects code 16:23:58 e.g. to modify CLI 16:24:01 I think the spec is just "stop doing downgrades" right? Do we have to change any code? 16:24:25 https://review.openstack.org/#/c/152337/ 16:24:31 so there's code change 16:24:32 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 and we have to remove all the downgrade actions 16:24:53 I was wondering (a) whether that is required and (b) whether there's abetter way 16:25:08 here are mor elinks 16:25:10 more links 16:25:11 .. [1] https://review.openstack.org/#/c/152337/ 16:25:11 .. [2] https://review.openstack.org/#/c/167554/2 16:25:11 .. [3] https://review.openstack.org/#/c/167834/ 16:25:11 .. [4] https://review.openstack.org/#/c/167189/2 16:25:11 .. [5] https://review.openstack.org/#/c/165740/ 16:25:27 I get these from a trove spec https://review.openstack.org/#/c/252477/ 16:25:42 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 say, in OSLO? 16:25:50 that's the question. 16:26:01 seems like a decent question 16:26:09 perhaps http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/sql/migration_helpers.py#n152 should live in oslo.db ? 16:26:23 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 Ron, hello 16:26:50 I think you know who I am ;) 16:27:13 amrith, of course! 16:27:17 amrith: what code? 16:27:18 I'm asking with my Trove hat, not with a "database guy" hat 16:27:32 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 rpodolyaka, ya its a tough thing to have oslo.db enforce 16:28:01 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 there's a work item in the spec that says to upgrade oslo.db to return errors on downgrade 16:28:08 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 if oslo.db added something we could use it in keystone 16:28:56 bknudson, right, or maybe its a variation of that thing in keystone, not sure 16:28:57 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 amrith : the spec is not "do not ever do downgrades" it says "downgrades do not need to be supported" 16:29:36 so it's up to the project teams to decide whether they want to support downgrades or not 16:29:37 + 16:29:40 dhellmann, this may be semantic 16:29:46 but the cross project spec states: 16:29:47 * Stop support of migrations with downgrade functions across all 16:29:47 projects 16:29:51 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 I read that as a TC mandate that projects should not support downgrade 16:30:00 :) 16:30:19 and since the listed alternative (which is dismissed) is that "Downgrade paths can continue to be supported." 16:30:20 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 I interpret it to mean that downgrades SHALL NOT be supported. 16:31:07 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 OK, thanks 16:31:22 so it is up to the projects to do it. thanks! 16:31:53 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 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 since we're going to try supporting rolling upgrades in keystone maybe we can do downgrades in a limited way 16:32:49 as in, you can downgrade as long as you haven't started any new keystones 16:32:51 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 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 well what do u play on TV? 16:33:21 mfisch is an operator and is a co-author of the no-downgrades spec 16:33:31 I got an answer, I'm fine with moving on. On TV I play politician (also in real life). 16:33:38 true: am elected 16:33:49 donald is that u 16:34:01 * amrith searches for hair piece. 16:34:03 ha 16:34:12 fyi: donald is not elected. 16:34:14 so no. 16:34:20 lol 16:34:34 ok, moving on 16:34:39 thanks! 16:34:47 np 16:34:56 #topic Open oslo-specs 16:35:11 sooo just wanted to bring any needed attention to any oslo specs if needed 16:35:19 #link https://review.openstack.org/#/q/project:openstack/oslo-specs,n,z 16:35:42 more eyes/views on https://review.openstack.org/#/c/247902/ i think would be good 16:35:53 'Replace incubator with unstable libraries.' 16:36:24 also I think https://review.openstack.org/#/c/226157/ is nice for oslo folks to look at 16:36:43 in general its the larger openstack spec for backwards compat by lifeless 16:36:59 and i think the creator(s) wanted to ensure oslo folks read over it espeically 16:37:07 'Backwards compat for libraries and clients.' 16:37:22 so if people get some time, please checks those out (if u haven't already) 16:38:23 Any other specs people want to raise besides those? 16:39:09 ok, assuming not then :-P 16:39:30 #topic Open discussion 16:39:50 anything else from folks that they want to bring up? 16:40:01 (if not that's ok to) 16:40:49 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 u may want to get your place checked for bugs 16:41:13 lol 16:41:48 ok, going one 16:41:54 Is there any plan to clean up bugs ? 16:42:09 sure 16:42:18 some bugs were fixed , but still in progress status 16:42:25 actually i'm not sure, whats the thoughts there? 16:42:34 seems like a good idea to clean up bugs 16:42:54 I try to triage bug and close some 16:43:05 gcb, where u just thinking of closing some, changing progress and all? 16:43:39 i'd be ok with that, maybe let's find dims after this and see what he thinks 16:44:19 gcb : http://lists.openstack.org/pipermail/openstack-dev/2015-December/081612.html 16:45:15 gcb, where u thinking of more cleanup than in ^ ? 16:45:41 I just did some clean up in oslo.policy 16:46:11 and found some bugs were fixed in code , but still in confirmed and other "open" status 16:46:22 ya, that seems like general cleanup then 16:46:34 yeah, that's the sort of thing we need to do by hand. thanks for starting that, gcb 16:46:41 maybe during one of our doc sprints, we should also do a doc/bug sprint 16:46:45 doc/bug cleanup sprint 16:47:15 or just do it as u find them 16:47:46 yes , maybe I set up a etherpad to record the to-do list 16:47:48 harlowja_at_home : ++ 16:47:58 gcb, that'd be great 16:49:08 #action gcb harlowja talk with dims about doc/bug cleanup sprint day (maybe before next year?) 16:49:19 seems like we could get one of those in before next year 16:49:22 *maybe* 16:49:22 lol 16:49:41 worth a try, but unsure, never know with peoples vacations 16:50:15 I didn't have vactions this month :-) 16:50:22 I don't 16:50:27 :) 16:51:25 okie dokie, i guess for anything else we can move back into #openstack-oslo 16:51:47 going once 16:52:03 going twice 16:52:14 sold 16:52:19 #end-meeting 16:52:24 #endmeeting