16:00:17 <cloudnull> #startmeeting OpenStack Ansible Meeting
16:00:22 <openstack> Meeting started Thu Sep 10 16:00:17 2015 UTC and is due to finish in 60 minutes.  The chair is cloudnull. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:26 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:46 <Sam-I-Am> moo
16:00:54 <cloudnull> #topic rollcall
16:01:00 <cloudnull> o/
16:01:01 <Sam-I-Am> yo
16:01:11 <prometheanfire> cloudnull: will be getting food at the start
16:01:31 <rromans> \o
16:01:53 <stevelle> o/
16:02:15 <palendae> o/
16:03:11 <evrardjp> o/
16:03:49 <cloudnull> couple more min to let some folks trickle in
16:03:58 <cloudnull> #chair openstack
16:03:59 <openstack> Current chairs: cloudnull openstack
16:04:04 <cloudnull> #chair odyssey4me
16:04:05 <openstack> Current chairs: cloudnull odyssey4me openstack
16:04:22 <odyssey4me> o/
16:04:53 <evrardjp> I'm sorry I'm not familiar with english, did you consider odyssey4me as furniture? ;)
16:05:05 <cloudnull> he is a fixture :)
16:05:19 <cloudnull> #topic Review action items from last week
16:05:41 <cloudnull> item: make a BP to track each OS service and remove deprecated variables
16:05:42 <odyssey4me> haha
16:06:03 <odyssey4me> ah, my bad - that should have been me and I haven't done it yet
16:06:05 <Sam-I-Am> cloudnull: does this include new things for liberty too?
16:06:10 <odyssey4me> add that as one allocated to me please
16:06:11 <Sam-I-Am> there's a lot of those changes
16:06:12 <cloudnull> #link https://review.openstack.org/#/c/221189/
16:06:37 <odyssey4me> oh yes, I did do a liberty spec :)
16:06:47 <cloudnull> now we need people to review it
16:06:50 <Sam-I-Am> i have some neutron changes that someday i'll get time to do
16:07:57 <cloudnull> Sam-I-Am: If you have the changes outlined can you write them down somewhere so we can get to it if you cant
16:08:30 <cloudnull> etherpad, spec review, etc are all perfectly acceptable.
16:08:34 <Sam-I-Am> sure
16:08:41 <odyssey4me> better yet, comment on the review that you want to be on the neutron work - there's a spot in the work task list
16:08:58 <Sam-I-Am> although i'm waiting on a better way to add configurability
16:08:59 <cloudnull> ++
16:09:03 <Sam-I-Am> i think you had a patch for that
16:09:17 <cloudnull> base your changes off of the change if needed.
16:09:20 <odyssey4me> my suggestion is that we try and pair up the work, ideally with pairs that are in different time zones to get better coverage and hand over
16:10:26 <cloudnull> as a reference this is the review for the better config capabilities
16:10:28 <cloudnull> #link https://review.openstack.org/#/c/217030/
16:10:57 <cloudnull> #link https://review.openstack.org/#/c/220212
16:11:18 <cloudnull> code to make it go and an implementation example ^
16:11:32 <Bjoern_> Hey
16:11:41 <cloudnull> o/ BjoernT
16:11:45 <cloudnull> next: prometheanfire to get involved with the ops meetup ligtning and moderator talks
16:12:14 <Sam-I-Am> cloudnull: needs more docs :)
16:12:22 <prometheanfire> I've added myself as a possible moderator and will do at least one lightening talk
16:12:45 <prometheanfire> moderating for infra containers
16:12:49 <cloudnull> kk
16:13:10 <d34dh0r53> o/ sorry I'm late, phonecall
16:13:15 <cloudnull> #topic Liberty Release Blueprints
16:13:22 <cloudnull> #link https://blueprints.launchpad.net/openstack-ansible/+spec/liberty-release
16:13:56 <cloudnull> from a bp prosepctive i think we're good.
16:14:10 <cloudnull> we just need reviewers on the implementations of the approved bps
16:15:14 <odyssey4me> I found myself thinking this morning that perhaps the liberty release should focus primarily on a greenfield deployment, then we work on the upgrade mechanism for a .1 release later
16:15:18 <Sam-I-Am> liberty release - do the things'
16:15:34 <cloudnull> I'm good with that.
16:15:38 <odyssey4me> I'm concerned about the code churn in the release prep interfering with the ability to effectively do upgrade testing
16:15:40 <palendae> odyssey4me: I think that's going to be the practical thing
16:15:52 <palendae> odyssey4me: Right now it's been hard to get people to do even greenfield stuff
16:15:59 <odyssey4me> I'm also concerned with resourcing
16:16:12 <evrardjp> I'm not fond of it, because I'll need to upgrade ;)
16:16:25 <evrardjp> but I understand
16:16:47 <odyssey4me> the .1 release with confirmed upgradability could be released very soon after .0 - but I'd prefer that we have a more focused sprint or two on it
16:16:59 <evrardjp> ok
16:17:26 <Sam-I-Am> turns out... most of the kilo stuff works in liberty plus a few deprecation messages
16:17:27 <odyssey4me> evrardjp this suggestion is for your protection :) also, we'd like your help with the upgrade testing
16:17:36 <palendae> ^
16:17:42 <Sam-I-Am> however, liberty wouldnt really be liberty without fixing that stuff
16:17:50 <palendae> Help on testing upgrades would be very, very appreciated
16:18:38 <Sam-I-Am> one of these days... upgrade gating
16:18:51 <odyssey4me> one other thing I think we should discuss is when we want to release liberty
16:18:59 <Sam-I-Am> when its ready
16:19:22 <Sam-I-Am> when all liberty-related config changes are done
16:19:33 <odyssey4me> do we want to target the same day as the upstream release, the friday that follows, or when?
16:19:55 <odyssey4me> Sam-I-Am vague target dates are never good - things never get done
16:20:01 <cloudnull> I personally think that we rev all of our sha's and if gate passes we release.
16:20:08 <odyssey4me> we should set a target and endeavour to meet it
16:20:16 <Sam-I-Am> just because the gate passes doesnt mean its liberty
16:20:24 <evrardjp> it's the 19th of this month, right?
16:20:24 <Sam-I-Am> i found that out with keystone this morning
16:20:40 <Sam-I-Am> next month?
16:20:43 <cloudnull> i disagree. if gate passes and its running the liberty code, its liberty
16:20:58 <stevelle> RC1 is this month on the 24th iirc
16:21:05 <Sam-I-Am> this is why gating fails to be realistic
16:21:15 <Sam-I-Am> neutron technically passes the gate
16:21:34 <odyssey4me> Sam-I-Am you're talking about a tangential issue - liberty will not release until it has passed the integrated gate tests
16:21:51 <Sam-I-Am> what i'm concerned about is releasing, then having to make considerable changes to config files for a point release
16:21:56 <odyssey4me> it's entirely different to the testing that's done day to day, and is a distraction in this conversation
16:22:00 <Sam-I-Am> because it wasnt really using liberty config items
16:22:18 <odyssey4me> Sam-I-Am so that's the point of the items to review all the config files
16:22:36 <Sam-I-Am> yes, and the reason why i was saying we shouldnt release until those are done
16:22:39 <odyssey4me> so we need to set a date when we expect that to be done, and we need volunteers to do it
16:22:43 <Sam-I-Am> which hopefully is on or around the upstream release
16:22:56 <Sam-I-Am> they should be frozen now at least
16:23:09 <cloudnull> and if you have thoughts on that please contribute them to the spec so we can implement the changes.
16:23:19 <odyssey4me> we can do the checks and adjustments with the RC's
16:23:25 <cloudnull> ++
16:23:43 <odyssey4me> if anyone has the inclination, that inspection can already be started now
16:24:00 <Sam-I-Am> odyssey4me: sort of working on that a a side-effect of upstream install guide updates
16:24:03 <Sam-I-Am> as
16:24:03 <odyssey4me> patches for policy/config file changes are welcome right now
16:24:04 <cloudnull> ^ that would be awesome for somebody to start
16:24:16 <Sam-I-Am> working my way through the services
16:24:40 <Sam-I-Am> keystone is going to be fun
16:24:40 <cloudnull> Sam-I-Am:  if you have a diff as you work through the services in the install guide refresh we can work off that
16:24:56 <Sam-I-Am> cloudnull: its more like notes rather than a diff, but there's something
16:25:06 <cloudnull> or if you're keeping track on an etherpad we can lurk there too
16:25:07 <Sam-I-Am> also need to determine what is a packaging bug
16:25:13 <Sam-I-Am> hence why i shall test these in osad too
16:25:16 <Sam-I-Am> ahh yeah thats a good idea
16:25:27 <Sam-I-Am> a matts-liberty-ramblings etherpad
16:25:33 <cloudnull> would you mind starting an etherpad ?
16:25:37 <Sam-I-Am> sure
16:26:00 <cloudnull> #action Sam-I-Am to create an etherpad for the config changes he finds for future OSAD implementation
16:26:06 <cloudnull> tyvm!
16:26:13 <odyssey4me> also
16:26:21 <Sam-I-Am> cloudnull: https://etherpad.openstack.org/p/liberty-config-changes
16:26:32 <odyssey4me> #action odyssey4me to switch the blueprint for juno->liberty upgrades to 12.1.0
16:26:50 <palendae> Whoa what?
16:26:52 <palendae> Juno to liberty?
16:26:55 <odyssey4me> whoops
16:26:58 <palendae> :)
16:27:13 <palendae> Kilo to liberty?
16:27:17 <odyssey4me> correction, Kilo->Liberty y'all know what I'm sa'in
16:27:36 <palendae> I've heard some crazy things in the past few months, so... :)
16:27:57 <evrardjp> :)
16:27:58 <Sam-I-Am> palendae: i heard we're upgrading icehouse to liberty
16:28:02 <Sam-I-Am> palendae: tag, you're it
16:28:15 <prometheanfire> seamlessly
16:28:18 <prometheanfire> notit
16:28:25 <Sam-I-Am> for various definitions of seam
16:28:28 <Sam-I-Am> and lessly
16:28:29 <palendae> Sam-I-Am: You can tag me all you want
16:28:55 <cloudnull> so next up
16:28:57 <cloudnull> #topic Mitaka Summit Discussion Agenda
16:29:11 <odyssey4me> it would seem to me that testing swift-only deployments and support for systemd also need to move to a later milestone?
16:29:21 <Sam-I-Am> wont be there
16:29:24 <Sam-I-Am> glhf
16:29:24 <cloudnull> just real quick , please add items to the etherpad for consideration at the summit
16:29:26 <prometheanfire> odyssey4me: probably
16:29:26 <cloudnull> #link https://etherpad.openstack.org/p/openstack-ansible-mitaka-summit
16:29:45 <Sam-I-Am> out of expendable organs
16:30:14 <stevelle> you got spare lung, kidney...
16:30:24 <evrardjp> maybe we could remove haproxy-v2, it's not that important I guess
16:30:24 <Sam-I-Am> true
16:31:07 <prometheanfire> is this things required for liberty to 'release'?
16:31:22 <odyssey4me> prometheanfire uh, what are you referring to?
16:31:38 <Sam-I-Am> we're talking about mitaka summit discussions?
16:31:46 <prometheanfire> liberty specs
16:32:01 <Sam-I-Am> welcome to 10 minutes ago?
16:32:02 <prometheanfire> ah, don't think the previous topic was closed
16:32:02 <cloudnull> the systemd support Im sure I can get to, I just need reviewers to make the other irons in the fire go. But if someone else wants to implement the change they're welcome to it
16:32:35 <evrardjp> for the summit discussion, shouldn't talk about the docs?
16:32:41 <odyssey4me> cloudnull my concern is that if it doesn't make it into 12.0.0 then it may have to wait until 13.0.0, unless it's not a breaking change?
16:33:13 <prometheanfire> odyssey4me: nice to have or need to have? and manpower
16:33:16 <odyssey4me> I'd rather get that into a .0 release so that it's there when we get into thorough upgrade testing
16:33:26 <cloudnull> yes 12 or 13 IMO we could do it as a major release but that feels dirty
16:33:47 <prometheanfire> with the new versioning we can version when we want
16:34:00 <prometheanfire> not that we already couldn't
16:34:10 <odyssey4me> prometheanfire yes, but we've opted to stay in line for major versions
16:34:58 <cloudnull> ths is what we have so far for liberty https://github.com/stackforge/os-ansible-deployment-specs/tree/master/specs/liberty (spec wise)
16:35:20 <prometheanfire> did we want the ipv6 spec for it?
16:35:49 <prometheanfire> I think you said it'd be nice to have for liberty
16:35:51 <cloudnull> named veths would be a good one to complete theres a second part to that process which is here: https://review.openstack.org/#/c/220342/
16:36:23 <Sam-I-Am> veth betterification in general
16:36:27 <odyssey4me> prometheanfire yeah, although considering the work we already have on our plate I'm inclined to say we should rather get that going in the Mitaka cycle
16:36:31 <Sam-I-Am> its been an annoying problem
16:36:49 <odyssey4me> cloudnull on the veth issue
16:36:52 <evrardjp> odyssey4me: should I remove haproxy v2?
16:36:52 <prometheanfire> odyssey4me: ya, doesn't mater to me when tbh
16:37:03 <cloudnull> #topic reviews
16:37:26 <odyssey4me> I have the impression from somewhere that naming the veths will cause the container restarts to not work at all... although I'm not clear on whether that is all the time or only sometimes
16:37:40 <cloudnull> odyssey4me:  yes that is true
16:37:44 <palendae> odyssey4me: Correct, if they dangle
16:37:45 <Sam-I-Am> it only fails if the veth pair still exists?
16:37:45 <odyssey4me> evrardjp it's up to you whether you want to discuss it or not
16:37:45 <cloudnull> and intended.
16:37:53 <Sam-I-Am> hence why there's the veth-deleter thingy
16:37:53 <prometheanfire> mhayden: ping
16:37:58 <palendae> The 2nd half of the solution is that because we can now know the names, we can delete them
16:38:02 <cloudnull> the second part of that fix resolves it though
16:38:10 <cloudnull> what palendae said
16:38:12 <cloudnull> :)
16:38:14 <palendae> The names without the delete are bad, though
16:38:17 <odyssey4me> palendae cloudnull ok, then the missing piece for me to make that all go is that ensure that there is an included script for cleaning up the dangling dirties
16:38:28 <Sam-I-Am> palendae: at least things fail a little better
16:38:40 <palendae> But generally agreed to be better than veth pairs floating in the ether.  vether pairs.
16:38:52 <palendae> odyssey4me: https://review.openstack.org/#/c/220342/
16:38:57 <mhayden> prometheanfire: echo reply
16:39:00 <odyssey4me> ah, I see the cleaner is in https://review.openstack.org/220342
16:39:06 <odyssey4me> ok cool - I'm down with that :)
16:39:22 <cloudnull> it would be great to backport that to kilo too
16:39:40 <prometheanfire> mhayden: we are talking about the veth stuff here
16:39:47 <odyssey4me> cloudnull is that not perhaps a breaking change though?
16:39:49 <mhayden> i'm still trying to figure out how to fix this in LXC, but i'm not well versed in C
16:40:02 <palendae> mhayden: That may be a long tail thing
16:40:11 <palendae> Sounds like LXC's tools could use some love overall
16:40:17 <mhayden> long story short, LXC should be cleaning up the veths -- if the kernel netlink backlog is overloaded, LXC should try to re-do it
16:40:23 <odyssey4me> palendae considering your work on this issue, I'm surprised not seeing your vote on https://review.openstack.org/220342 ?
16:40:26 <mhayden> extraordinarily long tail :)
16:41:00 <palendae> odyssey4me: Last week was meeting hell, this week's been cinder investigation hell. I'll re-visit that this afternoon though
16:41:10 <cloudnull> next review I want to highlight evrardjp
16:41:13 <cloudnull> #link https://review.openstack.org/#/c/218818/
16:41:25 <evrardjp> ok
16:41:33 <evrardjp> First, the status:
16:41:35 * cloudnull hands mic to evrardjp
16:41:43 <evrardjp> They were 2 patches for delivering keepalived for haproxy. We've got an agreement, and therefore we are closer to release keepalived for haproxy.
16:41:47 <evrardjp> However, there is still work to do.
16:41:54 <evrardjp> one of its is to decide the inventory form.
16:42:01 <evrardjp> we'll have to introduce an env.d/ file if there are ppl who'd like to test keepalived in containers.
16:42:11 <evrardjp> I'd not personnally do it, so I don't really care BUT I think keepalived/haproxy deserve an env.d/ file, whether it's to define variables for it or generate containers.
16:42:20 <evrardjp> I was planning to create "keepalived" containers, but it seems that the name isn't obvious.
16:42:27 <evrardjp> We can decide whether we use "haproxy", "keepalived" or do nothing.
16:42:33 <evrardjp> Keepalived: you can use the same name/container for other services than haproxy. I doubt that ppl will do that though.
16:42:39 <evrardjp> Haproxy: the name of the container reflects better of what's running inside in this case: haproxy
16:42:49 <Sam-I-Am> odyssey4me: i'd +1 https://review.openstack.org/220342 except i sort of worked with cloudnull to write it, so not sure here.
16:42:57 <evrardjp> nothing: if I'm not mistaken (cloudnull, could you confirm?) NOT setting an env.d would make the keepalived playbook run on the target you mention in conf.d. So it will run automatically on bare metal. The setup-hosts will not generate any containers.
16:43:14 <evrardjp> So what's your opinion on this first topic? ;)
16:44:07 <odyssey4me> hmm, so I find myself wondering why anyone would seperate their keepalived router from the service
16:44:14 <odyssey4me> do they not need to colocate?
16:44:21 <cloudnull> I think if we're making haproxy and keepalived a first class citizen it should have an entry in env.d
16:44:40 <odyssey4me> ie keepalived does start and stop scripts for haproxy, so surely they need to be on the same system
16:44:41 <evrardjp> I propose as haproxy
16:44:47 <palendae> I agree with the env.d entry
16:44:53 <evrardjp> ok
16:45:02 <evrardjp> we seem to agree :)
16:45:14 <odyssey4me> so for me it seems sensible to have a container for haproxy, and keepalived can facilitate the vip for it in the same container
16:45:30 <evrardjp> that part will be tricky though
16:45:42 <evrardjp> keepalived in containers with multicast... not so sure...
16:45:49 <evrardjp> it should be tested
16:45:55 <cloudnull> odyssey4me:  brings up a good point. but in this case keepalived could, in the future, be used with multiple services. so from a role prospective i think it makes snese to have two roles for haproxy and keepalived
16:45:56 <odyssey4me> oh dear, yes... there is that
16:46:13 <odyssey4me> cloudnull ++
16:46:18 <evrardjp> yeah, that seem obvious
16:46:21 <cloudnull> we could then set keepalived as a dep of the haproxy role passing vars into as needed
16:46:25 <palendae> ^
16:46:36 <evrardjp> it shouldn't even be a dep
16:46:39 <evrardjp> it's not mandatory
16:46:42 <odyssey4me> evrardjp to keep things simple for now I'd suggest leaving out trying to make it work in a container and rather set that as a future improvement task
16:46:42 <evrardjp> you could
16:46:44 <evrardjp> and it will work
16:46:49 <evrardjp> ok
16:46:52 <evrardjp> there is another point:
16:46:56 <cloudnull> maybe a dep with a conditional ?
16:47:05 <evrardjp> we could
16:47:15 <evrardjp> so about the other point:
16:47:17 <cloudnull> conditional executes when there os > 1 host ?
16:47:17 <evrardjp> at the moment I'm importing my changes from galaxy to this repo, so it's kinda annoying.
16:47:25 <odyssey4me> cloudnull I would prefer it not to be a dep in the haproxy role as it is too prescriptive of the architecture
16:47:52 <odyssey4me> it would be better to include the roles in the playbooks, that way the playbook describes the architecture but the roles are independent
16:47:56 <evrardjp> what's inside the current commit is almost good I'd say
16:48:16 <evrardjp> we can just include the keepalived playbook conditionnaly in haproxy's one
16:48:48 <odyssey4me> evrardjp yeah, I'm down with that
16:48:49 <evrardjp> so about the galaxt part:
16:48:51 <cloudnull> odyssey4me: if someone wanted haproxy on >1 host then they would need something like keepalived so having it as a dep makes sense to me.
16:49:11 <odyssey4me> cloudnull but maybe they want to use another way of doing the virtual ip
16:49:27 <evrardjp> like corosync etc.
16:49:31 <odyssey4me> yup
16:49:52 <odyssey4me> less prescriptive in the role, more prescriptive in the playbooks
16:49:56 <evrardjp> so this is a good topic, I think it would be best to continue it on the commit maybe?
16:50:11 <evrardjp> this way I can have another part of my message :)
16:50:16 <cloudnull> ok carry on
16:50:25 <evrardjp> so
16:50:38 <evrardjp> if I could use the ansible-role-requirements.yml(.example), that would be of some help to avoid double work for me
16:50:44 <evrardjp> I know there is no consensus yet, but do we have a timeline for it?
16:51:01 <odyssey4me> ah, so you mean the approval to allow independent role repositories?
16:51:14 <evrardjp> yup
16:51:24 <odyssey4me> ie https://review.openstack.org/213779
16:51:40 <cloudnull> ++
16:51:55 <odyssey4me> I have a revision to make on the spec after feedback from hughsaunders and cloudnull
16:52:09 <evrardjp> so definitely not until mitaka summit
16:52:24 <evrardjp> ok
16:52:27 <odyssey4me> it still seems that everyone is confused about the spec and thinks that it's the button to break out the current roles, which it is not
16:52:28 <cloudnull> evrardjp: I view that more like a meta spec .
16:52:42 <cloudnull> once we approve it we can start the process.
16:52:49 <evrardjp> I thought this could be a good use case, that's all
16:52:57 <cloudnull> and if moving the keepalived to the requirements file makes sense then i think we do that
16:53:00 <evrardjp> the keepalived's role
16:53:00 <odyssey4me> evrardjp it would :)
16:53:02 <cloudnull> as to not duplicate work
16:53:42 <evrardjp> I have another last topic, but I've taken too much time, sorry
16:53:45 <odyssey4me> ok, I'll revise that spec in the morning and hopefully we'll get some reviews through the day
16:53:52 <cloudnull> IMHO if that spec goes in we should have the ability to add requirement roles to the stack from liberty >
16:54:06 <evrardjp> k
16:54:59 <evrardjp> so that's all for me
16:55:08 <cloudnull> we have only 5 min left
16:55:27 <cloudnull> #topic Open discussion
16:55:29 <cloudnull> anything ?
16:56:00 <mhayden> and input on the security hardening thread is good ;)
16:56:06 * mhayden is considering drafting a spec
16:56:13 <cloudnull> .doit()
16:56:15 <mhayden> s/and/any/
16:56:26 <palendae> mhayden: Yes, we should :)
16:56:26 * mhayden will do the things
16:56:57 <evrardjp> there should be a lot of discussion about SSLing things then :p
16:57:09 <cloudnull> ++
16:57:17 <evrardjp> and omg... apparmor ><
16:57:28 <mhayden> TOMOYO? ;)
16:57:34 <mhayden> since we can stack LSM's in Linux 4.2 now
16:57:39 <prometheanfire> mhayden: and replied to the reply
16:57:41 * mhayden wanders off-topic and waits for cloudnull to throw a keyboard
16:57:48 <cloudnull> hahahaha
16:57:53 <palendae> mhayden: Is 4.2 in 16.04? :)
16:57:53 <odyssey4me> lol
16:57:55 <cloudnull> 4.2 or bust !
16:57:56 <prometheanfire> the LSM stacking is not that useful imo :P
16:58:00 <mhayden> palendae: 17.10
16:58:18 <mhayden> i still can't convince people that one LSM at a time is a good thing :P
16:58:31 <prometheanfire> mhayden: selinux or bust
16:58:34 <cloudnull> im sure RHEL will backport it to 3.10 ...
16:58:39 <prometheanfire> cloudnull: why don't we have selinux support?
16:58:47 <evrardjp> ubuntu?
16:58:48 <mhayden> i heard selinux sucks
16:58:50 <cloudnull> we do
16:58:52 * mhayden giggles
16:58:53 <Sam-I-Am> they all suck
16:58:54 <cloudnull> setenforce = 0
16:59:00 <evrardjp> :D
16:59:05 <mhayden> cloudnull: sigh
16:59:12 <mhayden> http://stopdisablingselinux.com/
16:59:22 <prometheanfire> I though about wearing that tshirt today :P
16:59:26 <cloudnull> http://startdisablingselinux.com/
16:59:31 <odyssey4me> haha
16:59:40 <mhayden> great, now someone will buy that :P
16:59:40 <odyssey4me> time to end the meeting
16:59:43 <cloudnull> ok we're done here
16:59:44 <palendae> http://dontreadthedocs.org
16:59:45 <prometheanfire> https://twitter.com/grsecurity/status/638529614743273472
16:59:49 * mhayden woots
16:59:49 <cloudnull> thanks everyone !
16:59:57 <Sam-I-Am> lates d00ds
16:59:57 <cloudnull> #endmeeting