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

[Colin Walters]

We should be consistent with the cloud image kickstart,
which uses `fedora-atomic`.

Note this string actually appears in the user interface and may be
typed by the admins, so the shift key gymnastics required by the
previous value are more painful than just having it in a URL or the
like.
---
 scripts/run-pungi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

[Dennis Gilmore]

On Saturday, April 25, 2015 11:09:10 AM Colin Walters wrote:
>  We should be consistent with the cloud image kickstart,
>  which uses `fedora-atomic`.
>  
>  Note this string actually appears in the user interface and may be
>  typed by the admins, so the shift key gymnastics required by the
>  previous value are more painful than just having it in a URL or the
>  like.
>  ---
>   scripts/run-pungi | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-) 
nak,

we should rename the kickstart if you want consistency. we base the name of 
things on 
https://fedoraproject.org/wiki/User:Adamwill/Draft_fedora_image_naming_po...  
which we really should move elsewhere, as atomic is a subproduct of the Cloud 
product it has to have Cloud in the name.

Dennis

[Colin Walters]

On Sat, Apr 25, 2015, at 12:16 PM, Dennis Gilmore wrote:

>  we should rename the kickstart if you want consistency. we base the
> name of 
>  things on 
>  https://fedoraproject.org/wiki/User:Adamwill/Draft_fedora_image_naming_po...   
That policy is about image names - and I'm OK with it for images.  The OSTree
"osname" is an entirely different thing.

Imagine if that policy was used for e.g. yum repository names - something an
administrator types and appear often in the in-machine UI.  I think you'd get
some pushback.

[Colin Walters]

On Sat, Apr 25, 2015, at 12:16 PM, Dennis Gilmore wrote:

> https://fedoraproject.org/wiki/User:Adamwill/Draft_fedora_image_naming_po...   
These aren't image names so much as they're *namespace prefixes*.  The
ref prefix is strongly analogous to the `fedora/` prefix on the Docker Hub
for the base image. 

If the Docker image were changed to be a product
of the Cloud group, and we changed the Docker name to be:
`Fedora-Cloud_Docker` or something, it would *really* stick out as
strange on the Hub.

Many things use what Sourceforge calls "unix names" style:
http://sourceforge.net/p/forge/documentation/Renaming/
such as package names, yum repository IDs, usernames,
Docker image names, etc. etc.  The OSTree "osname" is
intended to be in this style.

Given that it's a namespace, the simplest would just be `fedora`,
like the Docker image name.  But failing that, the current
`fedora-atomic` is very much preferable over introducing
a "product naming style" where "unix names" are expected.

Does that explain things better?  Thanks!

[Colin Walters]

Hi,

On Sun, Apr 26, 2015, at 08:27 AM, Colin Walters wrote:

>  Does that explain things better?  Thanks! 
I know there's a lot going on, but I'm wondering if this patch
is still in the queue for review by someone, based on the above
explanation.

Thanks!

[Dennis Gilmore]

On Tuesday, April 28, 2015 12:56:46 PM Colin Walters wrote:
>  Hi,
>  
>  On Sun, Apr 26, 2015, at 08:27 AM, Colin Walters wrote:
>  > Does that explain things better?  Thanks!
>  
>  I know there's a lot going on, but I'm wondering if this patch
>  is still in the queue for review by someone, based on the above
>  explanation. 
It his not in queue for review. the os name should match the image name.

Dennis

[Adam Miller]

On Sun, Apr 26, 2015 at 7:27 AM, Colin Walters <walters(a)verbum.org&gt; wrote:
>  On Sat, Apr 25, 2015, at 12:16 PM, Dennis Gilmore wrote:
>
> > https://fedoraproject.org/wiki/User:Adamwill/Draft_fedora_image_naming_po...
>
>  These aren't image names so much as they're *namespace prefixes*.  The
>  ref prefix is strongly analogous to the `fedora/` prefix on the Docker Hub
>  for the base image.
>
>  If the Docker image were changed to be a product
>  of the Cloud group, and we changed the Docker name to be:
>  `Fedora-Cloud_Docker` or something, it would *really* stick out as
>  strange on the Hub.
>
>  Many things use what Sourceforge calls "unix names" style:
>  http://sourceforge.net/p/forge/documentation/Renaming/
>  such as package names, yum repository IDs, usernames,
>  Docker image names, etc. etc.  The OSTree "osname" is
>  intended to be in this style.
>
>  Given that it's a namespace, the simplest would just be `fedora`,
>  like the Docker image name.  But failing that, the current
>  `fedora-atomic` is very much preferable over introducing
>  a "product naming style" where "unix names" are expected.
>
>  Does that explain things better?  Thanks! 
For what it's worth I think this makes sense. By framing ostree naming
as something analogous to yum repositories or docker hub registry
entries I think it makes sense to follow the "unix names" style in
some respect. What this will look like within the release tooling, I
don't know the details of just yet, but I think from an user
perspective the name change is a logical choice.

-AdamM

