[Base] Fedora Base Design Working Group (2014-07-11) meeting minutes and logs

[Phil Knirsch]

Summary:

  - moben aka Benekdit Morbach presented some of his first results of 
builreq analysis and wrote a tool for that[1]. Will work with haraldh, 
vpavlin and others on related topics.
  - Talked with Michal Sekletar and accepted him as a WG member. His 
focus is docker and container technologies.
  - Vaclav Pavlin demonstrated the latest Fedora 20 based docker images, 
only 133MB in size[2] generated via a kickstart file[3]

Lively discussion around docker, anaconda and rel-eng followed those 
docker focus topics.

Mattdm then followed with 2 1/2 additional topics:

1a. Identifying different Fedora products -- fedora-release-* contents 
and /etc/os-release
1b. having tools like yum and dnf talk to mirror manager in a way which 
lets us count product installs
2. a "generic fedora" netinstall

For 1a and 1b dgilmore, sgallagh and mattdm have already done a larger 
thread on fedora-devel ML to discuss the proper approach and solution. 
Several ideas already in place, just need to be implemented(tm).

Some more discussions past that about 2. and related items (install 
trees vs. images etc).

Minutes: 
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-11/fedora_base_de...
Minutes (text): 
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-11/fedora_base_de...
Log: 
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-11/fedora_base_de...

[1] https://github.com/moben/buildreq-check
[2] http://vpavlin.fedorapeople.org/fedora-base-image/
[3] 
http://vpavlin.fedorapeople.org/fedora-base-image/container-fedora-small-...

-- 
Philipp Knirsch              | Tel.:  [phone]
Manager Core Services        | Fax.:  [phone]
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch(a)redhat.com&gt;
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany

[Mike Pinkerton]

On 25 Jul 2014, at 07:52, Phil Knirsch wrote:

>  Summary:
>
>  Mattdm then followed with 2 1/2 additional topics:
>
>  1a. Identifying different Fedora products -- fedora-release-*  
>  contents and /etc/os-release 
As I understand it, you are trying to decide where and how to set a  
flag that will signal the "product" that is either installed or to be  
installed.  There was mention of dropping "product specific snippets  
in /usr/lib/os-release.d/" as one solution.

Does it have to be any more complex than the approach used by  
systemd?  If fedora-release were to drop all product specific  
snippets in /usr/lib/os-release.d/, then a system admin could use a  
symbolic link in /etc/os-release.d to flag which product (or no  
product) he wanted installed.  Similar to:

/etc/systemd/system/default.target -> /lib/systemd/system/ 
graphical.target

a system admin could set a symbolic link:

/etc/os-release.d/product -> /usr/lib/os-release.d/workstation.product

Then, if a system admin wanted to change the box to a server, or to a  
non-productized box, he could simply change the symbolic link to:

/etc/os-release.d/product -> /usr/lib/os-release.d/server.product

or

/etc/os-release.d/product -> /usr/lib/os-release.d/generic.product

and then run whatever product syncing tool you develop -- perhaps:

dnf product-sync

>  2. a "generic fedora" netinstall 
I appreciate your continued consideration of this item.  I'm not  
clear on how Anaconda is supposed to work with different products,  
but if it is reading whatever product flag you set in order to  
determine the package list, couldn't a single netinstall CD work for  
all products, as well as a generic, non-productized install, assuming  
that there were a place in the UI to specify which product the user  
wanted installed?

-- 
Mike Pinkerton

[Miloslav Trmač]

