21:02:09 <ttx> #startmeeting crossproject 21:02:10 <openstack> Meeting started Tue Jan 6 21:02:09 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:12 * mestery waves at ttx again 21:02:15 <openstack> The meeting name has been set to 'crossproject' 21:02:25 <ttx> Our agenda for today: 21:02:32 <ttx> #link http://wiki.openstack.org/Meetings/CrossProjectMeeting 21:02:42 <ttx> mestery: live line edit fail 21:02:49 <mestery> lol 21:02:58 <ttx> #topic State of nova-network to neutron migration 21:03:04 <ttx> anteaya: around? 21:03:14 <ttx> This was raised in a ML thread before the holiday season 21:03:23 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-December/053355.html 21:03:26 <jungleboyj> o/ 21:03:28 <boris-42> Hey hey 21:03:32 <boris-42> ttx: happy new year=) 21:03:37 <anteaya> I am 21:03:44 <ttx> boris-42: thx, glad you could join 21:03:50 <ttx> In summary, while this is a stated priority for Nova and Neutron teams, the effort has stalled 21:03:53 <boris-42> ttx: yep from vacation=) 21:04:04 <ttx> I think we have already taken steps to address this issue with a specific meeting and a champion to make sure progress is made 21:04:11 * nikhil_k joins in 21:04:18 <anteaya> we are working on collecting around a meeting time 21:04:22 <mestery> ttx: Yes 21:04:23 <ttx> I would just like to make sure there are no blockers at this point 21:04:28 <anteaya> so far myself and oleg have stated preferences 21:04:34 <ttx> If there are, see if that meeting can help remove them 21:04:35 <anteaya> well today russian holidays 21:04:41 <anteaya> but that will come to an end 21:04:56 <ttx> anteaya: do we have all the team-specific liaisons we need to make progress here ? 21:04:58 <jogo> anteaya: the timing for setting up a meeting wasn't great with the holidays. hope to respond today 21:05:05 <anteaya> jogo: thank you 21:05:18 <mikal> I know gus is interested too -- I'll make sure he's aware 21:05:18 <anteaya> we have jogo's and mikal's attention in nova 21:05:23 <anteaya> great and gus 21:05:25 <markmcclain> ttx: yes.. we should now 21:05:36 <anteaya> and mestery and markmcclain and oleg in neutron 21:05:42 <ttx> Do we need ops-side support ? 21:05:55 <anteaya> ttx good question, whom might you recommend? 21:05:58 <ttx> like have a few of them in the workgroup 21:06:02 <mestery> Someone from CERN I imagine 21:06:03 * anteaya turns down no offer of support 21:06:04 <mikal> anteaya: Tim Bell? 21:06:12 <anteaya> oh yes, we have two cern devs 21:06:12 <mestery> mikal: ++ 21:06:18 <anteaya> I have their email addresses 21:06:41 <anteaya> they attended the earlier impromtue meeting and have reviewd the current spec which is wip 21:06:58 <ttx> anteaya: I can reach out to fifieldt_ in case he has someone else to suggest 21:07:10 <jogo> the part I am still a bit unclear on is: what is required from nova 21:07:10 <anteaya> ttx would be great to have his participation 21:07:20 <jogo> last I read the spec it was not very complete 21:07:30 <anteaya> jogo: right, there were some passages in the spec that needed detail 21:07:46 <anteaya> and unfortunately the main author oleg is on holidays still 21:08:02 <ttx> anteaya: so we should know more next week ? 21:08:05 <asalkeld> what's the link to the spec? 21:08:09 <anteaya> I sure hope to 21:08:12 * mestery thinks we really need to wait for Oleg here 21:08:35 <asalkeld> found it: https://review.openstack.org/#/c/142456/ 21:08:42 <thingee> o/ 21:09:01 <ttx> anteaya: OK, we'll just let the workgroup make progress. If you are blocked, don't hesistate to raise a new topic for this meeing. Otherwise, we'll do a status update in this meeting in about a month ? Would that work ? 21:09:09 <ttx> #link https://review.openstack.org/#/c/142456/ 21:09:09 <anteaya> mestery: well we can identify concerned parties, which we are doing 21:09:18 <mestery> ++ 21:09:18 <anteaya> yes 21:09:20 <anteaya> thank you 21:09:27 <mestery> thanks ttx 21:09:34 <anteaya> lets do two weeks from today 21:09:36 <anteaya> not a month 21:09:44 <anteaya> if we hit a wall I want folks to know 21:09:56 <anteaya> fair? 21:10:10 <ttx> anteaya: if you hit a wall you can add the topic and we'll discuss it right away 21:10:14 <mikal> Yep 21:10:17 <anteaya> okay fair enough 21:10:19 <anteaya> thank you 21:10:20 <mikal> Many of these peoplre are also at LCA 21:10:26 <anteaya> yes 21:10:27 <mikal> So you can lock them in a room if needed 21:10:36 <anteaya> not oleg though unfortunately 21:10:40 <mikal> True 21:10:44 <ttx> anteaya: if it just goes well we'll update in one month 21:10:49 <anteaya> very good 21:10:59 <anteaya> I won't stay quiet you do know that 21:11:17 <ttx> #action ttx to schedule a status update on novanet2neutron one month from now, unless a more urgent status update is needed 21:11:25 <jogo> will any neutron folks be at LCA? 21:11:32 <anteaya> markmcclain will 21:11:40 <anteaya> and I am expecting gus 21:12:14 <jogo> markmcclain: can you be a proxy for Oleg ? 21:12:15 <ttx> OK, anything else on that topic ? 21:12:19 <mtreinish> jogo: http://lca2015.linux.org.au/media/news/115 21:12:25 <jogo> so we can get some f2f stuff done 21:12:35 <mtreinish> oh anteaya beat me to it... :) 21:12:39 <anteaya> ttx I'm done 21:12:42 <anteaya> mtreinish: :D 21:12:59 <ttx> mtreinish: that was the previous markmcclain 21:13:01 <markmcclain> jogo: yes 21:13:14 <ttx> #topic Discuss openstack-spec: log guidelines 21:13:21 <ttx> #link https://review.openstack.org/#/c/132552/ 21:13:45 <sdague> I even did another run of it today, hopefully working out the last kinks 21:13:46 <ttx> This is a proposed cross-project spec. It basically needs to be reviewed by project teams to make sure those guidelines are as applicable to them as possible 21:14:09 <ttx> There weren't strong opposition to it so far, most comments are about details 21:14:18 * ttx updates 21:14:32 <Rockyg> Really need to get some Ops eyes on this. 21:14:34 <dhellmann> sdague: I think at this point its safe to stop fiddling with wording, unless there's a major issue to be addressed :-) 21:14:55 <ttx> But that may mean most PTLs just didn't look into it yet 21:15:01 <bknudson> getting info from ops about if we're logging too much or not enough would be useful 21:15:02 <morganfainberg> Minor wording changes can happen post merge if needed. Specs are not set in stone. 21:15:03 <asalkeld> Rockyg: +1 21:15:03 <sdague> dhellmann: yeh, I hope so, I did try to explain the parts that I thought confused people a ton 21:15:04 <Rockyg> But, that said, Ops can always do a new/addition to this once this is out. 21:15:12 <sdague> morganfainberg: ++ 21:15:16 <bknudson> I know that the keystone logs are useless from my dev perspective. 21:15:36 <dhellmann> sdague: yeah, some of the new bits are helpful 21:15:47 <morganfainberg> bknudson: we need to work on that in general. Keystone logs are far less useful from a ops perspective than they should be as well. 21:16:10 <bknudson> doesn't need to be addressed in the spec... the spec looks fine to me. 21:16:22 <dhellmann> this spec is several months old at this point, and I don't see any point in continuing to wait for more reviews 21:16:32 <Rockyg> ++ morganfainberg 21:16:37 <morganfainberg> I'll score the spec post this meeting. It looks good to me. 21:16:43 <ttx> Rockyg: think you can gather ops feedback on it in a reasonable timeframe ? Don't want to stall those opsenstack-specss forever trying to get everyone's feedback before approving 21:16:48 <bknudson> the only complaint I would be worried about is dropping audit log level if some group is using it 21:17:08 <thingee> yeah I'll be looking at it post meeting too 21:17:10 <sdague> bknudson: realistically, we've never had push back on that point 21:17:18 <morganfainberg> bknudson: I think audit is a bad log level - cadf or info. 21:17:31 <sdague> that was in there from the original draft back in May 21:17:32 <asalkeld> bknudson: also you still get the log, just as info 21:17:46 <ttx> #action PTLs make sure to review (or get reviewed) the log guidelines spec as it's considered pretty much ready by now 21:17:51 <Rockyg> ttx: There is a midcycle meetup in March for Ops. I think if this gets out there as is, it will inspire the midcycle to improve it. and that's not too much lag time 21:17:52 <morganfainberg> If it really is audit info, hiding it in the logs is bad. 21:17:57 <bknudson> sounds good. I don't think I've seen it anywhere 21:18:00 <jungleboyj> bknudson: No one should be using that. If they are it should be changed. 21:18:24 <jungleboyj> bknudson: I thought there was effort to remove it a while back anyway. 21:18:46 <Rockyg> Also, I'll post the review to the devops list. 21:19:00 <dhellmann> Rockyg: do you anticipate major changes being proposed? 21:19:12 <ttx> Rockyg: ok, maybe just relay that the window of opportunity to comment before approval is closing fast 21:19:16 <sdague> jungleboyj: it was all the same effort, people were just digging in early based on early versions of this 21:19:47 <Rockyg> I expect tweaks to existing and additions and/or clarifications 21:19:59 <jungleboyj> sdague: Ah, good to know. 21:20:35 <Rockyg> Key here is that seandague has fought thes logs a lot in his position in QA, so what is there is goodness for anyone who has to use the logs 21:20:42 <asalkeld> sdague: are we going to move to a global log config format (at least a global config file for logging) to ensure consistent output? 21:20:54 <annegentle_> I'll comment in the review patch too, but is there ever Fatal? 21:21:24 <sdague> asalkeld: that's beyond the scope of this 21:21:28 <sdague> at least for now 21:21:32 <asalkeld> ok 21:21:42 <asalkeld> it is very high level 21:21:53 <sdague> this is hopefully to get all the projects roughly doing the same things internally with logging information 21:22:03 <ttx> yes, it's more a log philosophy than an implementation 21:22:09 <sdague> right, agreed 21:22:23 <morganfainberg> annegentle_: fatal? Higher than crit? I think crit meets that by spec definition. 21:22:24 <dhellmann> asalkeld: there is work happening in oslo.log and oslo.context to standardize the format 21:22:30 <bknudson> do we then have blueprints for each project? 21:22:38 <clarkb> we basically have the same default format if you use oslo.log too 21:22:44 <annegentle_> morganfainberg: sure, but the link referenced in the blueprint mentions fatal so I ask. Noting in a comment. 21:22:49 <sdague> clarkb: right agreed 21:22:59 <morganfainberg> Ah 21:23:09 <ttx> sdague: so we could let that bake for one more week and then have the TC tally the votes and approve it 21:23:10 <morganfainberg> annegentle_: ack 21:23:20 <sdague> ttx: I'm fine with that 21:23:33 <ttx> sdague: unless a big objection comes out 21:23:36 <Rockyg> So, do you guys see this as the basis for a "principles in Logging" for OpenStack? 21:24:24 <dhellmann> Rockyg: I wasn't anticipating anyone writing another document. Is that what you mean? 21:24:28 <ttx> #info Expect the TC to tally the votes on this one at next week meeting, unless a big objection is posted 21:24:52 <ttx> #action ttx to add log guidelines openstack-spec talkly to next week TC meeting agenda 21:24:53 <Rockyg> I'm thinking at a minimum, the intro on the Wiki page for Logging Standards 21:25:06 <annegentle_> Rockyg: dhellmann: I just commented on the review I'd like discussion on where this gets documented 21:25:18 <dhellmann> I thought the spec *was* the documentation for this. 21:25:31 <dhellmann> that's the point of having something that goes through the review process, no? 21:25:34 <ttx> that sounds like the right place 21:25:41 <Rockyg> anngentle_ ++ if it only lives in the spec, it doesn't really live. 21:25:44 <annegentle_> we have the Ops Guide http://docs.openstack.org/openstack-ops/content/logging_monitoring.html 21:26:05 <annegentle_> so we do already discuss it -- and I htink the scope would be "how does OpenStack approach/think about logging" 21:26:14 <annegentle_> so yes, I'd like that specifically addressed in the spec 21:26:18 <dhellmann> these are instructions for developers to follow when adding new logging calls and reviewing other patches with new logging calls. I don't think it needs to go into a manual anywhere 21:26:35 <dhellmann> if we want to replicate the information in a format appropriate for other consumers, that's independent of this spec 21:26:38 <annegentle_> dhellmann: those are for the specs, sure. I'd just like to see an operator doc in addition 21:26:38 <ttx> dhellmann: ++ 21:26:43 <sdague> dhellmann: agreed 21:26:43 <annegentle_> dhellmann: okay, sure. 21:26:45 <Rockyg> annegentle_ Ooh, good! but it also needs to link to developer docs so devs know how to write the log code chunks 21:26:51 <devananda> dhellmann: ++ 21:26:56 <ttx> annegentle_: anyone can translate that into a "this is the spirit of openstack logs" doc 21:26:58 <annegentle_> Rockyg: meh, it's a different audience 21:27:11 <ttx> but yes, different audience 21:27:32 <annegentle_> Rockyg: hence my thinking the Ops Guide (which is not read generally by contributor devs to my knowledge) 21:27:40 <Rockyg> Different audience, but we need to make sure the stuff stays in sync between dev and users 21:27:56 <dhellmann> just to be clear: AIUI, this repository is a place for us to agree on policy, like the governance repo is for the TC. Once something is approved here, it can be referenced as official. Is that right? 21:28:06 <annegentle_> dhellmann: Rockyg: I think the loop is closed if I log a doc bug for openstack-manuals to make sure the spec info goes into the Ops Guide 21:28:10 <ttx> Definition of log levels, in particular, would appear on both sides 21:28:10 <sdague> dhellmann: that's my understanding 21:28:10 <annegentle_> good enough 21:28:17 <dhellmann> annegentle_: ok, cool 21:28:19 <annegentle_> dhellmann: yeah that sounds right to me 21:28:20 <devananda> dhellmann: my understanding as well 21:28:33 <ttx> alright, last comments on that topic ? 21:28:55 <Rockyg> annegentle_ (I'll get your nick right eventuall;) yeah. So, maybe links between the docs? We can discuss offline? 21:29:55 <Rockyg> just caught up again. ++ Let's give it one more week, let ops folks know, then merge after comments addressed. 21:30:03 <ttx> ok, moving on 21:30:11 <dhellmann> ttx: is the output from this specs repo being published to specs.openstack.org yet? 21:30:11 <ttx> #topic Discuss openstack-spec: OSProfiler 21:30:14 <annegentle_> Rockyg: sure, let's start a bug for discussion 21:30:21 <boris-42> hey hey=) 21:30:24 <ttx> dhellmann: hmm.. maaaaybe ? 21:30:34 <boris-42> ttx: I updated spec and reply on some comments 21:30:40 <ttx> dhellmann: nothing was approved yet :) 21:30:48 <ttx> #link https://review.openstack.org/#/c/134839/ 21:31:00 <ttx> This is the second cross-project spec that's been posted for a while 21:31:09 <ttx> so I would like us to make progress on it one way or another 21:31:21 <ttx> dhellmann and me filed a few questions, but otherwise I suspect most PTLs overlooked it 21:31:41 <asalkeld> this is mostly done - right 21:31:43 <boris-42> ttx: so actually there was a request from dns team 21:31:45 <sdague> boris-42: I think there was some general concensus that we wouldn't put release in the paths in the repo 21:32:00 <boris-42> sdague: oh 21:32:05 * ttx checks rev2 21:32:06 <boris-42> sdague: didn't know, so I will update it 21:32:12 <ttx> err rev3 21:32:12 <sdague> dhellmann: right? 21:32:16 <morganfainberg> So I'll review that spec but it looks like a lot of the concerns from the proposed keystone spec will still be relevant there. 21:32:21 * boris-42 sdague: after meeting 21:32:27 <dhellmann> sdague: yeah, I think we agreed to that after boris-42 submitted this one 21:32:48 <boris-42> dhellmann: sdague sorry guys I am still on holidays=) 21:32:53 <eglynn> there were a lot of reviews of the previous version https://review.openstack.org/103825 ... is the new one pretty much a straight copy of that? 21:32:54 <boris-42> but I will fix it 21:32:56 <morganfainberg> At a glance that is. 21:33:05 <dhellmann> boris-42: np, it's an easy change 21:33:06 <boris-42> eglynn: yep with fixed issues 21:33:16 <boris-42> eglynn: that was on previous one 21:33:30 <eglynn> cool 21:33:33 <boris-42> So actually there is request from desingate team 21:33:42 <boris-42> to remove agrugments from api-paste.ini 21:33:58 <boris-42> as we are using CONF file of project we can do that 21:34:01 <boris-42> thoughts? 21:34:13 <boris-42> I heard that operators hates confs in api-paste.ini ;) 21:34:29 <morganfainberg> Pleas do not add arguments to be consumed from the paste-ini. We have had issues with typing etc from keystonemiddleware and its better to have options all in one place 21:34:51 <bknudson> auth_token middleware can get options from api-paste.ini or .conf 21:34:53 <morganfainberg> Easier to not need all sorts of magic to make it work right when the project conf already does. 21:34:59 <boris-42> So I'll need to make 2 new releases and some amount of patches to remove them 21:35:10 <morganfainberg> bknudson: we fixed the issues. But it was a lot of workaround code to do it right. 21:36:01 <ttx> My main objection to it was if there was a performance penalty when turned off, but I guess evaluating "if None" takes negligible time 21:36:06 <boris-42> morganfainberg: btw guys I can remove data from request that have tokens and credentials and so on 21:36:40 <boris-42> ttx: actually even when it is turned ON 21:36:52 <boris-42> ttx: but not triggered the overhead is same to "If None" 21:37:11 <boris-42> ttx: so it can be turned of by default imho=) but okay step by step 21:37:25 <morganfainberg> boris-42: I'll make sure to comment and we can figure out how to do that as needed. But I think most of the keystone concerns still apply to this spec. I will review in depth later today. 21:37:41 <boris-42> morganfainberg: thanks 21:37:47 <boris-42> morganfainberg: if you have any questions just ping me=) 21:37:56 <morganfainberg> Aye 21:38:01 <ttx> boris-42: who would you say is the main audience for the profiling results ? Ops ? Devs ? Both ? 21:38:11 <boris-42> ttx: both 21:38:27 <boris-42> ttx: Ops - when it will be finished and work via Horizon=) 21:38:32 <ttx> Rockyg: so it would also make sense to get ops reviewing this one 21:38:37 <boris-42> ttx: sure 21:38:49 <ttx> want to make sure they would use it 21:38:59 <boris-42> ttx: so it really helps to debug why part of requests works slow on proudction env 21:39:00 <Rockyg> ttx: Yup. so I should put this link into the email to the list, too. 21:39:26 <bknudson> I hope it's not keystone that's the slow part. 21:39:28 <ttx> It soujnds like a great thing to have overall, I just fail to see the crowd cheering yet 21:39:31 <boris-42> bknudson: it was=) 21:39:40 <boris-42> bknudson: in some cases=) 21:39:43 <ttx> so it doesn't seem to get anyone very excited 21:39:45 <boris-42> bknudson: but not in all=) 21:40:04 <ttx> last thing we want is to have it in and nobody using it :) 21:40:16 <annegentle_> boris-42: I just commented inline, but have you considered using x-openstack-request-id for the header rather than another new trace header? 21:40:29 <ttx> so I would very much like ops to say "THIS please" 21:40:38 <boris-42> annegentle_: I will add paragraph aobut that 21:40:39 <Rockyg> ttx: I don't think you have to worry about no one using it. Many are, they just don't talk about it. 21:40:42 <boris-42> annegentle_: why we need new one 21:40:47 <boris-42> annegentle_: ok? 21:40:59 <jogo> I am a little alarmed with the number of similar things we have for this: logging, osprofiler, notifcations (for ceilometer) etc 21:41:09 <asalkeld> ttx from a dev pov this is very nice, I have used it quiet a bit 21:41:10 <boris-42> ttx: it will be usable via rally perf job 21:41:11 <annegentle_> boris-42: I'd like to avoid more and more headers if possible, it's hard to document and difficult for users to know which is used when. Just wondered if it's usable. 21:41:25 <boris-42> annegentle_: yep but in this case it's impossbile (or I don't know) 21:41:43 <annegentle_> boris-42: ok, just asking if you considered it, then would be nice to explain if it's not possible 21:42:16 <boris-42> annegentle_: yep so I agree that it should be noted in spec 21:42:25 <annegentle_> boris-42: ok, thanks 21:42:28 <boris-42> ttx: like load + profiling 21:42:54 <boris-42> ttx: so I think many Devs will use it + I don't know about other companies but in Mirantis guys are wating for osprofiler 21:43:06 <boris-42> ttx: as zhiyan is helping around integrating it in ohter project 21:43:25 <boris-42> ttx: and jamespage was interested as well 21:43:39 <boris-42> ttx: so there are consumers=) 21:43:40 <Rockyg> I know some Huawei devs are using it 21:44:22 <ttx> boris-42: some teams (keystone?) have been rejecting their own profiler spec, do you remember what their objections were ? 21:44:44 <ttx> and were steps taken to solve those ? 21:44:58 <eglynn> jogo: I don't think ceilometer is intended to scratch the same itch directly, though it does act as the default collector for osprofiler 21:45:27 <boris-42> eglynn: this is another thing, there are already patches to make MongoDB collector 21:45:36 <eglynn> boris-42: cool 21:45:39 <boris-42> but for OpenStack gates and some installation 21:45:50 <boris-42> it makes sense to have Ceilometer driver cause it simplifes life=) 21:46:01 <eglynn> yeap 21:46:04 <boris-42> ttx: hm need more info=) 21:46:14 <devananda> when I last looked at osprofiler, I raised some questions about its use at public cloud scale 21:46:21 <jogo> eglynn: right, but we have a several similar itches and a very piecemeal solution to them 21:46:26 <devananda> are there any large operators evaluating / using it? 21:46:57 <ttx> boris-42: I hear sensitive information leaking was one of those concerns. We certainly don't want to filter that same sensitive information 3 times (in logs, in notifications, in profiling) 21:46:57 <boris-42> dhellmann: I don't know, it's not well know thing yet 21:47:15 <boris-42> ttx: Ah about sensitive info 21:47:20 <Rockyg> anither question for the ops list? devananda 21:47:25 <boris-42> ttx: yep it can be easily removed 21:47:27 <bknudson> we've got rally code in keystone already 21:47:52 <boris-42> bknudson: so + profiler and ulitmate tool to figth for better perf and scale 21:47:52 <boris-42> =) 21:48:17 <morganfainberg> Txt boris-42 I'll look at the spec and the one that was proposed for keystone to make sure appropriate comments are echoed in the cross-project one. 21:48:35 <morganfainberg> I am concerned about needing more custom filtering at each layer. 21:48:39 <boris-42> morganfainberg: probably I should add more details 21:48:48 <boris-42> morganfainberg: about how we can remove sensetive info in spec 21:48:52 <boris-42> morganfainberg: so to make it clear 21:49:08 <morganfainberg> Sure. Like I said I'll comment. 21:49:09 <boris-42> morganfainberg: like in DB requests don't send args 21:49:11 <devananda> boris-42: you said there's a mongodb backend. does that replace the use of ceilometer to store/retrieve profiling data, or augment it? 21:49:25 <boris-42> devananda: yep we are wokring on that 21:49:36 <boris-42> devananda: so you'll be able to use directly mongo if you setup your profiler in such way 21:49:45 <boris-42> devananda: and that scales very very well 21:49:48 <devananda> boris-42: is there support for apache or gpl licensed back ends in the works? 21:49:51 <boris-42> devananda: cause it's one table with 1 index 21:50:07 <morganfainberg> devananda: good question. 21:50:08 <ttx> boris-42: looks like this one needs a bit more iterations, and ops feedback too. Hopefully this discussion will trigger that 21:50:11 <boris-42> devananda: nope not at this moment, but as far as we get first backend 21:50:18 <boris-42> devananda: there will be way to add more of them 21:50:21 <devananda> boris-42: indeed. I'm pleased to see a pluggable back end there, like mongodb. but I also know that this limits its use 21:50:22 <ttx> and make it fly above radar 21:51:00 <devananda> ttx: ++ 21:51:33 <ttx> Sounds like a good idea overall, just want to make sure everyone agrees it's also the right way to do it 21:51:56 <ttx> alright, last comments on that topic ? 21:52:11 <ttx> Please review and comment on the spec to help it move forward 21:52:50 <boris-42> ttx: thank you for making meeting=) 21:53:02 <boris-42> ttx: I will try to add more info to spec during next week 21:53:10 <ttx> no problem. We'll regularly review proposed cross-project specs during this meeting 21:53:21 <annegentle_> good topic for cross-project, thanks boris-42 21:53:27 <ttx> #topic Open discussion & announcements 21:53:52 <ttx> On release side we had 1:1 syncs today, mostly restarting the engine as we come back from the holiday period. 21:53:57 <ttx> Logs at: 21:54:01 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2015/ptl_sync.2015-01-06-09.02.html 21:54:23 <devananda> question for other PTLs - how well have split timezone IRC meetings been working for folks? 21:54:33 <devananda> has anyone fallen back to a single time slot after trying to split? 21:54:39 <morganfainberg> Project meetings? Like nova does? 21:54:43 <devananda> yes 21:54:57 <morganfainberg> Ah keystone still has a single meeting. 21:55:06 <asalkeld> devananda: works ok for Heat 21:55:07 <dhellmann> devananda: ceilometer use to stagger meetings but I don't think they do any more, right eglynn ? 21:55:14 <morganfainberg> We haven't tried a split though. 21:55:25 <eglynn> devananda: we had alternating slots for the ceilometer meeting for a long time, but settled back to a single slot about a year ago 21:55:35 <ttx> it's a difficult balance. You want to be inclusive, but not split them to the point where they are not reaching critical mass either 21:55:39 <devananda> basically, Ironic split a couple months back, but I've seen less attendance overall, and am wondering if it just takes time for folks to adjust 21:55:54 * ttx copypastes snippets of wisdom cross-channels 21:56:11 <devananda> or if, by trying to accomodate everyone, we ended up making it harder on everyone ... 21:56:19 <asalkeld> (6am and 10pm for me tho') - the morning one is a bit quiet from the US 21:56:27 <ttx> devananda: then I'd say come back to single meetings 21:56:34 <devananda> eglynn: was there a deciding reason for returning to a single slot? 21:56:43 <eglynn> devananda: TBH I thought the split caused some loss of context 21:57:13 <eglynn> devananda: ... different line-up turning for each alternating meeting 21:57:36 <eglynn> devananda: ... but for a wide geo-spread of contributors, could be the only realistic option 21:57:36 <asalkeld> eglynn: well that is the point 21:57:39 <Rockyg> Are both meetings reflected in the calendar? I only see one, but I have sync issues 21:57:48 <devananda> Rockyg: both are in the cal, yes. 21:57:58 <dhellmann> if the point is to sync the team up, it's hard to do that if there are 2 separate groups meeting 21:58:25 <dhellmann> I thought splitting was meant to put a little of the timezone pain on everyone, not create 2 separate groups of attendees 21:58:25 <asalkeld> dhellmann: yeah, but just totally ignoring part of the team is not good either 21:58:35 <dhellmann> asalkeld: sure 21:58:58 <dhellmann> but when you split, you still want most of the team to come at both times, not create 2 separate groups 21:59:10 <devananda> dhellmann: right, exactly 21:59:12 <eglynn> dhellmann: true, but for some folks though one of the alternating slots just wasn't possible to attend 21:59:34 <dhellmann> eglynn: that's ok as long as it's a minority -- you're never going to get everyone to all of the meetings anyway 21:59:44 <eglynn> dhellmann: true that 21:59:57 <ttx> ok, last minute 22:00:05 <ttx> Anything else, anyone ? 22:00:10 <devananda> thanks for the perspectives, all 22:00:22 <eglynn> for cielometer, we made it harder on ourselves by having the alternating slots on different days of the week also 22:00:39 <eglynn> leading to a short-week, long-week pattern 22:00:52 <ttx> ok, time to close 22:00:55 <ttx> thx everyone 22:00:59 <ttx> #endmeeting