16:00:18 #startmeeting oslo 16:00:19 o/ 16:00:19 Meeting started Fri May 30 16:00:18 2014 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:22 The meeting name has been set to 'oslo' 16:00:24 o/ 16:00:37 #link https://wiki.openstack.org/wiki/Meetings/Oslo 16:00:53 hi 16:00:54 #topic Review action items from previous meeting 16:01:02 #info rebased wheel publishing change, close to approval 16:01:07 #link https://review.openstack.org/#/c/56760/ 16:01:22 we're waiting for a time when the infra team can watch that as it goes in 16:01:39 o/ 16:01:42 after it's done, we'll be ready to test publishing alpha releases, and I'll probably do that with oslo.i18n, since that shouldn't break anyone 16:01:55 * mkoderer add a doc patch for oslotest warning about mocking time.time 16:02:16 I didn't notice that come in, but maybe I missed it? 16:02:58 #action dhellmann suggest boris-42 send email about having oslo adopt osprofiler 16:02:59 dhellmann: https://review.openstack.org/#/c/95411/ 16:03:10 I didn’t get to talk to boris-42 16:03:15 beekneemech: thanks! 16:03:28 ah, I was looking in the incubator, heh 16:03:30 o/ 16:03:39 #info added oslo-specs to the review links section of the wiki 16:03:54 #link https://wiki.openstack.org/wiki/Oslo#Review_Links 16:04:05 I think that's it for old business 16:04:11 #topic Red flags from liaisons 16:04:25 do we have any new issues this week? 16:05:03 going once 16:05:29 is this topic for 'please review important patches'? :) 16:05:58 rpodolyaka: no, this is where our liaisons tell us we've made their life hard in some way :-) 16:06:09 rpodolyaka: we'll get to priorities toward the end of the agenda 16:06:17 got it 16:06:52 ok, it sounds like nothing new this week, so let's move on 16:06:57 #topic oslotest adoption status 16:07:18 how are we doing with integrating oslotest into the projects? 16:07:36 has anyone *not* started this? 16:08:31 liaisons? 16:08:41 keystone is using it 16:09:02 #action dhellmann prod liaisons on oslotest adoption 16:09:19 thanks, bknudson :-) 16:09:20 dhellmann: oslotest should be listed in requirements.txt or test-requirments.txt ? 16:09:36 gcb: usually test-requirementst.txt, since it is only used for testing 16:09:39 Keystone is still using the config fixture that was in oslo-incubator fixtures... need to switch to the one in oslo.config (if it's in a release) 16:09:40 there is a review about this : https://review.openstack.org/#/c/96720/ 16:10:21 gcb: we need oslotest for database migration testing 16:10:21 I saw nova use it in reuirements.txt 16:10:24 bknudson: that's a good example of something we can use your help tracking in these status updates 16:10:54 gcb: ok, that's probably not right and we should work with nova and jogo to fix that 16:11:14 viktors: so we need also keep it in requirements.txt ,right ? 16:11:39 gcb: I think, "yes" - only for incubator and oslo.db 16:11:45 another "status update" -- python-keystoneclient is now up-to-date with oslo-incubator -- did a full sync 16:12:05 viktors: no, we shouldn't list oslotest in the runtime requirements for oslo.db if we can avoid it 16:12:15 bknudson: excellent! 16:12:17 gcb: right. we have base test cases for migration tests that are subclasses of oslotest BaseTestCase 16:12:34 dhellmann, bknudson is awesome like that 16:12:36 looks like it also uses module=fixture.config -- so that should be able to use from oslo.config 16:12:40 dhellmann: but DB migration tests that are related to oslotest BaseTestCase 16:12:56 viktors: those are *tests* though, right? 16:13:00 morganfainberg: I'm getting help from dstanek and steve martinelli. 16:13:09 bknudson, ack. 16:13:28 dhellmann: they are more like 'production' code than tests, as they are reused by projects 16:13:39 rpodolyaka: when do they run? 16:13:43 dhellmann: so we can't put them to tests/ dir 16:13:44 dhellmann: yes, but it's the part of common code - https://github.com/openstack/oslo.db/blob/master/oslo/db/sqlalchemy/test_migrations.py 16:13:54 But they should only be run as part of the unit tests in the consuming projects, right? 16:13:57 it doesn't matter where they live, it matters where they run 16:14:05 beekneemech: right 16:14:06 beekneemech: yes 16:14:13 If someone's calling that code at runtime they're doing it wrong. :-) 16:14:30 if they run during deployment, then oslotest should be in requirements.txt but if they only run during unit tests then oslotest should be in test-requirements.txt 16:14:39 make sense? 16:14:50 dhellmann: agreed 16:14:59 yes 16:15:01 viktors: ok, good 16:15:21 viktors, rpodolyaka : when the current blocking patches land, let's plan a brief pause for review before making the first oslo.db release 16:15:37 ok, that's clear, it should be removed from requirements.txt 16:15:51 gcb: That's my preference 16:16:10 If only to avoid confusion when people start using libs. 16:16:13 here's what I see for current uses of oslotest: 16:16:14 $ grep oslotest openstack/*/test-requirements.txt 16:16:14 openstack/heat/test-requirements.txt:oslotest 16:16:14 openstack/keystone/test-requirements.txt:oslotest 16:16:14 openstack/oslo.config/test-requirements.txt:oslotest 16:16:15 openstack/oslo.db-importing/test-requirements.txt:oslotest 16:16:16 openstack/oslo.db/test-requirements.txt:oslotest 16:16:17 openstack/oslo.i18n/test-requirements.txt:oslotest 16:16:18 openstack/oslo.messaging/test-requirements.txt:oslotest 16:16:19 openstack/tempest/test-requirements.txt:oslotest 16:16:20 openstack/tripleo-image-elements/test-requirements.txt:oslotest 16:16:26 beekneemech, gcb: right 16:17:06 that oslo.db-importing is a copy of the repo before it was imported into our git system, so ignore that 16:17:22 #topic oslo.messaging adoption status 16:17:35 how is this one going? any roadblocks? 16:18:29 $ grep oslo.messaging openstack/*/*requirements.txt 16:18:29 openstack/barbican/requirements.txt:oslo.messaging>=1.3.0a4 16:18:29 openstack/ceilometer/requirements.txt:oslo.messaging>=1.3.0 16:18:29 openstack/cinder/requirements.txt:oslo.messaging>=1.3.0 16:18:29 openstack/glance/requirements.txt:oslo.messaging>=1.3.0 16:18:30 openstack/ironic/requirements.txt:oslo.messaging>=1.3.0 16:18:31 openstack/keystone/requirements.txt:oslo.messaging>=1.3.0 16:18:32 openstack/nova/requirements.txt:oslo.messaging>=1.3.0 16:18:33 openstack/pycadf/requirements.txt:oslo.messaging>=1.3.0 16:18:34 openstack/requirements/global-requirements.txt:oslo.messaging>=1.3.0 16:18:35 openstack/sahara/requirements.txt:oslo.messaging>=1.3.0 16:19:53 we know neutron is still being worked on 16:20:28 heat as well 16:20:34 are the neutron or heat liaisons here? 16:21:11 therve is heat and salv-orlando is neutron 16:21:51 ok, I'll talk to them separately 16:22:02 #topic oslo.db graduation status 16:22:10 rpodolyaka, viktors: do you want to make a report? 16:22:16 dhellmann: ok 16:22:36 so we've been working on making the first release of oslo.db 16:22:43 there is few issue left 16:23:09 we need you reviews :) 16:23:14 we have to fix config usage due to markmc's comments. See https://review.openstack.org/#/c/94552/ (Fix usage of oslo.config) 16:23:21 *r 16:23:35 tpool spec: https://review.openstack.org/96468 16:23:45 tpool patch: https://review.openstack.org/96467 16:24:00 tpool blueprint :) https://blueprints.launchpad.net/oslo/+spec/add-tpool-proxy-wrapper 16:24:43 when those are merged, I think, we'll be ready for a pre-release 16:24:47 viktors: is oslo-incubator facade going to change to use the new factory arguments? 16:25:11 rpodolyaka: do we need https://review.openstack.org/#/c/94593/ (slave database connections in EngineFacade) as well? 16:25:27 bknudson: I suppose, yes 16:25:27 dhellmann: yeah, completely forgot about this one :( 16:25:42 bknudson: what change do you mean? 16:26:03 viktors: def from_config(cls, connection_string, conf, -> def from_config(cls, conf, 16:26:09 rpodolyaka: how about if we start an etherpad to track them? 16:26:13 the connection_string argument is removed 16:26:24 dhellmann: ack, I'll take an action item 16:26:40 #action rpodolyaka create etherpad to track oslo.db graduation status 16:27:08 bknudson: which version of that function is in the incubator and which is in oslo.db? 16:27:12 bknudson: yes, we are mada some changes in the oslo.config usage 16:27:19 *made 16:27:45 so yeah, APIs are still being polished, but we don't expect any big changes 16:27:48 dhellmann: incubator has connection_string argument. Keystone is using it 16:28:01 if you have recent oslo-incubator code in your project, should not be a problem 16:28:14 it would be an easier switch to oslo.db if the args were the same as the incubator version. 16:28:16 bknudson: so you have a separate configuration option that you pass to open a connection? 16:28:34 yes, I'd like to understand why they are different 16:28:45 dhellmann: right, it passes the connection string. Which is in the conf anyways. 16:28:46 bknudson: this particular change you are talking about is needed to fix usage of config in oslo.db 16:28:52 viktors, rpodolyaka : is that part of the patch you linked above? 16:28:59 dhellmann: yep, the first patch 16:29:08 dhellmann: https://review.openstack.org/#/c/94552/ 16:29:36 ok, so the thing markmc was saying was we should hide the config options that oslo.db defines from the applications that use it, but that doesn't mean we should prevent them from doing something using their own configuration options 16:29:36 bknudson: viktors and I are ready to help with adoption of oslo.db 16:29:47 keystone does _engine_facade = db_session.EngineFacade.from_config(CONF.database.connection, CONF) 16:30:01 so if a project wants to connect to multiple databases, for example, we need to allow them to pass a separate URL 16:30:02 so I guess it just changes to _engine_facade = db_session.EngineFacade.from_config(CONF) 16:30:12 bknudson: right 16:30:16 bknudson: correct 16:30:28 in this case, it seems like keystone is passing redundant info, but that may not always be the case 16:30:31 dhellmann: Then I think they would need to use the kwargs constructor instead of the conf-based one. 16:30:41 beekneemech: true 16:30:59 there was a concept of a "slave" connection, which keystone never used. 16:31:43 bknudson: does the new API force you to consider that feature? 16:31:54 * dhellmann admits he hasn't had a chance to look at oslo.db since before the summit 16:32:06 dhellmann: no, keystone has and had no use for the 2nd connection 16:32:31 bknudson: ok, as long as we haven't changed something to make it hard for you to ignore it, I think we're ok 16:32:47 this isn't a concern for me as far as functionality 16:32:52 ok 16:33:16 I just thought the transition would be a drop-in and not require other changes. 16:33:26 bknudson: sorry :( 16:33:42 bknudson: we're trying for that in as many cases as possible, but it isn't always going to work out 16:33:47 no problem. we need to get the interface right 16:33:53 +1 16:33:54 right 16:34:21 is there anything else on oslo.db? 16:34:25 yeah 16:34:33 you might have noticed an ML thread on releases 16:34:40 but it was also a question of what gets backported and should I expect it in an oslo sync. 16:34:49 so I've been wondering what version we should start from 16:35:06 should we do 1.0.0 as the first release? 16:35:08 bknudson: good point -- we're trying to leave the incubated versions of things alone once we start graduation 16:35:20 make a pre-release? 16:35:22 dhellmann: works for me. 16:35:23 rpodolyaka: we should not release 1.0 until the *end* of juno 16:35:35 or go forwared with 0.x.y versioning? 16:35:47 I want to experiment with the alpha releases before we pick version numbers 16:36:09 if it works, we can release 1.0.0a1 but if we run into trouble we can make it 0.1 as originally planned 16:36:15 Maybe 1.0 happens after we have a successful adoption and know that the interface works? 16:36:27 that may make sense, too 16:36:43 +1 16:37:23 do you expect projects to use alpha release, or wait fo r1.0? 16:37:43 we expect projects to go ahead and use the alpha, because it will turn into a non-alpha at the end of the release cycle 16:37:56 ok 16:37:58 at least to try how projects work with lib 16:37:59 dhellmann: so when can we tag alpha release in oslo.db? 16:38:03 that's not really any different than the incubation process, and gives us a chance to test a package without breaking stable installations 16:38:26 viktors: I suppose right after we merge all the stuff on the ehterpad I'm going to create? 16:38:27 viktors: you have 4 patches to land, and then I want to take some time to look at things because I haven't been able to do that yet 16:38:37 cool 16:38:45 dhellmann: got it 16:38:53 so it's alpha as far as the interface but not functionality 16:39:03 it sounds like markmc's comments on the API were the only serious issues, but as I'm the one who will be yelled at, I'd like to take a day or two to read some code :-) 16:39:12 i.e., it doesn't turn keystone into an alpha 16:39:28 dhellmann: the more eyes we have, the more issues we'll fix before the release ;) 16:39:38 bknudson: well, the plan is to mark it as alpha so that stable installations and people doing CD won't use it, but development versions can use it 16:39:47 rpodolyaka: +1 :-) 16:40:11 ok, let's move on, 2 more topics this week 16:40:13 #topic oslo.i18n graduation status 16:40:18 #info 1 change to land before we can prepare the first release 16:40:22 #link https://review.openstack.org/92682 16:40:36 there are a few other patches up, but nothing critical 16:40:49 oh, hang on, I still need to fix another issue, so there's going to be one more patch :-/ 16:41:09 I forgot about the global USE_LAZY issue 16:41:47 I think I left a comment about that on the graduation spec. 16:41:51 as mentioned earlier, the log translation job is working (thanks to Andreas) 16:42:06 beekneemech: ok, thanks, I'll take a look 16:42:42 #topic priorities for this week 16:42:47 #info filing specs!! 16:43:18 we need to have specs for all juno blueprints filed ASAP 16:43:33 I've already asked for an extension, since we started our specs repo later that the other projects 16:43:40 I'll get the cache one up today then [so it can be reviewed] 16:44:05 I've seen some more come in in the past day or two, but there are a few for graduating libraries that don't have specs yet 16:44:30 I found it a very good exercise to go through for oslo.i18n, figuring out which files were included and what changes need to be made 16:44:53 I think next week any blueprints that don't have specs will be delisted from juno, for now 16:45:21 Deadlines are good. :-) 16:45:27 we can bring them back in later, of course, but I'd like to avoid moving them back and forth if possible 16:45:38 beekneemech: EOD US/Eastern on Monday? 16:46:01 that would ensure they are there before ttx looks during our 1:1 on tuesday 16:46:33 are there any questions about the specs? 16:46:37 dhellmann: I'll shoot for that then. 16:46:42 beekneemech: thanks! 16:47:00 #info reviewing specs 16:47:21 the other priority right now should be reviewing the specs that are written 16:47:38 I've seen some good feedback, so thank you and keep that up! 16:47:47 #link https://review.openstack.org/#/q/project:openstack/oslo-specs+status:open,n,z 16:48:27 is everyone clear on the process for working with the specs? 16:49:00 * beekneemech nods 16:49:41 I just -1 for https://review.openstack.org/#/c/96718/, should we mention the deadline somewhere, then others know it. 16:50:02 gcb: that's a good point, I'll send email to the -dev list 16:50:14 #action dhellmann announce spec deadline on -dev ML 16:50:29 that's everything I have on the official agenda for this week 16:50:33 #topic open discussion 16:50:42 does anyone have anything they would like to bring up? 16:51:35 I have a patch need review 16:51:51 have a link? 16:51:54 https://review.openstack.org/#/c/76901/ 16:51:59 so, just checking, is there an oslo.config version that has the fixture? 16:52:09 "version" -> "release" 16:52:25 bknudson: I don't believe so. I've been holding off on releases until we sort out publishing alphas. 16:52:32 ok, no prob 16:53:07 gcb: So that's on my list, but I've been focused on specs and lib-blocking changes. 16:53:28 thanks, that's OK :) 16:53:44 bknudson: that will probably be 1.3.0a1 16:53:44 beekneemech: so I'll ping you next week :) 16:54:28 gcb: yes, I've put off looking at fixes like that to get my specs written, too, but I'll be coming back to do more reviews next week 16:54:53 viktors: Not until after EOD Monday. ;-) 16:55:07 beekneemech: ok :) 16:55:34 gcb: does that change require a project to list every module they copy in their openstack-common.conf? 16:56:32 dhellmann: no , just use directly, not include ones used by oslo itself. 16:56:40 gcb: ah, ok 16:56:48 I'll take a closer look at it next week 16:57:15 it seems like that's all, so I think we can stop a little early again this week 16:57:23 thanks, we have lots of reviews until now :) 16:58:07 thanks everyone! 16:58:09 #endmeeting