14:20:24 <haraldh> #startmeeting Fedora Base Design Working Group (2015-07-20)
14:20:24 <zodbot> Meeting started Mon Jul 20 14:20:24 2015 UTC.  The chair is haraldh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:20:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:20:30 <haraldh> #meetingname  Fedora Base Design Working Group
14:20:30 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
14:20:44 <haraldh> #chair haraldh msekleta jreznik dgilmore vpavlin masta dwalsh lnykryn
14:20:44 <zodbot> Current chairs: dgilmore dwalsh haraldh jreznik lnykryn masta msekleta vpavlin
14:21:10 <haraldh> so, ping  dgilmore dwalsh haraldh jreznik lnykryn masta msekleta vpavlin
14:21:17 <haraldh> Hi lnykryn
14:21:18 <msekleta> hi, harald
14:21:23 <haraldh> hi
14:22:17 <masta> hello all
14:22:26 <haraldh> ping dgilmore
14:22:40 <haraldh> dgilmore, you brought up some topics for F23
14:25:42 <haraldh> zhmm
14:26:38 <masta> oh well
14:28:33 <haraldh> that's not how it works :-/
14:29:04 <haraldh> people agreed on a time and then they'll never show up
14:29:58 <haraldh> #topic "minimal install"
14:30:19 <haraldh> anyway, seems like we have to define the minimal install
14:31:36 <masta> so a group in comps?
14:31:42 <lnykryn> does anyone have a link for current core or minimal?
14:32:47 <lnykryn> https://git.fedorahosted.org/cgit/comps.git
14:33:10 <haraldh> https://git.fedorahosted.org/cgit/comps.git/tree/comps-f23.xml.in
14:33:44 <masta> ah, ok they are still on cgit
14:33:55 <haraldh> https://git.fedorahosted.org/cgit/comps.git/tree/comps-f23.xml.in#n6825
14:33:56 <masta> I thought they might have moved to pagure (https://pagure.io/comps)
14:34:27 <dgilmore> haraldh: here
14:34:31 <haraldh> ah
14:34:34 <haraldh> finally
14:34:41 <haraldh> hi dgilmore :)
14:34:44 <haraldh> very welcome
14:35:00 <dgilmore> masta: comps has not moved. I made a copy of it in pagure for some pungi testing
14:35:49 <dgilmore> the core group in comps it the minimal instal
14:35:51 <dgilmore> install
14:36:15 <haraldh> <id>minimal-environment</id>
14:36:15 <haraldh> <_name>Minimal Install</_name>
14:36:19 <haraldh> <grouplist>
14:36:19 <haraldh> <groupid>core</groupid>
14:36:19 <haraldh> </grouplist>
14:37:01 <haraldh> https://git.fedorahosted.org/cgit/comps.git/tree/comps-f23.xml.in#n639
14:37:27 <haraldh> So, what's the problem with the minimal install?
14:38:15 <haraldh> do we want to strip it?
14:38:21 <haraldh> make it more minimal?
14:39:05 <haraldh> dgilmore, ? ^
14:39:26 <dgilmore> haraldh: I think we just need tor eview it and see if there are changes we need to make
14:39:30 <haraldh> ok
14:39:48 <dgilmore> either cleaning it up some, or adding some things
14:41:00 <dgilmore> we need to make sure the arm minimal image is following the minimal install also
14:41:17 <lnykryn> core could be used as is or it is just a base for other compses?
14:42:20 <haraldh> I don't think the "Smallest possible installation" needs NetworkManager
14:42:26 <haraldh> or openssh
14:42:29 <haraldh> or even network
14:42:42 <haraldh> and e2fsprogs
14:42:53 <lnykryn> cronie, ncurses?
14:42:54 <haraldh> so, it's kind of a misleading title :)
14:43:23 <dgilmore> http://paste.fedoraproject.org/246102/14374033/
14:43:40 <dgilmore> that's the core group
14:43:49 <dgilmore> which is mandatory on a minimal install
14:45:03 <dgilmore> do we need initscripts there anymore?
14:45:13 <haraldh> does it have to have to have network capability?
14:45:20 <dgilmore> haraldh: yes
14:45:32 <lnykryn> dgilmore: it would be an interesting experiment to kick them out
14:45:48 <haraldh> e2fsprogs
14:45:52 <dgilmore> haraldh: at least for me the minimal install would give you a way to install other things
14:46:30 <haraldh> where is the kernel, btw?
14:46:35 <haraldh> only pulled in via deps?
14:46:39 <dgilmore> haraldh: it is needed if you use ext
14:46:44 <dgilmore> which is still most systems
14:47:06 <haraldh> shouldn't that be part of the installer?
14:47:24 <haraldh> know, which FS you installed and add the fsck tools?
14:47:26 <dgilmore> haraldh: it is not there because the actual kernel you install depends on what the hardware supports
14:47:38 <dgilmore> haraldh: likely yeah
14:47:43 <haraldh> ah, kernel-pae, etc..
14:47:49 <dgilmore> haraldh: yep
14:48:01 <haraldh> so, installer job
14:48:51 <haraldh> shouldn't ncurses be pulled in via deps also?
14:48:58 <haraldh> if needed?
14:49:09 <dgilmore> haraldh: I would think so yeah
14:49:11 <masta> probably
14:49:38 <dgilmore> the way we manage comps really does make checking some history difficult
14:49:55 <lnykryn> openssh-server?
14:50:40 <dgilmore> lnykryn: it is needed
14:51:08 <dgilmore> if you do a minimal install you may well only have ssh access
14:51:24 <dgilmore> and you need to ssh in to install and configure
14:51:38 <masta> ppc64-utils, I wonder if that could have an arch= ?
14:51:39 <dgilmore> but you are likely using kickstart then
14:51:50 <dgilmore> and can specify openssh in the kickstart
14:52:07 <dgilmore> masta: the arch= does nothing and is not valid
14:52:40 <masta> dgilmore: oh bummer
14:53:41 <masta> so I guess that means uboot is on all installs, even x86_64
14:54:07 <dgilmore> lots of installs have uboot-tools installed that do not really need them, because we needed it on arm
14:54:10 <dgilmore> yep
14:55:22 <msekleta> lnykryn, I often install VMs with only @core and would find very annoying if openssh-server is not installed by default. I mean, people would add it to their kickstarts anyway, but then what is the point of removing it.
14:55:35 <dgilmore> I guess we should probably start a thread on devel@ and swork out what changes should be made
14:55:52 <dgilmore> msekleta: I am with you there
14:56:07 <haraldh> so, my suggestions: drop "e2fsutils" "ncurses" and "glibc"
14:56:18 <haraldh> but, yeah
14:56:25 <haraldh> a thread on devel@
14:56:28 <dgilmore> it is needed if you specify @core only then use ansible to deploy and configure for instance
14:56:38 <dgilmore> haraldh: I can go with that
14:56:47 <dgilmore> glibc will be pulled in via deps
14:57:02 <dgilmore> but I am not sure we explicitly need to specify it
14:57:33 <haraldh> #action We'll start a thread on  devel@ and work out what changes to comps core should be made
14:58:02 <haraldh> #topic define the docker base image
14:58:19 <haraldh> dgilmore, so this docker base image has to be even smaller?
14:58:49 <dgilmore> haraldh: its in a confusing state, but afaik we are the owners of it
14:58:58 <dgilmore> we should be making sure that its being tested
14:59:07 <dgilmore> and suits it's purpose
14:59:20 <haraldh> ping vpavlin
14:59:26 <dgilmore> again I do not know that it needs any change
14:59:27 <msekleta> haraldh, I think for docker base image we can drop couple more things
14:59:34 <lnykryn> vpavlin is not here
14:59:34 <dgilmore> but it does need to be looked at
15:00:12 <msekleta> I think we might need new comps group for base-image as core contains things which doesn't make sense in base image
15:00:21 <dgilmore> https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-docker-base.ks?h=f23
15:00:35 <masta> it would be nice to see a full graph of all the deps the core group pulls in. I guess a quick @core install is the easy way. Would be interesting to see how weak-deps would help here
15:00:45 <dgilmore> the kickstart specifies --nocore
15:00:54 <dgilmore> so @core is not installed
15:01:04 <dgilmore> it then lists a few things to actually install
15:01:07 <msekleta> dgilmore, yeah, I see that now
15:01:14 <haraldh> so, @core could include @mini-minimal :)
15:02:07 <msekleta> dgilmore, at any rate, should we have this packages set specified in comps, having to look in two places is confusing
15:02:11 <haraldh> I would like to define a real @minimal and @minimal-network
15:02:23 <dgilmore> msekleta: yeah.
15:02:29 <haraldh> and let @core extend @minimal-network
15:02:42 <dgilmore> haraldh: not a horrible idea
15:02:44 <haraldh> and @docker extend @minimal-network
15:02:55 <haraldh> probably
15:03:16 <lnykryn> you meant @minimal
15:03:27 <dgilmore> the yum.conf changes in the kickstart are probably wrong
15:03:32 <haraldh> so, docker does not need network?
15:03:51 <dgilmore> haraldh: I think that is all managed by the docker daemon
15:03:52 <msekleta> haraldh, from I can see in ks file docker base image is more like your envisioned @minimal
15:03:57 <dgilmore> not in the container
15:04:15 <haraldh> mk
15:04:17 * dgilmore honestly is not 100% sure on that though
15:05:23 <dgilmore> https://docs.docker.com/articles/networking/
15:05:45 <haraldh> ok, I'll prepare a docker rpm list
15:06:11 <lnykryn> #fakesystemd #TODO: waiting for review https://bugzilla.redhat.com/show_bug.cgi?id=1118740
15:06:11 <lnykryn> I think we have abandoned that concept
15:06:37 <lnykryn> hmm the bug is still open
15:07:16 <dgilmore> lnykryn: afaik we have abandonded it
15:07:41 <msekleta> dgilmore, I don't think you need any network introspection utilities in container, for example with ip you can tell it to enter into container's network namespace, so you can introspect using the tool from host
15:08:11 <dgilmore> msekleta: right
15:08:29 <dgilmore> msekleta: I think its all set from outside the container also
15:09:18 <haraldh> why does the docker image need "dnf" ?
15:09:31 <lnykryn> for updates :-/
15:09:33 <haraldh> ?
15:09:35 <haraldh> what?
15:09:49 <dgilmore> haraldh: so you can install things
15:10:03 <dgilmore> make your own layers on top
15:10:06 <lnykryn> I think there is a recommodation that you should run dnf update in your dockerfile
15:10:35 * haraldh scratches his head...
15:10:50 <dgilmore> haraldh: and afaik all the tooling for making layered images etc relies on being able to use dnf/yum in the container to install things to make the layered image
15:10:52 <haraldh> why not make a new docker file then?
15:11:07 <haraldh> I mean all the dnf cache things will let the image grow
15:11:18 <haraldh> also the rpmdb is huge?
15:11:19 <dgilmore> haraldh: afaik dockerfiles use the yum/dnf in the container to do thier thing
15:11:46 <haraldh> 1st they complain about size, and the they have rpm inside the docker image :)
15:11:56 <haraldh> *then
15:12:34 <haraldh> and dnf bloats it further
15:12:41 <haraldh> I don't understand this docker thing
15:13:08 <dgilmore> haraldh: I do not entirely understand it either
15:13:14 <haraldh> ah
15:13:22 <haraldh> rm -rf /var/cache/yum/*
15:13:24 <haraldh> :)
15:13:29 <dgilmore> but people want it and we need to do as good as we can to deliver it
15:13:31 <haraldh> line 68
15:13:44 <dgilmore> haraldh: yeah, it all needs updated for dnf
15:14:21 <dgilmore> probably should turn off dnf auto updating the cache
15:14:32 <haraldh> they should remove the localized glibc messages also :)
15:15:40 <haraldh> ok, we need some docker experts here, preferably vpavlin
15:15:47 <msekleta> haraldh, recommendation is to run yum clean all after you installed needed packages when building some layered image
15:15:48 <dgilmore> yeah, though afaik glibc is planning to split all the locales out
15:15:51 <haraldh> msekleta, lnykryn : you know where vpavlin is?
15:15:55 <lnykryn> pto
15:15:59 <haraldh> ah, ok
15:16:10 <dgilmore> haraldh: yeah, I think we need his input
15:16:13 <lnykryn> dwalsh is also in base wg ;-)
15:16:29 <haraldh> haven't seen him in months here
15:16:45 <lnykryn> but he seems to be present of fedora-devel
15:19:50 <lnykryn> btw removing OOMScoreAdjust and masking those services should not be necessary with newer systemd
15:20:12 <dgilmore> lnykryn: guess we should test that
15:20:40 <lnykryn> dgilmore: I have tried that with 219 in rhel
15:21:19 <dgilmore> lnykryn: okay
15:21:30 <dgilmore> we shoudl try things first in Fedora
15:21:44 <dgilmore> that is what is supposed to happen
15:24:32 <dgilmore> so I guess here we need vpavlin and dwalsh to help us figure out what changes are needed
15:25:03 <lnykryn> I think that I and msekleta can consult the minimal docker images in person with vpavlin and guys who are currently working on the rhel images, so we could unify that as much as possible
15:25:34 <lnykryn> and then send a proposal to fedora-devel
15:25:35 <haraldh> ok, cool
15:25:43 <dgilmore> lnykryn: sounds good
15:25:59 <haraldh> #topic minimal disk image for importing into libvirt
15:26:11 <haraldh> dgilmore, so, what is this one?
15:26:20 <haraldh> a preinstalled minimal disk image?
15:26:25 <dgilmore> haraldh: yes
15:26:33 <haraldh> good idea
15:26:40 <haraldh> btrfs? xfs?
15:26:43 <haraldh> lvm?
15:26:44 <dgilmore> though we missed the change deadline
15:26:59 <lnykryn> how does it differ from cloud images?
15:27:14 <masta> good question
15:27:27 <dgilmore> lnykryn: it would run initial-setup to do final config and not use cloud-init
15:29:27 <lnykryn> but the package set would be more or less same right?
15:29:36 <dgilmore> lnykryn: the same as we do for the minimal disk image on arm today
15:29:46 <dgilmore> lnykryn: not really
15:30:07 <dgilmore> https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-arm-minimal.ks?h=f23
15:30:25 <dgilmore> https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-arm-base.ks?h=f23
15:30:49 <dgilmore> https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks?h=f23
15:35:35 <dgilmore> lnykryn: the packages may be much the same
15:36:06 <lnykryn> dgilmore: yep so they should have some common base
15:36:11 <dgilmore> but I would think that we would just do a minimal-install
15:36:24 <dgilmore> as opposed to a cloud-server install
15:37:01 <lnykryn> ok
15:37:10 <dgilmore> we do not need to know the differences
15:37:51 <dgilmore> anyway I think it is a useful deliverable
15:41:20 <dgilmore> we have a minimal disk image for arm.
15:42:00 * dgilmore needs to run and run the fedora releng meeting
15:42:26 <msekleta> dgilmore, also I think having minimal disk image built nightly (from rawhide) would be a good idea
15:43:08 <lnykryn> msekleta: that would require *a lot of* testing
15:43:30 <haraldh> *automated* ?
15:44:31 <msekleta> couple times I ended up in situation that I could not install rawhide VM using KS because anaconda bugs. If I have image built nightly I could grab latest and update it
15:44:34 <dgilmore> msekleta: there would be automated nightly builds
15:44:52 <dgilmore> msekleta: we are working to change rawhide to be a full compose that looks just like a release
15:46:35 <lnykryn> would it be possible to produce images that could run both in libvirt and nspawn?
15:46:38 <msekleta> dgilmore, awesome, I'd be glad to have just an image, but having full release with all artifacts built is of course even better
15:46:55 <dgilmore> lnykryn: doesnt the docker base image run in nspawn?
15:47:24 <lnykryn> it should, but I haven't try that
15:47:44 <dgilmore> msekleta: with a full release we can setup automated testing of everything and only push unbroken things
15:48:04 <lnykryn> but for testing purposes it is nice to have a bigger image
15:48:16 <dgilmore> lnykryn: having a container image that runs everywhere seems like a good goal
15:48:50 <dgilmore> being able to support rocket, nspawn, whatever comes along next
15:48:56 <dgilmore> as well as docker
15:50:15 <msekleta> dgilmore, docker base image is just tarball right, but we are talking about qcow2 image
15:50:58 <dgilmore> msekleta: okay, I do not know enough about all they how work
15:55:15 <lnykryn> so can we agree that this would be nice and now we can basically ship those arpm images just stripped from the arm stuff?
15:55:43 <lnykryn> and maybe for next time reconsider the package set
15:55:53 <msekleta> dgilmore, fwiw seems like docker doesn't support images yet https://github.com/docker/docker/issues/1617
15:57:59 <lnykryn> anything to add or can we move to the last topic?
15:58:11 <haraldh> #topic generic installer
15:58:41 <haraldh> what would that "generic installer" be? anaconda? shell  script?
15:59:00 <haraldh> anaconda to install "@core" ?
15:59:07 <haraldh> dgilmore, ?
15:59:07 <dgilmore> people want to be able to install fedora and not pick workstation/cloud/server
15:59:23 <msekleta> haraldh, your btrfs based installer :)
15:59:30 <haraldh> so basically anaconda with "fedora-release"
15:59:30 <masta> hehe
15:59:33 <haraldh> :)
15:59:40 <dgilmore> haraldh: kinda yeah
16:00:01 <dgilmore> but would offer xfce, lxde, mate, gnome, kde, etc
16:00:15 <dgilmore> basically a chose your adventure option
16:00:26 <haraldh> so basically the pre-next anaconda
16:00:32 <haraldh> ?
16:00:44 <dgilmore> haraldh: for lack of a better term yeah
16:01:09 <dgilmore> it could be a DVD or could just be a tree available for network installs
16:01:11 <haraldh> and we would be responsible for test plans?
16:01:20 <dgilmore> yes
16:01:22 <haraldh> and for the "product"
16:01:34 <dgilmore> right
16:01:44 <haraldh> meh
16:02:05 <lnykryn> so basically https://fedoraproject.org/wiki/Base#What_Base_is_NOT
16:02:10 <haraldh> sound more like a "Fedora Everything" WG :)
16:03:02 <haraldh> lnykryn, exactly :)
16:03:03 <dgilmore> haraldh: it would also give us a self contained environment for building the minimal disk image and testing the things under our scope. like anaconda
16:03:20 <haraldh> dgilmore, what's your point on lnykryn's link? :)
16:03:31 <dgilmore> haraldh: not seen his link
16:03:53 <haraldh> that was the definition of our working group in the beginning :)
16:05:00 <dgilmore> haraldh: DVD option is just that an option
16:05:18 <dgilmore> haraldh: we can focus it on just the minimal install use case
16:05:30 <dgilmore> and that you can install other things is just a side effect
16:05:39 <dgilmore> and need not be tested
16:07:57 <lnykryn> don't we have something like that already? I would swear that I have seen some os-release with "generic" product
16:09:49 <haraldh> https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/22/
16:10:28 <haraldh> so, that would be in "Everything"/<arch>/Images ?
16:10:54 <haraldh> IDK
16:14:45 <lnykryn> what would be a use-case for such product? for different desktops I can use their spins
16:15:04 <msekleta> I am still missing the reason why we need it
16:16:05 <dgilmore> we need it to install the minimal disk image
16:16:26 <dgilmore> if it can be used for different use cases then it is not a huge deal
16:18:04 <haraldh> all right
16:18:57 <haraldh> do we have to produce an ISO/netinst for that then?
16:23:29 <lnykryn> do we have to deal with it? from us it should just require to define a package set and that is the @core group
16:24:31 <lnykryn> Isn't this mostly a job for relengs?
16:25:03 <dgilmore> lnykryn: releng makes the things
16:25:10 <lnykryn> yep
16:25:11 <dgilmore> lnykryn: releng does not define or manage them
16:25:24 <lnykryn> and we will just provide the @core
16:25:33 <dgilmore> yes
16:25:36 <lnykryn> that is the only input needed
16:26:13 <lnykryn> Or am I missing something?
16:26:29 <dgilmore> lnykryn: there needs to be testing setup
16:27:14 <lnykryn> Can you elaborate on that?
16:27:14 <msekleta> imho, install tree should be enough. I guess road from comps group to install tree is not long, hopefully automated in some way :)
16:32:59 <lnykryn> my proposal to close this: If we need this internally, then go ahead and build image from @core. Tests would be "it installs and boots". But I don't think that we should ship it and support officially.
16:33:31 <lnykryn> as a fourth product
16:36:42 <msekleta> I agree with lnykryn's proposal
16:38:31 <lnykryn> any other opinions?
16:38:35 <haraldh> hmm
16:38:51 * lnykryn wants to go home and pack for his vacation :)
16:39:01 <haraldh> sure, go on
16:39:44 <haraldh> I like the idea of having a general product where I can freely click together my installation...
16:40:00 <haraldh> but then again, all the "presets" are unset
16:40:06 <haraldh> which is fine, I guess
16:41:49 <lnykryn> haraldh: would would be an example of such setup I don't think that anyone has a really generic setup, it is always something what is covered by spins
16:42:20 <haraldh> yeah, and in the spins you can also install other SW
16:42:43 <haraldh> but then again you can't "deselect" the spin's packages
16:42:46 <haraldh> right?
16:44:03 <lnykryn> if that is not possible shouldn't we file a rfe for anaconda
16:44:40 <lnykryn> you can do that in kickstarts
16:45:18 <haraldh> all right, let's continue this topic the next meeting
16:45:27 <haraldh> #endmeeting