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