16:00:14 #startmeeting oslo 16:00:14 courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dougwig, e0ne, flaper87, garyk, harlowja, haypo, 16:00:14 courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, 16:00:15 Meeting started Mon Oct 12 16:00:14 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:16 courtesy ping for sergmelikyan, sreshetnyak, sileht, sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek 16:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:19 o/ 16:00:19 The meeting name has been set to 'oslo' 16:00:19 o/ 16:00:21 o/ 16:00:23 o/ 16:00:25 sup 16:00:27 o/ 16:00:32 ./ 16:00:34 0/ 16:00:35 * bknudson on fleek. 16:00:35 hi 16:00:40 hello! 16:00:42 o/ 16:00:46 o/ 16:00:50 hi 16:00:52 \o/ 16:00:56 o/ 16:00:59 * haypo has two arms 16:01:17 :) 16:01:19 o/ 16:01:30 welcome everyone, let's get rolling 16:01:31 #topic Red flags for/from liaisons 16:01:44 Nothing to report 16:01:45 I have a question in that area. 16:01:55 o/ 16:02:00 I saw an email about moving mask_password() from utils back to o-o. 16:02:16 o/ 16:02:18 keystone unit tests are failing locally due to requests!=2.8.0... still looking into it 16:02:21 could someone tell me what that's all about (or maybe for the purposes of this meeting whether that email subject line was misleading). 16:02:28 also, need a requirements bump for oslo.cache 16:02:39 amrith: not going to happen 16:02:45 trove uses the method so I wanted to know about it. thanks dims__ 16:02:51 nothing else from me. 16:02:54 not sure if the requests!=2.8.0 is going to affect the gate but it's not working locally 16:03:06 o/ 16:03:10 Nothing from Cinder. 16:03:25 amrith: there was a concern about backports and a suggestion o-o may be easier 16:03:46 thanks jungleboyj 16:03:54 bknudson: the oslo.cache requirements update is approved 16:03:57 bknudson: please file a bump if not already done 16:04:04 jungleboyj: thanks! 16:04:07 dims__, thanks. I'm not sure I follow that rationale but I guess we don't have to hold up this meeting for that (the list of things I don't understand is very long). 16:04:16 dims__: You are welcome twice. 16:04:17 hmm, now keystone unit tests are failing with requests.exceptions.InvalidSchema ... odd. I'll keep looking. 16:04:19 amrith: let's do it in the open discussion 16:04:21 bknudson: flaper87 knows about the requests issue, you might coordinate with him 16:04:53 bknudson: there's long email threads, most recently with updates from zigo 16:05:07 oh, I haven't caught up on the ml. 16:05:09 switching topics 16:05:49 bknudson: short story requests uses a vendorized version of urllib3 which may or may not be an actual urllib3 release causing issues 16:06:01 #topic Releases for Mitaka 16:06:01 #link https://review.openstack.org/#/c/233326/ 16:06:01 Releases pushed out today after verifying tests this morning https://travis-ci.org/dims/ 16:06:28 so, who ever is interested in bumps in versions, please file openstack/requirements reviews 16:06:33 woah, lots of releases, nice 16:06:59 dims__: if those releases are done we should merge the patch 16:07:00 harlowja_at_home: y, ran travis based tests a few times since fri 16:07:07 dhellmann: yes, about to 16:07:10 dims__: ++ 16:07:23 dims__, cools 16:08:07 should be a ton of emails on openstack-announce :) 16:08:51 we caught a bunch of issues last week with updates to neutron, heat, cinder, nova etc for testresources/testscenarios 16:09:02 so oslo.db is at 3.0.0 16:09:40 there was issues between nova and o.vo which was addressed already as well 16:10:07 note: oslo.report 0.6 changes the signal from SIGUSR1 to SIGUSR2 by default 16:10:08 and a neutron issue as it was using implementation details in oslo.messaging i believe 16:10:20 oslo.reports* 16:10:24 sorry oslo.policy 16:10:35 haypo: thanks for the highlight 16:11:02 i know that dhellmann was not a big fan of this change :-D 16:11:02 so let's keep a look out on zuul today and please let me know if you see breaks 16:11:40 haypo: i still have a TODO to fix the update constraints stuff to let us use oslo.db[xyz] in requirements files 16:12:15 k switching topics 16:12:18 dims__: ah, lifeless change on requirements was merged? 16:12:32 haypo: which one? 16:12:43 dims__: to export dependencies in oslo.db 16:12:59 signals don't provide enough info... we've got a network use it. 16:13:00 i don't know how this stuff is called, something like oslo.db[mysql] to require PyMySQL 16:13:06 haypo: i believe so 16:13:10 oh ok 16:13:41 haypo: it works in oslo.db itself. other projects can't use that syntax for now (see my TODO remark) 16:13:51 ok 16:14:24 bknudson: "signals"? 16:14:44 SIGUSR1, SIGUSR2 etc. 16:14:53 it's an outdated concept 16:15:08 right 16:15:11 bknudson: oslo.reports is only needed when a process is dying or stuck 16:15:23 bknudson: so for example when it doesn't communicate to the network anymore :) 16:15:52 but luckily it responds to signals? 16:16:06 bknudson: yes, it does 16:16:07 bknudson: that's the bet of oslo.reports 16:16:41 switching topics 16:16:46 #topic openstack spec reviews - oslo-incubator changes to add wrapper classes for request-id 16:16:46 #link https://blueprints.launchpad.net/oslo-incubator/+spec/wrapper-classes-to-return-request-id 16:16:58 hi 16:17:07 question: do we let things in till tokyo? into oslo-incubator? 16:17:20 question: do we need a library for things abhishekk needs? 16:17:24 'These new classes will be added in common package of oslo-incubator (apiclient/base.py).' :( 16:17:27 oh noes, lol 16:17:52 as long as oslo-incubator is switched to being obviously private (_ prefix) I'm ok with it. 16:17:59 i had asked abhishekk to check what they will do in projects that don't use the apiclient/* stuff 16:18:21 it's going to create a lot of work if we can't have a stable interface. 16:18:28 i am checking on it 16:18:39 although, stable interfaces create a lot of work, too 16:18:51 dhellmann: thoughts? as this came from cross-project spec / TC 16:21:14 abhishekk: will approve that spec once the meeting is over. my feeling is that we can let the changes in for now. we'll have to deal with _ prefix etc anyway whether we have this change or not 16:21:17 * harlowja_at_home thinks doug is somewhere else, ha 16:21:27 thank you dims__ 16:21:43 i would prefer to stop modifying oslo-incubator 16:21:48 and instead start to work on a real library 16:22:08 this spec looks like a good motivation to create it 16:22:23 +1 16:22:24 abhishekk: what do you think? 16:22:48 would it be possible to make baby step, like starting with a subset of the apiclient API? 16:22:53 is that library openstack-sdk? 16:23:11 dims__: i am not aware about making new liabrary 16:23:14 bknudson: what? 16:23:35 bknudson: i proposed to create a new library, ex: oslo.apiclient 16:23:41 abhishekk: would you be able to help with pulling out code you need into a library? 16:23:53 there's a group working on an openstack sdk library to replace the python-*client 16:24:07 dims__: I will check it out 16:24:15 bknudson: i'm not talking about the openstack sdk thing, it's unrelated IMHO 16:24:33 abhishekk: check this out - https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary 16:24:48 abhishekk: i can try to help you to do that 16:24:55 me too 16:24:56 bknudson: for openstacksdk I have filed anothr blueprint 16:25:08 haypo: we've previously told people that they should just switch to something else, probably in openstack-sdk 16:25:13 dims__, hypo, joshua thank you 16:25:18 np 16:25:37 nice segue to the next topic 16:25:40 https://blueprints.launchpad.net/python-openstacksdk/+spec/return-request-id-to-caller 16:25:40 #topic summit request for sessions 16:25:40 #link https://etherpad.openstack.org/p/mitaka-oslo-summit-planning 16:25:43 if the funcationality is in openstacksdk, we can use it in python-keystoneclient 16:25:56 oh man, tokyo here we come 16:25:58 abhishekk: please add oslo.apiclient to the mitaka etherpad for consideration 16:26:10 dims__: sure 16:26:10 do we know who is all going to tokyo btw? 16:26:30 or maybe better question, who isn't going to tokyo 16:26:57 dims__: oh ok (for openstack-sdk) 16:27:25 i'll need help later today to finalize the list of topics, anyone free later today? 16:27:31 o/ - no travel budget :( 16:27:37 kgiusti: ouch :( 16:27:50 dims__, sure let me know, we can make up some creative session names, hahaha 16:27:57 harlowja_at_home: ack thanks! 16:28:12 #topic Open discussion 16:28:12 Any stuck reviews? or specs? 16:28:28 kgiusti: proton still holding up against devstack+tempest? 16:28:40 not exactly stuck, but very embarrassing: https://review.openstack.org/#/c/233094/ 16:29:02 haha :) +2 16:29:03 since i thought it was cool 16:29:05 http://tempsend.com/E38B61A9FA/6D80/oslo.svg 16:29:10 print that out and put on your wall folks 16:29:10 lol 16:29:18 harlowja_at_home: nice :) 16:29:29 looks like a big bang 16:29:32 :) 16:29:35 or traces from the supercollider 16:29:38 lol 16:29:42 kgiusti: i didn't understand https://review.openstack.org/#/c/233094/ but i see gate-tempest-dsvm-full-zmq FAILURE 16:29:54 the oslobigbang, ha 16:29:57 kgiusti: why do you expect the gate to fail? 16:30:17 bknudson, https://review.openstack.org/#/c/232729/ 16:30:18 haypo: it was failing before 16:30:25 http://tempsend.com/44D56E1EE3/A632/infra.svg is a bigger bang, lol 16:30:31 haypo: it is non-voting for that reason 16:30:40 haypo: I don't expect it to fail - that change only affects tox on amqp1 16:30:49 harlowja_at_home: Oh my ... So many oslo things. 16:30:50 hum wait, the patch is for AMQP but the failing gate is ZMP 16:30:53 lol 16:30:53 it's unrelated, right? 16:31:02 (http://tempsend.com/1F392B692C/1FFD/os.svg ) every project 16:31:04 haypo: dumps protocol trace msgs over "the wire" 16:31:23 kgiusti: anyway, i trust you, it's now approved := 16:31:24 :) 16:31:30 haypo: I had expected it to fail gate - it was consistently failing before 16:31:37 haypo: yeah 16:31:38 haypo: thanks1 16:31:55 haypo: hmmm - you trust me, eh? 16:32:04 kgiusti: i was confused by "the gate". there are a lot of gates 16:32:12 kgiusti: you worked on AMQP more than me :) 16:32:14 haypo: I've got a deal on some land in florida.... 16:32:26 haypo: :) 16:32:33 kgiusti: i only trust you for AMQP things :) 16:32:39 jungleboyj, http://tempsend.com/44D56E1EE3/A632/infra.svg is much bigger bang, lol 16:32:55 if you are bored, another pending review for python3 : https://review.openstack.org/#/c/233093/ 16:33:30 dims__: again, i'm not sure that an oslo session is required for python3, i still it in the etherpad 16:33:55 is python4 out yet? 16:33:57 :) 16:34:05 harlowja_at_home: Oy vey! 16:34:15 harlowja_at_home: lol 16:34:20 harlowja_at_home: almost 16:34:24 :) 16:34:57 dims__, I have one for open discussion 16:35:09 amrith: what's up? 16:35:20 next steps on oslo.messaging encryption 16:35:23 haypo: probably not 16:35:37 amrith: did you pick an approach yet? 16:35:42 https://bugs.launchpad.net/oslo.messaging/+bug/1504525 16:35:42 Launchpad bug 1504525 in oslo.messaging "oslo messaging should provide a mechansim to generate a completely encrypted channel" [Undecided,New] - Assigned to Amrith (amrith) 16:35:57 haypo, i'd be interseted in hearing peoples thoughts about what to do now that python3 support is nearly everywhere, would any project actually start only using python3 (and therefore people can actually use python3 features/functionality) 16:35:57 dims__, I'm not sure which is better 16:36:17 amrith: can you please enumerate the 2 approaches? 16:36:23 that would seem like something that people more experience in o.m should provide some color. 16:36:27 so the two approaches are these ... 16:36:29 haypo, aka, drop 2.7 completely for some project? 16:36:32 python3 support is nearly everywhere? 16:36:36 lol 16:36:50 nearly, lol :-/ 16:37:01 for some defintion of near 16:37:01 a) given that o.m already has a concept of a driver for each transport, make encryption common for all transports; i.e. implement encryption above the driver. 16:37:02 lol 16:37:14 b) provide implementations of encryption per-driver 16:37:19 bknudson: 6 applications works on Python 3, http://blogs.rdoproject.org/7807/python-3-status-openstack-liberty 16:38:07 sileht: kgiusti: ozamiatin: thoughts please ^^^ 16:38:53 haypo: the other applications are the ones everybody needs 16:39:08 current drivers support "over the wire" encryption (ssl/gssapi/etc). This would involve end-2-end encryption. 16:39:21 I think that' sbetter done above the drivers 16:39:42 the tricky part would be the key exchange - that's above my paycheck, sadly. 16:39:49 kgiusti, when you say current drivers support "over the wire" ... how so? 16:40:06 that would be a matter of how one configured the underlying transport. 16:40:10 harlowja_at_home: the next milestone is to run functional tests on python 3 16:40:19 harlowja_at_home: without this, it's hard to trust python 3 support :-/ 16:40:20 kgiusti: we had the kite project for a while for key exchange. 16:40:22 the best I've found, for example to enable ssl on rabbit, is to do https://www.rabbitmq.com/ssl.html 16:40:28 amrith: I think rabbitmq supports SSL encryption 16:40:36 haypo, good point 16:40:40 harlowja_at_home: the first step would be to add an option to install some apps and clients on py3 16:40:52 amrith: proton (amqp1) support SSL and SASL-based encryption 16:40:56 https://github.com/OpenStack/kite 16:41:19 amrith: but this is only on the wire to the broker. The secure tunnel ends at the broker 16:41:39 amrith: of course, both directions (from and to broker) are encrypted 16:41:47 I guess it's still around: https://review.openstack.org/#/q/project:openstack/kite,n,z 16:42:00 kgiusti, what's proton? 16:42:09 amrith: but messages on the broker are not, unless the sending endpoint has encrypted the payload. 16:42:36 amrith: sorry - that's the amqp1 driver - I really shouldn't be using the term 'broker' 16:42:52 amrith: no wait - not using 'proton' (freudian slip) 16:43:27 kgiusti, sounds like a discussion we can take offline (to #openstack.oslo) 16:43:27 amrith: what I really need to do is document how to setup SSL and/or SASL using amqp1 driver... 16:43:38 amrith: +1 16:44:15 bknudson: +1 that's what I was trying to remember ! 16:45:30 there's an oslo conf setting, if that helps ;) 16:47:15 dims__, kgiusti let's take this to #openstack.oslo for later 16:47:20 ok, so let's wrap up folks? 16:47:31 thanks everyone 16:47:38 #endmeeting