16:00:36 <dims> #startmeeting oslo
16:00:37 <openstack> Meeting started Mon Nov 30 16:00:36 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:37 <dims> courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dougwig, e0ne, flaper87, garyk, harlowja, haypo,
16:00:38 <dims> courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, spamaps
16:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:39 <dims> courtesy ping for sergmelikyan, sreshetnyak, sileht, sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek, gcb
16:00:41 <openstack> The meeting name has been set to 'oslo'
16:00:42 <ihrachys> o/
16:00:43 <sileht> o/
16:00:44 <johnsom> o/
16:00:44 <bknudson> hi
16:00:45 <kgiusti> o/
16:00:47 <gcb> o/
16:00:49 <jecarey> o/
16:01:00 <harlowja_at_home> yo yo
16:01:02 <kragniz> o/
16:01:06 <dims> kick things off :) Welcome to our new oslo core - welcome gcb!!
16:01:16 <rpodolyaka> o/
16:01:18 <kzaitsev_mb> o/
16:01:23 <sileht> gcb, welcome !
16:01:23 <bknudson> congrats to gcb
16:01:27 <harlowja_at_home> yaaaa welcome!
16:01:29 <bknudson> well deserved
16:01:36 <amrith> ./
16:01:42 <gcb> It's really excited to become an Oslo core reviewer. Thanks, everyone :-).
16:01:49 <dhellmann> o/
16:01:52 <ozamiatin__> o/
16:01:57 <dhellmann> welcome to the team, gcb!
16:02:10 <dims> #topic Red flags for/from liaisons
16:02:35 <bknudson> nothing for keystone.
16:02:54 <johnsom> Nothing here
16:03:04 <johnsom> (Though I have been out of the office)
16:03:28 <ihrachys> just curious how it goes with deprecation warning on 'obsolete' oslo.messaging driver aliases.
16:03:39 <dims> liaisons, please take a look at lifeless' openstack-spec for backward compats https://review.openstack.org/#/c/226157/
16:03:55 <dims> lifeless is looking for feedback on that
16:04:20 <dims> ihrachys : don't think we have nailed that yet
16:04:32 <johnsom> Ok, will have a look
16:04:46 <dims> thanks bknudson johnsom
16:04:48 <dims> #topic Releases for Mitaka
16:04:49 <dims> Does anyone need releases today? please file reviews in openstack/releases repo.
16:05:31 <dims> any specific requests for this week?
16:05:44 * harlowja_at_home thinks some people still in turkey coma lol
16:06:06 <dims> exactly, just wanted to be sure
16:06:09 <dims> #topic cleanup oslo-incubator
16:06:09 <dims> Please bid fond farewell to https://review.openstack.org/#/c/245461/
16:06:36 <dims> please cast your vote to cleanup oslo-incubator code, will +2A it later today!
16:06:37 <dims> yay!
16:06:44 <harlowja_at_home> lol
16:06:56 <dims> dhellmann wanted to give it a proper sendoff
16:06:59 <harlowja_at_home> ha
16:07:26 <harlowja_at_home> does that include a burial at sea?
16:07:40 <dhellmann> we all built it, we should all have a role in killing it :-)
16:07:45 <dims> treat it as a pirate? :)
16:07:51 <bknudson> the incubator repo still exists?
16:08:08 <dhellmann> it does still, I think, have some of our tool scripts in it, doesn't it dims?
16:08:10 <bknudson> I'm wondering if we delete the repo or the coce
16:08:11 <dims> Now, question was, what to replace it with, lifeless to the rescue again
16:08:20 <dims> dhellmann yes, just yanking out the code for now
16:08:29 <dims> will completely cleanup later in the cycle
16:08:37 <dims> #topic Policy Spec Review
16:08:38 <dims> #link https://review.openstack.org/#/c/247902/ (Replace incubator with unstable libraries.)
16:08:46 <dims> bknudson just the code in that review
16:09:09 * harlowja_at_home also not sold on v1, v2...
16:09:14 <dims> in the spec review, please note the v1/v2 package names for public api
16:09:46 <dims> alternatives are very welcome. my alternative is to just say what we did before, "till library is 1.0, anything can change"
16:09:53 <harlowja_at_home> ya, i like that...
16:09:57 <harlowja_at_home> thats more normal imho
16:09:58 <gcb> So, some useful stuff can move to oslo.*  like #https://review.openstack.org/#/c/249107/
16:10:18 <dims> gcb : let's try to keep that to a minimum
16:10:30 <bknudson> if the code isn't backwards compatible then how to release without breaking everything?
16:10:45 <harlowja_at_home> dims, and if a library releases a 1.0 and everything is all broken, well thats why debtcollector exists and such, to make it so that u can change things in a manner that works as people use your library...
16:10:46 <dims> bknudson : we file reviews in consumers first and then release
16:11:00 <dims> just like we catch backwards incompat bugs today
16:11:51 <harlowja_at_home> +1 v1/v2/v3 starts to feel like ummm, we can do better... using known patterns of how to do better...
16:11:51 <dims> i just did not want to formalize on v1/v2 names as they tend to NOT go away
16:11:55 <bknudson> maybe we'll have caps on libs for tox eventually
16:12:37 <dims> any way  let's add stuff to the review please
16:12:48 <dims> #topic Stuck Spec Review
16:12:48 <dims> #link https://review.openstack.org/#/c/103825/ (OSprofiler cross service & project profiling)
16:13:45 <dims> boris-42_ is trying really hard to get projects to accept the concept and agree on implementation
16:14:06 <dims> please take a look as this is something that will affect a lot of projects
16:14:19 <haypo> (crap i forgot the oslo meeting)
16:14:30 <harlowja_at_home> lol
16:14:36 <dims> my specific feedback was what changes we needed in oslo.messaging and oslo.db, that was not clear to me
16:14:41 <dims> haypo : haha
16:15:22 <dims> oslo.messaging was relying on a class that we were yanking out and oslo.db was relying on a global thing that Nova no longer uses
16:15:40 <dims> for examle
16:15:42 <dims> example
16:15:45 <rpodolyaka> dims: I'll take a look at oslo.db part
16:16:30 <dims> another point of contention was if we can switch it off completely for projects that do not want it enabled by default
16:16:53 <gcb> agree, we need a way to disable it
16:17:09 <dims> so liaisons, please take a look at the review, there's one in openstack-specs as well i think
16:17:14 <dims> boris-42_ : are you around?
16:17:23 * harlowja_at_home although i do wonder if the projects that think they want to enable it don't quite understand how useful it is
16:17:36 <dims> jd__ : around?
16:17:39 <harlowja_at_home> *that think they don't want to enable it
16:18:51 <dims> harlowja_at_home : yes, hence the ask for reviews. last time there was significant pushback from nova folks i think
16:19:03 <rpodolyaka> I didn't look at the spec, but I thought the idea was to have it enabled by default and triggered by special API requests
16:19:09 <rpodolyaka> so you don't profile all the time
16:19:21 <rpodolyaka> but you don't have to enable it explicitly and restart the services either
16:19:24 <dims> rpodolyaka : right, in the oslo-spec, what does that mean to our libraries
16:19:34 <rpodolyaka> ack, will take a look
16:19:43 <dims> thanks!
16:19:48 <dims> #topic New Spec Review
16:19:48 <dims> #link https://review.openstack.org/243114 (Pluggable CMDB for oslo.config)
16:19:49 <dims> #link https://review.openstack.org/#/c/247668/ (message compression proposal)
16:20:02 <sileht> api call relies of a hmac, if deployer doesn't set the hmac we can't enable it
16:20:18 <sileht> if we put a default value, we introduce security issue
16:20:18 <rpodolyaka> sileht: got it. thanks!
16:20:31 <dims> sileht : interesting
16:20:48 <dims> sileht what do you think of using driver-supported compression
16:20:56 <sileht> dims, I like :)
16:21:06 <dims> sileht, kgiusti : https://review.openstack.org/#/c/247668/
16:21:17 <dims> ozamiatin__ ^^
16:21:32 <sileht> dims, I was thinking of using msgpack in the past as a new message format, but the compression approach looks better
16:21:35 <ozamiatin__> dims: +1 already)
16:21:53 <dims> tcammann : i think https://review.openstack.org/#/c/243114/ is ready now
16:21:56 <kgiusti> interesting...
16:22:08 <dims> lxsli : you had looked at https://review.openstack.org/#/c/243114/ as well, please take another look
16:22:30 * harlowja_at_home woah we have messages that pass through openstack that are dozens of MB in size :-/
16:22:56 <harlowja_at_home> sounds like, ummm, that should be fixed, ha
16:23:02 <sileht> harlowja_at_home, I agree that's ugly
16:23:06 <dims> kgiusti : one thing that ozamiatin__ and others were looking at was, if we could do a compression before we hit the driver. but apparently some drivers like zmq using pickled stuff
16:23:19 <dims> harlowja_at_home : +10000
16:23:20 <harlowja_at_home> crazy ugly, lol
16:23:43 <dims> kgiusti and kombu for example has compression built in
16:23:54 <kgiusti> dims: amqp1 driver doesn't have compression built in
16:24:07 <harlowja_at_home> which messages are these? any idears? (scheduler select * hosts message?)
16:24:07 <kgiusti> dims: so something above the driver would be the only option atm
16:24:24 <lxsli> dims: re-reviewed that this morning
16:24:26 <dims> also another issue that crops up is rolling upgrades
16:24:29 <dims> lxsli thanks!
16:25:05 <haypo> we can just ask some stats on message sizes in a comment on the spec
16:25:06 <kgiusti> dims: IIRC nothing in amqp1 needs access to the msg contents, so pre compressed isn't a problem
16:25:10 <dims> kgiusti : so would it be ok for some drivers to use "above the driver" and some use "in the driver"?
16:25:14 <harlowja_at_home> haypo, +1
16:25:29 <kgiusti> dims: we should allow for that IMHO
16:25:48 <dims> kgiusti : cool, please chime in on the review when you get a chance
16:25:55 <sileht> about upgrades, just a description of how the driver should take care of the new format should be suffiscient
16:25:57 <kgiusti> dims: will do
16:26:15 <dims> dhellmann, harlowja_at_home : would love your input to https://review.openstack.org/#/c/243114/
16:26:41 <dims> oslo.config changes are scary :)
16:26:51 <harlowja_at_home> dims, yup, i'll look over that one again, i'm fine with it honestly, it will be interesting to see where it goes,
16:26:51 <dhellmann> dims : yes, I'm deeply skeptical of this being a good idea
16:26:57 <harlowja_at_home> lol
16:27:33 <haypo> can we stop making *everything* pluggable in openstack please?
16:27:36 <dims> dhellmann : the idea is for a container to start up say using keystone, and when the container is starting up, it pulls the configuration needed to start itself
16:27:45 <harlowja_at_home> haypo, impossible!
16:27:46 <dims> haypo : use case ^^
16:27:46 <harlowja_at_home> lol
16:27:49 <haypo> (i didn't read the spec)
16:27:56 <dhellmann> the central config service becomes a single-point-of-failure for the entire cluster, it introduces all sorts of complexity and synchronicity issues, *and* it doesn't eliminate the need to have client-specific configuration (client id at least) on each node
16:28:30 <dhellmann> dims : sure, I understand it, I just think it's a bad idea ^^
16:28:36 <dims> lol :)
16:28:47 <dims> please let's tell them about potential problems :)
16:29:06 <dims> #topic Open discussion
16:29:07 <dims> Any other stuck reviews?
16:29:11 <dims> open floor
16:29:34 <harlowja_at_home> so another option is to have oslo.cmdb or something that provides common cmdb -> oslo.config translators or something
16:30:06 <dims> amrith : kzaitsev_mb : kragniz : jecarey : anything from your side?
16:30:06 <haypo> yes, i would like your opinion on https://review.openstack.org/#/c/250731/ "Fix request_id type on Python 3: use text (Unicode)" IHMO my change fixes a bug in oslo.context, but dhellmann  complains (as always) that "i break the API"
16:30:36 <sileht> If people can take a look to this https://review.openstack.org/#/c/234716/, and tell me if this looks good or not or need a spec to discus
16:30:39 <haypo> my change only impacts python 3, and i checked most openstack projects, to update them (see the comments and dependency list)
16:30:42 <amrith> dims, nothing from my side. I thought there was something to bring up last week at the meeting but it turned out to be a false alarm.
16:30:51 <dims> sileht : does it break API for python 2.7?
16:31:06 <kzaitsev_mb> dims: nothing here either
16:31:06 * dhellmann refers haypo to the number of library releases in the last year blocked from global-requirements because of breaking API changes
16:31:12 <sileht> dims, I guess you mean haypo
16:31:18 <dims> oops yes
16:31:36 <dims> dhellmann : right
16:31:40 <haypo> dims: my change is specific to python 3, it doesn't change oslo.context on python 2
16:31:51 <harlowja_at_home> sileht, i'll look over for that today
16:31:51 <harlowja_at_home> haypo, is python 4 out yet?
16:31:57 <dhellmann> haypo : so you're saying that things will only break when applications start trying to port to python 3?
16:32:06 <dims> haypo : so if we break, we'd break python3 unit tests
16:32:22 <haypo> dhellmann: the major risk is breaking voting python3 jobs
16:32:27 <bknudson> don't even joke about python 4.
16:32:36 <dims> bknudson : haha
16:32:42 <dhellmann> haypo : right.
16:32:44 <harlowja_at_home> :)
16:32:59 <bknudson> I think request ID is bytes is a bug.
16:33:08 <bknudson> should be text
16:33:58 <dims> haypo : you have looked for and ran tests on lots of projects already right?
16:34:13 <dims> amrith : thanks
16:34:16 <haypo> dims: "major" projects yes
16:34:38 <dims> haypo : and searched using codesearch.openstack.org too
16:35:08 * harlowja_at_home just learned about codesearch
16:35:18 <haypo> dims: cinder, neutron, nova, ceilometer, heat
16:35:20 <dims> harlowja_at_home : that was intentional plug :)
16:35:43 <haypo> dims: yes. but i'm not sure that my search is enough to find all cases
16:36:00 <dims> haypo : let's drop an email to the -dev list as heads up, wait for all the Depends-On to merge that you filed already
16:36:28 <haypo> bknudson: "I think request ID is bytes is a bug. should be text" exactly. oslo.log currents write lines like [b'req-83a6...' 54492... - - -] ...
16:36:39 <dims> and then let the change in
16:36:49 <haypo> dims: an email to [all]?
16:37:01 <dims> haypo [oslo][all]
16:37:24 <lxsli> dhellmann did offer a way around this
16:38:06 <dims> haypo : what's the counter to doug's work around?
16:39:10 <dims> quickly rip off band-aid? :)
16:39:51 <haypo> dims: sorry, which work around?
16:40:13 <dims> haypo : "Instead of changing the return type of this function, we could add a new function that returns a unicode string, deprecate the old function, and update all of our applications to use the new one "
16:40:34 <haypo> dims: my problem is the .request_id attribute, i don't care of the generate_request_id() function, i guess that it's not called directly (but i didn't check)
16:40:58 <haypo> dims: i don't want to deprecate the .request_id, it's like used everyone (i guess)
16:41:02 <haypo> everywhere*
16:41:08 <dims> ack thanks haypo
16:41:21 <dims> any other reviews or things to discuss?
16:41:55 <lxsli> dhellmann mentioned a multi-callback system on um...
16:42:07 <lxsli> https://review.openstack.org/#/c/251422
16:42:07 * harlowja_at_home should try to write up an oslo blog entry soon
16:42:19 <dims> harlowja_at_home : ++
16:42:19 <harlowja_at_home> i swear i'm gonna finally do it! lol
16:42:21 <lxsli> From taskflow. Is that a thing?
16:42:41 <dhellmann> lxsli : yeah, I really  thought at the summit we said we wouldn't put callbacks into oslo.config at all, so I'm surprised to see it growing support for handling multiple callbacks.
16:42:51 <harlowja_at_home> lxsli, define thing :-P
16:42:52 <harlowja_at_home> taskflow is a thing, ha
16:43:11 <lxsli> dhellmann: I was in Nova meetings the whole summit so please educate me
16:43:38 <dhellmann> lxsli : the idea is that since the service-level code receives whatever signal to trigger the config reload, it can handle that, the application updates, and any other libraries at the same time
16:43:40 <lxsli> dhellmann: what's your solution and will it take more than 6 months to achieve?
16:44:01 <dhellmann> lxsli : I'm just saying this code needs to live somewhere else.
16:44:18 <lxsli> dhellmann: OK seems fair - then I'd like to remove the singular hook before oslo.config releases next
16:44:21 <dhellmann> oslo.config is at the bottom of the stack right now, and we don't want to make it really complicated
16:44:28 <harlowja_at_home> lxsli, http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.notifier.Notifier was an idea, but i think we didn't want to go there yet, but maybe people still want to
16:44:28 <dhellmann> lxsli : yes, I'll +2 that change if you ping me
16:44:34 <lxsli> will do, cheers
16:44:41 <dhellmann> dims : is this what you remember? ^^
16:45:14 <dims> dhellmann : don't recall, will find my notes later
16:45:20 <dhellmann> dims : ack
16:45:45 <dhellmann> I'm trying to remember if that was an oslo session, or if it was the cross-project session on reloading config data. Probably the latter.
16:45:59 <dims> dhellmann : yes, it was probably the latter
16:46:01 * harlowja_at_home thinks it was the latter
16:46:14 <dims> as i did not attend it LOL
16:46:26 <dhellmann> dims : oh, right
16:46:40 <dhellmann> harlowja_at_home : were you in that session? am I remembering correctly?
16:47:03 <harlowja_at_home> dhellmann, don't think i was, i just heard your results from what i remember
16:47:16 <harlowja_at_home> (your summary)
16:47:46 <haypo> 17:30 < sileht> If people can take a look to this https://review.openstack.org/#/c/234716/, and tell me if this looks good or not or need a spec to discus
16:48:54 <harlowja_at_home> https://etherpad.openstack.org/p/mitaka-cross-project-dynamic-config-services dhellmann dims i think that was the one
16:49:19 <dims> k let's take this to our channel and let everyone else go.
16:49:28 <dims> thanks everyone!
16:49:35 <harlowja_at_home> np
16:49:36 <dims> #endmeeting