14:59:51 <sgallagh> #startmeeting Server SIG Weekly Meeting (2015-08-18)
14:59:51 <zodbot> Meeting started Tue Aug 18 14:59:51 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:51 <sgallagh> #meetingname ServerSIG
14:59:51 <zodbot> The meeting name has been set to 'serversig'
14:59:52 <sgallagh> #chair sgallagh mizmo nirik stefw adamw simo tuanta mitr danofsatx
14:59:52 <sgallagh> #topic roll call
14:59:52 <zodbot> Current chairs: adamw danofsatx mitr mizmo nirik sgallagh simo stefw tuanta
15:00:01 <adamw> ahoy
15:00:07 <nirik> morning
15:00:09 * stefw won't be here, unfortunately
15:00:40 <tuanta> .hello tuanta
15:00:43 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
15:02:55 <sgallagh> /me waits to see if we have quorum
15:04:59 <sgallagh> not looking good...
15:05:16 <nirik> some folks might still be traveling back from flock
15:05:26 * mitr checks the topic
15:05:29 <mitr> Hello
15:05:54 <sgallagh> OK, that's five. (Also, hi!)
15:06:03 <sgallagh> #topic Agenda
15:06:04 <sgallagh> #info Agenda Item: i686 Media
15:06:04 <sgallagh> #info Agenda Item: Flock
15:07:10 <sgallagh> Anyone have other topics for the agenda?
15:08:08 <sgallagh> Enthusiastic crowd today
15:08:14 <sgallagh> #topic i686 Media
15:08:22 <sgallagh> #link https://fedorahosted.org/fesco/ticket/1469
15:08:49 <sgallagh> We need to consider if the Server SIG as a whole cares about shipping i686 media.
15:09:38 <nirik> I'm +1 to dropping it for f24
15:09:54 <simo> .hello simo
15:09:54 <zodbot> simo: simo 'Simo Sorce' <ssorce@redhat.com>
15:09:59 <mitr> +1 to dropping the media/kernel
15:10:01 <tuanta> +1 for dropping it
15:10:19 <simo> i686 for server ?
15:10:21 <simo> drop it
15:10:21 <mitr> (I would have liked the i686 library runtime to be a mandatory part of x86_64 Linux, but that ship has sailed…10 years ago?)
15:10:36 <simo> I still have an i686 machine, but meh
15:10:53 <sgallagh> mitr: What do you mean, exactly?
15:11:01 <simo> x32 ?
15:11:24 <mitr> No, keeping old 32-bit binaries running. But unless there is overwhelming consensus I am not going to push for this.
15:11:41 <sgallagh> mitr: Well, that's not going to end.
15:11:45 <mitr> (push^W argue? advocate?)
15:11:51 <sgallagh> Koji is still going to build 32 and 64 bit versions of packages.
15:12:04 <sgallagh> We're just not going to ship install media for the 32-bit-only ones
15:12:13 <mitr> True
15:12:26 <sgallagh> The multilib stuff will still be available in the 64-bit trees as well
15:12:30 <simo> you can still do it with netinstall iso
15:12:49 <sgallagh> simo: Only if we ship a 32-bit netinstall iso
15:13:11 <simo> will we not ?
15:13:19 <simo> there are machines running atom cpus
15:13:22 <sgallagh> simo: That's... kind of the question we're asking here.
15:13:22 <mitr> I hope not
15:13:51 <sgallagh> If we ship any Server medium that can install i686, then we have to test and support it
15:13:57 <simo> sgallagh: I thought you were asking about the DVD, not the netinstall
15:14:14 <simo> netinstall is not server specific
15:14:25 <sgallagh> simo: Actually, it is. We have branded netinstall media
15:14:32 <simo> ugh
15:14:41 <simo> hmm
15:15:51 <adamw> for now, anyway. the generic netinst thing may come with new pungi, iirc.
15:16:26 * adamw is fine with dropping i686, personally.
15:16:27 <simo> I am a bit hesitant to make it impossible
15:16:33 <simo> err drop netinst
15:16:37 <sgallagh> simo: Well, not necessarily impossible
15:16:53 <simo> because someone can always install workstation and then "pivot" to server
15:17:10 <mitr> Do we expect workstation to keep i686 support?
15:17:12 <sgallagh> Assuming Workstation doesn't drop i686 as well
15:17:20 <simo> right
15:17:26 <simo> and what happen if all products drop it ?
15:17:54 <sgallagh> Then it can finally be mourned and moved on from? :)
15:18:16 <simo> yeah
15:18:21 <simo> I am a bit sentimental here
15:18:29 <simo> but I haven't installed an i686 machine in ages
15:18:30 <nirik> well, then the question becomes do we build it at all... but I guess some 32bit compat might still be wanted.
15:18:39 <simo> and the only one I have is a very old laptop w/o battery :)
15:18:44 <sgallagh> nirik: Yeah, I think building at least multilib packages is mandatory
15:18:57 <adamw> you *can* install without any kind of installer media, of course (direct kernel installer boot).
15:19:16 * nirik isn't sure how much it really matters anymore. I guess steam needs it still... but hopefully they would fix that sometime
15:19:21 <adamw> as a general rule, whatever awkward thing it is, some bugger can probably still do it.
15:19:21 <simo> adamw: I can do a chroot on x86_64 and then install all rpms :)
15:19:37 <simo> then ship the disk to an actual i686
15:19:48 <adamw> nirik: i still have some...stuff...that needs i686 packages. can never remember what, but they keep cropping up. oh, right now i think it's teamviewer (ugh)
15:19:59 <adamw> anyhow, we're kinda off topic i guess
15:20:04 <nirik> yeah, it's usually poorly made 3rd party apps.
15:20:08 <sgallagh> Well, our users will need 32-bit support for third-party apps
15:20:14 <sgallagh> Like *shudder* Adobe crap
15:20:29 <sgallagh> adamw: I don't think it's off-topic.
15:20:41 <sgallagh> If we make the decision to drop it, we have to know what that could effect.
15:20:56 <sgallagh> (And no, I did *not* mean "affect" in that sentence)
15:21:05 <mitr> sgallagh: I find it a bit difficult to believe that multilib will have enough popular support; but, well, nothing to be done. Keeping an i686 boot media just to keep multilib is obviously nonsense.
15:22:17 <sgallagh> mitr: Well, for the most part, it will just keep happening without anyone really noticing, I think
15:22:26 <sgallagh> Since we're not proposing to stop doing the builds.
15:22:37 <adamw> sgallagh: well, dropping i686 install media doesn't stop people using crappy apps, as we still have the packages.
15:22:53 <sgallagh> adamw: I think I was agreeing with you on that.
15:22:57 <adamw> sgallagh: we were discussing what happens if we don't build packages for i686 (or do multilib) at all, which seems kinda a way down the road.
15:22:58 <mitr> sgallagh: Sooner or later somebody will raise a FESCo ticket instead of/in addition to trying to debug something, as is now happening with the install media.
15:23:41 <dgilmore> i686 server media could become a secondary arch deliverable
15:23:58 <sgallagh> Right, that's always an option as well
15:24:10 <dgilmore> mitr: main thing that really needs multilib is wine
15:24:26 <sgallagh> If a sufficient group wants to maintain it (with or without overlap from us), then they can. But it won't be blocking.
15:24:28 <adamw> we also i guess have the option of building it but not considering it 'supported' in some sense, though that's a fairly squishy concept at this point
15:24:35 <mitr> dgilmore: There are no interesting 32-bit binary-only applications on the Linux platform?
15:24:37 <adamw> but along the lines of a non-blocking live spin or whatever
15:24:47 <nirik> adamw: I'm against that personally...
15:24:51 <dgilmore> mitr: not that I am aware of
15:24:54 <sgallagh> adamw: I think that defines Secondary Arch, really
15:24:55 <adamw> i'm not a fan, just mentioning it :)
15:25:03 <dgilmore> mitr: oracle, flash, etc all have 64 bit builds also
15:25:07 <adamw> sgallagh: nah, the concepts of 'release-blocking image' and 'secondary arch' are fairly distinct.
15:25:09 <sgallagh> mitr: Not in the repositories, I think
15:25:19 <sgallagh> Outside the repos, plenty
15:25:25 <adamw> all release-blocking images must be for primary arches, but not all images for primary arches are release-blocking.
15:25:26 <sgallagh> Steam comes readily to mind
15:25:33 <nirik> mitr: steam. skype?
15:25:42 <nirik> but yeah, not so many as in the past.
15:25:46 <sgallagh> Finally
15:26:01 <sgallagh> Assorted Adobe stuff as well
15:26:14 * mitr apologizes for dragging this off-topic
15:26:28 <dgilmore> if server for 32 bit x86 becomes a secondary deliverable, the tree will go to /pub/fedora-secondary and be on a different stream of mirrors, than the /pub/fedora/ where it goes today
15:26:43 <adamw> dgilmore: that seems like an entirely new thing.
15:26:54 <mitr> dgilmore: Seems like a win to me ☺
15:26:59 <dgilmore> adamw: yes, its something we are looking at being able to enable
15:27:02 <adamw> dgilmore: as things stand we don't send, say, the LXDE live spin or the Security Lab spin there.
15:27:05 <nirik> but if it does that how does multilib work?
15:27:14 <adamw> ok. i'd worry that it's overloading the 'secondary' concept, though.
15:27:27 <mitr> nirik: Wouldn’t it be transparent through mirrormanager?
15:27:28 <adamw> right now that location is clearly for 'secondary arch deliverables'
15:27:38 <dgilmore> adamw: we are working on redefining secondary acompletely
15:27:55 <dgilmore> it fits perfectly into the plans
15:27:58 <nirik> mitr: I don't think that could work... it has to be in the same repodata.
15:28:00 <adamw> er, that last line has a unicode box in it for me, which made it hard to parse
15:28:12 <adamw> dgilmore: what came between 'secondary' and 'completely'?
15:28:14 <dgilmore> we could also promote aarch64 to primary for Sever but not other editions
15:28:26 <dgilmore> adamw: nothing but network lag
15:28:30 <sgallagh> adamw: 
15:28:39 <adamw> sgallagh: ...thanks.
15:28:41 <adamw> (same box.)
15:28:43 <sgallagh> Any time
15:28:51 <sgallagh> (That was intentional)
15:28:54 <adamw> (i know)
15:29:49 <adamw> so, okay, that's a big thing, but not really a server WG thing.
15:30:04 <sgallagh> Right, so back to the question at hand:
15:30:13 <sgallagh> Which I will phrase as a proposal.
15:30:19 <adamw> dgilmore: it better be tied to new pungi cos if i have to stuff any more special locations into fedfind i'm gonna have to flip some tables.
15:30:49 <dgilmore> adamw: it is
15:30:50 <sgallagh> Proposal: Starting with Fedora 24, Fedora Server Edition will not ship or block on any media that installs on an i686-only system.
15:31:11 <adamw> sure, +1
15:31:12 <mitr> +1
15:32:15 <dgilmore> sgallagh: counter proposal "Starting with Fedora 24, Fedora Server Edition will ship on 32 bit x86 as a secondary arch deliverable."
15:32:46 <dgilmore> sgallagh: secondary arch deliverables are non release blocking
15:32:46 <sgallagh> Counter-counter-proposal: Starting with Fedora 24, Fedora Server Edition will not ship or block on any media that installs on an i686-only system as a primary architecture.
15:33:06 <sgallagh> (I don't want to tie our decision to secondary arch, in case that gets deferred)
15:33:14 <dgilmore> sure
15:33:28 <tuanta> +1
15:34:36 <mitr> +1 to any of these
15:36:42 <adamw> +1 to the third, gives us wiggle room to go either way.
15:37:45 <simo> +1
15:37:50 <sgallagh> +1 for the record
15:38:09 <sgallagh> That's +5. We can revisit if any of the absentee members have issues with it.
15:38:22 <sgallagh> #agreed Starting with Fedora 24, Fedora Server Edition will not ship or block on any media that installs on an i686-only system as a primary architecture. (+5, 0, -0)
15:38:36 <sgallagh> #topic Flock
15:39:02 <sgallagh> I ran two Server-related sessions at Flock this year, both were well-attended.
15:39:32 <sgallagh> I revamped my usual "Fedora Server: Past, Present and Future" talk a bit and I think I kept people's attentions better
15:39:45 <adamw> hand puppets?
15:39:57 <sgallagh> adamw: Silly graphics and exaggerated speech
15:41:05 <sgallagh> The audience appeared to be most interested in our plans for defining and categorizing a platform API definition
15:41:20 <sgallagh> After that, most of the "questions" were thinly-veiled demands for new Server Roles.
15:41:40 <adamw> that's where the 'patches welcome' hand puppet would've been handy
15:41:53 <sgallagh> The other session I ran was a rolekit hackfest, which was much better-attended than I expected.
15:42:18 <sgallagh> We spent the majority of time getting people up to speed on the code base, but I actually do expect new contributors out of that, so that's good.
15:42:52 <sgallagh> Oh, the other thing people were interested in during the Server talk was the plans for doing Role->Atomic migrations. People are excited about that.
15:43:45 <sgallagh> BTW, if anyone cares, my slides for the talk are here:
15:43:45 <sgallagh> #link https://sgallagh.fedorapeople.org/server-pastpresentfuture.odp
15:44:31 <sgallagh> adamw, nirik, simo: Anything Server-related from your Flock experience?
15:45:21 <nirik> not off hand... some more interest in a storage appliance role...
15:45:35 <sgallagh> Yeah, everyone wants the *hard* one
15:45:59 <adamw> sgallagh: not really directly. i kinda wanted to build an openQA role, but didn't really get there.
15:46:11 <sgallagh> Yeah, understood.
15:46:23 <sgallagh> If that's a thing you remain interested in, I'll be happy to help with it down the road
15:47:02 <adamw> yeah, it's kind of a textbook case for a role because there's a bunch of checklist stuff to deploying an openQA instance, not all of which can go in the package.
15:47:51 <sgallagh> OK, sounds good
15:48:17 <simo> nothing that affects server SGI plans directly from me
15:48:29 <simo> lots of good discussions on lower level security plumbing of course
15:48:34 <sgallagh> /me nods
15:49:01 <sgallagh> There was some really cool stuff in Robbie and Nathaniel's Kerberos talk that I hope we can roll out more widely
15:49:44 <sgallagh> nirik: If you haven't had a chance, I encourage you to talk to npmccallum, because I *think* they've finally fixed all the issues that kept FAS off of Kerberos in the past (including the firewall one)
15:50:17 <nirik> sgallagh: yeah, our plan there was to deploy fas3 (it's pretty much done) and then look at moving to freeipa after that
15:50:56 <simo> ugh
15:50:59 <simo> move and then move again
15:51:09 <simo> but this is for another place to discuss
15:51:42 <sgallagh> Agreed
15:51:48 <sgallagh> #topic Open Floor
15:52:32 <sgallagh> Anything?
15:53:04 <sgallagh> OK, I'll set the fuse for 120s
15:53:35 <simo> I have to go
15:53:38 <simo> nothign from me
15:53:41 <simo> thanks all
15:55:12 <sgallagh> #endmeeting