16:00:42 <adamw> #startmeeting Server Working Group Weekly Meeting (2014-02-25)
16:00:42 <zodbot> Meeting started Tue Feb 25 16:00:42 2014 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:47 <adamw> #meetingname server-wg
16:00:47 <zodbot> The meeting name has been set to 'server-wg'
16:00:51 <adamw> #topic Roll call
16:01:05 * nirik is here, but gonna grab some coffee, so back in a min.
16:01:06 <adamw> sgallagh's double booked today, so he's asked me to run the meeting...
16:01:08 * mizmo here (Máirín Duffy)
16:01:16 <adamw> who else is around?
16:01:21 <adamw> .hellomynameis adamwill
16:01:23 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
16:01:23 <mitr> Hello all
16:02:15 <adamw> i believe quorum is 5?
16:02:42 <adamw> davidstrauss: ping
16:05:11 <adamw> well, if we wait for nirik to get back from coffee and we count sgallagh as present, we'd have 5, I guess.
16:05:54 <sgallagh> Hello
16:05:56 <sgallagh> Sorry, double-booked. Will be attending, but slow.
16:06:04 <nirik> back
16:06:11 * mizmo has to leave at a quarter of
16:06:14 <adamw> OK, well, I guess we can try and go ahead with this number
16:06:20 <adamw> mizmo: er, is that :15 or :45?
16:06:48 <adamw> #topic Target roles for F21
16:07:01 <adamw> I think we could call this one based on the list votes
16:07:59 <nirik> yep. seems clear cut and fine to go with those 2.
16:08:11 <sgallagh> Yes, I haven't fully tallied them yet (including mitr's latest), but it looks pretty firmly agreed (and with PostgreSQL as the winner for DB)
16:08:25 <adamw> we've got solid majorities for domain controller for 'primary blocker target', database server for 'secondary target' and pgsql for 'database of choice'
16:09:03 <mizmo> do we do an #agreed for that then?
16:09:07 <adamw> yup, doing it
16:09:39 <adamw> #agreed Domain Controller is accepted as the "primary blocker target" role for Fedora 21 (+9/-0)
16:10:04 <adamw> #agreed Database Server is accepted as the "secondary target" role for Fedora 21 (+9/-0)
16:10:29 <sgallagh> Did we get all +9?
16:10:35 <adamw> sgallagh: yeah, looks like it
16:10:39 <sgallagh> oh good
16:11:03 <mizmo> (btw i'm doing some wiki gardening atm)
16:11:11 <adamw> #agreed PostgreSQL is accepted as the "initial" database for Fedora 21 (7 pgsql, 1 mariadb, 1 abstain)
16:11:18 <sgallagh> mizmo: Much appreciated.
16:11:30 <adamw> OK, moving on
16:11:53 <adamw> #topic Install media and high-level view of default packages
16:12:33 <sgallagh> First question: do we need (or care about) any media besides netiso?
16:12:54 * nirik is fine with netiso + our packages (so it could be used to install locally too)
16:12:58 <mitr> Isn't this already resolved in https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Delivery_Mechanisms ?
16:13:08 <mitr> netninstall + offline ISO
16:13:09 <adamw> depends if anyone does offline installations without a site repository, I suppose
16:13:29 <adamw> #info PRD states "Fedora Server will produce two main installation resources, a netinstall image and an offline install iso image that allows one to install and configure featured roles offline."
16:13:29 <mizmo> yes
16:13:40 <mizmo> there are folks who do offline installs without a repo available
16:13:56 <adamw> mitr: good catch - though we can choose to only do the netinst iso for f21 if we want, i guess
16:13:58 <mitr> adamw: It's not a "site repository" (which would be fairly feasible), it's "control of the PXE server" (which may not)
16:14:06 <sgallagh> We left the presence of Roles ambiguous in the PRD there
16:14:20 <sgallagh> Does the offline media include Roles or just the base install?
16:14:52 <adamw> so, both of these are non-live media, i'm assuming
16:14:54 <nirik> I don't think we should do 2 media...
16:14:59 <adamw> we have no use for live
16:15:09 <mitr> PRD says "allows one to install ... roles offline".  I'm not sure we need _all_ roles off-line; we do need the PXE server off-line :)
16:15:13 <adamw> do we care at all about the CD size target?
16:15:38 <adamw> if not, then it seems pretty simple: do a netinst and an image with both roles
16:15:41 <adamw> (at least for f21)
16:15:43 <mizmo> i dont think we should as long as it fits on a reasonably priced usb stick
16:15:44 <nirik> mitr: we just need base stuff + whatever is needed for our roles...
16:15:48 <mitr> adamw: I think no live install, no CD size limitation (but perhaps a DVD size limitation, though I hope we are far from breaching that)
16:15:49 <sgallagh> adamw: Let's call a vote on that?
16:15:51 <adamw> (or just the DC role if we don't get database server role done)
16:16:07 <adamw> mitr: yeah, i'd expect we'd be way under DVD size, and server admins can afford a 4GB USB stick
16:16:19 <nirik> I suppose we could toss some other non role server stuff on there if we wanted... but that would be gravy/scope creep
16:16:25 <sgallagh> Proposal: Server full-install image should be kept within 4GB
16:16:40 <adamw> eh, i'd be okay with DVD size (4.7GB)
16:16:43 <mitr> nirik: Sorry, I was assuming a PXE / domain controller will eventually happen, not proposing to add PXE if we don't have a role yet
16:16:46 <sgallagh> nirik: I'd prefer to explicitly refuse that.
16:16:49 <nirik> mitr: ah right.
16:16:55 <nirik> sgallagh: thats fine to with me. ;)
16:16:57 <adamw> yeah, product focus!
16:16:58 <mizmo> sgallagh, +1 to 4.7gb proposal
16:17:07 <sgallagh> adamw: I'd rather keep it to 4.0GB for purposes of USB sticks
16:17:09 <mitr> sgallagh: +1 (big enough not to worry about 4G vs. 4.7G)
16:17:10 <nirik> sure, dvd size is fine. I sure hope we are very far from it tho
16:17:25 <mizmo> sgallagh, +1 to 4 gb proposal too lol
16:17:38 <adamw> OK, i'll +1 4GB as an initial target and we can re-consider if we turn out to be close to it (I doubt we will, but couldn't say for sure)
16:17:45 <sgallagh> adamw: Sounds good to me
16:18:12 <adamw> nirik: you OK with 4GB for now?
16:18:16 <nirik> sure, we have bigger fish to fry. ;)
16:18:45 <adamw> #agreed initial maximum size for offline ISO is 4GB (+5/-0)
16:18:50 <adamw> ok, so:
16:19:57 * nirik waits for adamw's so...
16:19:58 <adamw> proposed #agreed Fedora 21 deliverables will consist of a network install ISO image capable of deploying the roles we consider ready for release, and an ISO image capable of deploying the roles we consider ready for release without a network connection
16:20:19 <adamw> note: I'm saying "an image", but we haven't yet considered the topic of arch (and neither has any other WG, i don't think...)
16:20:30 <sgallagh> adamw: +1
16:20:41 <mitr> adamw: +1
16:20:42 <nirik> wait...
16:20:54 <nirik> the 'and' there... thats 2 seperate images?
16:20:58 <adamw> from a QA perspective, one 'extra' image seems doable (I'm assuming that in practice the netinst will wind up being our current netinst and effectively shared between products, but we can wave that hand later)
16:21:05 <nirik> that seems really silly to me.
16:21:10 <sgallagh> One's a netiso, the other is the "big" iso.
16:21:13 <adamw> nirik: well, the point of netinst is that it's small
16:21:25 <adamw> nirik: if the offline image goes over 700MB it'd also be our hedge for CD media
16:21:25 <nirik> how big do you think our roles are going to be?
16:21:29 <sgallagh> Possibly just boot.fp.o
16:21:30 <adamw> don't know
16:21:46 <nirik> I can't possibly think they would be 300MB+?
16:21:56 <nirik> 400 I guess.
16:22:00 <adamw> we could try and spin up some test images, but i suck at building DVDs and we have a week,.
16:22:02 <nirik> the net iso is about 300 now
16:22:15 <mizmo> adamw: +1
16:22:17 <nirik> I really think roles are going to be small...
16:22:17 <adamw> i don't think current netinst contains a single package, though.
16:22:31 <adamw> so, if there's more than a 400MB package load, we might go over CD size.
16:22:36 <sgallagh> I was actually thinking of the "tiny" image as being closer to boot.fp.o than the current netinst.
16:22:46 <adamw> sgallagh: hum, okay.
16:22:57 <mizmo> what about in the proposal we set size limits. if offline roles requires > x MB, then two media
16:23:08 <nirik> mizmo: I'd be ok with that...
16:23:16 <adamw> sgallagh: although i think pretty much all of the size of netinst.iso is the initramfs + anaconda itself. so if you have those two things, the size is kinda wired in.
16:23:21 <mitr> What we actually mean is "something that can be started from PXE", not specifically "an ISO image that is small and can download packages from elswehre", don't we?
16:23:29 <nirik> I just think it's silly to ship a 400MB netinstall and a 400mb 'non netinstall' thats pretty much exactly the same thing.
16:23:36 <mitr> IOW, we _could_ have a single ISO + the PXE-required kernel and config
16:24:08 <adamw> sgallagh: you were thinking of basically a kernel and initramfs and a PXE config on an image?
16:24:09 <nirik> mitr: I was thinking that... iso + vmllinuz/initramfs as we have always done
16:24:24 <sgallagh> adamw: Yes, that's what I was thinking
16:24:39 <mizmo> how would the non net install be the same size as netinstall? i dont understand :-/
16:24:51 <adamw> mizmo: i don't think it can be, but it could also be 'quite small'
16:25:06 <nirik> well, it could be very close...
16:25:18 <sgallagh> mizmo: nirik is suggesting that it might be only a few MB larger, at which point it's not sensible to separate them
16:25:28 <adamw> making the minimal 'image' be a boot.fp.o thing is kinda an interesting idea as it gives the potential to update the installer, I guess.
16:25:29 <sgallagh> But I'm talking about a more substantial difference.
16:26:01 <mizmo> the roles are only going to take a small bit? by roles you're including the packages req for the roles right?
16:26:23 <mitr> sgallagh: Actually, even if the "net" install required say a 1.5 GB download, would that be a problem?  A minimal install would not have to install everything, but if it would save us one deliverable to test, might be worth it)
16:26:34 <sgallagh> mizmo: I think they're likely bigger than nirik is assuming, but we're likely talking dozens rather than hundreds of MB
16:27:04 <nirik> the postgresql-server package is 3.8MB
16:27:20 <adamw> nirik: plus all the dependencies, starting from scratch
16:27:25 <nirik> sure...
16:27:27 <mizmo> sgallagh, i guess if we're starting with 2 roles only, right? but as time goes on there's gonna be more roles - so maybe we should do the proposal in terms of max size we allow to have one image for the long-term prospect of having more and more roles
16:27:34 <sgallagh> nirik: IIRC, FreeIPA plus deps ends up being a little south of 200MB, IIRC.
16:27:39 <nirik> but I really really don't see this being 100's of MB.
16:27:52 <nirik> sgallagh: that surprises me. ok
16:27:59 <sgallagh> nirik: Mostly dogtag
16:28:08 <mitr> The "minimal install" core is larger than any of the roles in any case
16:28:24 <adamw> do we consider the offline or online image our 'primary' thing?
16:28:27 <nirik> huh, those dogtag packages are very small.
16:28:43 <adamw> i kinda like the offline image myself, as it's a single thing you can just download and use and you're done.
16:28:46 <sgallagh> nirik: Hmm, maybe I misremember
16:28:53 <adamw> if we all agree on having the offline image for f21, i guess we can at least do a #agreed for that
16:29:20 <sgallagh> adamw: +1 for a "complete" offline image
16:29:40 <mizmo> +1 to offline image for f21
16:29:46 <nirik> sure. +1 I agree.
16:29:49 <adamw> proposed #agreed one deliverable for Fedora 21 will be a 'traditional install' style ISO image capable of deploying the roles we consider ready for release without a network connection
16:29:50 <sgallagh> (well, complete as possible without net)
16:30:07 <adamw> (traditional install is contrasted to live install)
16:31:35 <adamw> mitr: ?
16:32:03 <mitr> adamw: +1
16:32:05 <mitr> (Sorry, thought that was already recorded as an agreed thing)
16:32:10 <nirik> I guess as we add more roles I can see the netinstall and offline diverging... so we could just do a traditional netinstall from the start...
16:32:10 <adamw> #agreed one deliverable for Fedora 21 will be a 'traditional install' style ISO image capable of deploying the roles we consider ready for release without a network connection
16:32:34 <adamw> sgallagh: is there a particular advantage to doing a super-minimal ISO beyond the 'perhaps possible to update the installer' thing?
16:32:39 <nirik> unless we want to dump netinstall in favor of boot.fp.o images... thats an interesting idea...
16:32:41 <adamw> ultimately those bits are going to be needed one way or another
16:32:55 <adamw> (or some other super-minimal 'media' / deliverable)
16:33:01 <nirik> boot.fedoraproject.org 'images' are ipxe with a scipt built in
16:33:02 <sgallagh> nirik: That was pretty much where I was going.
16:33:25 <nirik> the script tells them where to grab kernel/initramfs and what to pass it.
16:33:59 <nirik> there's a number of types of images too.
16:34:26 <nirik> http://boot.fedoraproject.org/download
16:34:57 <sgallagh> I'd also like to discuss the boot.fp.o topic with the other Products
16:35:07 <adamw> the thing that worries me slightly with my QA hat on is that f21 is very likely to wind up having a netinst.iso anyway one way or another, and if that's not our other deliverable, we're throwing another on the testing pile
16:35:10 <mitr> So we would require the users to set up PXE with an image that goes off to boot.fp to see which kernel to download?  Why not just tell the users to set up PXE with the real kernel and and save one indirection?
16:35:12 <sgallagh> Because it would be really nice if we only have one that cna be used to deploy any of the products
16:35:13 <adamw> so i'd at least like the advantages to be clear
16:35:19 <adamw> sgallagh: that would be nice
16:35:44 <mizmo> there are environments where PXE is not allowed
16:35:46 <nirik> mitr: no local pxe is needed... you dl the image, boot it and it starts
16:35:59 * mizmo could rattle off several
16:36:20 <mitr> nirik: If I'm downloading something and manually inserting boot media, might as well download the full image
16:36:28 <adamw> the other thing we can do is handwave this for now if we want to move on and discuss the next topic
16:36:51 <adamw> mitr: that's kind of my thought, except the "updatable installer" angle. i've never quite got the point of b.f.o.
16:37:01 <sgallagh> mitr: Network-constrained environments like being able to download only the exact packages they care about
16:37:31 <nirik> mitr: sure.
16:37:32 <mitr> sgallagh: For Server, I'm more worried about network-connectivity-limited data centers than bandwidth constraints - might be wrong
16:37:58 <mitr> adamw: Who would sign up to do the testing of the updated installer?
16:38:07 <adamw> sure.
16:38:09 <nirik> anyhow, I'm fine with a traditional netinstall. I think we need more thought on boot.fp.o and if it gets us enough to deal with
16:38:28 <mitr> adamw: FWIW, Server was the only one with a "network install" deliverable.  No idea what this means WRT non-Product users wanting network install.
16:39:15 <adamw> proposed #agreed we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image or a boot.fedoraproject.org-style deliverable: this requires further consideration
16:39:20 <nirik> mitr: it may depend on if we as server working group want to tweak the installer defaults or add spokes or whatever.
16:39:34 <adamw> mitr: i was expecting we'd have one and it'd be 'owned' by base wg or no wg at all.
16:39:58 <mitr> So....
16:40:00 <mitr> Proposal variant 1) No change to existing decision: in addition to a full traditional ISO, we will produce a netinstall ISO as is currently done (i.e. ISO with anaconda, no RPMs)
16:40:02 <mitr> Proposal variant 2) We will document how to boot a full installation from PXE based on the traditional ISO, and test that as a supported deliverable
16:40:12 <adamw> mitr: we don't have an existing decision
16:40:19 <adamw> i've just done a 'fudge' proposed agreement
16:40:33 <mitr> adamw: The PRD calls for a netinstall iso.  We are essentially revisiting that.
16:40:38 * mizmo votes for variant 1 fwiw
16:40:38 <adamw> oh, right.
16:41:02 <mitr> adamw: +1 to your "plan for", but I'd rather settle this now, this will not become clearer later
16:41:08 <adamw> so, we now have three live proposals, which is bad. and i don't think mitr's proposal 2 is actually what sgallagh was talking about.
16:41:13 <mitr> I'm for variant 2) above
16:41:19 <adamw> mitr: why won't it become clearer later? sgallagh's proposal is kind of a new one we hadn't thought about before.
16:41:28 <adamw> it'd be good to have more details/implications of that.
16:41:32 <adamw> i'm certainly still digesting it.
16:41:32 <sgallagh> mitr: It calls for netinstall, but it was (IMHO) ambiguous whether it was a traditional netinstall.iso vs. just being able to install over the network
16:41:47 <mitr> sgallagh: true
16:41:54 <nirik> mitr: in your proposal 2 thta means we don't care about netinstall? all our deliverable is the 'offline' iso?
16:42:08 <mitr> nirik: we care about installing over the network, but not about delivering a small image
16:42:09 <adamw> mitr: aiui sgallagh's plan was for the other deliverable to be a very minimal image in the boot.fedoraproject.org style, not just a different way of installing from the variant ISO.
16:42:33 <adamw> so yours is effectively a new proposal - that we support the style but not with a different deliverable.
16:42:35 <mitr> adamw: OK, let's defer this for more discussion (... a specific #action?)
16:42:44 <adamw> mitr: that was my proposed #agreed, essentially.
16:42:48 <adamw> proposed #agreed we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image or a boot.fedoraproject.org-style deliverable: this requires further consideration
16:42:53 <nirik> mitr: I guess I'd be ok with that... then leave netinstall for base
16:42:58 <nirik> right
16:43:05 <adamw> hum, let me amend it a bit
16:43:35 <adamw> proposed #agreed we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image, a boot.fedoraproject.org-style 'anacondaless' image, or just a variant method of deployment from the 'full' deliverable: this requires further consideration
16:43:58 <nirik> sure.
16:44:00 <mitr> adamw: You convinced me, +1
16:44:34 <adamw> any other votes?
16:44:47 <nirik> +1 for the proposal, and we can discuss more on list
16:45:06 <adamw> sgallagh: mizmo: ?
16:45:16 <mizmo> +1 from me
16:45:16 <sgallagh> Sorry, double-booking it right now
16:45:19 <sgallagh> Reading scrollback
16:45:30 <adamw> mizmo: do you have to leave now?
16:46:00 <sgallagh> adamw: +1
16:46:08 <mizmo> adamw, i do
16:46:10 * mizmo turns into a pumpkin
16:46:14 <adamw> #agreed we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image, a boot.fedoraproject.org-style 'anacondaless' image, or just a variant method of deployment from the 'full' deliverable: this requires further consideration
16:46:17 <nirik> bye mizmo-out
16:46:18 <adamw> OK, we're under quorum now
16:46:21 <mizmo-out> byebye :)
16:46:28 <adamw> we didn't get through everything, so should we schedule another meeting?
16:46:32 <nirik> bummer. I was going to suggest xfs default filesystem. ;)
16:46:38 <adamw> or agree to have sgallagh schedule one?
16:46:40 <sgallagh> So we don't have voting population, but should we still discuss things?
16:46:41 <nirik> yeah, I think so... later in the week.
16:46:48 <adamw> we could keep talking things over, sure
16:47:03 <adamw> what did you have in mind with 'high level view of default packages'?
16:47:03 <sgallagh> Seems a waste to lose fifteen minutes of discussion at least
16:47:26 <sgallagh> adamw: Start talking about what basic functionality (pre-Roles) means
16:47:42 <sgallagh> I.e. "Is SSHD installed and running by default?" Cockpit?
16:48:32 <nirik> +1 sshd installed and running and reachable. I guess if we are depending on cockpit to configure things, it should be installed and set to start in some default state.
16:48:48 <mizmo> hi
16:48:54 <mizmo> so math is hard, i dont actually have to go until 12:45
16:48:56 * mizmo facepalm
16:49:20 <mitr> I kind of think these are dictated by the Roles; without a running application the infrastructure doesn't mean much.  Still, we can take an educated guess :)
16:49:22 <mitr> +1 to sshd
16:49:27 <sgallagh> Well, I want Cockpit to be the preferred way, but it needs to be doable via API as well
16:49:34 <sgallagh> So that's the hard requirement in my mind.
16:49:44 <sgallagh> Cockpit is a firm "very-nice-to-have" for that
16:50:32 <sgallagh> mitr: Well, we need to figure out what we need to support the roles
16:50:38 <sgallagh> That's really what I mean here
16:50:47 <adamw> mizmo: d'oh :)
16:50:52 <nirik> sgallagh: right. we need that as yet to be written dbus listening thingie...
16:50:57 <mitr> Re: Cockpit running by default ... I'm leaning towards "yes", but it would be good to air it on the mailing list just to make sure there won't be an explosion of outcry
16:51:38 <adamw> sgallagh: seems like there's two levels there: what's needed to support 'roles in general', and what's needed to support a specific role
16:51:49 <sgallagh> sure
16:51:49 <adamw> though i suppose what's needed to support a role is part of that role. meh.
16:51:58 <sgallagh> I was just going to say that
16:52:15 <sgallagh> So let's focus on "roles in general"
16:52:24 <adamw> i think cockpit running by default is fine for any path where you're explicitly deploying the fedora server product.
16:52:27 <nirik> there's also: default fs, firewalld or not, NM (but I guess we need quorum to vote on that)
16:52:33 <sgallagh> So clearly the first problem there is the D-BUS configuration listener for roles
16:52:40 <mizmo> +1 to sshd, holy crap is that annoying that we dont do that anymore
16:52:48 <adamw> nirik: we have quorum again now mizmo isn't leaving, but perhaps we shouldn't vote on everything with minimal quorum
16:52:57 <nirik> mizmo: we do do it, but just not on live. ;(
16:53:12 <sgallagh> adamw: I'm fine with us voting and being willing to backtrack with new information
16:53:15 <adamw> OK
16:53:30 <adamw> do we want a vote on sshd/cockpit?
16:53:34 <mizmo> nirik, huh i installed f20 with dvd and didnt get it :-/ had some annoying initial firewall config too
16:53:47 <nirik> mizmo: weird. I thought it was still on on dvd installs. ;(
16:54:02 <adamw> do we enable password login or not for sshd by default?
16:54:26 <sgallagh> adamw: PAM login, I think
16:54:38 <adamw> mizmo: iirc all our default firewall zones have 22 open
16:55:15 <adamw> cfv: sshd installed, running and enabled by default when deploying Fedora Server
16:55:18 <nirik> well, there was some talk a while back about ways to get keys on new installs... if those pan out I'd be fine restricting to keys, but if not, we need passwords at least initially.
16:55:18 <adamw> +1 for me
16:55:23 <nirik> +1
16:55:31 <sgallagh> +1
16:55:50 <mitr> adamw: We have to right now (no domain client support in the installer GUI).  Having sshd running always but usable only on kickstart installs doesn't make sense
16:55:57 <mitr> So +1 if this is a vote
16:56:11 <adamw> yeah, i went with 'cfv' this time. i like to switch things up. :P
16:56:20 <adamw> mizmo: ?
16:57:39 <adamw> "<mizmo> +1 to sshd, holy crap is that annoying that we dont do that anymore"
16:57:41 <adamw> so:
16:58:01 <adamw> #agreed sshd will be installed, enabled and running by default when deploying Fedora Server
16:58:54 <mizmo> sorry driveby cubing
16:59:05 <mizmo> adamw, the fierwall config that had me annoyed related to printing
16:59:15 <adamw> ah, following in linus' hallowed footsteps :P
16:59:26 <mizmo> so, i have been hacked via brute force password guess
16:59:33 <mizmo> so i would be against password ssh logins by default
16:59:50 <adamw> cfv: cockpit installed, enabled and running (is that appropriate terminology for cockpit?) by default
16:59:54 <nirik> well, there's no other way to get in initially currently.
16:59:57 <mizmo> we had talked in anaconda about letting you set up the system without a password
17:00:08 <adamw> we do need to focus for f21
17:00:10 <nirik> (unless we have a way to easily pull in ssh keys)
17:00:20 <nirik> adamw: +1
17:00:23 <adamw> if that's something we feel sufficiently strongly about to commit to building it for sure as part of f21 dev...
17:00:25 <sgallagh> adamw: Well, socket-activated rather than "running"
17:00:28 <mizmo> why dont we have some kind of keyserver thing like we do for ntp
17:00:34 <sgallagh> I'm not sure I want to commit to that part of it today
17:00:35 <mizmo> so you pulls the keys down from a server
17:00:55 <sgallagh> I *do* want to commit to building the D-BUS API that Cockpit would be talking to, though
17:01:02 <nirik> mizmo: monkeysphere. ;)
17:01:02 <adamw> sgallagh: sorry, i'm crossing streams
17:01:19 <adamw> trusted keys can be part of a freeipa deployment too...there's various ways to do it, but i'm not sure we can rely on any of them
17:01:35 <sgallagh> Right, but we still need a way to install FreeIPA in the first place.
17:01:43 <sgallagh> There will always be a bootstrapping problem
17:01:43 <adamw> (and, er, anaconda isn't capable of making a system a freeipa client yet anyway)
17:01:49 <mitr> mizmo: We have that, it's called cloud-init , but it's also a horribly insecure thing to use if the user things there isn't one
17:01:54 <adamw> sgallagh: anaconda's supposed to be able to do it, but no-one's written it yet.
17:02:01 <sgallagh> We have some ideas on how to solve this with OpenLMI, but they won't be ready for F21.
17:02:16 <mitr> adamw: re: cockpit - bring it up on the ML, I'll probably be +1 in a week
17:02:19 <adamw> there used to be an "Advanced..." button on the user creation tab which did nothing at all
17:02:33 <mizmo> should we add some kind of freeipa / openlmi key sharing integration to the cool ideas wiki page
17:02:37 <sgallagh> adamw: Actually, that used to work, then broke
17:02:45 <adamw> sgallagh: in newUI, i mean.
17:02:50 <sgallagh> oh
17:02:53 <adamw> mizmo: that sounds like the right venue for it, yup
17:02:58 <sgallagh> mizmo: yes
17:03:02 <mitr> mizmo: That's already covered in Use Case 3 AFAICT
17:03:17 <adamw> mitr: what do you need to be +1 to cockpit?
17:03:18 <nirik> or a clever way to pull your ssh keys from fas. :)
17:03:20 <adamw> ...aaand we're over time
17:03:20 * nirik runs
17:03:21 <sgallagh> I'll happily explain the plan to anyone who wants to listen, but it's a longer explanation than we want here right now
17:03:35 <mitr> adamw: opportunity for non-voting members to voice their opinion
17:03:42 <adamw> mitr: OK
17:03:42 <sgallagh> adamw: I'm +0 on Cockpit right now.
17:03:43 <mizmo> mitr, this is a bit more nuanced though it'd have to be during install
17:03:54 <adamw> a thought: do we want to enumerate our really basic requirements, like desktop WG did?
17:03:54 <mitr> mizmo: Explicitly adding this as one of the things that should be a part of the domain would make sense to write down, yes
17:04:00 <adamw> do we have any that are *different* from desktop WG?
17:04:43 <mizmo> https://fedoraproject.org/wiki/Server/Polish_Ideas  #3 here is how i added it
17:04:44 <sgallagh> adamw: Do you mean the core services stuff?
17:04:46 <nirik> I think some of them we should... like filesystem/etc.
17:04:53 <sgallagh> I'm going to send an email with my thoughts on that this afternoon
17:04:56 <adamw> sgallagh: yeah, basically
17:04:58 <adamw> OK, cool
17:05:06 <adamw> looking forward to it
17:05:15 <sgallagh> There are a few that don't make sense, but many of them do
17:05:21 <adamw> that was more or less my take, yeah
17:05:25 <adamw> i'd like to see as much convergence as possible
17:05:29 <adamw> (again with my qa hat on)
17:05:39 <sgallagh> ack
17:06:28 <adamw> #action sgallagh to send out a mail regarding 'core dependencies' for discussion
17:06:31 <nirik> yeah, we should only diverage where it makes good sense for our product.
17:07:10 <adamw> should we wrap things up for now? i think we got some useful stuff decided at least, and we seem to have reached a natural point where we need more extensive basis for discussion (like a nice solid mailing list strawman)
17:07:26 <nirik> do we want another meeting later this week?
17:07:56 <adamw> probably a good idea
17:08:02 <adamw> maybe we should schedule it on list, though
17:08:12 <adamw> sgallagh: do you want to do that, or should someone else take it?
17:08:19 * adamw is in not-volunteering-for-anything-at-all mode atm
17:08:32 <adamw> (aka "oh shit i have a gigantic backlog" mode)
17:08:49 <nirik> perhaps friday... to allow list discussion time before hand.
17:09:34 <nirik> anyhow we can decide on list.
17:10:10 <mitr> Can we just reuse the "server overflow meeting" date from last time instead of waiting on whenisgood?
17:10:20 <sgallagh> Sorry, I'm back (and reading backtrace again)
17:10:23 <nirik> mitr: when was that, do you recall?
17:10:41 <mizmo> last overflow meeting was thursday
17:10:43 <mitr> Thurstday 4PM my time
17:10:43 <mizmo> november 19
17:11:10 <mitr> Which is 10am eastern I think
17:11:25 <sgallagh> I'll send out a whenisgood for Thursday and Friday.
17:11:35 <nirik> thursdays are already meetingorama for me, but I can try and make it
17:11:56 <sgallagh> We'll see what has the highest overlap
17:12:00 <adamw> sounds good
17:12:01 <mizmo> fridays are really hard for me
17:12:14 <adamw> #action sgallagh to send a whenisgood for a follow up meeting later this week to discuss the rest of the things we have to settle
17:12:50 <sgallagh> Also, if two meeting times come up with a large overlap, I have no problem scheduling two meetings.
17:12:54 <sgallagh> Since we have limited time...
17:13:04 <sgallagh> Anyway, let's see what happens.
17:13:25 <sgallagh> #action sgallagh to send whenisgood request for Thursday/Friday
17:13:39 <adamw> i did that already :)
17:13:40 <adamw> never mind
17:13:51 <sgallagh> #undo
17:13:54 <adamw> OK, let's wrap up! thanks for coming, everyone
17:14:03 <adamw> sgallagh: i don't think I #chair'ed anyone, so you're talking to dead air :)
17:14:12 <sgallagh> ...
17:14:26 <sgallagh> Ok, thank you very much for chairing, adamw
17:14:31 <sgallagh> Much appreciated
17:14:40 <adamw> sorry i forgot to do backup chairs, i always forget that
17:14:44 <adamw> #endmeeting