>  _______________________________________________
>  rel-eng mailing list
>  rel-eng(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/rel-eng

[Colin Walters]

On Fri, May 1, 2015, at 10:28 AM, Dennis Gilmore wrote:
>  On Tuesday, April 28, 2015 12:56:46 PM Colin Walters wrote:
>  > Hi,
>  > 
>  > On Sun, Apr 26, 2015, at 08:27 AM, Colin Walters wrote:
>  > > Does that explain things better?  Thanks!
>  > 
>  > I know there's a lot going on, but I'm wondering if this patch
>  > is still in the queue for review by someone, based on the above
>  > explanation.
>  
>  It his not in queue for review. the os name should match the image name.\ 
After discussion with Adam W,
https://fedoraproject.org/wiki/User:Adamwill/Draft_fedora_image_naming_po...
is now updated to explicitly state that the policy is not normative for
OSTree "osname"s (or other things like yum repo IDs, Docker image names, etc).

I feel like my "vote" as the upstream author of OSTree (with designs for how it
should be used)
and as one of the primary maintainers of this specific content set is
not being respected.  

I'm absolutely willing to have a discussion here - we could change the identiifer
to something other than "fedora-atomic" - for example, it would be consistent
with the Docker base image if it was simply fedora/.  

For convenience I've reattached the patch.  Thanks!

[Matthew Miller]

On Tue, May 05, 2015 at 08:17:08AM -0400, Colin Walters wrote:
>  Note this string actually appears in the user interface and may be
>  typed by the admins, so the shift key gymnastics required by the
>  previous value are more painful than just having it in a URL or the
>  like. 
As a previous sysadmin, this rationale alone makes sense to me. :)

I understand the idea for post-f22-release is to move Atomic to being
outside of the Cloud edition per se, into... well, into something we
haven't done before, like a spin but respun every two weeks. (Possibly
need a new term for that.) So dropping the Cloud name makes sense from
that point of view as well.

I think, mostly, Dennis wants consistency and traceability from one
point back to its origin. (Dennis, is that fair/correct?) Are we losing
any of that with this change?

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

[Dennis Gilmore]

On Tuesday, May 05, 2015 05:09:16 PM Matthew Miller wrote:
>  On Tue, May 05, 2015 at 08:17:08AM -0400, Colin Walters wrote:
>  > Note this string actually appears in the user interface and may be
>  > typed by the admins, so the shift key gymnastics required by the
>  > previous value are more painful than just having it in a URL or the
>  > like.
>  
>  As a previous sysadmin, this rationale alone makes sense to me. :)
>  
>  I understand the idea for post-f22-release is to move Atomic to being
>  outside of the Cloud edition per se, into... well, into something we
>  haven't done before, like a spin but respun every two weeks. (Possibly
>  need a new term for that.) So dropping the Cloud name makes sense from
>  that point of view as well.
>  
>  I think, mostly, Dennis wants consistency and traceability from one
>  point back to its origin. (Dennis, is that fair/correct?) Are we losing
>  any of that with this change? 
correct.  at the moment it is really unknown. at this
point in the release 
cycle I am extremely change adverse. I want to avoid anything that has the 
potential to cause a slip in any way shape or form.

Dennis

[Colin Walters]

On Tue, May 5, 2015, at 05:18 PM, Dennis Gilmore wrote:

>  correct.  at the moment it is really unknown.  
it = risk?
it = "traceability"?

>  at this point in the release 
>  cycle I am extremely change adverse. I want to avoid anything that has the 
>  potential to cause a slip in any way shape or form. 
But...currently Atomic is non-blocking, and if somehow this change were
to break generating the installer, it's a matter of...something like the attached
patch?

[Dennis Gilmore]

On Tuesday, May 05, 2015 06:19:23 PM Colin Walters wrote:
>  On Tue, May 5, 2015, at 05:18 PM, Dennis Gilmore wrote:
>  > correct.  at the moment it is really unknown.
>  
>  it = risk?
>  it = "traceability"? 
Both

>  > at this point in the release
>  > cycle I am extremely change adverse. I want to avoid anything that has the
>  > potential to cause a slip in any way shape or form.
>  
>  But...currently Atomic is non-blocking, and if somehow this change were
>  to break generating the installer, it's a matter of...something like the
>  attached patch? 
we would deal with the failure as it happened. if it failed to
compose when 
the final RC compose completes then it owuld miss the boat for F22 and would 
be completely absent.  we have an integrated process. so there is no do overs 
or makeups. If you are okay with risking missing F22 altogether then we can do 
something.  as I said earlier we can and should be looking now at what changes 
should be getting made for Fedora 23.

Dennis

[Colin Walters]

On Tue, May 5, 2015, at 08:35 PM, Dennis Gilmore wrote:
>  On Tuesday, May 05, 2015 06:19:23 PM Colin Walters wrote:
>  > On Tue, May 5, 2015, at 05:18 PM, Dennis Gilmore wrote:
>  > > correct.  at the moment it is really unknown.
>  > 
>  > it = risk?
>  > it = "traceability"?
>  Both 
I am trying to understand how this identifier relates to "traceability" (which
is a term Matthew mentioned).

