20:02:03 #startmeeting tc 20:02:04 Meeting started Tue Mar 4 20:02:03 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:07 The meeting name has been set to 'tc' 20:02:12 Our agenda for today: 20:02:17 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:27 Been reordering the topic to account for some people's availability 20:02:33 topics* 20:02:35 o/ 20:02:43 #topic Murano incubation request 20:02:50 #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/027736.html 20:03:01 #link https://etherpad.openstack.org/p/murano-incubation-status 20:03:22 I'll kick this off with my feedback from thread 20:03:33 in the thread I said I had two issues with this, both linked to the fact that this is a complete solution built on top of OpenStack 20:03:45 (1) The complete solution (or product) approach make it span multiple programs, as it doesn't match the "basic component" landscape we currently have 20:03:58 (2) The "solution built on top of OpenStack" aspect makes me think this should live as an OpenStack consuming application rather than in the integrated release. 20:04:11 I mean, I think it's a bit early for us to tackle that space, while we still have large "basic application blocks" functionality uncovered. 20:04:22 So IMHO it fails the "measured progression for OpenStack as a whole" requirement. As would Solum if they applied right now. 20:04:31 but maybe that's just me 20:05:14 Thanks for bringing these concerns. 20:05:58 TC members, comments ? 20:06:03 ttx: I've struggled with some of this myself 20:06:06 yeah 20:06:06 ttx: ie the same thoughts that you have 20:06:13 about tackling the "new" space so to speak 20:06:23 I think Murano is great and should exist. I'm not convinced it should be made a part of "OpenStack" at this point. 20:06:29 those seem like legit concerns; I've only started looking at the implementation details fairly recently 20:06:30 there were also comments from the Images and Orchestration programs, and i'd like to see all the relationships clearly worked out 20:06:33 As for 1) we technically can split Murano to have Catalog part and application package processing part. 20:06:36 i didn't get the impression that consensus was reached yet 20:07:03 Murano is mature technology which already can be and already used by the customers. 20:07:08 jgriffith: Basic orchestration of resources (Heat) is as high as I would go up the stack right now 20:07:08 yeh, that's my bigger concern, how much of this is really efforts that should be part of Images and Orchestration 20:07:13 o/ 20:07:28 I'd like to see more of the Murano orchestration solutions handled in heat in a declaritive way 20:07:39 jgriffith: at least until we get most basic infrastructure and app building blocks covered 20:07:56 ^^^ see, if heat PTL has concerns, that's probably a red flag that's it's too early 20:08:03 the workflow portion scares me 20:08:13 it seems to me that the application packaging DSL and the catalog part are quite separable 20:08:41 considering we have mistral/heat/taskflow 20:08:44 zaneb: They are. 20:08:57 we have too much workflow related stuff with too much overlap 20:09:09 vishy: +1 20:09:09 vishy: yes, it seems a bit early to slash the innovation and movement in that space 20:09:18 Actually we want to understand where Murano fits better in OpenStack. 20:09:25 vishy: ttx: +1 20:09:42 and integrat it with corresponding OpenStack programs. 20:09:48 that said the application catalog seems useful. It has some overlap with glance/heat 20:10:04 gokrokve_: I could definitely see a cross-project session at the next design summit to clarify that between all the affected projects 20:10:45 ttx: Thanks. That would be helpful. 20:11:02 the overlap with glance in terms of storing fixed representations of application packages feels quite straightforward to me, FWIW 20:11:05 we had some of the same problem with clustering between savanna and trove 20:11:23 vishy: agree, I think that you could have a single service as the catalog for both Heat templates and Murano applications 20:11:30 markwash: yes, that part was, I think , well clarified in the thread 20:11:42 and the probably belongs in the glance program somehow 20:11:47 markwash: yes i like that idea 20:11:48 that* 20:11:49 FWIW we had that discussion at the Glance mid-summit and there was consensus that application catalog stuff belongs in Glance. 20:11:54 markwash: +1 20:11:58 zaneb: +1 20:12:35 * stevebaker looks forward to glance cataloging all the things 20:12:45 so in that case murano could be a kind of a bridge between glance and heat 20:12:45 +1, storing more than just disk images in glance seems straightforward to me at this point, sorry I have been a slacker on updating the mission and program 20:12:49 So we can keep aside the orchestartion part and make Application Catalog as a first step. 20:12:51 gokrokve_: so in summary, i would be -1 for incubating the way it is now, but +1 for actively engaging with other projects in that area and see how you could cooperate 20:13:12 vishy: ++ 20:13:19 the funny thing will be is if we have a DB stack and a hadoop stack in the Application Catalog 20:13:27 because then what are trove and savanna for? 20:13:28 and I'm willing to help in making sure you have space to discuss that cooperation at the next summit 20:13:36 if the glance part is the most straight forward, maybe starting there this cycle is the best place to start? 20:13:40 maybe for the management features of dbs and data processing? 20:13:43 vishy: lightbulb moment 20:13:47 vishy: just APIs? 20:14:00 the deployment happens through murano in the future, but runtime mgmt is done by the services? 20:14:02 there is also a UX component to Murano that is quite slick. 20:14:26 ttx: It will be great to have a feedback on where Murano should fit better. We do not consider to be incubated immediately but sometime in Juno release. 20:14:34 russellb: I'm not sure that the glance component is that useful without the application definition component? 20:14:52 Before Juno we can actively discuss App Catalog with other project to find better aligment. 20:15:03 zaneb: unless it starts out being a catalog of heat templates 20:15:05 gokrokve_: we plan to have an avenue for long cross-project sessions at the next Design Summit 20:15:09 vishy, zaneb, in both trove and savanna there a lot of domain ops like db backups, jobs execution management and etc. 20:15:11 zaneb: glance would simply be a repository for that definition the same way it will be for heat templates and images 20:15:12 It looks like App Catalog itself is valuable. 20:15:13 stevebaker: +1 20:15:38 jaypipes: I think the UX component raises an interesting question about program placement 20:15:44 indeed. 20:15:47 btw I can imagine the application definition part ending up as a project in the orchestration program 20:15:50 it doesn't seem inconceivable to me for the images program to have a UX component 20:15:51 Horizon == UX? 20:16:00 but I would like to see closer collaboration with the TOSCA TC 20:16:09 randallburt: Horizon = Dashboard 20:16:10 randallburt: yes, horizon is one project in the uX program, IIUC 20:16:16 I'd like to see a UX program where GUIs fit in 20:16:19 jaypipes: k 20:16:20 I'd like to consider extending the heat HOT spec to support some kind of contract/interface, so a stack can define a component or app 20:16:20 jaypipes: no UX program yet 20:16:24 no? 20:16:27 ok, sorryr. 20:16:28 UX != UI 20:16:37 yes, I was trying to make that point, sdague 20:16:42 sdague: true dat 20:16:50 but I'm not sure what UX means in the murano case, honestly 20:17:03 sdague: a visual catalog < jaypipes? 20:17:05 are you talking about the custom user ui 20:17:06 So. do we agree that App Catalog is a right way and it will be valuable for OpenStack? 20:17:18 sdague: murano has a component that *builds* user interfaces that allow a wizard-like flow for constructing application packages. 20:17:42 gokrokve_: yes, but it may be best to start with a template catalog until we know what an "App" is 20:17:50 jaypipes: but its similar/identical to what was added to Horizon for Heat IIRC. 20:18:01 jaypipes: so that's cool, but I'm not sure I'd say being cool makes it something we wan part of the integrated openstack release that we co-gate on 20:18:11 I'm still not convinced that applications-as-a-service belongs in openstack at this point, at least not until we get better at covering the lower layers 20:18:31 randallburt, sdague: no disagreement. just pointing out that Murano has components that bridge a number of programs (or programs-to-be I guess) 20:18:36 yeh, gokrokve_ I think I share ttx's point of view 20:18:36 which makes it difficult to tackle. 20:18:38 ttx: +1 20:18:39 stevebaker: We will support heat template use case too. This is a question of application definition format. 20:18:56 which is there is a bunch that murano does that we'd rather have as features in existing openstack components 20:18:59 lets do that 20:19:03 fwiw I would be interested in incubating the user-facing component of the catalog in a Catalog-nee-Images program 20:19:05 then reevaluate what remembes 20:19:09 remains 20:19:10 * jaypipes would like to see the Mistral DSL, Murano DSL, and HOT languages aligned more... 20:19:26 but perhaps that is overreach 20:19:30 jaypipes: +1 20:20:17 ttx: Application Catalog is a logical step after Heat. You need to store application definitions somewhere, so catalog seems pretty good solution for that. 20:20:20 But it's tough to align those things when it's not entirely clear where Murano "belongs" in the integrated program world. 20:20:23 We should make sure those various projects talk together and prepare a common future... But my understanding of "measured progression" is we should complete the lower levels of the stack before going too far up 20:20:30 also, SOlum's DSL too... 20:20:56 ttx: ya, no disagreement on that point. 20:21:06 gokrokve_: yes. It's the logical step after Heat. But I just don't think we should go after Heat. Not until we get basic pieces in like a queue service 20:21:07 ttx: agreed; trove and savannah have both made compelling cases they are building blocks for cloud application developers. this seems like one more step up 20:21:17 ttx, nice, I like that 20:21:25 Basic orchestration of resources (Heat) is as high as I would go up the stack right now 20:21:33 ttx, the measure progression == lower levels of the stack first 20:21:34 dns would be nice... 20:21:37 ++ 20:21:40 jeblair: yes 20:21:41 yeh, dns 20:21:50 jeblair: + 20:21:55 It's not as if we were really missing incubation candidates either 20:22:01 markwash: do you mean something like murano dynamic ui feature? 20:22:25 BUT I want to facilitate cooperation in the space Murano is addressing 20:22:48 hence the proposal to have one of our cross-project sessions focused on that space 20:23:10 tsufiev: not necessarily 20:23:34 ttx: yeah, it seems like we have a concrete suggestion to see how much of this can be done with glance and heat, and to support that collaboration at the summit. that sounds good and constructive. 20:23:59 Looks like TC members are in agreement ? 20:24:03 +1 20:24:05 +1 20:24:15 yep 20:24:24 +1 20:24:32 +1 20:24:35 +1 20:25:23 #agreed Murano is slightly too far up the stack at this point to meet the "measured progression of openstack as a whole" requirement. We'll facilitate collaboration in that space by setting up a cross-project session to advance this at the next design summit 20:25:54 gokrokve_: also if you need ATC passes to get the right people in Atlanta, just let me know 20:26:16 ttx: Sure. Thanks! 20:26:29 OK, moving on to next topic... 20:26:42 #topic Barbican final incubation decision 20:26:49 #link https://review.openstack.org/#/c/77647/ 20:26:49 just finished my keynote so I'm here for questions 20:26:59 jraim: I'm the king of timing 20:27:05 We agreed to put final incubation decision on Barbican immediately back on the agenda when the last QA requirements would have been cleared 20:27:17 With the merging of https://review.openstack.org/#/c/74530/ it looks like it's ready now 20:27:38 jraim: you confirm ? 20:27:49 I believe that we've covered everything at this point 20:28:08 #link https://wiki.openstack.org/wiki/Barbican/Incubation 20:28:11 devstack was the last hurdle and I think we got all the patches merged 20:28:32 * russellb has no outstanding concerns on this one 20:28:54 jraim: hgetting a KDS featureset will be instrumental in graduating for the K release 20:28:55 jraim: where is the job running? 20:29:28 https://review.openstack.org/#/c/77689/ 20:29:31 there was some back and forth on whether is was a non-voting job or not. The patch reflected the consensus feedback we got I think 20:29:31 not apparently on barbican 20:29:57 oh, it's a check job 20:29:59 http://logs.openstack.org/89/77689/2/check/gate-barbican-devstack-dsvm/2a0d9f4/console.html#_2014-03-03_23_30_57_332 20:30:12 so it seems like it doesn't actually work 20:30:22 that's the last patch that merged from barbican 20:31:34 sdague: it did hit the local bug 20:31:49 there was an issue with the new version of the iso lib revving under us 20:31:51 ok, fair, do we have a version that did work? 20:32:00 not sure if this was related 20:32:23 chadlung: you on? can you talk about the devstack testing you did? 20:32:24 ttx: sorry, EPRINTING 20:32:30 erm 20:32:31 ESPRINTING 20:32:32 PRINTING? 20:32:39 * dansmith chuckles 20:32:45 heh, that excuse sounds better 20:32:50 sdague, jraim: i just ran recheck no bug on it 20:32:56 so we can see if it works now 20:32:57 (suspense) 20:33:17 ttx: well that will be 2hrs at this point 20:33:24 hah 20:33:25 The gating is difficult to test as we don't have that infrastructure to directly inspect. However, I'm checking on a VM with DevStack to get more details. Is not a big issue, should be solved soon. 20:33:25 it looks like only the last 3 changes ran 20:33:31 anyway, the review is up 20:33:35 Please vote on that review, I'll approve it when it reaches enough +1s 20:33:40 so while we're waiting… I do have one question/observation 20:33:44 you can hold your vote until you're confident the check test exists 20:33:53 markmcclain: sure 20:34:03 I don't see any entries to aligning with the libraries that other programs use 20:34:03 The actual integration with Barbican is working, the sanity check on the API is not working but the service is running and if I ping it it is up. So just need to see what the issue is. 20:34:04 yeah, i for one would like to see a check result where i can interpret whether we're effectively testing what we think we are 20:36:10 chadlung: yeh, the point was that it demonstrably worked in a gate like env 20:36:10 markmcclain: we are using global reqs at this point so I don't think we are using anything that's not being used by other services? 20:36:10 jraim: is there an update on the pecan/falcon thing at all? 20:36:10 so seeing an actual success on the barbican API is important 20:36:21 also, does this work with python 2.6? 20:36:21 jraim: the global requirements includes a few libs that grandfathered in 20:36:21 jraim: for example falcon 20:36:25 mordred markmcclain: right now we use Falcon and we're aren't currently planning any changes. We're open to a discussion about it 20:36:28 fwiw, I am expecting a report on our Pecan evaluation by the end of the week 20:36:28 (marconi) 20:36:28 other projects use falcon and I thought we were waiting on a eval of Pecan 20:36:28 ha kgriffs beat me to it :) 20:36:28 I asked a new openstack contributor to lead the project to minimize bias 20:36:29 no other integrated project uses falcon 20:36:36 no integrated project uses falcon. 20:36:36 dhellmann: my understanding is that most other projects don't use pecan either? 20:36:36 jraim, would you like to ultimately be part of convergence on this stuff across openstack? 20:36:39 dhellmann: correction "no integrated" 20:36:51 the rest of the community is moving to pecan, and I would expect any incubated project to look at that seriously 20:37:01 jraim, even if it means switching from falcon 20:37:02 sdague: yes, thank you 20:37:04 markmc: yep. I'm certainly willing to make changes as needed 20:37:26 markmc: I have no intrinsic tie to either project, if we need to move, we can do that 20:37:35 jraim: the integrated projects that don't use pecan yet are working on it 20:37:42 I would like to see kgriffs study as soon as possible 20:37:44 we are looking at it seriously, to be sure, but IMO it is important to allow due diligence when vetting something as a standard 20:37:45 markmcclain, markmc: that would be a graduation requirement (alignment on relevant libs) 20:37:57 kgriffs: I spent a year doing that vetting 20:37:59 jraim: I will ask balaji to post to the ML 20:38:09 kgriffs: great 20:38:12 apropos of nothing, it occurs to me that we should be asking projects applying for incubation to have created Heat resource plugins. This often shows up problems in the API design, and it would be nice to catch them early. 20:38:37 zaneb: I'm only comfortable doing that once heat actually has real gating on it 20:38:50 dhellmann: do you have some docs I could look at? I haven't seen a good study of the two and I would love to have more info 20:38:50 zaneb, we settled on that being a post-graduation-before-first-integrated-release thing 20:38:57 zaneb, in a review I put up recently 20:39:00 * markmc digs up the link 20:39:01 jraim: docs about pecan and falcon? 20:39:07 markmc: ok, fair enough 20:39:35 dhellmann: or just a general 'why pecan' would be somewhat helpful, but pecan v falcon would obviously be ideal since that's the scenario we are in 20:39:40 zaneb, https://review.openstack.org/68258 20:39:55 jraim: so - I think the thing here, not to belabor a point 20:39:57 jraim: we can discuss some of that after the meeting 20:40:02 sdague: it's not a gating thing, it's a "does this API design work" thing 20:40:03 ttx: I agree it is a grad requirement, but I do think we should make sure we note when the are library incompatibilities 20:40:07 dhellmann: great 20:40:26 markmcclain: I think it's good to set up graduation expectations too 20:40:35 jraim: start with https://etherpad.openstack.org/p/havana-common-wsgi which has a link to the grizzly session, too 20:40:48 zaneb: that's fine, but until heat actually has real gating, I don't feel it's ok to have heat imposed requirements on a lot of other projects 20:40:51 it goes 2 ways 20:40:57 we're kinda trying to avoid re-opening the can of worms every time there is a new project 20:41:04 dhellmann: great, I'll do some reading and come bug you with questions :) 20:41:08 jraim: ++ 20:41:10 sdague: there's a non-voting gate job now and it passes 20:41:15 jraim: cool! 20:41:36 zaneb: gating == voting, and it didn't as of last time I looked. :) But we can take that offline 20:41:56 markmc: that doesn't mention anything about Heat resources though 20:42:20 zaneb, revision 2 - https://review.openstack.org/#/c/68258/2/reference/incubation-integration-requirements 20:42:56 ah 20:42:59 mordred: I can understand that. When we started barbican, pecan wasn't really a standard 20:43:20 mordred: however, I believe we need to strike a balance between allowing innovation and trying to limit complexity 20:43:46 mordred: which I htink is an ongoing oslo challenge that I'd like to help with 20:43:48 OK, I propose we move on. The review is in gerrit now, the test is supposed to work. barbican knows that graduation expectations will include KDS featureset and potentially convergence to Pecan 20:43:52 jraim: The testing is identical to what Solum is doing 20:43:57 jraim: when we are talkign about potentially integrated project #14 - we need to move a lot more towards limit coplexity 20:44:08 #link https://review.openstack.org/77647 <- barbican incubation vote 20:44:08 We'll vote on it asynchronously 20:44:12 ttx: is "potentially" a problem in that sentence? 20:44:14 thx markmc 20:44:23 ttx: i'd expect it to be a grad requirement 20:44:33 sdague: you're correct, but IMO missing the point. the benefit is not to Heat, it's to the prospective project to know that their API design is sound for orchestration ahead of time 20:44:37 jeblair: well, we can set graduation requirements anytime we want 20:44:37 so i wonder if we need to be more formal about whether we all agree on that and if we need to communicate that to barbican 20:44:57 jeblair: we don't have to set them now, as long as jraim explains he is willing to look into it 20:44:57 ttx: okay, but we've spent a lot of time talking about how we should be nice and try to set the expectations early 20:45:20 jeblair: I'm happy to just assume we need the Heat templates for now and if that changes we can re-evaluate 20:45:34 yeah I'd rather set early vs project feeling like we changed the rules mid cycle 20:45:45 jraim: i'm talking about pecan, actually 20:45:50 jeblair: sure, it's just not part of the thing we vote on -- we might need another document 20:46:09 i can put in a signing statement with my vote, i suppose. :) 20:46:09 as in explicit graduation requirements 20:47:03 but i'm a little worried about not voting -1 now on something like that. 20:47:29 jeblair: oh sorry. If it is a requirement, then we'll move. I don't have a strong opinion other than it would require some work on our part to move over 20:48:11 jraim: i think the tc needs to collectively have an opinion on this, and i don't think we've expressed in strongly enough yet. 20:48:24 jeblair: ++ 20:48:30 jeblair: we need to do a better job at tracking specific graduation requirements, yes 20:48:34 jraim: i don't want you to be caught up in the middle of that, so i'd like to go aheand and say to you that at least i personally think it should be a req 20:48:57 jraim: right, that's why I think bringing it up earlier is better 20:48:58 jeblair: +1 20:49:10 jeblair: fair enough. I'm certainly going to start looking closer, especially at the work that kgriffs is doing 20:49:11 jraim: hopefully as a group we'll get make a decision one way or the other more officially soon 20:49:23 jeblair: sounds good. If we decide it is a requirement, then we'll change Barbican 20:49:47 OK, we'll comment and vote on the review 20:50:01 and it's good to spell out expected grad requirements early 20:50:10 moving on to next topic 20:50:10 ttx: agreed :) 20:50:23 #topic Integrated projects and new requirements: Neutron 20:50:30 #link https://etherpad.openstack.org/p/IcehouseProjectReviewNeutron 20:50:34 This is a the continuation of last week's discussion, as we were short on time 20:50:36 um, with 10 minutes left? 20:50:39 and we are again, short in time 20:50:48 may want to just punt 20:50:50 can we push it next week then and make it early 20:51:01 yes 20:51:03 because I feel like this needs to start off on the first slot 20:51:08 to give it time to breath 20:51:16 OK then. i'll miss next meeting but you can do that without me 20:51:17 these reviews are probably low priority anyway 20:51:22 as in, they don't have a deadline 20:51:26 sdague: so neutron is like wine now? 20:51:27 they are lwoer priority yes 20:51:37 #topic Minor governance changes 20:51:43 markmc: sure, though doing so before summit would be good 20:51:47 so plans can be made 20:52:01 * Add pycadf and oslo-cookiecutter to Oslo Program (https://review.openstack.org/#/c/76602/) 20:52:12 dhellmann approved it, so I'll approve this one unless someone yells about it very soon 20:52:25 We missed pycadf when we listed the other adoptions, and the cookiecutter repo is for making new libs. 20:52:51 will approve as soon as I get a breath from crazyweek 20:53:02 #topic Open discussion 20:53:08 Anything else, anyone ? 20:53:16 #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/028783.html 20:53:16 i move that we fast forward past feature freeze. i am tired. 20:53:31 just a heads up that i started a thread about moving from freenode to oftc 20:53:44 russellb: +1 20:53:44 that will likely result in a tc motion 20:53:45 * dhellmann has registered his nick 20:53:48 russellb: i move that next week i'm back on snow 20:54:00 ttx: jealous 20:54:21 based on how that thread goes. so we'll have a chance to vote on the decision and timing 20:54:25 jeblair: I voiced my very few concerns there 20:54:49 I haven't seen the OFTC questions addressed 20:54:57 about whether they're a smaller target or better prepared 20:55:25 ttx: I agree with your concerns 20:55:33 yeh, jeblair do you have an idea about how to get that answer? 20:55:45 dansmith: yep. i think it's going to be a hard question to answer due to limited visibility into the operations of both groups. 20:55:49 jeblair: seems like a reactive rather than proactive plan (reacting to ddos) 20:56:01 annegentle: i'm trying to be proactive, actually... 20:56:03 don't let the terrorists win 20:56:19 jeblair: yeah I think your plan is well-laid, but the root motivation seems off 20:56:25 annegentle: i registered all the channels when freenode was unavailable for an entire day 20:56:32 I fear we are trading our old cadillac that doesn't work that well for a second-hand car that looks like it will be working better. 20:56:43 yeah 20:56:43 annegentle: and was considering whether we needed to switch under duress... 20:56:56 annegentle: but we've been talking about this off and on in infra for a long time 20:57:01 and many of us will have to straddle both networks for a long time (and some of us have to be on freenode forever anyway) 20:57:12 jeblair: then I think an emergency plan is more what we'd need than a full switch 20:57:16 and i'd like to have a plan, and possibly execute it, before it becomes even more of an issue 20:57:30 annegentle: i think an emergency plan carries a very high risk of failure 20:57:42 with lots of people left behind 20:57:43 jeblair: +1 20:57:59 so when was freenode unavailable for an entire day? 20:58:30 jeblair: I guess I see it more as a communications outage that you would then route temporarily as your plan 20:58:31 unavailable doesn't happen, AFAIK, but it is unusable at times :) 20:58:34 sdague: i think a week ago saturday? 20:58:35 jeblair: my only gripe is that i'm unsure OFTC won't catastrophically fail the first day it becomes a target. freenode has a lot of experience handling those situations 20:58:42 the fact that the oftc admins are actually good to work with would be part of the pro-active part of thigns 20:58:44 dansmith: _definitely_ completely unavailable. 20:58:45 jeblair: rather than give up on a working solution 20:58:54 dansmith: all of the servers in rotation were rejecting connections 20:59:04 jeblair: heh, okay 20:59:07 mordred: yes, the admins have been extremely responsive 20:59:09 mordred: can you reach out about the ddos question? 20:59:09 jeblair: maybe we could get some advice from OFTC people that they are actually routinely working around those too 20:59:20 if they admins are good to work with 20:59:25 +1 for OFTC admins over freenode admins, FWIW :) 20:59:29 maybe we should just run a freenode node ? 20:59:31 sdague: sure. 20:59:39 e.g. in racksapce 20:59:46 lifeless: there is actually already one 21:00:03 lifeless: only freenode runs freenode nodes (they remote admin them) 21:00:05 (freenode node at rax) 21:00:28 anyway, time is up 21:00:33 follow up on thread ! 21:00:35 sdague, dansmith, mordred: will ask in #oftc 21:00:38 #endmeeting