16:00:14 <dhellmann> #startmeeting oslo
16:00:15 <openstack> Meeting started Fri Oct  3 16:00:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:18 <openstack> The meeting name has been set to 'oslo'
16:00:24 <dhellmann> who's around for the oslo meeting?
16:00:27 <bknudson> hi
16:00:27 <rpodolyaka> o/
16:00:29 <kgiusti> o/
16:00:32 <jecarey> o/
16:00:34 <harlowja_at_home> \o
16:00:40 <tedross> o/
16:00:49 <viktors> o/
16:01:11 <dstanek> hello
16:01:50 <dhellmann> dimsum_, beekneemech, jd__, haypo, sileht : ping
16:01:57 <beekneemech> o/
16:02:10 <dimsum_> o/
16:02:14 <jd__> pong but I'll have to go very soon
16:02:21 <dhellmann> jd__: ok
16:02:23 <dhellmann> flaper87: ping
16:02:28 <dhellmann> our agenda:
16:02:29 <flaper87> o/
16:02:31 <dhellmann> https://wiki.openstack.org/wiki/Meetings/Oslo
16:02:34 <dhellmann> oops
16:02:36 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:02:45 <dhellmann> #topic Review action items from previous meeting
16:02:54 <dhellmann> #info dhellmann talk to ttx about timing for oslo.db and pbr releases
16:02:54 <dhellmann> we took care of the oslo.db patch release
16:02:54 <dhellmann> at this point the release candidates for the other projects are almost done
16:02:54 <dhellmann> and sdague is working on some test configuration changes
16:02:54 <dhellmann> so we should wait on other releases
16:03:12 <zzzeek> o/
16:03:24 <dhellmann> the testing changes will reconfigure the integrated gate to use released versions of the libraries, rather than the master branch
16:03:29 <dhellmann> that means we'll want to do more frequent releases
16:03:49 <dhellmann> but we will also be able to set up our own test job that does test proposed changes of libs against the apps
16:03:49 <harlowja_at_home> interesting
16:04:12 <dhellmann> the idea is we want the release to be tested against what we're actually releasing
16:04:18 <viktors> cool!
16:04:25 <dimsum_> +1
16:04:25 <harlowja_at_home> cool, is that the 'gate-tempest-dsvm-src-taskflow' that i saw showing up job ?
16:04:40 <dhellmann> harlowja_at_home: yeah, I don't know all the names of the new jobs, but that looks like it's related
16:04:47 <harlowja_at_home> cool
16:05:06 <dhellmann> until that work is done, we won't be cutting any more releases, but it shouldn't be very long
16:05:17 <dhellmann> and I don't think we had any plans for a while anyway
16:05:41 <dhellmann> I've asked sdague to post a description of the work to the ML, and he said he would when it all comes together
16:05:54 <harlowja_at_home> i'd like to get a 0.4.1 taskflow one out, fixes some small stuff but shouldn't be to much of an issue if that is delayed by a few days
16:05:54 <dhellmann> questions on that?
16:06:15 <dhellmann> yeah, we want to be certain that the jobs that are voting actually run the tests they say they are running
16:07:06 <dhellmann> this also means we're going to want to set up some stronger in-project functional tests, especially for the libs that rely on services like rabbit and mysql
16:07:15 <viktors> dhellmann: we'd like to get oslo.db 1.0.3 with commit https://review.openstack.org/#/c/125347/
16:07:32 <kgiusti> and qpid :D
16:07:42 <dhellmann> kgiusti: yes, "like" :-)
16:07:43 * rpodolyaka will upload a final version in a few minutes ^
16:08:09 <dhellmann> viktors, rpodolyaka : that may have to wait. when the backport is committed and ready, let's see where sdague's work stands
16:08:37 <dhellmann> so keep doing all of the work right up to the point of tagging the release, and we'll see who wins the race
16:08:44 <rpodolyaka> dhellmann: ok
16:09:00 <viktors> dhellmann: ok
16:09:14 <dhellmann> any other questions/comments about the testing stuff?
16:09:30 <harlowja_at_home> dhellmann, will it be including heat and such?
16:09:50 <dhellmann> harlowja_at_home: "it"?
16:09:51 <harlowja_at_home> i believe there are different jobs for neutron, heat... or will it just be the basic projects?
16:09:56 <harlowja_at_home> *sorry, the jobs
16:10:10 <dhellmann> we will be able to decide which projects we want to gate on
16:10:28 <harlowja_at_home> k
16:11:14 <dhellmann> #info dhellmann update graduation instructions to say delete code instead of marking it obsolete DONE
16:11:28 <dhellmann> so we're officially in delete-as-you-go mode now :-)
16:12:20 <dhellmann> #topic oslo.db connection change breaking keystone
16:12:20 <dhellmann> #link https://bugs.launchpad.net/keystone/+bug/1374497
16:12:20 <dhellmann> #info 1.0.2 includes this fix
16:12:21 <uvirtbot> Launchpad bug 1374497 in oslo.db "change in oslo.db "ping" handling is causing issues in projects that are not using transactions" [High,Fix committed]
16:12:31 <dhellmann> thanks, rpodolyaka, viktors, and zzzeek for the work on that
16:12:41 * flaper87 is sufering of terrible network lag
16:12:45 <zzzeek> thanks zzzeek for breaking it !
16:12:48 <dhellmann> me, too, I think
16:12:54 <flaper87> suffering*
16:13:07 * dhellmann read that as surfering first
16:13:19 <viktors> this seems to be fixed, isn't it?
16:13:33 <dhellmann> viktors: you tell me! :-)
16:14:06 <viktors> dhellmann: yes, 1.0.2 includes this fix, sorry
16:14:24 <dhellmann> viktors: *whew*
16:14:50 <dhellmann> #topic Library testing and versioning discussion
16:14:50 <dhellmann> #info http://lists.openstack.org/pipermail/openstack-dev/2014-September/047280.html
16:15:37 <dhellmann> it would be good to get some comments from the rest of the team on this thread; it sort of died down
16:16:12 <dhellmann> the testing changes are part of what sdague is already working on, but the library version numbering question keeps coming up
16:16:18 <dhellmann> I would very much like to stop talking about that
16:16:23 <harlowja_at_home> :)
16:16:27 <dhellmann> but, I would like to stop after resolving it :-)
16:17:41 <dhellmann> some of the comments get into the level of stability that is expected for the libraries, so I want to make sure everyone has a chance to be involved in the discussion -- I don't want to be the only one making this decision since it affects us all
16:18:12 <beekneemech> ack
16:18:29 <dhellmann> we should have that discussion on the list, so we don't need to spend time on it now unless anyone has questions?
16:18:58 <dhellmann> moving on, then
16:19:00 <dhellmann> #topic Red flags for/from liaisons
16:19:09 <bknudson> none here
16:19:24 <flaper87> dhellmann: more than a red-flag I'd like to say that I'll be sharing my glance liaisons duties with zhiyan
16:19:29 <harlowja_at_home> only question from me, is have other pypi projects found a good mix that has worked for them?
16:19:42 <harlowja_at_home> with regard to alpha releases...
16:19:43 <flaper87> I'm Zaqar's and Glance's liaison and I think I hadn't done a good job with the later
16:19:44 <harlowja_at_home> oh to late
16:19:56 <sdague> dhellmann: re: where things stand on the new testing changes, we're 3 patches away from it - https://review.openstack.org/#/c/125946/ (in gate), then https://review.openstack.org/#/c/125966/ and https://review.openstack.org/#/c/125720/ which are project config changes
16:20:02 <dhellmann> flaper87: ok, that's fine -- I'll be asking for new volunteers on the ML next week now that the PTL elections are done
16:20:04 <flaper87> so, I'm sharing my duties and I'll be working with him on getting that done
16:20:14 <dhellmann> sdague: great, thanks for the update!
16:21:44 <dhellmann> #topic Ongoing work
16:21:44 <dhellmann> #link https://launchpad.net/oslo/+milestone/next-kilo
16:21:52 <dimsum_> dhellmann: congrats on PTL again! :)
16:22:01 <dhellmann> dimsum_: thanks :-)
16:22:31 <dhellmann> I think I said this last week, but now that we have LP set up to make it possible, I'd like us to be using it for planning instead of etherpads
16:23:00 <dhellmann> we have some release automation that depends on using the milestone name "next-foo" so rather than picking versions in advance we'll use that
16:23:12 <dhellmann> as each one closes, it will be renamed with the library-appropriate version number
16:23:30 <dhellmann> that way we can look back and tell which release should have a given bug fix in it
16:24:05 <harlowja_at_home> sounds good
16:24:13 <dhellmann> the next-kilo milestone is also a good place to look if you want something to do, since it will have triaged bugs that we feel we need to work on quickly
16:24:24 <dhellmann> there are several bugs targeted there now without owners, for instance
16:24:56 <dhellmann> I'll clean out the invalid and incomplete ones, I guess
16:25:05 <beekneemech> So basically stop using lists on etherpads and start using lp bugs?  Blueprints are presumably still reserved for specs?
16:25:46 <dhellmann> beekneemech: yeah, this will make us more like the other projects. It was hard before because we had one big pile of bugs, instead of separate projects.
16:26:01 <beekneemech> dhellmann: Yep, sounds good.
16:26:24 <dhellmann> I will be using this list to determine priorities for my reviews, for instance (though I won't limit myself to just these items)
16:27:05 <dhellmann> this is also the list that ttx and I review each week
16:27:16 <dimsum_> sounds good
16:27:45 <dhellmann> let me know if you see surprises here, and during this section of the meetings we should talk about anything that needs to be added or removed
16:28:22 <kgiusti> I've got a few bugs related to the amqp1.0 driver:
16:28:37 <kgiusti> https://bugs.launchpad.net/oslo.messaging/+bug/1367911 for instance
16:28:38 <uvirtbot> Launchpad bug 1367911 in oslo.messaging "AMQP 1.0 driver needs better credit management" [Undecided,New]
16:28:38 <dhellmann> so we'll see how that goes, and adjust what we do over the course of the release
16:29:01 <dhellmann> kgiusti: do you anticipate the fix for that going into the next alpha release of oslo.messaging?
16:29:11 <dhellmann> or should it, I guess?
16:29:18 * harlowja_at_home almost read that as credit-card management, lol
16:29:52 <kgiusti> It should go in as soon as I stabilize it - not sure of the timeframes atm.
16:30:23 <dhellmann> kgiusti: we should get together sileht and prioritize the messaging related work for kilo
16:30:37 <kgiusti> +1
16:30:53 <dhellmann> I hate to schedule a separate meeting, but we might need to because of the time for this one
16:31:24 <dhellmann> which reminds me, we may want to think about moving this meeting to a different time to make it easier for some of our european contributors to attend
16:31:39 <dhellmann> I don't know how many friday nights out we can expect jd__ to give up ;-)
16:31:56 <viktors> dhellmann: +1
16:32:09 <dhellmann> would someone like to volunteer to put together a list of proposed times and set up a doodle for voting?
16:33:00 <rpodolyaka> I can do that
16:33:04 <dhellmann> thanks, rpodolyaka
16:33:20 <dhellmann> #action rpodolyaka set up a doodle with proposed times for our weekly meetings
16:33:23 <harlowja_at_home> dhellmann, i have https://wiki.openstack.org/wiki/Meetings#State_management_team_meeting that is unused (mainly because this meeting supersedes it), could be a possible slot
16:33:30 <harlowja_at_home> 'Weekly on Thursdays at 1900 UTC'
16:34:08 <dhellmann> rpodolyaka: keep in mind we need to pick a time and room that isn't already being used by another team, so we might need to move rooms, too
16:34:26 <rpodolyaka> dhellmann: ok
16:34:48 <dhellmann> harlowja_at_home: I'm afraid later in the day may just make the problem worse for europe
16:34:54 <harlowja_at_home> k
16:34:56 <dhellmann> but we should put that on the list and see if I'm right
16:35:18 <rpodolyaka> yeah, friday night is not really working for us :(
16:36:05 <dhellmann> rpodolyaka: my only major conflict is the tc/release meeting block on tuesdays but moving off of friday would be good
16:36:27 <dhellmann> some time tuesday-thursday would involve the fewest misses, I think, since I tend to travel on monday or friday
16:36:41 <dhellmann> but let's see what's actually available to us
16:36:45 <rpodolyaka> ok
16:36:52 <dhellmann> maybe we can ask infra to create a meeting-4 :-)
16:36:58 <rpodolyaka> heh
16:37:12 <rpodolyaka> well, meeting rooms must be cheap :)
16:37:13 <dhellmann> so we'll look for the email about that on the -dev list, thanks rpodolyaka
16:37:20 <dhellmann> rpodolyaka: you would think, yes :-)
16:37:34 <dhellmann> #topic Namespacing config options for Oslo libs (bnemec)
16:37:38 <dhellmann> beekneemech: the floor is yours
16:37:42 * beekneemech starts composing email about a new program - meetings as a service ;-)
16:37:49 <beekneemech> dhellmann: This is actually from last week.
16:37:54 <dhellmann> oh?
16:38:04 * dhellmann didn't update the wiki last week
16:38:05 <beekneemech> Related to the oslo.concurrency namespace, which I think we agreed was fine.
16:38:17 <dhellmann> ah, right
16:38:28 <dhellmann> did you document that somewhere?
16:38:37 <beekneemech> Not yet, but I should.
16:38:47 <beekneemech> Probably in the graduation steps?
16:38:52 <dimsum_> dhellmann: i did add notes in oslo.config docs
16:39:10 <dhellmann> dimsum_: aha, yes, thank you, now I remember talking about this
16:39:20 <dimsum_> https://review.openstack.org/#/c/125198/
16:39:38 <dhellmann> cool, and we can update the graduation docs to point to that page after it merges
16:39:52 <beekneemech> +1
16:40:07 <dhellmann> is there anything else we need to talk about for that one?
16:40:16 <beekneemech> Not for me
16:40:25 <dimsum_> nope
16:40:48 <dhellmann> ok
16:40:52 <dhellmann> #topic review priorities for this week
16:41:09 * zzzeek has blueprints
16:41:23 <dhellmann> yes, the specs repo is open so we should look at those this week
16:41:30 * dimsum_ wants to figure out what else needs to be in oslo cookie cutter
16:42:01 <harlowja_at_home> dhellmann,  for specs that didn't get finished for juno, should a symlink be made to it from juno -> kilo in the repo, or resubmitted, or other?
16:42:19 <dhellmann> harlowja_at_home: the ones that didn't land have been deleted from the repo, so they need to be resubmitted under kilo
16:42:29 <harlowja_at_home> k
16:43:02 <dhellmann> I did that, and then the nova team used a process that moved them to another directory instead, which would make resurrecting them easier, so maybe that's what we should do for kilo
16:43:25 <harlowja_at_home> idk, there in git anyway
16:43:46 <beekneemech> The only thing for me is that we lose any previous discussion if we delete them completely.
16:43:58 <beekneemech> Or at least the discussion gets split over the old and new reviews.
16:44:24 <beekneemech> I don't know if the Nova process addresses that either though.
16:44:54 <dhellmann> beekneemech: yeah, that's a good point. I didn't want to leave them there, since they weren't done, but I didn't have a good answer for that.
16:45:59 <dhellmann> does anyone have any other items we should treat as high priorities for reviews?
16:46:14 <dhellmann> I'm still working on the oslo.log cleanup, so there are some reviews there and more to come
16:46:40 <beekneemech> So should we be focusing on specs until summit?
16:47:10 <dhellmann> likely, though I'd like to see oslo.concurrency and oslo.log makes some progress
16:47:25 <dhellmann> dimsum_: where do you stand with the analysis you've been doing on new libraries?
16:47:37 <dhellmann> #link https://etherpad.openstack.org/p/kilo-oslo-library-proposals
16:47:58 <dhellmann> are we ready to write specs for any of those?
16:48:25 <dimsum_> dhellmann: looks good from a dependency point of view
16:48:39 <beekneemech> We should be pretty close on concurrency.
16:48:58 <beekneemech> I think maybe the last outstanding issue was the question of eventlet testing (which I need to follow-up on...)
16:49:00 <dhellmann> there are some open questions on the etherpad. It might be easier to work some of those details out with the holistic view, rather than across the specs for each library
16:49:04 <dimsum_> dhellmann: a few libraries can definitely be done quickly
16:49:52 <dimsum_> dhellmann: do we tell folks to sign up for writing specs?
16:49:58 <dhellmann> dimsum_: ok, good. we need to start getting volunteers to write the specs
16:50:03 <dhellmann> heh
16:50:05 <dimsum_> :)
16:50:22 <dimsum_> i am reading your mind :)
16:50:43 * dhellmann is only thinking about lunch at this point
16:51:34 <dhellmann> dimsum_: can you take a pass through and look at the open questions and see if we actually know the answers to any -- or figure out who would?
16:51:48 <dimsum_> dhellmann: yep
16:51:54 <dhellmann> the xmlutils thing, in particular, is something we should be careful about
16:52:13 <dimsum_> dhellmann: poof it's gone!
16:52:18 <dhellmann> as well as hooks.py (how did we end up with code no one is using?)
16:52:38 <dimsum_> jd__ took care of nuking xmlutils from nova
16:53:13 <dhellmann> dimsum_: context.py and locals.py are the ones that make me lose sleep
16:53:22 <dhellmann> ok, good on xmlutils
16:53:42 <dimsum_> dhellmann: ack. will dig deeper on those
16:54:00 <dhellmann> thanks!
16:54:26 <dhellmann> #action dimsum_ review kilo lib plan and resolve open questions that have been answered
16:54:38 <dhellmann> #topic summit planning
16:54:41 <dhellmann> #link https://etherpad.openstack.org/p/kilo-oslo-summit-topics
16:54:57 * beekneemech will be there now \o/
16:54:58 <dhellmann> I've been doing TC governance stuff this week instead of summit planning, but I see a lot of comments on the etherpad
16:55:02 <dhellmann> beekneemech: woo!
16:56:12 <beekneemech> It doesn't appear we will lack for things to talk about.
16:56:40 <dhellmann> yes, we're going to need to make good use of our pod time on friday, I think
16:57:02 <beekneemech> Hopefully they won't schedule _all_ of my tripleo sessions Friday afternoon again. :-)
16:57:07 <dhellmann> I'm going to try to push the python 3 discussion to the cross-project list
16:57:32 <dimsum_> dhellmann: +1 to move python3 out
16:58:09 <beekneemech> Yeah, although I wonder if the answer from the other projects is going to be "We will when Oslo does"
16:58:22 <dhellmann> lifeless has a proposed solution to the namespace package issue, but I'm really tempted to just stop using them anyway. Maybe that's something we can discuss before the summit, though
16:58:48 <dhellmann> beekneemech: yeah, true, we need to get the messaging support sorted out
16:58:56 <zzzeek> dhellmann: change the name of all the oslo libs ?
16:59:00 <beekneemech> It would be nice to not have to rename...everything.
16:59:20 <dhellmann> the nova objects thing may just be a spec and informal session, I don't know if we need a scheduled slot for that
16:59:36 <dhellmann> beekneemech: well, my idea was to just keep calling things oslo.foo even though you would import oslo_foo
16:59:44 <dhellmann> so no renaming
16:59:54 <dhellmann> new libs might not use the . in their name
16:59:56 <zzzeek> dhellmann: but we need to change all the imports
16:59:57 <beekneemech> I think we really need to kidnap superdan for the nova objects discussion, wherever we have it.
17:00:17 <dimsum_> +1 to kidnap plan :)
17:00:20 <dhellmann> zzzeek: yeah, I need to test, but I think we can ship packages that have both the namespace package and a non-ns pkg to give us a transition period
17:00:39 <dhellmann> beekneemech: yes, definitely
17:00:49 <zzzeek> dhellmann: OK, would be interested to see how that works
17:01:02 <dhellmann> zzzeek: yeah, I still have to test it
17:01:02 <beekneemech> Yeah, and we could add a deprecation warning to the namespace package.
17:01:07 <dhellmann> beekneemech: right
17:01:12 <zzzeek> “Nova objects are basically the current way forward for non-disruptive upgrades” ….eh ?
17:01:27 <harlowja_at_home> zzzeek,  ya i didn't quite agree with that either ;)
17:01:44 <zzzeek> i have no idea how that could be true, as long as you stil have a SQL schema underneath it
17:02:01 <superdan> zzzeek: it's a statement mostly about RPC versioning
17:02:15 <dhellmann> dimsum_: while I'm thinking about it, I noticed that we have some client libraries that have started to use oslo.utils and some of the other libraries, so we need to be careful about how many dependencies we put together in that one utils lib. We may want to split some of the things like fileutils, imageutils, etc. out to separate libraries just to avoid dependency bload
17:02:21 <dhellmann> I'll add that comment to the etherpad
17:02:27 <superdan> zzzeek: upgrades in this case being multiple machines being on different versions of the code, insulated from the schema
17:02:30 <dimsum_> dhellmann: ack
17:02:49 <zzzeek> superdan: oh, you mean nova objects provides API versioning
17:03:06 <zzzeek> guess you just said that :)
17:03:19 <superdan> zzzeek: versioning of our RPC APIs, and the data we send over the wire, so that *that* data is insulated from the schema in the DB, which might be different during an upgrade
17:03:40 <zzzeek> superdan: how is that different from just having web services in any case with version schemes
17:04:03 <zzzeek> superdan: OK I guess the objects themselves means the versioned APIs can still have RPC-like APIs, i get it….
17:04:05 <superdan> zzzeek: it's not? but nova components talk to each other over the message bus
17:04:07 <zzzeek> superdan: this is acrtually what SOAP is :)
17:04:08 <dhellmann> zzzeek: because the different services within nova might all still be updated separately, and they use rpc
17:04:24 <zzzeek> on those rare occasions someone actually uses SOAP correctly
17:04:36 <superdan> zzzeek: not sure I agree with that
17:04:41 <superdan> zzzeek: it's not server-side objects
17:04:45 <dhellmann> superdan: will you have some time next week to chat about working on an oslo.objects library during kilo? I'd like to collaborate on the spec.
17:04:53 <superdan> dhellmann: sure
17:05:11 <dhellmann> #action dhellmann schedule a chat with superdan about nova objects -> oslo transition
17:05:21 * superdan to come up with a list of excuses
17:05:32 <beekneemech> :-)
17:06:42 <dhellmann> oh, we're way over time here
17:06:48 <dhellmann> thank you everyone!
17:06:58 <dhellmann> #endmeeting