----- Original Message -----
>  On 25 Jul 2014, at 07:52, Phil Knirsch wrote:
>  > Summary:
>  >
>  > Mattdm then followed with 2 1/2 additional topics:
>  >
>  > 1a. Identifying different Fedora products -- fedora-release-*
>  > contents and /etc/os-release
>  
>  As I understand it, you are trying to decide where and how to set a
>  flag that will signal the "product" that is either installed or to be
>  installed.  There was mention of dropping "product specific snippets
>  in /usr/lib/os-release.d/" as one solution.
>  
>  Does it have to be any more complex than the approach used by
>  systemd?  If fedora-release were to drop all product specific
>  snippets in /usr/lib/os-release.d/, then a system admin could use a
>  symbolic link in /etc/os-release.d to flag which product (or no
>  product) he wanted installed. 
This alone is not sufficient because we need that information to be available as RPM
dependencies ( https://fedoraproject.org/wiki/Per-Product_Configuration_Packaging_Draft ).
 So, in the end, we need the sysadmins to use rpm to switch between products.  (This does
not necessarily provide the _canonical_ answer for “how should other software check what
product is installed”, but it does give us _a possible reliable_ answer—namely, “query the
RPM database“).

<snip>
>  and then run whatever product syncing tool you develop -- perhaps:
>  
>  dnf product-sync 
What if the user changes the symlink but doesn‘t run the tool?  We
should be able to do this (if, indeed, we do need to support switching products at all)
without requiring a two-step manual process.


>  > 2. a "generic fedora" netinstall
>  
>  I appreciate your continued consideration of this item.  I'm not
>  clear on how Anaconda is supposed to work with different products,
>  but if it is reading whatever product flag you set in order to
>  determine the package list, couldn't a single netinstall CD work for
>  all products, as well as a generic, non-productized install, assuming
>  that there were a place in the UI to specify which product the user
>  wanted installed? 
Actually, this seems to already be the case.  A netinstall is produced as a Fedora Server
deliverable, but it can be used to install a non-Product system, and, if other Products
adopted the same conventions, also any other Product.

How this works: For Server, comps.xml defines server-product-environment (visible as a
"Fedora Server” base environment on the Anaconda’s Software Selection screen), which
contains a server-product group, and this groups pulls in the fedora-release-server
package, ultimately defining the product.  On a DVD, we restrict the set of packages
available to essentially offer only the Fedora Server, and this causes other parts of
comps to be filtered out and invisible to the user.

OTOH, the netinstall image loads the full comps.xml from the internet, so all other
environments (including non-product environments like “Minimal” or “Xfce Desktop”) are
available as choices for the user, and they do not pull in the fedora-release-server
package.

If other Products defined a $name-product-environment environment in comps.xml (which they
currently don’t because they don’t need to, for the live image-based and
partition-image-based installations), the other products would equally be visible when
booting the Server Product netinstall image.
    Mirek

[Matthew Miller]

On Mon, Jul 28, 2014 at 12:28:11PM -0400, Miloslav Trmač wrote:
>  > I appreciate your continued consideration of this item.  I'm
> not
>  > clear on how Anaconda is supposed to work with different products,
>  > but if it is reading whatever product flag you set in order to
>  > determine the package list, couldn't a single netinstall CD work for
>  > all products, as well as a generic, non-productized install, assuming
>  > that there were a place in the UI to specify which product the user
>  > wanted installed?
>  Actually, this seems to already be the case.  A netinstall is produced as
>  a Fedora Server deliverable, but it can be used to install a non-Product
>  system, and, if other Products adopted the same conventions, also any
>  other Product. 
But does anyone "own" that netinstall working in this way? Presumbably
Server only cares about it being able to install Server, and the rest is a
side-effect.



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Miloslav Trmač]

----- Original Message -----
>  On Mon, Jul 28, 2014 at 12:28:11PM -0400, Miloslav Trmač wrote:
>  > > couldn't a single netinstall CD work for
>  > > all products, as well as a generic, non-productized install, assuming
>  > > that there were a place in the UI to specify which product the user
>  > > wanted installed?
>  > Actually, this seems to already be the case.  A netinstall is produced as
>  > a Fedora Server deliverable, but it can be used to install a non-Product
>  > system, and, if other Products adopted the same conventions, also any
>  > other Product.
>  
>  But does anyone "own" that netinstall working in this way? 
Not that I know of.
    Mirek

[Matthew Miller]

On Fri, Jul 25, 2014 at 01:44:40PM -0400, Mike Pinkerton wrote:
>  >Mattdm then followed with 2 1/2 additional topics:
>  >1a. Identifying different Fedora products -- fedora-release-*
>  >contents and /etc/os-release
>  As I understand it, you are trying to decide where and how to set a
>  flag that will signal the "product" that is either installed or to
>  be installed.  There was mention of dropping "product specific
>  snippets in /usr/lib/os-release.d/" as one solution.
>  
>  Does it have to be any more complex than the approach used by
>  systemd?  If fedora-release were to drop all product specific
>  snippets in /usr/lib/os-release.d/, then a system admin could use a
>  symbolic link in /etc/os-release.d to flag which product (or no
>  product) he wanted installed.  Similar to: 

So, one catch is that os-release.d, with snippets, isn't currently supported
by the upstream standard. (If there is work to make it so, awesome.) And
it's not completely trivial, because either /etc/os-release needs to be
regenerated on change to the .d snippets, or else software which reads that
file (like agetty) needs to be updated to follow the .d directory too.

But also, ideally, the contents of /etc/os-release aren't just notes -- they
actually reflect the state of the system. Having it managed by RPM (or some
higher-level tool, theoretically) is helpful there. Here:

>  Then, if a system admin wanted to change the box to a server, or to
>  a non-productized box, he could simply change the symbolic link to:
>  /etc/os-release.d/product -> /usr/lib/os-release.d/server.product 
the _name_ has changed, but you don't necessarily have any of the actual
software (either installed or running) that makes it "Fedora Server".
That's
significantly less useful.

>  /etc/os-release.d/product ->
> /usr/lib/os-release.d/generic.product
>  and then run whatever product syncing tool you develop -- perhaps:
>  dnf product-sync 
Okay, so, yeah -- something like that would be needed. But if we're gonna
have such a tool, might as well make it also update the os-release
information. 


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader