15:05:57 <adamw> #startmeeting Server Working Group Weekly Meeting (2014-04-15)
15:05:57 <zodbot> Meeting started Tue Apr 15 15:05:57 2014 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:06:10 <adamw> #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr
15:06:10 <zodbot> Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta
15:06:17 <tuanta> .fas tuanta
15:06:17 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
15:06:19 <adamw> #topic roll call
15:06:27 <adamw> .fas adamwill
15:06:28 <zodbot> adamw: adamwilltest 'Adam Williamson (test)' <adamwill@shaw.ca> - adamwill 'Adam Williamson' <awilliam@redhat.com>
15:06:33 <mizmo> .fas duffy
15:06:34 <zodbot> mizmo: mikeduffy 'xiaofeng.wu' <mikeduffy@qq.com> - duffy 'Máirín Duffy' <fedora@linuxgrrl.com> - cduffy 'Charles Duffy' <charles_duffy@dell.com> - dduffy 'David Duffy' <duffy.david@gmail.com> - pduffy 'Pat Duffy' <Pduffy117@gmail.com> - kdpkd 'kev duffy' <kevduf@gmail.com> - dufflebag 'Martin Duffy' <duffym@gmail.com> - thequbit 'Tim Duffy' <thequbit@gmail.com>
15:06:38 <nirik> .hellomynameis kevin
15:06:39 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:06:41 <mizmo> what the
15:06:43 <adamw> heh, that test account's still there, apparently
15:06:56 <adamw> mizmo: looks like it's a fuzzy search :)
15:06:57 <mitr> Hello
15:07:02 <nirik> mizmo: .fas is a wildcard search. ;) Thats why we added the hellomynameis. ;)
15:07:14 <mizmo> hellomynameis is too long! lol i was trying to be slick
15:07:41 <adamw> i was just copying tuanta
15:07:50 <adamw> i'm not scheduled to wake up for another two hours or so
15:08:08 <adamw> anyone else?
15:08:37 <adamw> and can the Duffy table *please* either order some drinks or free up the space for other patrons ;)
15:08:53 * nirik wonders if we should just make it 'hello' or perhaps 'hi' :)
15:09:22 <adamw> #info present: adamw, mizmo, tuanta, mitr, nirik, simo
15:09:56 <adamw> #info Agenda Item: Drafting a test plan
15:10:12 * mizmo pours some pints of guinness for the duffy clan
15:10:15 <adamw> #info Agenda Item: Should we have a default caching DNS server?
15:10:26 <adamw> oh, yeah, of course it'd be a clan
15:10:34 <adamw> and there's me reading scottish-set fiction right now
15:11:22 <adamw> does anyone have any other agenda items?
15:11:27 <simo> mizmo: what you haven't read how guinness puts harmful stuff in their beers? :-P
15:11:56 <simo> adamw: should we talk about this journald remote protocol thing ?
15:12:05 <simo> is this something we should care for in F21 ?
15:12:08 <mizmo> simo, don't tell me i dont want to know!
15:12:12 <davidstrauss> +1 on installing Unbound by default.
15:12:23 <adamw> simo: what's the reference for this?
15:12:24 <simo> davidstrauss: it is more nuanced thn that
15:12:29 <mizmo> unbound is the caching dns server?
15:12:34 <adamw> also, we're not on that agenda item yet
15:12:36 <simo> davidstrauss: one of our deliverables is the domain controller role
15:12:38 * adamw waves order papers, frowns
15:12:41 <simo> which comes with bind
15:13:03 <davidstrauss> Oh, I mistook the #info line with moving to that item.
15:13:04 <adamw> simo: is the journald remote protocol thing a devel@ reference? i'm like 500 mails behind.
15:13:09 <simo> adamw: the reference is a thread on fedora-devel: F21 Self Contained Change: Remote Journal Logging
15:13:26 <adamw> ah, okay. let's add it, if we have nothing to say, no problems.
15:13:31 <davidstrauss> adamw: Also, I am present.
15:13:34 <simo> ok
15:13:39 <adamw> #info Agenda item: Remote journal logging
15:13:44 <adamw> #info also present: davidstrauss
15:13:50 <adamw> OK then
15:14:05 <adamw> #topic Drafting a test plan
15:14:32 <adamw> So with my QA hat on, I figured that now the products are reasonably defined, it'd be a good time to try and come up with test plans for them
15:15:02 <adamw> i'm not aiming to do the job in the meeting :), just a heads-up and discussion starter thing
15:15:31 <nirik> so, likely we need 3 plans? a base server role framework one for all roles and then role specific addons for each role?
15:15:40 <adamw> the idea being initially to define what we ought to test (in an ideal world) to validate a Server product release
15:16:18 <adamw> nirik: however exactly you want to frame that semantically, yeah, we at least need to test the 'framework' bits, and also the functionality of any supported roles
15:16:37 <adamw> (a corollary of that is probably that supported role propositions better come with testing resources...)
15:16:46 <adamw> er, proposals.
15:17:09 <nirik> we may be able to grab some upstream related tests for some things... ie, does freeipa have a set of tests or docs on such? I'm sure there is some postgresql test docs.
15:17:13 <adamw> #info adamw has volunteered himself to draft a broad initial test plan for the Server product, an attempt to define the required scope of test coverage to validate a Server release
15:17:25 <adamw> good thinking
15:17:52 <adamw> #info nirik suggests checking for already-existing upstream test plans (e.g. freeipa, postgresql)
15:18:02 <simo> adamw: what is the scope of Fedora QA ?
15:18:08 <simo> I am always a bit fuzzy on hat
15:18:18 <adamw> simo: excellent question ;)
15:18:19 <nirik> as much as we can do, but no more? ;)
15:18:20 <simo> I would assume that you do not test the product works flawlessly
15:18:30 <simo> but that it can be properly installed and the roles also installed ?
15:18:30 <adamw> simo: sure we do. all bugs are products of your overactive imagination.
15:19:03 <adamw> actually, nirik's answer is fairly close to the truth of it
15:19:25 <simo> we still have very little upstream testing of freeipa :(
15:19:31 <simo> but we are working on it
15:19:43 <adamw> the approach we're taking here is to define (quite broadly, we don't need a lot of detail) these 'ideal' test plans, and then do the fun bit of figuring out how much we can practically undertake to achieve
15:20:00 <simo> adamw: ok can w also define priority ?
15:20:01 <adamw> we do have some freeipa test cases already: https://fedoraproject.org/wiki/Category:FreeIPA_Test_Cases
15:20:03 <nirik> I'd say it would be worth tossing out a bunch of things, then prioritizing them...
15:20:13 <simo> for example I think it is a proprity that the role framework works
15:20:14 <adamw> simo: i'd probably make that a second-stage thing, but it's something to bear in mind
15:20:19 <simo> ie you can get to install the domain controlle role
15:20:23 <adamw> yeah, anything that's 'fundamental' gets fairly high priority
15:20:30 <simo> however if then the role has bugs, that is not a big concenrs
15:20:34 <adamw> so initial deployment and later configuration of roles
15:20:34 <simo> *concern
15:20:42 <simo> as long as the install finishes and it "starts"
15:20:46 <adamw> i would like to have at least *some* functional testing of our primary role
15:20:54 <adamw> analogous to the way we currently do some basic tests of the desktop
15:20:57 <simo> adamw: sure
15:21:16 <adamw> it's kind of a laugh test - you don't really want to put out a product that just fails extremely obviously out of the box, even if it's 'just a regular bug' that 'can be fixed with an update'
15:21:19 <simo> adamw: do you have any testing infrastructure to deal with multiuple machines interacting ?
15:21:48 <simo> adamw: because a simple test that will go a long way is this
15:21:59 <adamw> simo: we don't have something permanent / shareable / formal really, afaik (red hat does, fedora doesn't). we tend to knock up ad hoc VM farms if we need to test something like that.
15:22:00 <simo> 1. install fedora server
15:22:07 <adamw> but it can be done.
15:22:08 <simo> 2. install fedora workstation on another machine
15:22:14 <adamw> or we can just formalize the VM farm process.
15:22:17 <simo> install domain role on server
15:22:22 <simo> join workstation to server
15:22:25 <simo> create user on server
15:22:31 <simo> login as that user on workstation
15:22:37 <simo> there in 6 simple steps :)
15:22:40 <mitr> simo: beaker exists and runs $somewhere in fedora-land; I don't know how much it's been used
15:22:42 <adamw> right
15:22:48 <simo> and as a bonus you are testind TWO products :)
15:23:23 <adamw> mitr: i thought we only ever had a test instance of beaker
15:23:30 <mitr> adamw: I have no idea
15:23:31 <adamw> but imbw :P
15:23:38 <adamw> i'll check with tflink, he'd probably know
15:23:56 <nirik> yeah, there's a test type instance. it's not doing anything that I know of.
15:24:12 <adamw> #info simo suggests simple deployment of domain controller role on server machine and domain join / user creation on a Workstation machine as a basic smoke test for domain controller role
15:25:32 <adamw> so, yeah, i'll probably just work on the basis of drafting something up and sending it to both server@ and test@ for review, but if anyone wants to help or contribute thoughts, please do, the ones so far have been helpful for sure
15:25:55 <simo> adamw: as for database role, we can do something similar, just on a single machine
15:25:57 <adamw> simo: one thing that would be really useful if you have the time (or a minion who does :>) would be to go through the freeipa test cases at https://fedoraproject.org/wiki/Category:FreeIPA_Test_Cases and check for bitrot
15:26:07 <simo> you'd have to identify an application to "test" the db though
15:26:08 <tuanta> +1 simo
15:26:10 <adamw> some of them date back a few years
15:26:23 <simo> I would rather do real world application testing than synthetic upstream tests thouhg
15:26:26 <adamw> that feels like something it shouldn't be hard to find stress tests for
15:26:32 * davidstrauss has to duck out in a few minutes to head to Pantheon and set up for the systemd hackfest.
15:26:35 <adamw> true
15:26:35 <simo> those are good but already done by upstream/rh (I hope)
15:26:37 <nirik> yeah, for db... install, confirm you can connect with test user, confirm you can update/commit some test data and query it.
15:26:54 <adamw> simo: well, a *lot* of the issues we find in validation are interaction issues
15:26:56 <simo> a real scenario IMO adds more value to the whole ecosystem and may uncover bugs that escape synthetic testing
15:27:07 <tuanta> nirik, you meant we will do that from command line?
15:27:16 <adamw> simo: not really "this code doesn't do what it was meant to do" bugs but "this specific version of this bit doesn't work with this specific version of this other bit at this time" stuff
15:27:28 <adamw> so you can't rely on upstream/downstream testing so much for that
15:27:51 <nirik> tuanta: sure, we could have a test script or something...
15:27:53 <tuanta> nirik, we can write a test script for that
15:27:57 <nirik> yeah
15:28:00 <tuanta> yes, it makes sense
15:28:01 <adamw> anyhow, OK if we jump to the next item so davidstrauss can get in anything he has to say before he leaves?
15:28:08 <simo> ack
15:28:23 <simo> adamw: maybe we can discuss again once you have a draft
15:28:23 <adamw> yup
15:28:25 <adamw> thanks for the input so far
15:28:29 <simo> more ideas may spring once we have something more defined to look at
15:28:35 <adamw> i know how that is :)
15:28:57 <adamw> #topic Should we have a default caching DNS server?
15:29:04 <adamw> davidstrauss: anything you want to put in at the top?
15:29:30 <davidstrauss> Just that we've found this immensely valuable on our Fedora boxes at Pantheon.
15:29:42 * jsmith always adds one to his Fedora servers as well
15:29:46 <davidstrauss> We were overloading Rackspace's before implementing one, and picking was hard.
15:30:01 <adamw> #info davidstrauss and jsmith have found caching DNS very valuable in real-world deployments
15:30:02 * nirik is a big fan of unbound...
15:30:04 <davidstrauss> We started with pdns-recursor, but it *still* lacks DNSSec validation in 2014.
15:30:23 * adamw was thinking there was something built into NM, but that's client-side caching, isn't it.
15:30:24 <davidstrauss> We're transitioning to Unbound, maybe 70% complete.
15:30:40 <adamw> jsmith: what do you use?
15:31:04 <mitr> adamw: that's the same thing AFAIK, support for running/managing a system-wide caching daemon
15:31:06 <davidstrauss> I haven't found a single benefit for PDNS-Recursor over Unbound, and I wouldn't wish using BIND as a bundled caching DNS server on anyone.
15:31:17 <jsmith> adamw: Used to use bind, now using unbound
15:31:26 <tuanta> we are currently using unbound on our servers as well
15:31:49 <adamw> looks like a case of 'student body, unbound'
15:32:02 <davidstrauss> The biggest integration challenge is having it automatically configure upstream servers from DHCP or an initial list populated into resolv.conf
15:32:19 <nirik> the dnssec-trigger stuff does this fine on clients...
15:32:27 <davidstrauss> We should not ship a Fedora server that goes right to root for all lookups
15:32:34 <nirik> +a million
15:32:38 <jsmith> +1
15:32:44 <tuanta> +1
15:33:06 <nirik> so what we need is something like a simpler NM plugin like dnssec-trigger...
15:33:07 <davidstrauss> There is a NetworkManager integration for Unbound, but it looked pretty unmaintained.
15:33:07 <adamw> shall we take a vote just to put a stamp on it?
15:33:30 <tuanta> yes, I think it's worth, adamw
15:33:40 <mitr> davidstrauss: Wouldn't the biggest challenge be coexisting with a DNS server role?  (Obviously not today's concern, but we do need to have some plan)
15:34:04 <simo> ok sorry
15:34:09 <simo> I got distracted a few minutes
15:34:24 <simo> I wanted to bring this up because it is *not* straightforward for server
15:34:25 <davidstrauss> mitr: Not really, if it's just for local use. We have our DNS servers listen on everything but ::1 and and Unbound listen on those loopbacks.
15:34:26 <simo> for example
15:34:33 <simo> how do we deal with is on a domain controller ?
15:34:46 <simo> the role allows for installing bind as the DNS server
15:34:53 <adamw> so just to be clear, we are just talking about doing caching for the system running Server itself here
15:34:57 <simo> of course we can decide to run both unbound and bind on the same machine
15:34:57 <adamw> not a 'caching DNS server role'
15:34:59 <nirik> simo: unbound on localhost, dns server on other ips?
15:35:00 <davidstrauss> It is not possible, by the way, to have the resolv.conf system talk to a non-standard port.
15:35:04 <mitr> davidstrauss: ignoring people shouting about one more daemon, that's clearly a clean solution
15:35:09 <simo> we just need a modification so that bind does not listen on
15:35:18 <simo> but sounds like a waste and potentially confusing
15:35:28 * nirik is also not a bind fan. ;)
15:35:37 <adamw> Proposal: the Server product should have DNS caching functionality enabled by default
15:35:46 <adamw> (patches to the wording welcome if it's silly)
15:35:49 <simo> davidstrauss: can't you add a port to the ip address of the nameserver option ?
15:35:55 <davidstrauss> simo: Nope.
15:35:58 <simo> interesting
15:36:02 <davidstrauss> AFAIK
15:36:03 <mitr> adamw: +1 in general; re: timing, F22 together with the rest of the OS?
15:36:09 <nirik> I'm +1 to the idea, but we need some NM integration. perhaps we could ask NM folks if they would be willing to make something for us?
15:36:15 <davidstrauss> simo: We looked into that. It would have been easier.
15:36:16 <simo> adamw: well I would like to get there
15:36:25 <adamw> like I said, I thought NM actually *had* some DNS caching functionality. but imbw on that.
15:36:26 <simo> but dhcp passed resolvers is also a problem
15:36:34 <simo> should we have these things are blockers ?
15:37:04 <simo> adamw: it has integration witrh dnsmasq
15:37:08 <nirik> adamw: it can use dnsmasq I think... not sure about unbound.
15:37:10 <mitr> simo: I'd say that whatever works for all the complex setups Workstation needs to handle is very likely to work for Server well
15:37:15 <adamw> ah, yeah, that's what I was thinking of
15:37:16 <simo> adamw: and there is serious work going on to do an unbound plugin
15:37:23 <simo> but I think they are targeting F22 ?
15:37:28 <mitr> simo: yes
15:37:31 <nirik> so, I wouldn't make this a blocker, but a nice to have. ;)
15:37:53 <simo> mitr: problem is for F21 we have only dnssec-trigger, and I do not think that is good enough for now
15:37:59 <simo> not sure, it *may* work
15:37:59 <adamw> #info there is an effort underway to write a plugin for NetworkManager to integrate with unbound, which appears to be the WG's caching nameserver of choice
15:38:07 <adamw> #undo
15:38:07 <zodbot> Removing item from minutes: INFO by adamw at 15:37:59 : there is an effort underway to write a plugin for NetworkManager to integrate with unbound, which appears to be the WG's caching nameserver of choice
15:38:18 <adamw> #info there is an effort underway to write a plugin for NetworkManager to integrate with unbound, which appears to be the WG's caching nameserver of choice, but it is on track for F22 not F21
15:38:22 <mitr> simo: I'd really prefer using the NM-led solution, not Server doing something special just to get in F21
15:38:33 <simo> mitr: indeed
15:38:38 <adamw> seems like we have a consensus on that
15:38:53 <simo> so should we make this default conditional to people getting a plugin for NM first ?
15:38:57 <davidstrauss> mitr: Consider this a nudge to NM ;-)
15:39:01 <simo> adamw: we also have another problem
15:39:05 <simo> now that I think of it
15:39:14 <simo> server will often be used as a base for virtualization
15:39:31 <davidstrauss> simo: How does that affect this?
15:39:37 <simo> in that case dnsmasq is used by default by virt-manager/libvritd right ?
15:39:40 <mitr> davidstrauss: I'm generally following pspacek and psimerda's work, they don't need more nudging :)
15:39:47 <adamw> Proposal: We would like the Server product to have DNS caching functionality by default, but we believe this can be done at a project-wide level as of Fedora 22 and do not intend to NIH it for the Server product only Fedora 21
15:39:51 <simo> is that going to caue conflict again if unbound is present ?
15:40:03 <adamw> simo: yeah, we have amusing interaction issues with libvirt's dnsmasq quite a bit.
15:40:17 <davidstrauss> simo: Can libvirt switch to Unbound as well?
15:40:17 <adamw> i don't know specifically about this case, but it sure seems like something to watch out for.
15:40:19 <mitr> simo: AFAICS it listens "only" on the virt interface
15:40:23 <simo> adamw: I'll take an action item to ask Dan Berrange
15:40:25 <mitr> adamw: +1
15:40:51 <davidstrauss> This is not just an optimization to me. With Unbound, it's a major enhancement to security.
15:40:55 <adamw> #action simo to work with virtualization and networking folks to make sure any caching DNS plans consider libvirt's use of dnsmasq
15:40:56 <davidstrauss> One more remark before I go.
15:40:59 <mitr> Also, eventually, containers - we'll want to forward DNS from the containers to the host in most cases
15:41:21 <davidstrauss> Some recursors break Unbound DNSSec validation. Google's, for example, validate but don't pass on the right info.
15:41:26 <nirik> adamw: +1
15:41:29 <simo> mitr: right
15:41:48 <simo> davidstrauss: I think they have fixed that now
15:41:55 <adamw> the one I recall is that we had some fun with libvirt's dnsmasq getting nested - when we started installing Boxes by default, networking stopped working in VMs because of libvirt's dnsmasq running in the guest
15:41:59 <davidstrauss> Dyn's also breaks Unbound
15:42:00 <mitr> davidstrauss: fedora-devel has been talking a lot about ways unbound can workaround broken recursors
15:42:13 <mitr> well, unbound+dnsssec-trigger
15:42:14 <simo> davidstrauss: Dyn ?
15:42:35 <adamw> any more votes on the proposal? is anyone opposed?
15:42:54 <simo> +1 with all the caveats
15:43:00 <tuanta> +1 from me too
15:43:46 * adamw +1s his own proposal
15:44:26 <adamw> #agreed We would like the Server product to have DNS caching functionality by default, but we believe this can be done at a project-wide level as of Fedora 22 and do not intend to NIH it for the Server product only Fedora 21
15:45:01 <adamw> do we need any further action items at this point? do we have someone on whatever the team is that's working on this NM/unbound approach?
15:45:30 <simo> adamw: I tend to keep myself up to date on this stuff
15:45:38 <simo> so I can try to be liason when needed
15:45:38 <adamw> cool.
15:45:54 <adamw> #info simo will try to act as liaison to the folks working on NM/unbound integration
15:46:42 <adamw> okey dokey, a few minutes for the last topic...
15:46:56 <adamw> #topic Remote journal logging
15:47:19 <adamw> simo: did you have something specific here? (I've not caught up to the thread yet)
15:47:28 <simo> I have to say I brought this up because the current plans seem to make it very hard to have secure remote logging
15:47:32 <mitr> I'm also behind I'm afraid
15:47:38 <simo> they are planning to use HTTPS as the transport :(
15:47:53 <adamw> #info see devel@ thread "F21 Self Contained Change: Remote Journal Logging", https://lists.fedoraproject.org/pipermail/devel/2014-April/197980.html
15:47:55 * nirik just asked on list what ssl lib(s) they plan to use
15:48:05 <simo> if we ever want to build anything on this it seem to me it will require a ton of work on setup tools
15:48:38 <simo> I really wish we could influence them to not use such a broken protocol as HTTP
15:48:39 <mitr> simo: Why is HTTPS a problem, in principle?  You need to provision _some_ keys on both parties to get MITM protection
15:48:56 <simo> mitr: kerberos key are like 100 times easier to distribute an manage
15:49:09 <simo> and gssapi is not as broken as TLS when it comes to validation
15:49:21 <simo> most HTTPS client libraries screw up validation big time
15:49:29 <adamw> #info simo has concerns about the security of the proposed design (suggests kerberos as a better framework than https)
15:49:33 <mitr> And more generally, is there an reason to revisit https://fedoraproject.org/wiki/Server/Technical_Specification#Logging ?
15:49:39 <simo> let alone admins that seem to regularly fail to grasp how CAs work, let alone set up a personal PKI infrstructure
15:50:00 <simo> and I am saying this as one of the proponent of th domain controiller role that gives us a CA for free
15:50:20 <simo> adamw: not much about the scurty
15:50:25 <simo> but about usability
15:50:43 <mitr> simo: Sorry, "HTTPS clients are generally screwed up" is too much of a stretch.  I'm not saying it's easy or always used correctly but let's not be alarmist...
15:50:54 <simo> mitr: I think eventually forwarding structured logs will be a good idea
15:51:13 <simo> mitr: think about setting that thing up
15:51:18 <simo> what CA do you use ?
15:51:29 <simo> or do you excahnge fingerprints betwen client and server ?
15:51:41 <simo> it's hard
15:51:43 <mitr> the domain-controller-created one would be natural (but not applicatble always)
15:51:58 <simo> mitr: I think what I want to say is that we should stick to rsyslog for the forseable future
15:52:04 <mitr> simo: rsyslog can exract and forward the full journal data set (up to some message limit I suppose, not multi-gigabyte core files )
15:52:25 <simo> but we should keep an eye on remote journald and provide feedback on the feasibility of configuring the mechanism they are proposing
15:52:42 <simo> mitr: the dc only proveds a CA
15:52:48 <simo> you cannot trust just any certificate though
15:52:49 <mitr> simo: ok, I fully agree
15:52:55 <simo> LOGs are *very* sensistive
15:53:04 <simo> you need means to say *this* and only *this* server
15:53:21 <simo> and from the server's perspective you amy also wnat to say *these* and only *these* clients
15:53:29 <simo> to avoid being flooded by random clients
15:53:41 <mizmo> i gotta run in 5
15:53:48 <simo> and I see nothing about this stuff in the change proposal
15:53:55 <simo> I guess my proposal is:
15:54:40 <simo> proposal: due to configurability limits and unclear access control of current journald remote protocol the Server WG will stay on rsyslog for the foreseable future
15:55:09 <nirik> that seems fine based on what I know now
15:55:11 <simo> *for remote loggin of course*
15:55:28 <adamw> can we just make it 'will stay with rsyslog at least for Fedora 21 and then reconsider'? to make it less vague
15:55:29 <nirik> I mean this change was just proposed, we don't need to jump on it's bandwagon for f21. ;)
15:55:42 <simo> adamw: until those concerns are resolved ?
15:55:55 <mitr> simo: +1 to the conclusion, can't put my voice behind 'unclear access control" at this point because I really _am_ behind on fedora-devel
15:55:56 <simo> nirik: well they are proposing it for F21
15:55:59 <adamw> sure I guess?
15:56:08 <simo> nirik: not sure what they mean by this proposal though
15:56:17 <adamw> simo: as i read the proposal it's not to have it enabled by default or 'mandatory' in some way
15:56:22 <mitr> "for the foreseeable future" is fine, I think - journal has AFAIK an explicit non-goal of being an enterprise logger with local filtering and the like
15:56:22 <adamw> it's really a 'feature addition'
15:56:29 <adamw> mitr: fair enough
15:56:32 <adamw> +1 then
15:56:43 <nirik> simo: yes, but I mean we don't need to change our plans based on some new experemental thing thats not even written yet.
15:56:55 <nirik> but I share your concerns as well.
15:57:35 <adamw> the "Scope" section of the Change proposal indicates quite well why it needs to be a change, I think - just for the fedora accounting
15:57:49 <adamw> stuff like checking for conflicts with the default port, doing the user creation bureaucracy, etc etc.
15:58:29 * adamw counts votes
15:59:31 <adamw> i can only count 4 +1s, really, and a couple of those are pretty vague - but it doesn't seem like we really need a formal agreement here anyway
16:00:00 <adamw> #info it looks like we all have some reservations regarding the new proposed systemd remote logging functionality, and expect to stick with rsyslog for the foreseeable future for Server
16:00:04 <adamw> is that good enough for now?
16:00:26 <adamw> simo: ^^^
16:00:32 <adamw> and does anyone have anything else before end of meeting?
16:01:35 <adamw> did I miss a zombie invasion or something?!
16:01:42 <simo> adamw: +1
16:01:52 <simo> adamw: braaaaaainz
16:01:58 <simo> I thi nk we are done for today
16:02:01 <adamw> oh, you want brains? then I'm safe. whew.
16:02:05 <simo> we are lucky we pulled it off at all :)
16:02:27 <simo> adamw: lol, I need one, I want to know what it looks like, never tried myself ;-)
16:02:35 <adamw> i hear they tickle
16:02:47 <adamw> thanks for coming, folks!
16:02:49 <adamw> #endmeeting