15:00:09 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-02-28)
15:00:09 <zodbot> Meeting started Fri Feb 28 15:00:09 2014 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:17 <pknirsch> #meetingname  Fedora Base Design Working Group
15:00:17 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:00:24 <pknirsch> hello and welcome folks :)
15:01:09 <pknirsch> sorry for sending out the agenda so late today, we've had network trouble in the office all days
15:01:15 <haraldh> <-
15:01:15 <pknirsch> s/days/day/
15:01:21 <pknirsch> heya haraldh
15:01:26 <haraldh> hey
15:01:51 * notting is here
15:02:10 <pknirsch> #chair haraldh notting
15:02:10 <zodbot> Current chairs: haraldh notting pknirsch
15:02:44 * sgallagh lurks
15:03:07 * jreznik is here
15:03:36 <pknirsch> heya sgallagh! thanks for lurking :) we might have a question or two at some point, but i've reviewed the tech spec and haven't seen anything out of the ordinary there yet.
15:03:40 <pknirsch> heya jreznik
15:03:45 <pknirsch> #chair jreznik
15:03:45 <zodbot> Current chairs: haraldh jreznik notting pknirsch
15:03:47 <sgallagh> great
15:04:02 <pknirsch> and it's pretty much work in progress at the moment from what i saw
15:04:07 <pknirsch> which is great :)
15:04:30 <pknirsch> so, first and only official topic for today:
15:04:51 <pknirsch> #topic Discussion of Server Tech Spec
15:05:03 <pknirsch> #info https://fedoraproject.org/wiki/Server/Technical_Specification
15:06:31 <pknirsch> I've taken a look at it today already, and it aligns very well with the discussions and decisions the Server WG has done over the past months regarding their concept of roles and basic functionality
15:07:10 <pknirsch> XFS i thought was a very interesting and great recommendation, but i believe thats still being discussed on a broader scale.
15:07:48 <pknirsch> Lots of the other low level points are strongly related to systemd (service mgmt, logging, session tracking)
15:07:55 <sgallagh> I'm currently trying to get my hands on the reports for why that was selected for RHEL 7
15:07:56 <notting> sgallagh: it's the intent of the server WG to ship accountsservice?
15:08:13 <sgallagh> notting: accountsservice is moving into SSSD
15:08:35 <sgallagh> It's part of a larger effort to provide more identity information
15:08:57 <pknirsch> to basically define one central place that takes care of it?
15:09:01 <notting> sgallagh: *nod*, it makes more sense to specify it as a part of sssd; just was curious about specifying it while it was separate
15:09:01 <sgallagh> i.e. work around the very limiting get*by*() calls to glibc
15:09:26 <sgallagh> notting: I kind of just left that in when I copied from Workstation. The phrasing is subject to change
15:10:00 <sgallagh> But if SSSD doesn't have it by F21 (and it probably won't), I want to leave open the possibility of pulling that piece in if we need it
15:10:12 <notting> ok
15:10:18 <notting> sgallagh: systemd-nspawn, not docker?
15:10:42 <sgallagh> notting: I may have misremembered, but I'm pretty sure dwalsh told me that docker is moving to use systmed-nspawn
15:10:51 <sgallagh> If that information is incorrect, this is *certainly* up for revision
15:10:51 <pknirsch> i had one question regarding the installer, sgallagh. There it's specified to minimalize the user interaction. Are you guys envisioning a different frontend for anaconda here or simplify the existing one>
15:10:57 * pknirsch nods
15:11:00 <pknirsch> i think thats the plan
15:11:09 <pknirsch> away from libvirt-lxc to systemd.nspawn
15:11:20 <pknirsch> haraldh might know more about this i believe
15:11:24 <sgallagh> pknirsch: Simplify an existing one. Reduce the guided storage path to "default" or "custom"
15:11:32 * pknirsch nods
15:11:36 <pknirsch> thanks for the clarification, sgallagh
15:11:55 <sgallagh> Instead of "ext4", "ext4+LVM", "btrfs", etc. that we have in the drop-down now
15:12:44 <jreznik> pknirsch: yeah, I heard the same for docker
15:12:47 <sgallagh> pknirsch: That's contingent on discussions with Anaconda and UXD
15:13:56 <drago01> sgallagh: so re security of nspawn ... do we have the selinux support yet or is this all wip?
15:14:48 <pknirsch> sgallagh: right, sounds good. and for Server i would expect a lot more automated installs anyway, via kickstart or provisioning services e.g. puppet & friends
15:14:53 <haraldh> "systemd-nspawn will be used to manage containerization capabilities" .. hmm.. Lennart initially didn't want to promote it as a product tool
15:14:57 <haraldh> nspawn is intended for debugging
15:15:00 * dgilmore is here
15:15:00 <haraldh> but more and more people are using it
15:15:01 <sgallagh> drago01: I haven't been able to confirm that since talking to you an hour ago :)
15:15:10 <sgallagh> Right, and that's going to remain as it is today.
15:15:47 <sgallagh> Actually, I need to note that in the doc
15:15:48 <sgallagh> Thanks
15:15:49 * jreznik_ is not sure he was online and you see his message, but doesn't matter :)
15:15:57 <drago01> sgallagh: ok fair enough ;)
15:16:28 <sgallagh> jreznik_: Which one?
15:16:34 <notting> yeah, specifying 'we expect kickstart to be a primary installation focus' would be good
15:17:13 <jreznik_> and do we really expect that?
15:17:13 <dgilmore> kickstart support is critical for any type of non interactive install
15:17:22 <jreznik_> it is critical
15:17:34 <jreznik_> but what kind of server deployment we expect for Fedora Server?
15:17:46 <dgilmore> kickstart parsing should be one spec and ideally one tool
15:18:00 * dgilmore uses fedora for mail and routers
15:18:00 <sgallagh> dgilmore: Sorry, I can't parse that cleanly
15:18:14 <dgilmore> sgallagh: which bit?
15:18:15 <jreznik_> I'd say Fedora would be more for small business/home office servers... but maybe I'm out
15:18:19 <notting> jreznik_: given the notes about it expecting to be enrolled in some sort of IPA/DS directory service, that implies fedora server being used for more than one-off home servers
15:18:23 <sgallagh> what spec and tool?
15:18:43 <dgilmore> sgallagh: pykickstart, and the kickstart it supports
15:18:44 <jreznik_> notting: and based on what we are expecting so?
15:19:05 <sgallagh> jreznik_: Less "expecting" more "targeting"
15:19:19 <sgallagh> I see it being more for the start-up/small-business case initially
15:19:26 <haraldh> in an ideal world, kickstart would be a tool written in C, using libs, shared with anaconda
15:19:29 <dgilmore> sgallagh: I really don't want people going off writing a different kickstart parser that supports kickstarts that are dont work with pykickstart
15:19:30 <sgallagh> With it also being a proving ground for the same stuff landing in RHEL eventually
15:19:40 <sgallagh> dgilmore: That's not on the table as far as I know
15:19:48 <jreznik_> sgallagh: ok, but that world is probably less kickstart one but interactive installation
15:19:59 <dgilmore> sgallagh: Ive not heard of it, but I think we need to make it clear
15:20:04 <jreznik_> (as I remember these kind of companies)
15:20:29 <sgallagh> jreznik_: Which is why we put so much focus on how we want the interactive install to look :)
15:20:40 <sgallagh> But after you do it the first time, chances are you'll kickstart the rest
15:21:05 <jreznik_> ok, makes sense
15:21:53 <sgallagh> dgilmore: Ok, when I update the doc to mention kickstart, I'll note that pykickstart/anaconda is the only tool we intend to support for this
15:22:32 <dgilmore> sgallagh: thanks. I dont want a repeat of boxgrinder
15:22:52 <sgallagh> ack
15:23:55 <notting> sgallagh: cockpit's only mentioned in passing in one spot. should it be denoted as the primary user-facing management interface?
15:24:36 <sgallagh> notting: Yeah, I was going to bring that up at today's meeting, but we're lacking quorum :-/
15:24:44 <notting> actually... that's not relevant to the base design interaction, so that can likely be tabled for you to handle somewhere other than this meeting.
15:25:16 <sgallagh> Ok, I've been informed that my understanding of docker/nspawn is incorrect. I'm going to recommend we yank that discussion and hold it for a Container Host role in F22.
15:25:19 <dgilmore> sgallagh: was the longer term plan to support /boot on xfs?
15:25:40 <sgallagh> dgilmore: I think we settled on that being the current plan too.
15:25:54 <sgallagh> I think we decided that having a different /boot fs didn't make sense
15:26:15 <dgilmore> sgallagh: okay, some arm systems it wont be an option
15:26:37 <sgallagh> Also valuable information...
15:27:17 <dgilmore> sgallagh: there is zero support for xfs in u-boot
15:27:41 <sgallagh> ARM is going to be a special case in any situation.
15:27:42 <pknirsch> and u-boot is being used by most 32bit arm systems, right?
15:27:49 <dgilmore> and while I can likely work to get it added, some systems we have said thatw e will use the vendors provided u-boot
15:27:56 <sgallagh> it's a stated goal, but we may or may not manage it for F21
15:27:57 <dgilmore> pknirsch: it is
15:28:00 <pknirsch> ok
15:28:21 <dgilmore> right now im working to standardise booting on extlinux for arm systems
15:28:56 <dgilmore> I really don't know what it would take to get iin xfs support
15:29:37 <dgilmore> but it will likely be a longer term thing, and to support we may have to replace vendor supplied u-boots or get them to update u-boot
15:29:38 <sgallagh> I'm alright with having XFS as a "goal" vs. a "requirement"
15:29:44 <sgallagh> If it doesn't work initially, we can land it later
15:29:54 <dgilmore> some arm systems today dont boot from ext4
15:30:06 <dgilmore> and only support ext2 and ext3
15:30:17 <dgilmore> there is a lot of work we need to do there
15:30:58 <pknirsch> is there any plans to get grub2 working there?
15:31:05 <dgilmore> none
15:31:06 <pknirsch> or does it even make sense to try that?
15:31:09 <pknirsch> ok
15:31:27 <dgilmore> there is a grub2 port but it has quite a few issues
15:31:50 <pknirsch> mhm
15:31:57 <dgilmore> and you would still need xfs support in u-boot
15:32:06 <pknirsch> right
15:32:15 <dgilmore> as u-boot would load grub2 from a filesystem
15:33:06 <dgilmore> the u-boot story is getting better
15:33:14 <pknirsch> hehe
15:33:29 <dgilmore> somehow i ended up the u-boot maintainer
15:33:40 <dgilmore> and im working with upstream
15:34:01 <pknirsch> gz? :)
15:34:14 <dgilmore> gz?
15:34:27 <pknirsch> congratulations, sorry (gz is a gamer shortcut)
15:34:43 <dgilmore> :)  thanks
15:35:31 <dgilmore> I just wanted to make sure that it was considered a longer term goal, or at the least its noted that different platforms may need to do different things
15:35:40 <pknirsch> right
15:35:51 <dgilmore> im not sure where ppc64 and s390x stand
15:35:57 <dgilmore> ppc64 is probably okoay
15:36:03 <dgilmore> but s390x not sure
15:36:05 <pknirsch> especially with ARM being on the list of supported platforms for Server and being a primary arch
15:36:08 <pknirsch> hm
15:36:19 <jreznik_> and as sgallagh said - it's more goal now than requirement
15:36:20 <dgilmore> I also want to make sure that we consider secondaries
15:36:25 <pknirsch> s390x is a good question, pretty sure xfs isn't in zipl :)
15:36:57 <dgilmore> i know ppc64 and s390x likely will only support server and not workstation or cloud
15:37:19 <dgilmore> aarch64 is still a bit in the air as we will have to wait and see what hardware lands in the wild
15:37:21 <jreznik_> seems like we're already going to end up with a few fs - so there should be always some kind of support when there would be need for something different for other arches
15:38:11 <dgilmore> right
15:38:16 <dgilmore> just need to documemnt it
15:38:38 <pknirsch> aye
15:38:55 <pknirsch> but those are pieces that would be proper for the tech spec for the Server, granted
15:39:17 <pknirsch> i think they are currently talking on #meeting-1 actually
15:39:18 <dgilmore> right
15:40:39 <dgilmore> anyway. just wanted to raise my concerns
15:41:17 <jreznik_> sure and it's a good argument for server guys
15:41:43 * pknirsch nods
15:42:33 <sgallagh> Well, we're always going to "support" custom layouts
15:42:42 <sgallagh> Which means many and varied filesystems anyway
15:42:47 <pknirsch> mhm
15:43:00 <sgallagh> So if we determine that it makes sense to have different defaults on certain architectures, I'm not going to weep
15:43:59 <pknirsch> :)
15:44:07 <dgilmore> right, just need to be flexible
15:44:22 * sgallagh heads to yoga class ;-)
15:44:50 <notting> *nod* - i mean, i'd feel comfortable dictating that the default must be *one of* ext4/xfs/btrfs for a particular arch for now, but i can allow them being different
15:46:01 <sgallagh> Right, and I think that's what we're doing: XFS-on-LVM except where that's technically infeasible
15:47:52 <dgilmore> yep
15:49:10 <dgilmore> sgallagh: do we really need to specify arches in the spec?
15:49:40 <sgallagh> Probably, since at least Workstation is talking about restricting the set
15:49:56 <dgilmore> ugghh
15:50:05 <dgilmore> I guess i need to pay closer attention to them
15:50:45 <dgilmore> sgallagh: armv8 is known as aarch64
15:51:15 <dgilmore> sgallagh: and pointing it out in the spec seems to make some assumption that it will be primary? or that you plan to work in teh secondary arch sphere to support it?
15:51:42 <dgilmore> sgallagh: I do hope that it will become primary at an appropriate point in time
15:51:44 <sgallagh> dgilmore: I believe our plan is "primary as soon as possible" on aarch64
15:51:51 <notting> are we assuming that whether or not to implement a product is up to the secondary arch?
15:52:05 <pknirsch> i'd certainly prefer that, yes
15:52:12 <sgallagh> That hadn't explicitly come up, but I think that's the only sane way
15:52:18 * pknirsch agrees
15:52:23 <dgilmore> notting: its not really clear how secondaries fit into the new world
15:52:35 <dgilmore> like spins they seem to have been mostly ignored
15:52:37 <jreznik_> dgilmore: does it make sense for WS to aim for example aarch32 - there's some HW available but if would not fulfill what they expect?  personally I guess it makes sense, but
15:52:54 <dgilmore> talking with the secondaries I have said that they should decide what products to support
15:53:03 <jreznik_> dgilmore: yep
15:53:28 <dgilmore> jreznik_: it does make a lot of sense for workstation to support 32 bit arm
15:53:47 <dgilmore> there is very active work on 3d support etc
15:53:54 <jreznik_> should Base take closer look on spins too? as we're going to be base for spins too and nobody else is really much taking care as dgilmore said
15:55:33 <dgilmore> jreznik_: someone needs to
15:55:48 <notting> what do you mean by 'closer look'?
15:56:11 <jreznik_> I'm a bit surprised no spin owners are active a bit more, seems like nobody cares :(
15:56:23 <dgilmore> I think the main thing we need to be sure of is that spins are tested, signed off as working, and shipped in a consistent manner
15:57:55 <notting> but is there a change in how we are making sure spins are tested other than asking maintainers 'did you test it'?
15:58:19 <dgilmore> notting: we took steps in f20 to get more active testing
15:58:33 <dgilmore> I think we can take it a little further
15:58:59 <dgilmore> but maybe that is a discussion to bring up with qa and spins owners
16:00:32 <pknirsch> ye
16:02:45 <dgilmore> pknirsch: do we have anything else to discuss here?
16:02:54 <pknirsch> ok, i think we've had a pretty good coverage of the current state and had a good feedback session with sgallagh as well.
16:03:18 <pknirsch> dgilmore & rest: i think we're done here for today. lets see how the tech spec for Server looks by next week and revisit it imho
16:03:54 <dgilmore> pknirsch: okay, probably need to look closer at workstations spec also
16:04:06 <pknirsch> cool, thanks dgilmore
16:04:23 <pknirsch> i'll recheck it once again next week, too
16:04:37 <pknirsch> anything else anyone?
16:05:03 <dgilmore> I have nothing
16:05:25 <pknirsch> #info Good feedback session with sgallagh, identified several sections that might need clarification (installer, filesystems, SSSD)
16:05:34 <pknirsch> alright, let's close it for today then
16:05:52 <pknirsch> thanks everyone! and thanks sgallagh once more for your time today, that was really helpful
16:06:06 <dgilmore> thanks pknirsch and sgallagh and everyone else
16:06:18 <pknirsch> #endmeeting