16:00:50 #startmeeting oslo 16:00:51 Meeting started Mon Jun 15 16:00:50 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:52 o/ 16:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:53 o/ 16:00:54 o/ 16:00:55 The meeting name has been set to 'oslo' 16:00:56 o/ 16:00:59 o/ 16:01:16 o/ 16:01:26 hi 16:01:32 yo yo 16:01:38 hi 16:02:07 hi 16:02:11 let's get started :) 16:02:14 hi droyal 16:02:19 #topic Red flags for/from liaisons 16:02:39 None from Cinder. 16:02:55 Nothing on the Octavia front 16:03:00 I'd like to get a call on https://review.openstack.org/#/c/189523/ -- Revert "timeutils: deprecate isotime()" 16:03:02 o/ 16:03:07 im not a liason but neutron’s pymysql woes are probably significant 16:03:09 liaisons, i had filed some oslo-incubator sync's please look out for them 16:03:11 afaik none for neutron. 16:03:22 bknudson: ack 16:03:44 ./ 16:04:43 I don't care which way it goes myself, but if it's going to remain deprecated then we need to move away, and if it's un-deprecated then we'll go back to using it 16:04:53 bknudson: stevemar: did the python-dateutils get through global? 16:05:31 zzzeek, yeah, it's under control 16:05:35 ihrachyshka: :) 16:05:35 #link https://review.openstack.org/#/c/190268/ 16:06:46 dims, not yet, needs another +2 16:06:46 where's the docs? 16:06:56 https://dateutil.readthedocs.org/en/latest/ 16:07:04 jd__, yt 16:07:14 dims, https://review.openstack.org/#/c/190268/ 16:07:17 bknudson: so my take on this is...we are just marking it as deprecated, so keystone does not have to remove it immediately and can leave it for a cycle. but keystone really wants to get rid of it right away, so you should do what you want to do which is copy the code or use python-dateutils or something else 16:08:03 in effect we want to be able to tell everyone else that it's a bad idea and find alternatives i feel 16:08:19 bknudson: works? 16:08:20 * jd__ nods 16:08:28 dims: I'd like to see -2s on https://review.openstack.org/#/c/189523/ 16:08:56 how many -2s u want, lol 16:09:12 -2 with extreme prejudice! 16:09:15 i can help there -_- 16:09:19 lol 16:09:24 i just did a -1 16:09:34 real men put -4 on it 16:09:37 lol 16:09:44 :-) 16:10:00 they say Chuck Norris puts -8 16:10:10 -4, when -2 just doesn't get the message across 16:10:19 ihrachyshka, i'm pretty sure the whole CI system blows up when chuck norris touches it 16:10:21 bknudson: thanks for your patience and helping navigate all of us to a path 16:10:26 forward 16:10:36 harlowja_at_home: ++ 16:10:41 harlowja_at_home, you should not be the one to blow it up sometimes 16:10:48 it takes a single new library release 16:10:51 (that may or may not explain how it blows up every now or then) 16:11:36 any other issues? 16:11:43 k. moving on 16:11:47 #topic Releases for this week 16:11:47 Do we neeed any releases? Here are the unreleased changes 16:11:47 #link http://paste.openstack.org/show/294121/ 16:11:58 * harlowja_at_home is going to pop out a taskflow release today 16:12:13 or get dhellmann to (mr.release-man) 16:12:21 tooz? 16:12:37 yes, tooz we should to, jd__ what u think? 16:12:49 * harlowja_at_home also needs to get kazoo out (another lib that people use) 16:12:59 yes! 16:13:28 * https://github.com/python-zk/kazoo/pull/336 (if people care, the PR for that kazoo releasE) 16:13:29 tooz, taskflow from oslo space :) 16:13:43 the oslo galaxy 16:13:44 lol 16:14:47 on oslo.vmware 1.x i got word from vipin, garyk etc about fixing up their exception hierarchy as a pre-req for 1.x designation 16:14:58 so that's probably another week 16:15:13 k. next topic 16:15:16 #topic New libraries and drivers - how is it going? 16:15:16 #link specs - http://specs.openstack.org/openstack/oslo-specs/ 16:15:26 dims, dhellmann, we were going to create a feature branch for the new zmq driver 16:15:42 new libraries going good, hopefully a futurist release soon 16:15:51 *new librraries i'm helping get out there 16:15:56 ozamiatin: you need to provide dhellmann with a SHA which he can use to create a feature branch 16:16:08 i did create https://bugs.python.org/issue24451 (that would be nice for futurist) 16:16:16 harlowja_at_home: thanks 16:16:27 and i'll probably try to get something upstream in python for that, haypo hopefully help ;) 16:16:34 dims, k, got it 16:16:57 ozamiatin: sileht: the "new" support for dropping devstack in functional test is enough for zmq as well? 16:16:58 amqp 1.0 in CI - progress continues. If I can send more Red Bull to flaper87, we should be done soon 16:17:08 kgiusti: awesome 16:17:31 Anyone working on oslo.cache? i am concerned about that 16:17:59 dims, the gate jobs work, but the zmq functionnal tests still don't pass 16:18:23 silent, dims, they didn't pass with devstack too 16:18:30 sileht: thx for the update 16:18:36 something is stuck inside the driver during the tests, I have not invetigated more 16:18:38 ozamiatin: ack 16:19:19 anyone working on oslo.service or oslo.reports here today? 16:19:31 silent, I think it will be fixed in new driver now :) 16:19:42 ozamiatin: haha ++ 16:20:43 k switching 16:20:46 #topic New Specs 16:20:46 #link https://review.openstack.org/#/c/189006/ (Kafka) 16:20:46 #link https://review.openstack.org/#/c/191168/ (Windows support in oslo.service) 16:21:21 https://review.openstack.org/#/c/191168/ will be an interseting one to see how that goes 16:21:24 sileht: how much work is needed to expose our base classes so someone can write a messaging and notification driver outside our tree? any ideas? 16:21:28 * dhellmann steps away to deal with sofa delivery 16:22:06 harlowja_at_home: y especially reloading configs etc 16:22:14 * harlowja_at_home needs to poke sputnix (min) to get him to update https://review.openstack.org/#/c/186524/ 16:22:26 dims, no idea 16:22:37 dims, ya, it might expose some stuff we need in upstream python (or it might not, unsure) 16:22:49 dims, but that shouldn't be hard 16:22:59 #action harlowja_at_home poke sputnix about https://review.openstack.org/#/c/186524/ 16:23:39 sileht: so we can tell them to get their own repo and implement a kafka driver? 16:24:00 dims, for notifier it's very easy 16:24:01 since most of the code they pointed to is a kafka client from what harlowja_at_home told me :) 16:24:09 zzzeek, is there any online migration spec or such for oslo.db (it'd be interseting to read at the least, although u said u might be doing the changes in alembic itself, so maybe not oslo releated) 16:24:28 harlowja_at_home: at the moment i’ve been tasked with doing one for neutron 16:24:33 harlowja_at_home: it can become an oslo thing 16:24:47 harlowja_at_home: i wrote the rambly version on friday today I hope to chop out all the ramble from it 16:24:49 zzzeek, or alemibc thing, i was more interested in just reading how it would work :) 16:24:54 zzzeek, haha, kk 16:25:04 harlowja_at_home: yeah tehre’s also some alembic stuff I want to do in support of it 16:25:21 dims, I think we should document how to write a messaging that does only notification stuff 16:25:27 harlowja_at_home: but realy this issue of, “the model that speaks to both schema versions”, this is an unsolved, or not-very-well-solved problem 16:25:33 sileht: ++ 16:25:40 zzzeek, cool, i know to get alembic to run migrations automatically i had to do something 'weird' in taskflow 16:25:56 harlowja_at_home: wonder what you mean by “automatically" 16:26:10 sileht: i remember we also talked about more than one active notification driver with different messaging infra as well (is it possible now?) 16:26:10 well zzzeek by calling an upgrade() function 16:26:30 harlowja_at_home: OK, that is pretty straightforward…. 16:26:36 ya, https://github.com/openstack/taskflow/blob/master/taskflow/persistence/backends/sqlalchemy/migration.py#L31 16:26:44 nothing to magical 16:26:51 harlowja_at_home: you did too much here 16:26:56 probably, lol 16:26:57 dims, that possible from oslo.messaging PoV, but nova/neutron/... need to be updated to setup multiple transport instead of one global object 16:27:03 harlowja_at_home: you just call command.upgrade() for a straight upgrade 16:27:47 zzzeek, k, can chat after meeting to tweak that 16:27:51 harlowja_at_home: k 16:27:59 couple of new things, to help with release/requirements issues, we took over mox3 last week from mordred's repo 16:28:26 how much are people still using that? 16:28:34 jamielennox pinged me about a jsonhome impl - https://github.com/jamielennox/jsonhome/ - to see if oslo folks are interested 16:29:02 because i've seen weirdo errors with mox3 like in http://logs.openstack.org/72/190372/6/check/gate-oslo.service-python34/0e83172/console.html.gz 16:29:07 'AttributeError: No values given for arguments: self' 16:29:18 harlowja_at_home: it's in our global requirements, at least nova is using it. there's active work to move to mock, so we'll get rid of it when we are able to 16:29:20 we've got JSON-Home in keystone but it's just implemented with dicts 16:29:32 so if there was a library we'd use it in keystone 16:29:38 harlowja_at_home: y i logged a bug for that one 16:29:40 whats jsonhome? 16:29:55 and also when we add support for JSON Home resolution in keystoneclient we'll need some invention 16:30:04 harlowja_at_home: http://tools.ietf.org/html/draft-nottingham-json-home-02 16:30:10 JSONHome describes your REST resources 16:30:36 ah, k 16:30:56 it's provides relationships for the URLs so there's a level of indirection 16:31:33 so rather than go to /v3/auth/tokens, you would look up the relationship for "get_a_token" or whatever we call it. 16:31:54 it wont fit neatly into any existing oslo projects (like CORS did with oslo.middleware)... 16:32:09 so would need a new repo 16:32:47 me / bknudson will talk more with jamie and let everyone know...ok? 16:33:06 switching 16:33:10 #topic Ongoing work & Review priorities 16:33:10 #link https://etherpad.openstack.org/p/liberty-oslo-priorities-tracking 16:33:33 any items folks would like to speed up? 16:34:01 depends on how big of chunks of taskflow people want to know about :-P 16:34:23 https://review.openstack.org/#/c/189526/ would be neat (and https://review.openstack.org/#/c/189536/ ) 16:34:29 the example is neat imho if u want to try it 16:34:33 pretty awesome-sauce 16:34:54 some easy ones from harlowja_at_home - https://review.openstack.org/#/q/message:pypip.in,n,z :) 16:35:09 ya, i have up on that site 16:35:11 *gave up 16:35:16 been up/down to much 16:35:46 they even tried giving the owner some paypal money 16:35:48 didn't help 16:36:17 *see https://github.com/badges/pypipins/issues/37 16:36:17 here's an old one from jamie - https://review.openstack.org/#/c/143423/ 16:37:03 this one is a security related one in nova (needs a change in our code) - https://review.openstack.org/#/c/190472/ 16:37:32 essentially provide a hook so nova can track the pid and know when to kill 16:37:49 cool 16:38:28 dims: I don't think we want to add anything new to CfgFilter. 16:38:49 Given that we pretty much decided we weren't going to support it going forward. 16:38:57 bnemec: ack, please cast your vote on that review 16:39:01 i'll change mine too 16:39:02 * bnemec needs to get busy on that deprecation patch 16:40:00 another one i wanted to bring here - oslo.messaging does not use oslo.log...do we want to add oslo.log? https://review.openstack.org/#/c/190683/ 16:40:05 if people want some meaty taskflow review, https://review.openstack.org/#/c/164922/ (cue and octavia projects want that) 16:40:16 maybe to meaty for some people, idk 16:40:43 *especially vegetarians 16:40:51 bnemec: ++ on the deprecation patch 16:41:00 #topic Open discussion 16:41:11 #action bnemec deprecate config filter 16:41:25 if people are intersted: https://mail.python.org/pipermail/python-ideas/2015-May/033609.html 16:41:29 'Adding jsonschema to the standard library' 16:41:48 dims: what's the profit of using oslo.log in oslo.messaging? I thought, we tried to avoid inter-dependencies between oslo libs 16:41:48 may or may not happen 16:41:52 batteries included 16:42:03 rpodolyaka1: right, that's why i brought it up here 16:42:18 rpodolyaka1: in this case, there's a deprecation helper in oslo.log that might be useful in oslo.messaging 16:43:08 dhellmann: ahh, haven't seen it yet 16:43:09 dhellmann: how's the sofa? :) 16:43:11 also, https://mail.python.org/pipermail/python-ideas/2015-May/033740.html 16:43:16 'Displaying DeprecationWarnings in the interactive interpreter, second try' 16:43:25 *relevant a little to oslo 16:43:43 dims: the old one is gone now, still waiting for the new one :-) 16:43:54 :) 16:44:13 dhellmann: remember we talked about Oslo project group on Launchpad ? 16:44:20 #link https://bugs.launchpad.net/oslo/ 16:44:20 #link https://blueprints.launchpad.net/oslo 16:44:43 folks, do we need that group? or should all projects just show up under openstack? 16:44:50 openstack launchpad group 16:44:51 oh, dims dhellmann almost forgot, 2.6 dropping support, how much longer does that still have to happen? 16:45:05 *retaining 2.6 support that is 16:45:28 dims: the question is whether we ever need to look at all oslo projects in launchpad at once 16:45:43 we did for kilo, as we tried to predict what would land in certain milestones 16:45:46 * harlowja_at_home gets asked by infra sometimes, why 2.6 support for this new library X (since other library Y still maintains 2.6 and Y will use X) 16:45:55 but now that we're releasing on demand, that seems less useful 16:46:07 anddddddd oh, oslo.blog (??) 16:46:28 harlowja_at_home: we can use blog.openstack.org for blogging, we just need to give people the credentials they need 16:46:28 a handy library for blogging. 16:46:29 * harlowja_at_home is gonna blog all over that thing, lol 16:46:40 on the pro side, if we get rid of the group, our links in commit messages for bp(s) would work 16:46:56 bknudson, :) 16:47:10 harlowja: for 2.6 support, we need to maintain it in libs that are used by clients that still support 2.6 16:47:23 * dims has credentials, but has not worked up any posts yet 16:47:37 dhellmann, k, guess i need to go examine all those clients 16:47:42 see what they are up to 16:48:23 I believe juno is still tested on 2.6, but we have stable branches for libs now so that shouldn't affect us -- just projects testing 2.6 against master 16:48:30 keystonclient still has a 2.6 job 16:48:44 we'll drop it for 2.0 16:49:17 kk, so hopefully don't have to wait much longer i think 16:49:47 going to try something new, let's vote on the oslo group thing 16:49:49 #startvote Drop oslo project group? Yes, No, Maybe 16:49:50 Begin voting on: Drop oslo project group? Valid vote options are Yes, No, Maybe. 16:49:51 Vote using '#vote OPTION'. Only your last vote counts. 16:49:56 #vote Yes 16:50:10 #vote Yes 16:50:15 #vote yes 16:50:19 seems fine with me 16:50:32 *not sure what it buys us really 16:50:48 * sileht never uses it 16:50:52 #vote yes 16:51:14 harlowja_at_home: did you prepare the list of names for our mascot? :) 16:51:26 anyone else wants to vote? 16:51:28 oh crap 16:51:29 lol 16:51:39 maybe next time :-P 16:52:03 * jungleboyj doesn't have a strong feeling either way 16:52:08 #endvote 16:52:08 folks probably moved on :) 16:52:09 Voted on "Drop oslo project group?" Results are 16:52:10 Yes (4): harlowja_at_home, dims, dhellmann, sileht 16:52:29 anything else from anyone? 16:52:40 if not...give you back 8 mins 16:52:47 thanks everyone 16:52:48 #endmeeting