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'
(What I don't get here is why you couldn't allow atomic to
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,
- 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
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
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
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
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
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
>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
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.
Fedora Project Leader