16:00:07 <dims_> #startmeeting oslo
16:00:07 <openstack> Meeting started Mon Oct  5 16:00:07 2015 UTC and is due to finish in 60 minutes.  The chair is dims_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <dims_> courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dougwig, e0ne, flaper87, garyk, harlowja, haypo,
16:00:07 <dims_> courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka,
16:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:09 <dims_> courtesy ping for sergmelikyan, sreshetnyak, sileht, sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek
16:00:11 <dhellmann> o/
16:00:11 <openstack> The meeting name has been set to 'oslo'
16:00:12 <e0ne> hi
16:00:15 <jungleboyj> o/
16:00:18 <jecarey> 0/
16:00:18 <bknudson> hi
16:00:19 <ozamiatin> o/
16:00:21 <johnsom> o/
16:00:28 <toabctl> hi
16:00:42 <harlowja_at_home> sup
16:01:30 <dims_> #topic Red flags for/from liaisons
16:01:40 <johnsom> No issues
16:01:44 <bknudson> nothing for keystone
16:01:50 <dims_> bknudson: johnsom: glad to hear
16:02:06 <jungleboyj> Nothing for Cinder.
16:02:16 <dims_> thanks jungleboyj
16:02:33 <dims_> #topic Releases for Mitaka
16:02:34 <dims_> Is there any libraries that really need releases from master asap?
16:02:38 <stevemar_> 2o/
16:02:44 <dims_> hey stevemar_
16:02:49 <stevemar_> err o/
16:02:52 <stevemar_> hi dims_!
16:02:57 <stevemar_> we're the cool underscore guys
16:03:05 <dims_> haha
16:03:16 <harlowja_at_home> oh, i'd like to get taskflow out, i guess i can submit a change for that ?
16:03:25 <dims_> harlowja_at_home: yes, please go ahead
16:03:27 <harlowja_at_home> to release repo or something
16:03:32 <harlowja_at_home> k, will do
16:03:35 <kzaitsev_mb> .
16:03:50 <dims_> #topic oslo.service liberty/grenade scenario problem
16:04:03 <dims_> sdague: eezhova: ping
16:04:07 <dims_> https://bugs.launchpad.net/oslo.service/+bug/1446583
16:04:07 <openstack> Launchpad bug 1446583 in oslo.service "services no longer reliably stop in stable/liberty / master" [Critical,New]
16:04:09 <stevemar_> ugh, going right into the hard one
16:04:38 <dims_> not sure if either of them are here. but worth a shout out :)
16:04:39 <bknudson> I guess I didn't fix that one.
16:04:40 <harlowja_at_home> ya, i wonder why thats happening
16:04:43 <sdague> dims_: increasing the shutdown time has helped some, but it's still around a bit
16:04:53 <dims_> sdague: ah.
16:04:59 <sdague> the fix so far was moving the timeout from 10s to 30s for shutdown
16:05:02 <harlowja_at_home> can it be locally reproduced without requiring nova, like in a small example?
16:05:10 <sdague> however, it's still popping up
16:05:14 <bknudson> seems like if you tell something to shut down it should shut down, but then it looked like some people don't like things shutting down.
16:05:21 <dims_> last update seems to be https://bugs.launchpad.net/oslo.service/+bug/1446583/comments/54
16:05:21 <openstack> Launchpad bug 1446583 in oslo.service "services no longer reliably stop in stable/liberty / master" [Critical,New]
16:05:39 <sdague> so, the real issue seems to be children with in flight work, which is why it's a race
16:06:10 <dims_> hence pops up in grenade test
16:06:18 <bknudson> the gate tests don't care about the in-flight work?
16:06:20 <dhellmann> that comment about killing the process group seems interesting
16:06:22 <sdague> harlowja_at_home: eezhova said they reproduced it locally, but you do need real services, plus them doing real work
16:06:27 <harlowja_at_home> k
16:06:40 <harlowja_at_home> services doing fake work :-P
16:06:44 <harlowja_at_home> *computing PI
16:06:44 <sdague> dhellmann: yes, I'm getting some patches up to see what that looks like
16:06:52 <dims_> sdague: ack, will keep an ear out for eezhova's updates
16:06:53 <sdague> and if it makes things better
16:07:04 <dhellmann> sdague: ++
16:07:19 <amrith> anybody home?
16:07:28 <dims_> amrith: yes, we are talking :)
16:07:38 <amrith> is there an oslo meeting today?
16:07:42 <bknudson> kill -9 will shut things down.
16:07:48 <haypo> amrith: yes, it's here, right now :)
16:08:15 <dims_> ok switching topics
16:08:18 <dims_> #topic openstack spec reviews - rabbitmq driver using pika
16:08:19 <dims_> #lin khttps://review.openstack.org/#/c/228992/
16:08:22 <dims_> reviews please!
16:08:22 <sdague> bknudson: right, but then what we're saying is we expect all init scripts to kill -9
16:09:05 <dims_> dukhlov has a few reviews up with code in oslo.messaging, devstack as well
16:09:26 <dims_> my feeling is to start the code into a feature branch and get tempest up and running
16:09:30 <dims_> like zmq
16:09:39 <harlowja_at_home> i like that to dims_
16:10:01 <dims_> thanks harlowja_at_home
16:10:13 <harlowja_at_home> will be interesting to see where this goes
16:10:22 <bknudson> we should make more use of feature branches but there's maintenance work required.
16:10:25 <dims_> anyone objections? (i.e. only after the spec gets merged as usual)
16:11:02 <bknudson> so kombu is done?
16:11:08 <dims_> bknudson: not a replacement
16:11:13 <harlowja_at_home> define done
16:11:15 <haypo> dims_: a feature branch sounds like a good idea
16:11:26 <bknudson> it's not supported.
16:11:27 <harlowja_at_home> i think we need experience with pika to say much of anything 'done' vs 'not done'
16:11:42 <harlowja_at_home> i would hope not, this is an alternative that imho needs to prove itself
16:11:44 <dims_> harlowja_at_home: right
16:11:45 <ozamiatin> dims_: my only trouble with feature branch were that I could't merge master into it (only release team can)
16:11:56 <bknudson> the spec says kombu isn't supported
16:12:07 <harlowja_at_home> yes, i commented on that
16:12:10 <dims_> ozamiatin: i can do that i think else will request for karma to do that
16:12:12 <bknudson> you can get auth to merge to feature branch
16:12:22 <ozamiatin> dims_: yeah, so we need to merge things time after time to keep gates up
16:12:36 <dhellmann> dims_: this is a new driver, right, not a reimplementation of the existing driver?
16:12:54 <dims_> dhellmann: yes, new driver that does the same thing that the old driver does
16:12:57 <harlowja_at_home> bknudson, i wouldn't exactly call kombu not supported, seeing that its used and is actively worked on (unless the git repo is lying to me), which is why i objected to that statement in the spec
16:12:59 * dhellmann apologizes if that's covered in the spec
16:13:03 <dims_> dhellmann: and supports same config options
16:13:08 <bknudson> weird.
16:13:33 <harlowja_at_home> flaper87, is kombu dead?
16:13:36 <bknudson> why have 2 drivers for rabbit?
16:13:59 <ozamiatin> bknudson: pivotal recommended pika AFAIK
16:14:03 <dhellmann> harlowja_at_home: that's a good point, the folks from rabbit brought that up at the summit and it wasn't clear why pika is really considered better
16:14:13 <dims_> dhellmann: hence the trial
16:14:26 <harlowja_at_home> right, pika imho needs to prove itself, which i'm fine with, thats life :-P
16:14:32 <bknudson> pivotal can't work with kombu?
16:14:33 <dhellmann> dims_: is this just a matter of them wanting us to use a lib they control vs. one they don't?
16:14:37 <dims_> dhellmann: we can't tell if it's better unless we try especially HA destructive scenarios with rabbitmq
16:14:56 <dhellmann> ah, ok, so pika may handle some failure cases better?
16:14:58 <dims_> dhellmann: they know it better so they can help us fix things btter
16:15:00 <harlowja_at_home> bknudson, stop asking all the hard questions, lol
16:15:04 <dims_> dhellmann: y that's what they say
16:15:20 <dhellmann> dims_: ok, it would be good to get some more detail about that in this spec, I think
16:15:43 <dims_> dhellmann: right, so dmitry is exploring all of that using actual code
16:15:45 <harlowja_at_home> funny comment from the spec imho
16:15:55 <harlowja_at_home> 'About kombu. You can continue use it if it works fine. But in our case we have problems with RabbitMQ stable work in HA mode. And when we asked RabbitQM developers for help in bugfixing they said that it is possible but first of all update your environment to recommended library stack. It is mane reason of developing this driver.' (from dimitry)
16:16:08 <jungleboyj> harlowja_at_home: That is what bknudson does.
16:16:10 <dhellmann> dims_: ack
16:16:11 <harlowja_at_home> ;)
16:16:21 <bknudson> I'm not a fan of having to support 2 drivers indefinitely, so I don't think we should pick up a new driver unless we're really planning on deprecating kombu/rabbit.
16:16:29 <dims_> harlowja_at_home: y, it's been brought up by pivotal folks in a lot of occasions
16:16:56 <harlowja_at_home> dims_, anyway we can get a comment from pivotal on this, it seems a little odd to me
16:17:06 <harlowja_at_home> upgrade to pika, or we won't help u
16:17:11 <harlowja_at_home> that seems weird :-/
16:17:13 <dims_> bknudson: hence the feature branch
16:17:29 <dims_> bknudson: so decision to deprecate the existing one can be taken later
16:17:53 <dims_> so let's debate on the spec :)
16:17:58 <harlowja_at_home> i will offer kombu support for half the price pivotal will :-P
16:18:01 <harlowja_at_home> (j/k)
16:18:15 <dims_> harlowja_at_home: yes, i requested Michael Klishin to respond on the spec
16:18:36 <harlowja_at_home> cools, let's see where this ship takes us, haha
16:18:48 <dims_> #link https://github.com/rabbitmq/rabbitmq-website/issues/6
16:18:54 <dhellmann> dims_: I like the idea of a feature branch
16:18:57 <haypo> for me, it's ok to support the two drivers during a few cycles
16:19:09 <haypo> it's hard to estimate which one will be the best right now
16:19:21 <haypo> (it's hard to estimate right now which one will be the best)
16:19:21 <harlowja_at_home> haypo, agreed
16:19:32 <dims_> haypo: we can decide around milestone-2 to merge into master or leave it in feature branch
16:20:06 <haypo> a driver is not 100k of code, it's much smaller :-p
16:20:07 <dims_> #topic summit request for sessions
16:20:07 <dims_> #link https://etherpad.openstack.org/p/mitaka-oslo-summit-planning
16:20:49 <harlowja_at_home> more sessions!
16:21:04 <harlowja_at_home> dims_, do we have a count of how many we can actually have yet? to help prune that etherpad down
16:21:07 <haypo> (oh, i didn't propose asynio this time :-) i abandonned my idea to replace eventlet with asyncio. i will retry in 10 years when openstack will drop python 2 support)
16:21:13 <haypo> asyncio*
16:21:23 <dims_> #link current layout https://docs.google.com/spreadsheets/d/1tpLN5emWhcMmSmkn8z_HuclcjnEPevP77BhdnFN9KCs/pubhtml?gid=5&single=true
16:21:25 <harlowja_at_home> haypo, lol
16:21:32 <dims_> harlowja_at_home: ^^
16:21:36 <harlowja_at_home> dims_, thx
16:21:38 <bknudson> keystone can drop eventlet support this release.
16:21:42 <dims_> harlowja_at_home: haha
16:21:42 <haypo> and i didn't propose python 3 this time... because all libraries are now compatible with python 3 \o/
16:21:47 <dims_> bknudson: ++
16:21:53 <haypo> bknudson: cool
16:21:56 <harlowja_at_home> haypo, i'm pretty sure the retrying library can help u with that retry
16:22:01 <dims_> bknudson: along with /v2 :)
16:22:05 <dims_> haypo: yay!
16:22:10 <harlowja_at_home> retry(again="10 years")
16:22:18 <bknudson> we didn't deprecate /v2 yet.
16:22:29 <haypo> harlowja_at_home: lol
16:22:40 <dims_> harlowja_at_home: 3 fishbowls and 5 work sessions
16:22:45 <harlowja_at_home> cool
16:23:01 <haypo> oh, someone really wrote "Anything we can do with python3?"
16:23:13 <haypo> FYI i proposed a cross-project session to discuss how to enable functional tests on python 3
16:23:22 <haypo> it's the next major step for python 3
16:23:24 <dims_> haypo: nice
16:23:39 <dims_> haypo: sirushti is doing good with that devstack patch from dhellmann. so yay for that too
16:23:41 <harlowja_at_home> so 8 sessions, that maps pretty nicely to that etherpad i think
16:23:45 <haypo> i'm not sure that it's required to discuss that in an oslo meeting. what do you think?
16:24:05 <dhellmann> yay, sirushti!!
16:24:06 <dims_> :) celebrate awesomeness has no limits
16:24:40 <dims_> #topic feedback from other teams
16:24:50 <dims_> harlowja_at_home: please paste your etherpad link
16:24:55 <harlowja_at_home> oh ya, locating
16:25:04 <dims_> sorry i did not give you feedback last week
16:25:27 <harlowja_at_home> np, just gotta find the link, ha
16:26:21 <dims_> dhellmann: other than liaisons is there any other way to get some feedback from other dev teams that you would recommend?
16:26:32 <harlowja_at_home> https://etherpad.openstack.org/p/oslo-mikata-survey
16:26:34 <harlowja_at_home> found it!
16:26:37 <dims_> harlowja_at_home: thanks
16:26:37 <harlowja_at_home> #link https://etherpad.openstack.org/p/oslo-mikata-survey
16:26:44 <harlowja_at_home> so that was just some ideas i was thinking about
16:26:45 <dims_> folks please look ^^^
16:26:58 <harlowja_at_home> see if can get feedback that people may not usually give
16:27:19 <harlowja_at_home> in a forum that we can propose questions, and all that, without having people be shy about answering..
16:27:20 <dims_> harlowja_at_home: should we ask people to respond inline on the etherpad?
16:27:24 <harlowja_at_home> sure
16:27:32 <dhellmann> dims_: maybe talking to liaisons/PTLs/cores 1:1 ? that's time-consuming
16:27:42 <harlowja_at_home> mutate the etherpad if u want, or can be done differently
16:28:11 <dims_> dhellmann: we can try an email to openstack-dev first and then try to raise the question in different weekly meetings
16:28:20 <haypo> we should maybe add a question on API stability to the survey?
16:28:26 <harlowja_at_home> haypo, sure
16:28:40 <dims_> haypo: +1 please throw it in
16:28:51 <haypo> maybe with a time limit: do you think that the Oslo API were stable enough last 12 months?
16:29:00 <harlowja_at_home> haypo, sounds good to me
16:29:18 * harlowja_at_home wants to get negative feedback as well, if people don't like things, i'd rather have them say it, so we can fix it...
16:29:24 <dims_> harlowja_at_home: so let's work on the etherpad and send it out say on wed and we can ask liaisons to raise it in their weekly meetings
16:29:39 <harlowja_at_home> dims_, sounds good to me
16:29:46 <dims_> harlowja_at_home: we can ask them to email both of us direct for negative feedback if necessary
16:29:53 <bknudson> it might be more interesting to hear from the other devs rather than the liaisons.
16:29:54 <harlowja_at_home> thats fine to
16:30:05 <haypo> i added my question,  please modify it directly :)
16:30:21 <dims_> bknudson: liaisons ask in their weekly meetings and get us feeback from the cores of those projects...
16:30:32 <dims_> thanks haypo
16:30:33 <harlowja_at_home> bknudson, ya, if we can get people to tell us positive/negative, thats great, even if there is some 'spam' involved, thats ok to, feedback is good
16:30:43 <dims_> k. let's try it!
16:30:50 <dims_> thanks for ideas everyone
16:31:12 <dims_> #topic Open discussion
16:31:12 <dims_> #endmeeting