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
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) )
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.
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.
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.
Colin do you want Lokesh to create a atomic-release package?
(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
Colin, so what should we do?
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.
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.).
(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?
(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.
(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?
(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.
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
Colin, is this not the purpose of /etc/system-release-cpe ?
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.
(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.
(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.
(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"
(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.
Any update on this?
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.
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.
It seems this would be a patch to http://pkgs.fedoraproject.org/cgit/rpms/fedora-release.git/
(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.
(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.)
I'd prefer if it was VARIANT_ID=atomichost for the same reason as it's "Atomic Host" in VARIANT. Otherwise, yes.
(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)?
(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.
(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 ?
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
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.
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!
(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
The other reason to use atomichost is that there are *many* things now under the Project Atomic banner that are not Atomic Host.
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).
Will changes to usr/lib/os-release be noted in etc/os-release as well?
It's a symlink to /usr/lib/os-release.
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 ..
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)
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.
Cross-linking this here for completeness: https://pagure.io/fedora-atomic/issue/6
Could we re-open this as this has yet to still be fixed.
Cross-linking the CentOS implementation: https://github.com/CentOS/sig-atomic-buildscripts/issues/61#issuecomment-242139868