16:00:18 #startmeeting oslo 16:00:18 Meeting started Mon Jun 1 16:00:18 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:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:22 The meeting name has been set to 'oslo' 16:00:25 o/ 16:00:26 o/ 16:00:27 courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka, zzzeek, sileht, kgiusti, dansmith 16:00:28 courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith 16:00:29 o/ 16:00:33 sup 16:00:36 o/ 16:00:39 o/ 16:00:43 o/ 16:00:46 o/ 16:00:48 o/ 16:00:54 \o 16:00:57 aloha 16:01:21 dims_: You might want to replace yourself in the courtesy ping list with dhellmann. :-) 16:01:36 welcome back everyone, it was nice seeing y'all at vancouver 16:01:47 bnemec: still using his cheat sheet :) 16:01:58 Yeah, I figured 16:02:18 #topic Review action items from previous meeting 16:02:19 :) 16:02:37 1. dims to research oslo mid-cycle possibilities (IN PROGRESS) 16:02:48 hawaii? 16:02:50 so, anyone fancy a mid-cycle meetup? 16:02:52 o/ 16:03:15 harlowja_at_home: other than lounging on the beach what else would we do? 16:03:32 collaborate and all that 16:03:44 ha 16:03:46 :) 16:03:51 the oslo.db build made my entire machine hang up. fully rebooted. machine restored its state, the whole test suite ran completely while the whole machine was frozen! 16:03:55 it would be best if we were able to identify a couple of specific things to focus on for that time 16:04:12 looking for something to bind us all together or we'd end up doing something by ourselves there 16:04:14 y 16:04:36 i'll ask this again next week if anyone has any ideas 16:04:39 hmmmm 16:04:53 #topic Red flags for/from liaisons 16:05:13 No red flags for keystone. 16:05:21 anything graduating that I need to worry about? 16:05:21 o/ 16:05:23 Nothing from Cinder right now. Just trying to find time to work on the issues I have open. :-) 16:05:25 heads up, we'll be cutting a bunch of releases tomorrow 16:05:29 neutron is here to wave some flags! 16:05:30 I think I need to switch versionutils 16:05:37 first, we want oslo.policy release to be able to switch to it 16:05:56 #link http://paste.openstack.org/show/245057/ 16:05:57 ihrachyshka: that's next item on agenda 16:06:25 Nothing from Octavia 16:06:41 second, we had that discussion on the summit about neutron playing bad with ServiceLauncher and friends. we have some patches in review, but I'm not completely sure whether we consume everything correctly from our side, so if someone from oslo.service guys is able to check those, it would be great 16:06:44 #link https://review.openstack.org/#/c/161732/ 16:06:57 and dependents 16:07:04 hmmm, oslo.service is one of those things graduating i think this time around (last time i checked) 16:07:21 harlowja, yeah, but there is already service.py that we consume from incubator 16:07:24 should be the same code 16:07:27 hi where’s the agenda? link at http://eavesdrop.openstack.org/#Oslo_Team_Meeting goes to a blank page 16:07:29 #action dims to ping eezhova about ihar's https://review.openstack.org/#/c/161732/ review 16:07:35 right, or better ihrachyshka 16:07:51 the neutron issue was mostly that we spawned multiple Launchers in single process 16:08:20 there is one thing I want to note in this context: there is nothing that documents that current neutron usage of the module is incorrect 16:08:22 zzzeek_: it's here - https://wiki.openstack.org/wiki/Meetings/Oslo - but i have to bring it up to date 16:08:28 so oslo.service needs better docs 16:08:30 * harlowja_at_home wonders if https://review.openstack.org/#/c/164836/ should/would help 16:08:35 or better, it needs docs :) 16:08:36 +1 to better docs 16:08:47 ihrachyshka: true. will make sure we do as part of oslo.service 16:08:49 dims_: OK so the agenda for today is not published 16:08:55 o/ 16:09:13 zzzeek_: yes, it's dated 16:09:22 dims_, meh... if eezhova is behind oslo.service, then it's worthless for her to check the patch since it's her patch :) 16:09:36 :) 16:09:57 ihrachyshka: there's a couple of more people i think, don't remember off the top of my head have to go find the old reviews 16:10:06 especially the reverts 16:10:07 https://review.openstack.org/#/c/142659/ (sachi?) 16:10:36 but elena uploading stuff, so i'm guessing both 16:10:47 harlowja_at_home: at least those 2 16:11:07 ya 16:11:56 ihrachyshka: will make sure there is eyes on that review. anything else from anyone? 16:12:03 if not... 16:12:05 #topic Releases for this week 16:12:20 dhellmann: what are we releasing today? 16:12:54 a shorter list would be what's not being released today 16:12:59 haypo needs a oslo.db release for some python34/nova work according to my notes 16:13:31 dims_: I wasn't planning to release anything other than the middleware library today, but I can do more if you'd like 16:13:39 oslo.utils yet (or are we still waiting on that one for nova fixes?) 16:13:59 stevemar: side topic but we want to release pycadf 1.0.0? 16:14:00 dhellmann, oslo.policy? :) 16:14:04 harlowja_at_home: i spoke wrong, it was not oslo.utils that was going to break nova, it was oslo.serialization 16:14:09 ah 16:14:13 dims_: I had a long list for tomorrow: http://paste.openstack.org/show/253257/ 16:14:15 release all the things!!!! lol 16:14:58 yeah, basically, all of it 16:15:07 dhellmann: if we don't break gate today, we can try to get all of them out tomorrow 16:15:07 gordc: I can do pycadf as well, if you want 16:15:10 :) 16:15:12 dims_: ++ 16:15:41 #action dims to poke nova folks for possible oslo.serialization impact on nova unit tests 16:15:49 dhellmann: sure -- just checking to see if there's no last minute patches 16:16:31 dhellmann: yeah, i think we can do a 1.0.0 release for pycadf 16:16:45 dhellmann: expect pbr, right? 16:16:59 gordc: ++ to 1.0.0 16:17:01 gordc: http://paste.openstack.org/show/253258/ shows what it will include 16:17:07 except pbr i mean 16:17:08 dims_: right, not pbr, I leave that for lifeless 16:17:14 sounds good dhellmann 16:17:52 dhellmann: looks fine to me. the big thing was just removing all the middleware and dependencies 16:18:15 k 16:18:20 dhellmann: at some point we have to figure out if the library versions need to be bumped up to 1.x (of those that are 0.x) do we do that in milestone 3 like last time? 16:18:29 pycadf 1.0 ! 16:18:43 gordc, i think we're good for pycadf 1.0.0... we dropped the middleware bits right? 16:18:45 we can do that whenever we're ready. It would be good to have them all at 1.0 by the end of the cycle 16:19:16 gordc: just give me and dhellmann a heads up when you push it, so we can watch for fallout 16:19:27 stevemar: yeah. 16:19:48 next topic... 16:19:55 #topic Documentation 16:20:13 Anyone have time to write user facing documentation for different oslo libraries? 16:20:25 i can write a little, but not all of it :-P 16:20:48 ack. is this something that we can do in a mid-cycle meetup? 16:21:23 i'd be nice to have at least each library have something minimial like @ http://docs.openstack.org/developer/debtcollector/ (overview, + some examples + some api doc) 16:21:25 I'll be working on the oslo.log docs this cycle 16:21:28 dims_, could be 16:21:33 please ping me if you are interested in specific ones so we can divide up work 16:21:48 dims_: nice idea to work on the docs at the midcycle 16:21:53 ++ harlowja_at_home 16:22:51 ok. switching topics 16:22:53 #topic Feedback from Vancouver summit 16:22:56 maybe we should see what people think as the ones that need the most docs and go from there? 16:23:00 what was good? bad? keep? change? 16:23:20 change, more airplane rides 16:23:37 apart from some travel issues (visa/flight).. :) 16:23:37 dims_, ./ 16:23:42 it was very difficult to get flights to vancouver 16:24:05 zzzeek_: ack. thanks for google hangout at least 16:24:06 *airplane rides (== the ones taking off from the bay); not the other ones, lol 16:24:11 dims_: sure 16:24:17 dims_, ./ 16:24:22 hi amrith 16:24:31 dims_, didn't want to interrupt 16:24:34 because I tuned in late 16:24:37 np 16:24:42 but your q: re: feedback from vancouver 16:24:45 I have two 16:24:47 yes 16:24:49 relate specifically to trove 16:24:51 I thought we had a few Oslo sessions where there wasn't a lot of discussion needed. 16:25:04 Maybe those should have been resolved as plain old specs instead. 16:25:13 bnemec: the config ones? 16:25:20 the first is whether there is any way in which a oslo.messaging client can manage users/authentication of the underlying AMQP (like Rabbit) through o.m. 16:25:32 the second is about the feasibility of having an o.m driver for zaqar 16:25:47 to projects like Trove, the benefit of o.m is that it is a layer of abstraction 16:25:50 sileht: around? ^^^ 16:25:53 dims_: Yeah, maybe one or two others too. 16:25:54 and a user can choose what they want under the covers 16:26:02 bnemec: ack i agree 16:26:02 * harlowja_at_home would also somehow like more PTL(s) from other projects knowing whats happening in oslo, maybe there should be a designated session/talk/other each summit just for that, so they can know whats 'happening/coming up'? 16:26:29 dims_: In the past we had pushed back on topics like that, but because we got basically all the sessions we wanted this time we didn't bother. 16:26:32 harlowja_at_home: hard to get PTL(s) into one meeting as every has a track 16:26:37 as the big tent gets bigger, it'd be nice to have something like that (IMHO); a oslo-recap 16:26:38 bnemec: right 16:26:43 dims_, maybe recorded presentation then? 16:26:47 "State of Oslo" 16:26:50 ya 16:26:56 something like that 16:26:57 https://libertydesignsummit.sched.org/?s=oslo#.VWyHu0RL1Ls -- oslo schedule 16:27:07 I think it would have reduced the conflicts with other relevant sessions if we limited ours a little more. 16:27:25 I'd like to see fewer keystone sessions, too. 16:27:38 we're not likely to have as many sessions for tokyo, so we'll need to be more careful with topic selection 16:27:47 amrith: we have never talked about managing users/auth of underlying infra so far. 16:27:50 Do they really need to schedule the work room sessions? seems like we should just have free time to get together 16:28:09 amrith: if we get someone interested its a possibility i guess 16:28:35 Well, we had pods in the past for ad hoc work sessions, but without a scheduled time I never actually went to any. :-/ 16:28:43 it'd be cool if there was a technical (not just a presentation) for state of [oslo, nova, glance, keystone, all of them...] for all the projects, some kind of talk that is recorded so that everyone can know whats been and will be happening for each project 16:28:46 dims_, the issue is that in case of projects like trove, the o.m channel is used to talk with guests 16:28:52 * bnemec is a slave to the schedule 16:28:53 amrith: zaqar - flaper87 indicated that zaqar may not be a good fit for where oslo.messaging is used right now 16:29:03 and having per-tenant authentication would be a good thing. 16:29:11 bnemec: ack, we can trim our sessions 16:29:15 o/ 16:29:27 so, we're very hesitant to have that driver inside o.m 16:29:28 amrith, oslo.messaging is not aware of what is a tenant/user/project/domain/... 16:29:30 dims_, I don't understand the issue there; I believe his feeling was that people would think zaqar was a replacement for rabbit and that would be bad. 16:29:37 but he's here 16:29:39 harlowja_at_home, they used to do that 16:29:42 he can explain it better. 16:29:46 TBH, the suggestion was to give it a try and have it as an external driver 16:30:05 amrith: may i request adding a few blueprints on the topics you mentioned in oslo.messaging and see if anyone is interested? (after this meeting) 16:30:16 stevemar, oh, hmmm, wonder why that stopped 16:30:17 amrith, oslo.messaging is rcp abstraction layer zaqar is messaging as service 16:30:21 harlowja_at_home: in the past we've done those as video presentations recorded by the foundation and published online, I just didn't do one for kilo 16:30:21 rcp/rpc 16:30:30 but generally, yeah, I'd like to avoid people thinking Zaqar is a replacement for rabbitmq 16:30:32 Also, ++ to state of oslo fishbowl session 16:30:38 My request comes from the place that there are people who see value in running trove over zaqar but having trove get tied to zaqar seems like a bad idea. 16:30:51 Although I think we need liaisons to attend more than ptls, necessarily. 16:30:58 bnemec: agree 16:31:00 bnemec, sure, either or 16:31:05 TBH, to some extent we could say that as long as we document it, we should be fine. But that's kinda never the case 16:31:06 amrith, dims_, sileht : could we maybe discuss that separately from the summit feedback? 16:31:13 * amrith tries to demultiplex conversations 16:31:22 dhellmann, ++ 16:31:25 * flaper87 should have read the topic 16:31:26 amrith: thanks :-) 16:31:30 I'm sorry for that 16:31:43 flaper87: Well, we did ping you. :-) 16:31:53 what else, hmmm, the food was good :-P 16:31:59 so +1 to that 16:32:02 :) 16:32:23 I request more sessions on terraces with gorgeous views. 16:32:31 And float planes. :-) 16:32:33 re: feedback ... the parties didn't run out of beer and wine which is an improvement over Paris. 16:32:40 def, more sessions on sea/flow planes 16:32:43 it's good to hear that we noticed the lack of focus/usefulness in some sessions, since this was the first time we've had so many time slots available to us. I think that means we'll be able to be constructive with less time, even if we have to cut some topics. 16:32:57 *float planes (not flow, ha) 16:33:17 * dhellmann thinks harlowja_at_home has taskflow on his mind 16:33:23 haha 16:33:27 dhellmann: right and gives us time to attend other project sessions to get to know what they need from us 16:33:28 :-) 16:33:32 I would have liked to attend more oslo sessions but there were other ones keeping me busy 16:33:34 dims_: ++ 16:33:53 we learn more about how to have good summits every time we do them 16:33:54 Yeah, between oslo and tripleo I could hardly attend any other sessions. 16:34:02 dhellmann: +1 16:34:06 duly noted :) 16:34:16 k. switching 16:34:19 #topic New libraries and drivers - how is it going? 16:34:33 anyone here got started on any of the new ones? 16:34:37 #link specs - http://specs.openstack.org/openstack/oslo-specs/ 16:34:40 ozamiatin: ? 16:34:40 hi, I'm in progress with a spec 16:35:00 ozamiatin: link? 16:35:16 not yet uploaded 16:35:21 ok 16:35:22 I will finish today 16:35:41 sounds good, did you get enough feedback from folks at the summit ozamiatin? 16:36:31 yes 16:36:49 I think we will also discuss in comments to the spec 16:36:57 dhellmann: so i have trouble reaching solly 16:37:08 dhellmann: for oslo.reports - (https://review.openstack.org/#/c/185715/) 16:37:19 anyone work with solly? 16:37:36 dims_: we should see if some of our other red hat contacts can help us reach him 16:37:43 bnemec: ? 16:37:49 dims_: I do 16:38:05 Yeah, we should be able to get ahold of him. 16:38:14 kgiusti: please ping him about oslo.reports. review url above 16:38:17 thanks 16:38:19 I know he was keen to get it graduated for Kilo, but ran out of time. 16:38:23 dims_: will do 16:38:37 k switching 16:38:53 #topic What do we ask other projects to adopt for liberty on a higher priority? 16:38:56 oh me me 16:38:57 https://review.openstack.org/#/c/182808/ (waiting) and https://review.openstack.org/#/c/185077/ (waiting) 16:38:57 so mainly just waiting, lol 16:38:57 * harlowja_at_home may poke infra to just get those going... 16:39:15 so i can find ptls and liaisons and talk to them about it 16:39:18 dims_: oslo.context and oslo.log standardization should be a priority; I'll be helping with that. 16:39:32 oslo-config-generator? oslo.policy? oslo.versionedobjects? 16:39:38 dhellmann: nice 16:40:04 dims_: the config generator is another good one 16:40:23 Yes, especially after what happened in cinder this cycle. 16:40:23 all of those are good, but policy and vo are newer so maybe we give more time for those 16:40:37 There be dragons in mixing the old config generator with the new libs. 16:40:43 dhellmann: bnemec: ack 16:41:05 bnemec: Yeah, there are dragons there. 16:41:24 k switching 16:41:28 #topic Ongoing work & Review priorities 16:41:42 any requests for reviews? 16:41:48 bnemec: I need to find time to actually code up things for the new config generator. Don't like that we are mixing old and new. 16:41:49 jungleboyj: did we resolve the plan, or do we need to make changes to the config generator first? 16:42:34 dhellmann: I think I need to come up with a way of using the new config generator that everyone can agree upon. 16:43:03 jungleboyj: ok, if that means changes to make it more palatable we can discuss those when the time comes 16:43:27 Ok. I hope to get time to poke at that again in the next couple of weeks. 16:43:32 * jungleboyj crosses fingers. 16:43:49 kgiusti: we need to work towards proton running dsvm+tempest CI jobs? 16:44:33 harlowja_at_home: all your reviews for governance etc made it through? 16:44:38 also do we need to get the rabbitmq folks in the #oslo channel? be nice to have them there 16:44:39 dims_: yes - flaper87 and I are working on making the required proton libraries better available via pypi 16:44:40 dims_, seems so 16:45:09 *or whoever the rabbitmq (corp) said they would get involved,be nice to get that person ramping up 16:45:09 dims_: trying to land those changes in proton upstream shortly 16:45:24 harlowja_at_home: we have them on twitter at the moment, let's see if we get any actual reviews from them then we can request them to show up on irc 16:45:31 k 16:45:35 fair enough 16:46:23 harlowja_at_home: we have them on twitter at the moment, so we need you on twitter now :) 16:46:58 anyone have really old reviews that needs attention? 16:47:25 #topic Open discussion 16:47:48 * harlowja_still_a arg, why do i keep on getting disconnected 16:47:51 the review dashboard link produces a query with patches older than 5 days without reviews 16:48:15 https://wiki.openstack.org/wiki/Oslo#Review_Links 16:48:30 zzzeek_: how did that nova session with oslo.db go? (you had mentioned that you can try to switch migrations to alembic etc and there was some concerns about the online migration they were proposing) 16:49:07 dims_: OK so, i had the session, and got their rationales, and basically they’re just going to do it that way and I’d anticipate that other projects will start doing similar things 16:49:21 is that good/bad/meh? 16:49:24 dims_: that is, they’re abandoning the concept of fixed schema migration files 16:49:33 only for data migrations, right? 16:49:39 dhellmann: no, full schema migrations 16:49:41 dhellmann: everything 16:49:51 where will column additions happen? 16:50:09 dhellmann: that is, a tool runs which inspects the current DB, compares it to the model in Python, and applies “expansions” dynmically 16:50:12 dhellmann: in the “expand” phase 16:50:22 ok, I guess I need to find that spec 16:50:31 dhellmann: yeah 16:50:36 * harlowja_still_a wonders why we are using things with schema(s) at all, lol 16:50:50 * harlowja_still_a runs away 16:50:54 thanks zzzeek_ 16:51:08 so anyone have an opinion on this one? https://review.openstack.org/#/c/185504/ 16:51:13 removing oslo.utils dependency from debtcollector 16:51:19 ah, yes, that one 16:51:56 we shouldn't have a circular dependency there, how did we let that happen? 16:52:18 snuck in i think 16:52:20 oslo.utils needs to have fewer dependencies. 16:52:40 * harlowja_still_a is fine with a new-tiny-library, but i'll let others decide 16:53:16 debtcollector probably needs to be one of those things that doesn't depend on much though. 16:53:25 Since it could be pulled in to any lib at any time 16:53:26 https://pypi.python.org/pypi/silvering (for example, the process of making mirrors, aka reflection...) 16:53:36 could just take that and make it the refelction stuff 16:53:40 yeah, debtcollector should be at the bottom -- why does it need these functions? 16:54:08 making nice messages about what is deprecated 16:54:13 thats all 16:54:23 can we not just ask the developer to provide the details? 16:54:43 dhellmann: original online schema cahnges spec at https://review.openstack.org/#/c/102545/ 16:55:01 for example, if we deprecate a public class in an oslo lib that's in a private module but exposed through a public module, we would want to specify the public name for the class rather than have this code give the actual name 16:55:05 zzzeek_: thanks 16:55:48 dhellmann / dims_ : also a wrapup of my thoughts of the discussion are at http://lists.openstack.org/pipermail/openstack-dev/2015-May/064602.html 16:56:08 dhellmann, possible to do that, although the current api tries to be nice and helpful and figure out the names 16:56:23 zzzeek_: thanks 16:56:50 harlowja_still_a: yeah, but it seems like the case I describe, which we have in our code, is going to break that anyway, right? 16:57:09 it's just reflection that it uses, so maybe have an oslo_reflection rather than oslo_utils.reflection. 16:57:10 sounds like a new feature to make it possible to turn off the auto-figuring stuff out 16:57:25 bknudson, or i can go claim https://pypi.python.org/pypi/silvering and make that the reflection stuff 16:57:35 3 mins left, let's move discussion to the review please? 16:57:42 yeah, and I would say we want debtcollector not depend on anything else, if we can help it, as bnemec pointed out 16:57:49 dims_: ++ 16:57:59 dhellmann, ok, the review is fine then i think, chops stuff thats used out 16:58:43 thanks everyone, let's continue on our irc channel 16:58:48 #endmeeting