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