16:01:08 #startmeeting oslo 16:01:09 Meeting started Fri Jul 11 16:01:08 2014 UTC and is due to finish in 60 minutes. The chair is dims_. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:13 The meeting name has been set to 'oslo' 16:01:14 o/ 16:01:21 hi all 16:01:24 o/ 16:01:27 * markmc only barely here 16:01:35 Hi! 16:01:36 markmv, :) 16:01:39 markmc, :) 16:02:56 #topic Review action items from previous meeting 16:03:26 Agenda is here - https://wiki.openstack.org/wiki/Meetings/Oslo 16:04:09 i can see all items marked as done or merged or released in this section 16:04:22 +1 16:04:25 anything else we need to talk about? 16:04:31 from prev meeting 16:04:56 I can't find it in agenda, but it is ready to review and merge https://review.openstack.org/#/c/93424/ 16:05:18 i159, thanks will look at it 16:05:26 moving to next topic 16:05:30 #topic Report from Sprints/ParisJuno2014 16:05:43 how many of us made it there? 16:05:56 o/ 16:06:06 and markmc and haypo 16:06:43 any updates for us flaper87 ? 16:06:43 The summary is that we went through lots of reviews, we discussed in depth asyncio, came out with a plan (markmc sent an email about this) 16:06:59 We also reviewed the amqp1.0 driver for olso.messaging 16:07:21 and talked to the team proposing such drivers about what's missing and how feasible it is to get it done 16:07:30 summary about that last point is that there's still hope 16:07:33 ;) 16:07:58 Also, we moved mask_password out of `log` into strutils 16:08:02 that's pretty much it 16:08:22 thanks flaper87 16:08:41 any questions for flaper87 from anyone else? 16:08:50 #topic Red flags for/from liaisons 16:09:01 any liaisons here today? 16:09:10 * jogo o/ 16:09:15 just a heads up here: Marconi has adopted oslo.i18n and there's a patch under review for glance 16:09:22 but I haven't been behind 16:09:26 have been* 16:09:28 flaper87, nice 16:09:42 It's a bit weird to have to create the `i18n.py` module on each project but... 16:09:55 I guess that's the best we can do to avoid injecting `_` to the builtins 16:10:00 and keepint things explicit 16:10:24 flaper87, reminds me...what do we do about handling _() in other oslo-incubator code within a project? 16:11:12 * dhellmann appologizes for being late 16:11:39 dims_: I've kept gettextutils around for now 16:11:51 until oslo-inc is fully migrated to oslo.i18n 16:11:56 and projects are synced 16:11:59 right 16:12:07 so we leave that as-is 16:12:08 I don't think we should modify them manually in each project 16:12:42 that's what I've done and it makes more sense to me 16:12:42 any other concerns from liaisons? 16:12:52 flaper87, ack. agree 16:12:52 oslo syncs are magical enough already 16:12:54 dims_: I talked that through with bknudson for keystone, and he came up with a way to monkey patch gettextutils 16:13:13 dhellmann: for the sake of magic? (joke) 16:13:15 flaper87: agreed, I thought we would move the modules in the incubator to i18n as they graduate 16:13:16 :D 16:13:54 dhellmann: sounds good. We should probably migrate to i18n the ones that won't graduate soon 16:13:58 * dims_ steps back to let dhellmann take over :) 16:14:11 #link https://review.openstack.org/104400 16:14:17 but I given the state of syncs in projects, I don't thik we should worry much about it 16:14:20 that's the keystone changes for i18n 16:14:42 s/I given/given/ 16:15:19 dims_, thanks for picking up my slack :-) 16:15:30 flaper87: yeah, not a high priority 16:15:32 dhellmann, so the magic is the last few lines in i18n.py? 16:15:41 dims_: yes 16:15:49 lgtm 16:16:36 the other suggestion was to create a local enable_lazy() function that calls both functions in the 2 versions of gettextutils until that module is no longer needed in the projects, but the monkeypatching works, too 16:16:41 dhellmann, how exactly do they test if stuff is working :) (dumb question) 16:17:13 dims_: that's not a dumb question, it's actually a thing that's blocking the TC from adopting a policy that projects must support translation 16:17:30 ah ok 16:17:31 dims_: Ajeager is working on adding a test job for that 16:17:49 I think the plan is to run the regular d-g tests with translation enabled 16:18:29 were there any red-flags? 16:18:37 dhellmann, no red flags 16:18:53 ok, dims_, since you're the chair I don't think I can change the topic 16:19:08 #topic Exception filtering proposal 16:19:24 hi 16:19:26 im here! 16:19:27 let's tag team dhellmann 16:19:31 OK 16:19:35 dims_: great, thanks! 16:19:37 (dims_ you can chair dhellmann by doing #chair dhellmann ) 16:19:47 #chair dhellmann 16:19:48 Current chairs: dhellmann dims_ 16:19:49 so there’s a lot of stuff coming in that builds on this proposal, e.g. things that want to filter on exceptoins 16:19:55 w00t thanks flaper87 16:19:55 flaper87: nice, thanks! 16:20:38 so i want to make sure ppl are cool with this, and i have more things for it coming later, and if so we can get it in 16:21:11 * rpodolyaka looked at the spec but haven't left comments yet 16:21:12 zzzeek: the proposal looked good to me, and I agreed with bnemec's comments on tweaks, but there were no major issues 16:21:48 my patches are in general going to be big like this since I have bigger things to do 16:21:51 I'll wait for rpodolyaka and viktors to leave their +1, and give everyone else a chance to review it, too, before approving. how about by tuesday? 16:22:12 its fine by me! ive jhust been holding up other patches from other folks until this goes in 16:22:13 Yeah, I was torn on even -1'ing that. 16:22:16 zzzeek: I haven't had a chance to look at the code change yet, but will after the spec is approved 16:22:29 ok so the big thing here is that, it back-ports some new SQLA functionality 16:22:43 dhellmann: sure! 16:22:43 e.g. the event is new in sqla 0.9.7, but here ive re-implemnted it for 0.96 backwards 16:22:52 beekneemech: the point about the location of the exceptions is good, since we did have an oslo.exceptions module planned at one point and we want the spec to be accurate in that regard 16:23:04 and theres a bit more i think i should add to it, supporting being able to mark an exception as a “disconnect”, we were just talking about that for a percona issue 16:23:19 rpodolyaka: which versions of sql are we supporting in production now? 16:23:24 dhellmann: Yeah, that's what I was thinking. I had to go check if we actually had that module. :-) 16:23:30 dhellmann: 0.8.4+ 16:23:37 teh 0.9.7 feature supports that, will add it here, but it means a tiny bit more of SQLA internals will be restated in oslo.db.sqlalchemy.compat 16:23:51 oslo.db.sqlalchemy.compat is where I’ll be putting all these “reimplement things that are in newer SQLA versions” 16:23:59 beekneemech: is it there, or was it something we just discussed? 16:24:14 +1 on compat 16:24:17 dhellmann: No, I didn't find anything. 16:24:22 rpodolyaka: OK great 16:24:34 what i want to try to do there, evertyhing in compat only targets existing releases, never anything future 16:24:46 so we don’t have to be too scared of private API access in there 16:24:50 ok, I like the general approach of that compat module, too, and I'll leave it up to you all to ensure that these features work on all of the versions of sqla we advertise that we support 16:25:01 dhellmann: ok greart 16:25:26 zzzeek: that's a great point on private api access, we should write that down somewhere so we can refer people to it during reviews -- I'm quite likely to forget and -1 something myself :-) 16:25:28 zzzeek, some of us use DB2 at the moment, if you hadn't already heard :) 16:25:57 dims_: yeah i just put up https://review.openstack.org/106406 in response to https://review.openstack.org/92182 16:26:14 thanks zzzeek 16:26:30 I think we all agree on the general plan for this, then, is there anything else to say? 16:26:35 dims_: i worked on the DB2 driver with the IBM folks, I got it up to speed for SQLA 0.8 and all 16:26:49 very cool 16:27:22 ok, we can come back to details on this during open discussion if needed. 16:27:31 #topic Adoption status 16:27:31 #link https://etherpad.openstack.org/p/juno-oslo-adoption-status 16:27:51 flaper87: did you say the marconi work on oslo.i18n was done, or in progress? 16:28:10 dhellmann: marconi merged, glance https://review.openstack.org/#/c/105453/ 16:28:28 #info marconi has adopted oslo.i18n 16:28:41 #info glance use of oslo.i18n up for review https://review.openstack.org/#/c/105453/ 16:29:26 I know we hit some issues with getting alpha releases of other libs into the global requirements 16:29:30 #info the fix to allow alpha releases to be added to the requirements list is up for review 16:29:30 #link https://review.openstack.org/#/c/106125/ 16:29:40 and since I wrote up my notes, it has merged :-) 16:29:47 #info that fix is actually merged 16:29:59 \o/ 16:30:13 #action dhellmann poke the reviews for adding alpha versions of oslo libs to global requirements 16:30:54 #topic Approved specs 16:30:54 we have 3 approved specs 16:30:54 #info oslo.utils - https://review.openstack.org/#/c/98431/ 16:30:54 #info rootwrap daemon mode - https://review.openstack.org/#/c/94613/ 16:30:54 #info taskflow conditional execution - https://review.openstack.org/#/c/98946/ 16:31:21 \o/ 16:31:23 we should probably be slowing down on writing new specs, and concentrate on finishing the work on the ones we've already started :-) 16:31:32 ack :) 16:31:36 #topic Nearly approved specs 16:31:36 I will approve these specs later today or Monday unless anyone objects 16:31:36 #info greenio executor for oslo.messaging - https://review.openstack.org/#/c/104792/ 16:31:36 #info redis backend for taskflow - https://review.openstack.org/#/c/105298/ 16:31:37 #info AMQP 1.0 driver for oslo.messaging - https://review.openstack.org/#/c/96729/ 16:31:38 #info scoping for atoms and flows - https://review.openstack.org/#/c/100048/ 16:32:13 all of those lgtm and had someone from the library in question vote in a positive way 16:32:53 #topic Specs needing review 16:33:10 in addition to zzzeek's spec from earlier, I’d like some feedback from the oslo.messaging team about this one 16:33:17 #info cross-service profiling changes in oslo.messaging - https://review.openstack.org/#/c/103825/ 16:33:40 the change itself isn't large, but I want to make sure we understand the implications 16:34:44 does anyone have any other specs they were counting on having approved this cycle? we have some that have lingering -1 comments that aren't addressed, so I assume those are low priority items 16:35:12 dhellmann: https://review.openstack.org/#/c/105796/ 16:35:21 dhellmann: spec for olso.messaging 16:35:47 Alexei_987: did I see a code change to go with that one somewhere? 16:36:05 dhellmann: https://review.openstack.org/#/c/104983/ 16:36:44 Alexei_987: ok 16:36:47 any others? 16:36:53 dhellmann: there are also some diagramms in the spec - old http://goo.gl/osO69Q , new - http://goo.gl/h3G5XS 16:37:29 Alexei_987: ok, you're going to need to render those in ascii or something so we can review them without relying on external links 16:37:44 ascii sucks 16:37:54 it have plantuml test in the spec 16:37:58 it has* 16:38:03 Alexei_987: http://git.openstack.org/cgit/openstack/oslo-specs/tree/specs/template.rst#n18 16:38:24 dhellmann: yes but ascii cannot help here 16:38:35 dhellmann: I want to add uml diagramms 16:38:47 dhellmann: IMHO we should add support for plantuml 16:38:50 Alexei_987: we can take this offline, but I'm not inclined to be terribly flexible on this point 16:39:06 https://review.openstack.org/#/c/105796/2/specs/juno/oslo-messaging-server-main-loop/main_loop_current.uml 16:39:36 did anyone else have any other specs we should make a priority? 16:40:33 ok, moving on then 16:40:34 #topic oslo.utils graduation status 16:40:44 #link https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-utils 16:40:44 the repository for the new library has been set up, good work dims_! 16:40:44 #link http://git.openstack.org/cgit/openstack/oslo.utils 16:41:17 dims_: how much work is left before you can tag 0.1.0? 16:41:19 dhellmann: Oh plantuml can generate ascii diagramms... I will update the spec with those 16:41:30 Alexei_987: that works 16:41:36 dhellmann, i'll check and let you know later 16:41:43 today 16:41:45 dims_: ok, sounds good 16:42:03 #topic oslo.serialization graduation status 16:42:03 #link https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-serialization 16:42:15 beekneemech: how is that looking? 16:42:57 dhellmann: Not started yet, but one of the things that have been eating all of my time lately is done so I'm hoping I can get started on my specs finally. 16:43:08 good news! 16:43:25 #topic oslo.concurrency graduation status 16:43:25 #link https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-concurrency 16:43:31 I assume the same here? 16:43:35 Ditto :-) 16:43:43 ok 16:44:06 we're coming up on j2 next week, so we should go ahead and retarget bps we know we aren't going to finish by then 16:45:04 it's better to keep the bp list accurate than to rush the work through 16:45:19 #topic Release review 16:45:19 stand by for paste-dump... 16:45:36 #info oslo.i18n 0.1.0 16:45:36 #link https://etherpad.openstack.org/p/oslo-i18n-1.0.0 16:45:37 #info oslo.vmware 0.4.0 16:45:37 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/039230.html 16:45:37 #info oslosphinx 2.2.0.0a2 16:45:38 #link https://etherpad.openstack.org/p/oslosphinx-2.2.0 16:45:39 #info pbr 0.9.0 16:45:40 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/039481.html 16:45:41 #info oslo.config 1.4.0.0a2 16:45:42 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/040013.html 16:45:43 #info oslo.messaging 1.4.0.0a3 16:45:44 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/039669.html 16:45:45 #info oslo.db 0.3.0 16:45:46 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/039738.html 16:45:47 That’s a nice *long* list. Good work everyone! :-) 16:45:57 +1 16:46:13 d:) 16:46:32 I'm really really happy with the progress we've made already. I know we have hit a few roadblocks, but the work you're all doing is solid. 16:46:35 Thank you all! 16:47:07 +1 ") 16:47:10 dang, that's exiting 16:47:12 do we anticipate any other releases in the next week? 16:47:39 rpodolyaka, viktors: am I up to date on oslo.db there, or did I miss a 0.4.0? 16:48:07 dhellmann: yes, it up to date 16:48:13 viktors: ok, good 16:48:40 #topic review priorities for this week 16:48:51 #info db migration test issues (devananda) 16:48:51 this one has been on our agenda for a couple of weeks, so it would be good to close it out soon 16:48:51 #link https://review.openstack.org/#/c/93424/ 16:48:51 related to two bugs: https://bugs.launchpad.net/ironic/+bug/1327397 and https://bugs.launchpad.net/nova/+bug/1328997 16:48:53 Launchpad bug 1327397 in oslo "No notice given when db migrations are not run due to missing engine" [High,In progress] 16:49:09 o/ 16:49:26 it would be great if we could roll that into an oslo.db release next week, so let's jump on reviewing it asap 16:49:46 * rpodolyaka adds it to the review queue 16:49:50 speaking of oslo.db, I was pinged on the eventlet / transaction locking issue in oslo.db a few days ago 16:50:08 there's a review up for a test for that bug, which zzzeek and I both -1'd because it's not really testing it 16:50:09 devananda: is that the topic from the ML about adding a test? 16:50:18 yep. lemmme get the link 16:50:20 devananda: i cant keep track of all the things people are doing withj that 16:50:25 ok, if the test is bad we don't want it but if the test is good we do want it :-) 16:50:27 devananda: some ppl are testing mysql-connector 16:50:33 devananda: some ppl dealing with that test 16:50:49 zzzeek: cool. i was just raising awareness of it :) 16:51:06 i think changing the mysql driver is a really big change and id expect that the whole world of openstack projects are going to complain if they realized we are doing that 16:51:15 taht problem loks like it will affect multiple projects 16:51:17 well 16:51:17 zzzeek: it's probably too late in the cycle to change the database connection library we will use for this release, but it's good to have the testing done so we can consider the change for early in K 16:51:26 except that we've been wanting to get away from this bug for years 16:51:44 *the bugs in eventelt+mysqld 16:51:45 mysqldb 16:51:54 dhellmann: good point, so, I want to try to focus on https://bugs.launchpad.net/oslo/+bug/1339206, which will allow us to write tests that can easily be run on many backends 16:51:57 Launchpad bug 1339206 in oslo "oslo.db test suite is too rigidly hardcoded to a small number of potential database backends" [Medium,Triaged] 16:52:10 devananda: yep, and I think we have an easy way to achieve that now as teams migrate to oslo.db, since we can update the requirements in one place 16:52:29 dhellmann: yep 16:52:49 can someone volunteer to coordinate the work on this issue, so we can keep track of all of it? 16:52:57 that's "coordinate" not "do" the work :-) 16:53:15 zzzeek: just to check, do you mean different db engines (myusql, pgsql, db2, ...), or different connectors? 16:53:29 we're going to want some detailed notes about what testing was done before we change libs, and in the mean time we have alternatives to work on 16:54:03 devananda: well either 16:55:07 devananda: the SQLA tests, I can run them like py.test —dburi mysql+mysqldb://… —dburi mysql+oursql://… —dburi mysql+mysqlconnector://.. and tests marked as “backend” will run for all three 16:55:13 zzzeek: expanding the testing options sounds like a good idea, too 16:55:32 zzzeek: ++ 16:55:57 dhellmann: so i might have to use some metaclass magic to make it happen in oslo.db’s tests 16:56:04 zzzeek: maybe we can use testtools scenarios and environment variables to achieve the same thing 16:56:22 dhellmann: OK maybe, ill look into that... 16:56:39 dhellmann: basically the discovery has to come up wiht more tests than are actually listed out 16:56:40 zzzeek: there should be some examples of using scenarios in the ceilometer test suite 16:56:48 yep, scenarios do that 16:56:49 dhellmann: e.g. a single piece of test code is multplied during discovery 16:56:51 dhellmann: ok 16:57:13 #info oslo.utils changes needed to allow a release 16:57:32 in addition to those review items we've already discussed, let's help dims with any reviews he needs to finish a first release of oslo.utils 16:58:00 * flaper87 is working on the strutils changes 16:58:02 are there any other review items up now that we should be prioritizing? 16:58:16 flaper87: excellent, ping us as needed for reviews 16:58:33 almost ready, I'm bikeshedding with myself on module names 16:58:38 the rest is done 16:58:39 heh 16:58:40 :P 16:58:54 btw, it's really weird to have `utils` in the module name 16:58:57 I just noticed that 16:59:01 oslo.utils.importutils 16:59:06 yeah, but 'str" is a bad module name 16:59:20 oh yeah, I wanted to use strings (joke) 16:59:21 :P 16:59:30 it'll be used as "from oslo.utils import importutils" and then later in the module "importuils.foo()" 16:59:44 mmh, right 16:59:52 it probably just look bad in the code base 16:59:53 so it looks weird, except in use :-) 16:59:56 like I said, I'm bikeshedding 17:00:09 ok 17:00:16 flaper87: I had the same comment on the spec. :-) 17:00:22 I think that's it, and we're out of time 17:00:25 thanks everyone! 17:00:28 beekneemech: :P ahhh, we love bikeshedding 17:00:33 cheers 17:01:18 #endmeeting