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

[Matthew Miller]

On Wed, Jun 17, 2015 at 12:25:09PM -0400, Máirín Duffy wrote:
> 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)

True.

> (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.)

That could be done. As I see it, the concerns are:

- the Atomic releases will be significantly more experimental and less
stable, and it seemed like another page would communicate that more
clearly. (For example, we expect that they will be released with no
human testing, while careful human testing is a hallmark of Fedora
release to date.)

- Having deliverables with different refresh/update policies on the
same page also seemed confusing.

If you think that having this all together on the cloud page is less
confusing after all, 

Additionally: 

- The plan calls for automatic update of some of the page content. I
don't know if that fits into the workflow by which getfedora.org is
updated.

> 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)

Yeah, I think that's fair, although in the pets-vs-cattle distinction,
Atomic Host _should_ be always cattle, and therefore I don't think an
aura of cloudiness is bad. (See my message you linked below.)

> 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)

We are definitely making a lot of this up as we go along. Atomic is
based on several different underlying technologies, including
rpm-ostree. We might use that tech in other editions, but it's unclear
if the result should also be branded "Atomic", or if Atomic is really
meant to apply specifically to the specific container-host pattern (Joe
Brockmeier can probably better speak to this).


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

I'm going to bracket that as a deep dive for later, yeah. :)


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

*Nod* — yeah, I'm definitely open to this.

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

I think, in general, the Fedora cloud community would like to see
Atomic prove itself a little more before making that commitment. But,
the way we were doing it (in the larger sense, not just the web page)
wasn't working — ending up with a deliverable not useful to the
developers and early adopters _or_ to real users, and so not really
advancing towards proving itself.

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

Yes, there's absolutely a lot more to it than the website.


> 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?

"Are you comfortable with the traditional Linux distribution model and
want to build on top of a lightweight image with all of the advantages
of Fedora, including reliable, up-to-date components and a huge library
of RPMs? Fedora Cloud Base. Or, are you interested in experimenting
with next-generation of OS technology, where everything is
containerized? Fedora Atomic Host."

> >>4) Would Docker images continue to live on getfedora.org/cloud?
> >Bear with me a minute here for some exposition. :)
[...]
> 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?

Yes — although they are different at the lowest level, once they're in
the registry they've basically treated the same. Most users don't care;
it's only distributions who have to worry about it, really, because we
have to make the base image. (A layered image can be derived from any
other image.)


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

No, to the contrary, it's nice to have a fresh perspective.

-- 
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader