Bug 1200122 - Fedora Atomic should report atomic in os-release
Summary: Fedora Atomic should report atomic in os-release
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-09 18:44 UTC by Langdon White
Modified: 2016-08-24 17:11 UTC (History)
18 users (show)

Fixed In Version: fedora-release-24-0.14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-11 17:51:20 UTC


Attachments (Terms of Use)

Description Langdon White 2015-03-09 18:44:38 UTC
Description of problem:
In order for tooling (e.g. vagrant) to properly work with atomic (e.g. know that it can't use yum), we need to identify it as such. In other words, the word "atomic" should appear somewhere in os-release.


Seems related:
https://bugzilla.redhat.com/show_bug.cgi?id=1102241

Comment 1 Colin Walters 2015-03-09 20:51:28 UTC
I'd prefer looking for features.  For example in this case, if yum isn't present, assume you can't do whatever you would do with yum?

If you need to though runtime, there is /run/ostree-booted, which isn't the same as [Fedora/CentOS/Red Hat Enterprise Linux] Atomic (it's also present on gnome-continuous and other OSTree-consuming distributions), but it exists.

Or you could do what yum does and check for /usr being a read-only bind mount (preferred is via statvfs(2), but you can just shell out to 'test -w' which uses access(2) )

Comment 2 Langdon White 2015-03-09 21:40:44 UTC
I understand what you are saying, however, the example may just not be a great one. I think there are countless reasons why you would want to know what OS you are on. Fundamentally, I feel like you need to treat an atomic-OS as something different than a traditional version of Fedora. 

At its simplest, I think it will be weird/confusing/not-DRY to have a bunch of branching code for various capabilities (e.g. is rsync locally present? is it in a container? is it something else in one spot; is nfs available? in a container? etc) where the branches essentially, but not completely, repeat. Generally speaking, I would expect to branch once (e.g. this thing is "atomic fedora" and that thing is "server fedora" and that one is "workstation fedora") and then have a reduced set of tests within. 

Now, arguably, if "atomic-ness" is a "feature" of cloud, wkstn, server, kde-spin, etc then, I would be more inclined to agree with your argument. However, thus far, we seem to be treating "atomic-ness" as a variant of "fedora" not a variant of an edition/spin.

Comment 3 Colin Walters 2015-03-19 16:34:28 UTC
The "is it in a container" question also applies to mainline systems too.

If you want to branch globally of "can I install packages", the read-only bind mount seems like a useful global state, and would clearly distinguish mainline from Atomic now and into the forseeable future.


Re: "atomic-ness" - indeed, there are people interested in using the rpm-ostree technology outside of the Docker Container Host.  For example, workstation labs.

Comment 4 Colin Walters 2015-04-09 15:04:17 UTC
All of the above said I'm fine making a new -release package.  We already have a separate product package.

I think we'd just take the existing release package and append "Atomic Host" to it or so.

Comment 5 Daniel Walsh 2015-08-21 05:08:49 UTC
Colin do you want Lokesh to create a atomic-release package?