>  we would deal with the failure as it happened. if it failed to
> compose when 
>  the final RC compose completes then it owuld miss the boat for F22 and would 
>  be completely absent.  we have an integrated process. so there is no do overs 
>  or makeups. If you are okay with risking missing F22 altogether then we can do 
>  something. 
I am OK with risking missing F22 altogether rather than ship with this string.

>   as I said earlier we can and should be looking now at what changes 
>  should be getting made for Fedora 23. 
Then what was blocking applying this patch for F23?

[Dennis Gilmore]

On Tuesday, May 05, 2015 08:46:15 PM Colin Walters wrote:
>  On Tue, May 5, 2015, at 08:35 PM, Dennis Gilmore wrote:
>  > On Tuesday, May 05, 2015 06:19:23 PM Colin Walters wrote:
>  > > On Tue, May 5, 2015, at 05:18 PM, Dennis Gilmore wrote:
>  > > > correct.  at the moment it is really unknown.
>  > > 
>  > > it = risk?
>  > > it = "traceability"?
>  > 
>  > Both
>  
>  I am trying to understand how this identifier relates to "traceability"
>  (which is a term Matthew mentioned). 
traceability in being able to take that name
and map it back to the image it 
was installed from.

>  > we would deal with the failure as it happened. if it failed to
> compose
>  > when
>  > the final RC compose completes then it owuld miss the boat for F22 and
>  > would be completely absent.  we have an integrated process. so there is
>  > no do overs or makeups. If you are okay with risking missing F22
>  > altogether then we can do something.
>  
>  I am OK with risking missing F22 altogether rather than ship with this
>  string.
>  >  as I said earlier we can and should be looking now at what changes
>  > 
>  > should be getting made for Fedora 23.
>  
>  Then what was blocking applying this patch for F23? 
two reasons, one, we do not make this as part of rawhide, and two we currently 
have no way to enable this change without, it applying to f22 also. 

Dennis

[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.

[Joe Brockmeier]

On 05/05/2015 08:46 PM, Colin Walters wrote:
>  On Tue, May 5, 2015, at 08:35 PM, Dennis Gilmore wrote:
> > On Tuesday, May 05, 2015 06:19:23 PM Colin Walters wrote:
> >> On Tue, May 5, 2015, at 05:18 PM, Dennis Gilmore wrote:
> >>> correct.  at the moment it is really unknown.
> >>
> >> it = risk?
> >> it = "traceability"?
> > Both
>  
>  I am trying to understand how this identifier relates to "traceability" (which
>  is a term Matthew mentioned).
>  
> > we would deal with the failure as it happened. if it failed to compose when 
> > the final RC compose completes then it owuld miss the boat for F22 and would 
> > be completely absent.  we have an integrated process. so there is no do overs 
> > or makeups. If you are okay with risking missing F22 altogether then we can do 
> > something.
>  
>  I am OK with risking missing F22 altogether rather than ship with this string. 
Whoa, really? I think that requires some discussion. A number of folks
are expecting this as part of F22 and if it's a question of "do this and
risk shipping nothing" and "hold off on this change briefly" ... I think
we need to strongly consider holding off. This definitely needs to be
discussed w/the Cloud Working Group.

Best,

jzb
-- 
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/

[Colin Walters]

On Wed, May 6, 2015, at 08:23 AM, Joe Brockmeier wrote:
>  
>  Whoa, really? I think that requires some discussion. A number of folks
>  are expecting this as part of F22 and if it's a question of "do this and
>  risk shipping nothing" and "hold off on this change briefly" ... I think
>  we need to strongly consider holding off. This definitely needs to be
>  discussed w/the Cloud Working Group. 
Fair enough.

[Colin Walters]

On Tue, May 5, 2015, at 09:41 PM, Colin Walters wrote:
>  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
>  ? 
So likely we should pursue expressing the F23 for Atomic as some
sort of variant tag, which is the same way mainline does it.
That way we don't need to overload the OSTree "osname".

>  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. 
And given all of the above, I would really appreciate re-consideration
of the patch.

[Colin Walters]

On Fri, May 8, 2015, at 11:46 AM, Colin Walters wrote:
>  
>  And given all of the above, I would really appreciate re-consideration
>  of the patch. 
And actually, this change broke upgrades from the installer:

error: Remote "Fedora-Cloud_Atomic" not found.

I should have noticed this a lot earlier. The problem is the templates in
spin-kickstarts assume osname == remote name, which is something we should fix.

Please re-review this patch in light of the above and the previous discussion.
Thanks!

[Dennis Gilmore]

On Sunday, May 17, 2015 10:53:40 AM Colin Walters wrote:
>  On Fri, May 8, 2015, at 11:46 AM, Colin Walters wrote:
>  > And given all of the above, I would really appreciate re-consideration
>  > of the patch.
>  
>  And actually, this change broke upgrades from the installer:
>  
>  error: Remote "Fedora-Cloud_Atomic" not found.
>  
>  I should have noticed this a lot earlier. The problem is the templates in
>  spin-kickstarts assume osname == remote name, which is something we should
>  fix.
>  
>  Please re-review this patch in light of the above and the previous
>  discussion. Thanks! 
I pulled it in earlier today. 


Dennis