fedora-meeting-1
LOGS
15:01:35 <sgallagh> #startmeeting Server SIG Weekly Meeting (2015-05-26)
15:01:35 <zodbot> Meeting started Tue May 26 15:01:35 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:40 <sgallagh> #chair sgallagh mizmo nirik stefw adamw simo tuanta mitr danofsatx
15:01:40 <zodbot> Current chairs: adamw danofsatx mitr mizmo nirik sgallagh simo stefw tuanta
15:01:41 <mitr> Hello
15:01:43 <sgallagh> #topic roll call
15:01:52 <tuanta> .hello tuanta
15:01:53 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
15:02:08 * nirik sort of here, but also busy with release day stuff
15:02:16 <sgallagh> Understandable
15:02:23 <stefw> .hello stefw
15:02:24 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
15:04:43 <sgallagh> /me waits a couple minutes to see who else filters in
15:05:02 <andreasn> .hello andreasn
15:05:03 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
15:05:18 <sgallagh> I was really hoping simo would be here, given his experience with FreeIPA and Samba, but I got word he's out this morning
15:07:15 <sgallagh> OK, I guess that's long enough.
15:07:17 <sgallagh> #topic Agenda
15:07:32 <sgallagh> #info Agenda Item: File-sharing Role
15:07:41 <sgallagh> #info Agenda Item: Stable API Documentation
15:07:54 <sgallagh> #info Agenda Item: Dependency Chain Reduction
15:08:00 <sgallagh> Other items for the Agenda?
15:09:31 <sgallagh> #topic File-sharing Role
15:10:07 <sgallagh> So yesterday, Dennis Gilmore started a thread about a NAS service that is pretty close to our earlier discussions about a file-sharing role
15:10:39 <sgallagh> The first, obvious question is: "Should we attempt this for F23?"
15:11:14 <sgallagh> Technologically, we have all of the file-sharing components we could want available, so what we would need to do would be to build tooling around them
15:11:35 <sgallagh> This means (to me) a management API daemon and a Cockpit UI for the user.
15:11:46 <andreasn> what protocols?
15:12:22 <sgallagh> andreasn: Right, so there are a number of them thrown about, but IMHO the two to consider first would be SMB/CIFS and NFS.
15:12:33 <sgallagh> (not necessarily both, but at least one or the other)
15:13:03 <sgallagh> Other longer-term goals would be SAN-style features like iSCSI
15:13:13 <andreasn> iSCSI target, right?
15:13:16 <sgallagh> And possibly things like becoming a Gluster or Ceph node system
15:13:21 <sgallagh> Yes, target
15:14:37 <mitr> It seems to me that we should split them by how they present the storage; e.g. perhaps treat NFS+SMB as a single server role, because it can share storage and expose a similar view, but iSCSI has little in common with SMB, and AFAIK same for Gluster nodes.
15:16:05 <sgallagh> mitr: Yeah, that's probably reasonable.
15:16:39 <sgallagh> mitr: In theory, the user experience for SMB/NFS could be essentially identical, with just a radio button selecting one or the other (or both).
15:16:48 <andreasn> we have our hands full development wise on the cockpit team, but I would be happy to work with anyone who's interested in implementing a UI
15:16:58 <mitr> sgallagh: exactly, especially with IPA handling accounts.
15:17:00 <sgallagh> Though an interesting case is that of NFS home directories for FreeIPA
15:17:40 <sgallagh> andreasn: Yeah, Cockpit developers are the primary constraint to any of this.
15:18:22 <sgallagh> Unlike the Domain Controller and Database Server roles, there's no value to *just* the rolekit side of things here.
15:18:31 <sgallagh> We need to be able to manage fully it post-install.
15:18:31 <andreasn> right
15:18:56 <stefw> in addition there needs to be some component that actually does that post-install configuration
15:19:19 <stefw> seems like it's far more than just a UI
15:19:45 <sgallagh> stefw: It certainly is, though at least in the case of Samba, there are at least *libraries* out there for managing the configuration
15:20:06 <stefw> right
15:20:06 <sgallagh> So plugging that into a daemon for Cockpit to talk to is likely to be comparatively straightforward.
15:22:43 <sgallagh> Resource constraints are likely to be our biggest issue here. Without someone volunteering to work on the Cockpit side (since the core team is full up), we're likely at an impasse :(
15:24:22 <sgallagh> I'm willing to do much of the plumbing (the API/daemon on the system), but my JavaScript skills are... nonexistent.
15:24:50 <stefw> i'm looking forward to the development work the GSoC student is going around rolekit
15:24:58 <sgallagh> /me nods
15:25:07 <stefw> that'll help expand what's there ... and is at least a start in this direction
15:25:15 <sgallagh> I suppose we always might get lucky and he'll finish up really early :)
15:25:32 <sgallagh> (We could also opt to repurpose his secondary target to this instead of the Database Server role)
15:26:56 <sgallagh> OK, two proposals:
15:27:55 <sgallagh> 1) We work towards supporting file sharing in Fedora 23, at least getting the plumbing done this cycle.
15:27:56 <sgallagh> 2) We focus on SMB/CIFS support for the first pass and expand later.
15:28:50 <sgallagh> (I suggest SMB for the first pass due to its OS-agnostic value)
15:30:38 <mitr> Both make sense to me (but I can't commit to working on them I’m afraid)
15:33:27 <sgallagh> OK, not getting much traction here.
15:33:39 <sgallagh> Let's let the mailing list thread continue for a week and see what happens.
15:33:51 <sgallagh> Without someone working on it, this may be dead in the water.
15:35:05 <sgallagh> #info Seems like an interesting proposal, but resources to work on it are lacking. Volunteers greatly wanted!
15:35:15 <sgallagh> Let's move on.
15:35:30 <sgallagh> #topic Stable API Documentation
15:36:27 <sgallagh> So, given our obvious resource constraints for this cycle, I think the primary task here is going to be locating someone from the Docs team who is willing to start gathering API docs for known-stable APIs.
15:37:05 <sgallagh> For F23, we may want to limit this pretty much to the kernel, systemd and the lowest-level language runtimes.
15:37:29 <sgallagh> And expand this set as we go, working with upstreams to determine stable functionality.
15:38:17 <sgallagh> Thoughts?
15:38:57 <mitr> ack
15:39:26 <mitr> (I would love to see more but that really requires strong upstream commitment)
15:39:32 <sgallagh> /me nods
15:40:03 <sgallagh> I'm hoping that "if we build it, they will come". Meaning that people will see value in wanting to be on the stable API list and help us with it.
15:40:30 <sgallagh> #action sgallagh to talk with Fedora Docs
15:40:49 <sgallagh> OK, last topic:
15:40:57 <sgallagh> #agenda Dependency Chain Reduction
15:41:17 <sgallagh> Unfortunately, F22 release kept me tied up most of last week, so I didn't get much further with my investigation.
15:41:45 <sgallagh> I am somewhat concerned that the F22 media grew so much larger than F21, considering they are built from almost the same kickstart.
15:42:20 <sgallagh> Right now, the biggest offender appears to be the FreeIPA dep-chain, so I'm working on narrowing that down.
15:42:49 <sgallagh> (I know Peter Robinson has also been attempting to do this for the benefit of the secondary arches, so I'll work with him on that)
15:43:40 <sgallagh> If anyone has any clues where some of the problems are (or is interested in helping us sort through the mess), we'd love some help
15:43:59 <sgallagh> #info Volunteers wanted to sort through the dependency chain mess and locate waste.
15:44:14 <stefw> is the list somwhere?
15:44:46 <sgallagh> stefw: I sent some raw data to the Server List describing the length of the chain for every package in the standard and maximal Server DVD installs
15:44:56 <stefw> ah, ok
15:45:41 <sgallagh> Rendering the full results into something human-readable is extremely complicated.
15:46:20 <sgallagh> A good first pass would be scanning the list and noting things that seem to have unexpectedly-long depchains
15:48:04 <sgallagh> Describing the actual dependency sets as anything other than a list of all recursive dependencies is next to impossible (due to cycles, packages that are the dep for many things, etc.)
15:49:02 <sgallagh> My computer spent six hours attempting to draw the graphviz rendering of the standard Server Install, after which I got an SVG that is impossible to follow.
15:49:31 <sgallagh> Anyone with ideas on how better to process the data is certainly welcome.
15:50:04 <mitr> Wouldn't it be easier to start by just comparing the package lists, and going one big added package at a time? Or perhaps sizes of installed packages?
15:50:42 <mitr> Diffing the dependency graph must be a nightmare, but it’s not obvious to me that this is a necessary starting point.
15:51:08 <sgallagh> mitr: You may have something there
15:51:40 <sgallagh> Running my depchain-counting script on the F21 media and the F22 media could at least let us see which packages had a significant jump in the size of their chain.
15:51:56 <sgallagh> That would help us reduce the *gain*, but I'd love to see us get it down below F21 as well.
15:52:08 <sgallagh> Still, might provide some clues.
15:52:36 <sgallagh> mitr: Thanks
15:52:51 <sgallagh> #topic Open Floor
15:53:15 <sgallagh> #info Congratulations on the F22 release!
15:53:24 <sgallagh> Well done, folks. Thanks for all your hard work
15:54:46 <sgallagh> Anything else for Open Floor?
15:56:41 <sgallagh> Thanks for coming, folks.
15:56:44 <sgallagh> #endmeeting