Comment 6 Colin Walters 2015-08-21 17:54:09 UTC
(In reply to Daniel Walsh from comment #5)
> Colin do you want Lokesh to create a atomic-release package?

Let's wait for the outcome of https://lists.fedoraproject.org/pipermail/cloud/2015-August/005660.html

Comment 7 Daniel Walsh 2015-09-29 15:03:12 UTC
Colin, so what should we do?

Comment 8 Stef Walter 2015-11-13 13:41:25 UTC
Cockpit will likely also need this in the future.

We need a central place to look for this information (such as /etc/os-release and friends) and not just imagine we can look at the whole system for features.

In addition, on RHEL Atomic, in the future Cockpit really wants to know which other Red Hat products have been installed.

Subhendu may have some insight here.

Comment 9 Charlie Drage 2015-11-13 16:14:27 UTC
While implementing an atomic provider for Docker Machine I too encountered this problem with /etc/os-release. The way that Docker Machine detects what OS to provision is by grepping the releaseid from /etc/os-release. Unfortunately Atomic hosts are the only ones that do not abide by this rule (all others such as CoreOS, RancherOS, SUSE, etc follow suit). 

Even providing a hyphenated release id would be great (centos7-atomic, fedora23-atomic, etc.).

Comment 10 Colin Walters 2015-11-13 16:15:14 UTC
(In reply to Charlie Drage from comment #9)
> While implementing an atomic provider for Docker Machine I too encountered
> this problem with /etc/os-release. The way that Docker Machine detects what
> OS to provision is by grepping the releaseid from /etc/os-release.

But what do you want to do with this information?

Comment 11 Charlie Drage 2015-11-13 16:28:11 UTC
(In reply to Colin Walters from comment #10)
> (In reply to Charlie Drage from comment #9)
> > While implementing an atomic provider for Docker Machine I too encountered
> > this problem with /etc/os-release. The way that Docker Machine detects what
> > OS to provision is by grepping the releaseid from /etc/os-release.
> 
> But what do you want to do with this information?

The releaseid information from /etc/os-release helps determine what underlying OS is runnning on the system. Having this information would be able implement an atomic provider for Docker Machine as well as a better implemented ansible atomic detection.

Comment 12 Colin Walters 2015-11-13 16:56:21 UTC
(In reply to Charlie Drage from comment #11)

> The releaseid information from /etc/os-release helps determine what
> underlying OS is runnning on the system. Having this information would be
> able implement an atomic provider for Docker Machine as well as a better
> implemented ansible atomic detection.

What exactly would docker machine do differently in an Atomic Host provider versus say a Fedora Server one, or for that matter Debian?

Comment 13 Charlie Drage 2015-11-13 17:09:44 UTC
(In reply to Colin Walters from comment #12)
> (In reply to Charlie Drage from comment #11)
> 
> > The releaseid information from /etc/os-release helps determine what
> > underlying OS is runnning on the system. Having this information would be
> > able implement an atomic provider for Docker Machine as well as a better
> > implemented ansible atomic detection.
> 
> What exactly would docker machine do differently in an Atomic Host provider
> versus say a Fedora Server one, or for that matter Debian?

Quite a bit :)

See https://github.com/docker/machine/blob/master/libmachine/provision/redhat.go

A TLDR:

Installs Docker (not applicable to atomic). 
Provisions a hostname
Provisions the systemd docker config for clustering / swarm / networking
Installs relevant packages (not applicable to atomic)
Update repo (not applicable to atomic)

In other words, the integration is to have clustering / networking / swarm working natively with the --generic docker machine provider. 

A better example of what I am integrating would be very similar to the current CoreOS provider:

https://github.com/docker/machine/blob/master/libmachine/provision/coreos.go

Where the only relevant things that are changed at the hostname and daemon options.

We *could* simply add an *if* statement for the redhat.go provider on Docker machine to check /run/ostree-booted, or /etc/system-release-cpe but I believe that wouldn't be best practice in comparison to adding the relevant information to /etc/os-release.

Comment 14 Dusty Mabe 2015-11-16 17:17:45 UTC
I'm +1 on having something in there to indicate:

1 - I am running on Fedora 23 (or CentOS 7) 
2 - I am an Atomic Host.


I think it is easier for upstream projects (ansible, docker-machine, cloud-init, others..) to look at one place to determine what environment they are in.


Just my $.02

Comment 15 Jeremy Eder 2015-11-17 11:19:39 UTC
Colin, is this not the purpose of /etc/system-release-cpe ?

Comment 16 Fabian Deutsch 2015-11-17 15:42:32 UTC
Let me point out that /etc/os.release.d/* could also help.

/etc/os-release could indicate the platform

A file i.e. /etc/os.release.d/atomic

can override the VARIANT and VARIANT_ID field to signal that it's the Atomic flavor.

Comment 17 Colin Walters 2015-11-17 17:06:58 UTC
(In reply to Charlie Drage from comment #13)

> https://github.com/docker/machine/blob/master/libmachine/provision/redhat.go

The nature of "provisioning glue" type code means that it won't be beautiful.  And I have certainly myself written some ugly bits in Ansible and those type of things.

That said, this code is pretty awful.

   "sudo hostname %s && echo %q | sudo tee /etc/hostname",

No apparent awareness of shell quoting issues, or idempotency ("don't do this if the hostname is already set").  Or the fact that `tee` does an open(O_TRUNC) and so will potentially leave a corrupted file if interrupted, etc.

Really the whole thing should admit it's just a pile of hacky shell script and not actually Go.  

In the bigger picture, Docker Machine would do well to follow the path of Vagrant, and support callouts to well-known remote automation tools like Ansible/Puppet etc.  (Vagrant has some of its own builtin provisioning that's mostly just as hacky as Docker Machine, but at least it's easy to hook up sane provisioning tools in Vagrant)

> Installs Docker (not applicable to atomic). 
> Provisions a hostname

Best done by detecting that the host uses systemd, and call out to `systemctl set-hostname --static`.

> Provisions the systemd docker config for clustering / swarm / networking

Tricky and system dependent, but also *not* specific to Atomic Host - the same instructions would apply to a Fedora 23 Server with Docker.

> Installs relevant packages (not applicable to atomic)
> Update repo (not applicable to atomic)

Yes, best done by detecting that `rpm -q docker` is found and not trying to install it, like Ansible's `yum state=present` does.

Comment 18 Charlie Drage 2015-11-17 17:19:09 UTC
(In reply to Colin Walters from comment #17)
> (In reply to Charlie Drage from comment #13)
> 
> > https://github.com/docker/machine/blob/master/libmachine/provision/redhat.go
> 
> The nature of "provisioning glue" type code means that it won't be
> beautiful.  And I have certainly myself written some ugly bits in Ansible
> and those type of things.
> 
> That said, this code is pretty awful.
> 
>    "sudo hostname %s && echo %q | sudo tee /etc/hostname",
> 

I do admit it's extremely hacky. There's an open PR for this to be fixed:
https://github.com/docker/machine/pull/1586

Imo, the --generic option is a glorified shell script at the moment for Docker Machine.


Regardless, I would like to see a central location that we can gather information whether or not it is an atomic host, similar to other OS' that have followed suit this way.

Comment 19 Charlie Drage 2015-11-17 17:21:25 UTC
(In reply to Jeremy Eder from comment #15)
> Colin, is this not the purpose of /etc/system-release-cpe ?

Unfortunately I don't think this is standard between RHEL-based Atomic Hosts :(

I've just done this on a CentOS 7 Atomic:

[centos@cloud ~]$ sudo cat /etc/system-release-cpe
cpe:/o:centos:centos:7

[centos@cloud ~]$ cat /etc/os-release 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

Comment 20 Charlie Drage 2015-11-17 18:04:44 UTC
(sorry to spam)

But I have filed https://bugs.centos.org/view.php?id=9776 after finding that the previous bug had been closed. 

I don't believe that "grep 'ostree=' /proc/cmdline" is a viable solution for finding whether a host is Atomic or not.

Comment 21 Daniel Walsh 2016-01-06 19:29:20 UTC
Any update on this?

Comment 22 Dusty Mabe 2016-02-06 12:33:42 UTC
In a presentation at DevConf today the presenter tried to show the host he was on was an Atomic host by looking at /etc/{fedora,redhat}-release. When that didn't show what he wanted he just tried to write a file in /usr/ (in order to get a read only filesystem error) to prove that he was on Atomic.

We need a clear way for people to find this out that doesn't fall too far outside of their already known methods for discovering what platform they are on.

Comment 23 Fabian Deutsch 2016-02-08 09:07:44 UTC
Please use the VARIANT and VARIANT_ID fields in /etc/os-release.

It aligns well with what we have, it is easy to discover, and it is the same on CentOS and Fedora.

Comment 24 Colin Walters 2016-02-08 12:52:23 UTC
It seems this would be a patch to
http://pkgs.fedoraproject.org/cgit/rpms/fedora-release.git/

Comment 25 Stephen Gallagher 2016-02-08 13:29:30 UTC
(In reply to Colin Walters from comment #24)
> It seems this would be a patch to
> http://pkgs.fedoraproject.org/cgit/rpms/fedora-release.git/

Tell me *exactly* what you want the resulting os-release file to look like and I'll get it done.

Comment 26 Charlie Drage 2016-02-08 14:40:46 UTC
(In reply to Fabian Deutsch from comment #23)
> Please use the VARIANT and VARIANT_ID fields in /etc/os-release.
> 
> It aligns well with what we have, it is easy to discover, and it is the same
> on CentOS and Fedora.

Yeah, according to https://www.freedesktop.org/software/systemd/man/os-release.html that'd be a good route.

for ex.

VARIANT="Fedora 23 (Atomic Host)"
VARIANT_ID=atomic

Can this be consistent across all platforms however? (ex. server vs workstation vs atomic, etc.)

Comment 27 Colin Walters 2016-02-08 14:49:46 UTC
I'd prefer if it was VARIANT_ID=atomichost for the same reason as it's "Atomic Host" in VARIANT.

Otherwise, yes.

Comment 28 Stephen Gallagher 2016-02-08 14:51:18 UTC
(In reply to Charlie Drage from comment #26)
> VARIANT="Fedora 23 (Atomic Host)"
> VARIANT_ID=atomic
> 
> Can this be consistent across all platforms however? (ex. server vs
> workstation vs atomic, etc.)

Could you clarify this? I'm not sure what you're asking to be consistent.

We already have:

VARIANT=Server Edition
VARIANT_ID=server
PRETTY_NAME=Fedora 23 (Server Edition)

So I assume what we'd be looking for here is

VARIANT=Atomic Host
VARIANT_ID=atomic
PRETTY_NAME=Fedora 23 (Atomic Host)

Are you asking for something different related to a hypothetical Atomic Server Edition (or Workstation)?

Comment 29 Charlie Drage 2016-02-08 16:19:33 UTC
(In reply to Stephen Gallagher from comment #28)
> (In reply to Charlie Drage from comment #26)
> > VARIANT="Fedora 23 (Atomic Host)"
> > VARIANT_ID=atomic
> > 
> > Can this be consistent across all platforms however? (ex. server vs
> > workstation vs atomic, etc.)
> 
> Could you clarify this? I'm not sure what you're asking to be consistent.
> 
> We already have:
> 
> VARIANT=Server Edition
> VARIANT_ID=server
> PRETTY_NAME=Fedora 23 (Server Edition)
> 
> So I assume what we'd be looking for here is
> 
> VARIANT=Atomic Host
> VARIANT_ID=atomic
> PRETTY_NAME=Fedora 23 (Atomic Host)
> 
> Are you asking for something different related to a hypothetical Atomic
> Server Edition (or Workstation)?

Ah yeah, sorry, I meant a hypothetical Atomic Server edition (possibly not workstation, although there is another OS out there which wants to go that route...) 

I'd prefer VARIANT_ID to be "atomic" in my opinion. Code-wise would be better to grep when implementing atomic host support in ansible / docker-machine / chef, etc.

Comment 30 Colin Walters 2016-02-12 15:18:26 UTC
(In reply to Charlie Drage from comment #29)

> I'd prefer VARIANT_ID to be "atomic" in my opinion. Code-wise would be
> better to grep when implementing atomic host support in ansible /
> docker-machine / chef, etc.

Why VARIANT_ID=atomic and not VARIANT_ID=atomichost ?

Comment 31 Jan Kurik 2016-02-24 13:21:46 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 32 Stephen Gallagher 2016-03-08 11:43:31 UTC
Just a reminder, I'm still waiting for a clear answer on what this should look like. It's probably not going to make F24 Alpha at this point.

Comment 33 Charlie Drage 2016-03-08 16:45:54 UTC
In my opinion the variant_id should be "atomic". It's be good for parsing and as of right now I don't think there are any other products that use the "atomic" ID that's significantly different than Project Atomic hosts.

What Stephen Gallagher said previously I 100% agree with:

VARIANT=Atomic Host
VARIANT_ID=atomic
PRETTY_NAME=Fedora 23 (Atomic Host)

If anyone else has some input please say!

Comment 34 Colin Walters 2016-03-08 16:53:43 UTC
(In reply to Charlie Drage from comment #33)
> In my opinion the variant_id should be "atomic". It's be good for parsing
> and as of right now I don't think there are any other products that use the
> "atomic" ID that's significantly different than Project Atomic hosts.

https://fedoraproject.org/wiki/Workstation/AtomicWorkstation

Comment 35 Colin Walters 2016-03-08 16:54:35 UTC
The other reason to use atomichost is that there are *many* things now under the Project Atomic banner that are not Atomic Host.

Comment 36 Stephen Gallagher 2016-03-08 18:13:05 UTC
What I am going to do is generate /usr/lib/os-release with the following content:

VARIANT=Atomic Host
VARIANT_ID=atomic.host
PRETTY_NAME=Fedora 24 (Atomic Host)

This VARIANT_ID should be very easy to parse while still offering a secondary mark to denote a particular Atomic project (in this case, Atomic Host).

Comment 37 Charlie Drage 2016-03-08 18:42:23 UTC
Will changes to usr/lib/os-release be noted in etc/os-release as well?

Comment 38 Zbigniew Jędrzejewski-Szmek 2016-03-08 18:47:46 UTC
It's a symlink to /usr/lib/os-release.

Comment 39 Fabian Deutsch 2016-03-08 18:48:50 UTC
Stephen, I've already seen dashes (-) in VARIANT_ID, but not dots.
This might sound nit picky, but what about replacing the dot with a dash ..

Comment 40 Stephen Gallagher 2016-03-08 18:52:11 UTC
From the os-release(5) manpage:
"""
A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" and "-")
"""

(Which is a little self-referential since I wrote that manpage...)


The dot is fine IMHO and I've already added it to the queue of fedora-release package changes under review here:

https://pagure.io/fedora-release/pull-request/29 (Rawhide/F25)
https://pagure.io/fedora-release/pull-request/30 (F24)

Comment 41 Charlie Drage 2016-03-08 18:56:33 UTC
I'm happy with atomic.host

Makes sense.

As long as the ID differentiates to other Fedora releases (server, workstation, etc.) I'm happy, since that means that tools such as Ansible and docker-machine can now work with determining if the release is an Atomic Host or not.

Comment 42 Jonathan Lebon 2016-07-25 17:08:03 UTC
Cross-linking this here for completeness:
https://pagure.io/fedora-atomic/issue/6

Comment 43 Charlie Drage 2016-08-23 15:44:45 UTC
Could we re-open this as this has yet to still be fixed.

Comment 44 Colin Walters 2016-08-24 17:11:04 UTC
Cross-linking the CentOS implementation: https://github.com/CentOS/sig-atomic-buildscripts/issues/61#issuecomment-242139868


Note You need to log in before you can comment on or make changes to this bug.