[PATCH] run-pungi: atomic: Change the `ostree_osname` to be fedora-atomic

[Colin Walters]

On Tue, May 5, 2015, at 09:05 PM, Dennis Gilmore wrote:
> 
> traceability in being able to take that name and map it back to the image it 
> was installed from.

Thanks!  I appreciate having a more explicit rationale.  

The way you say "map it back" implies that this is something a
downstream user would do.  Do you see
a similar situation with "mainline"?  Do you see this as being addressed
by the `VARIANT` bits from
https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
?

I would say "image it was installed from" is a concept that most strongly
maps to the ostree branch name, i.e. fedora-atomic/rawhide/x86_64/docker-host,
not the "osname".

The branch/tree is equivalent to "set of RPMs from a particular set of yum repos".

The exception here is that one of the entire reasons that we have
a separate installer is to set up different partitioning
https://github.com/projectatomic/fedora-productimg-atomic
by default for Docker (totally unrelated to the core OSTree which is block
storage independent). this is not something that is part of the tree/branch,
but is part of the "image" i.e. the ISO or qcow2.

(Further blurring the lines here is the fact that the tree contains
 docker-storage-setup which is a system to affect the partitioning for Docker)

Anyways, now that you've phrased it that way, it is clear to me that with
that change you are trying to solve a real need.

But we still have a "style mismatch".

In the end, in Fedora today there's only one use of OSTree, one branch,
and only one ostree/docker using installer ISO, and...two images (cloud
and vagrant).  All of these include the same content set and the same
partitioning defaults, although there are important configuration
differences between an install done from an ISO and a cloud image,
such as cloud-init being disabled on the former.

Given the above, I can't imagine that many users are going to find the
binding between the image and osname to be substantially more useful
than "fedora"/"fedora-atomic"/"fedora-cloud-atomic" etc.

I am definitely willing to explore other options to address "traceability".

One thing to note is that of course every installed system will have
/root/anaconda-ks.cfg, which has many advantages for this such as
existing since approximately time began, applying to non-Atomic,
distinguishing between Vagrant and non-Vagrant, etc.