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
--
websites mailing list
websites@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/websites
