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