[Design-team] new Fedora Atomic sub-site - help wanted

Wed Jun 17 16:25:09 UTC 2015

On 06/17/2015 11:46 AM, Matthew Miller wrote:
> See <https://fedorahosted.org/cloud/ticket/96> for some
> background.

The rationale I'm seeing in the links (just to reiterate to make sure 
I'm getting it right):

1) There are tools that don't work with atomic, so atomic installs need 
to identify themselves as 'atomic' so that the tools that don't work 
aren't included with it and we don't ship 'broken' bits. However, those 
tools that break it don't necessarily break 'cloud' images. 
(https://bugzilla.redhat.com/show_bug.cgi?id=1200122)

(What I don't get here is why you couldn't allow atomic to identify 
itself as 'atomic' or even 'cloud-atomic,' have the non-atomic images 
identify themselves as cloud, and ship the atomic images on the 'cloud' 
page.)

2) There are people who would like to use atomic tech outside of the 
container host use case, eg workstation labs, so coupling atomic tightly 
to cloud could cause confusion 
(https://bugzilla.redhat.com/show_bug.cgi?id=1200122)

Maybe. Or you could roll out atomic images to the other editions in a 
similar manner they've been rolled out on the cloud page, just follow 
the same format when (if that's planned) they are available.

3) Atomic was meant to be an option for *any* of the editions, not just 
cloud, so it shouldn't be coupled with cloud 
(https://lists.fedoraproject.org/pipermail/cloud/2015-March/004996.html)

I wish I knew a little bit more about the problems atomic solves and why 
we don't have atomic versions for all of the editions already and 
whether or not they are in the plan and who would use them for what 
(although I am assuming that is a deep dive.)

> My basic mental model here is that the Fedora Atomic Host is something
> like a Spin rather than an Edition, except different from the normal
> expectations for Spins, too — and definitely doesn't fit into the shiny
> new Spins page, which focuses on alternate desktop environments. And it
> doesn't seem fit into the Labs model either, since it doesn't have
> featured applications (unless you count the "atomic" command).

For what it's worth, I don't think having featured applications is a 
requisite for being on the Labs page. That section of the page can be 
focused however is needed for Atomic if it were to be a Lab spin.

> So, that's why I was thinking "whole new page".

The problem with this as a solution is that there is a real cost to 
spinning up a whole separate custom site rather than fitting it into the 
framework that's already been built out - for example, any future 
upgrades done to the sites we already have in place are going to have to 
be done custom to this new site or this new site won't get those 
upgrades for free and may become more dated (as in design / style / 
adherence to the general fedora websites presence look/feel) compared to 
the others. (I do want to contrast this with taking a domain like 
'kde.fpo' and pointing it to a spin page - that's no issue, it's not 
adding a lot of overhead since it's providing a more convenient URL to 
something that's been fit into the site divisions that were established 
instead of creating something new and separate.)

What I don't see in any of the background reading is a real clear 
problem statement driving the decision. What is the exact problem to be 
solved - it seems nebulous? There seems to be reluctance in setting a 
strong direction for cloud edition / story for how atomic fits into 
Fedora in general. At least in what I've read. We should figure out a 
direction and commit to it.

Before spinning up another site I'd advise some kind of one-off 
deep-dive discussion about problem statements / goals here to try to 
come up with the best solution. I'm getting the feeling spinning up a 
new atomic.fpo is going to be a band-aid on something bigger that needs 
to be addressed.

>> 3) Stepping back from even the specifics of the Fedora Cloud edition
>> story in particular - are we separating "cloud" from "containers"
>> somehow here? For users coming to Fedora with an interest in cloud,
>> is atomic.fpo going to be something they will want to know about?
>> For users coming to Fedora with an interest in containers, is Fedora
>> Cloud Edition (non atomic images) something of interest to them? Are
>> they going to be confused picking up docker images from
>> getfedora.org and atomic images from atomic.fpo?
>
> In order: maybe (and that's possibly problematic), yes, yes, and I hope
> not.
>
> I'm definitely willing to reconsider this, and I think the Cloud SIG
> would be open to consideration too — we could scrap basically
> everything I said for your #1 and #2 and fit this into
> <https://getfedora.org/en/cloud/download/atomic.html>

I think splitting two related resources into different websites is going 
to be problematic for the user experience here, based on how you've 
answered above, although I don't fully understand the type of users 
we're targeting either (I have just never done contextual interviews / 
etc with them.)

I still don't understand what the story would be for these users to 
guide them to the disparate websites to get the resources they needed. 
If you were in an elevator with a cloud developer, how would you explain 
it to them so they could try it out?

>> 4) Would Docker images continue to live on getfedora.org/cloud?
>
> Bear with me a minute here for some exposition. :)

much appreciated :)
>
> There are fundamentally two kinds of Docker images: base images, and
> layered images. Base images are created outside of Docker and are the
> underlying building blocks. Layered images are derived from those base
> images, using a Dockerfile to add additional content and configuration.
>
> Right now, we produce official base images, and layered images are
> somewhat in limbo — we produce Dockerfiles which can be used to making
> layered images as part of the fedora-docker package, but don't have any
> real mechanism for building the layered images officially.
>
> That's planned to change with
> <https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service>
> — this is the same tech Red Hat is using internally, and we're working
> to bring it into the open.
>
> The resulting layered images will be, in some ways, very like RPMs —
> although they're in fact constructed from RPMs, each one has a
> name-epoch-version-release, and we'll track contents for security
> updates and etc.
>
> So.... what's the relevance here? Basically, like individual RPMs,
> these aren't something we really want a download page for. They're,
> instead, something you obtain/launch with the atomic or docker
> commands, just like you'd obtain RPMs with DNF or applications with
> GNOME Software.
>
> However, in order to get to that future vision, we need the layered
> build service change, *and* a future change where we run our own
> registry (or else an agreement to make the upstream Docker hub our
> official distribution system). So that's some way off, and in the
> meantime, we need a place to present that. I don't know what the right
> answer is, honestly.

Okay so at some point we need a web presence for the registry (if end up 
needing to create our own) and it'd make sense for the base image to 
live there too?

>> 5) Do you want cross-referencing between the sites, eg getfedora.org
>> references atomic.fpo (I'm guessing on getfedora.org/cloud?? and
>> maybe in the footer?) and atomic.fpo references getfedora.org (i'm
>> guessing to getfedora.org/cloud??)
>
> Yes, I think so.
>
>> I probably have a lot more questions but they'd depend on the above answers.

Does the above make sense or my behind-ness on container-foo make me 
kind of useless at helping here?

~m