#65: crucial questions on Docker image deliverable
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 21 (Branch)
Component: Docker Base Container | Keywords: meeting
Adam W asks some excellent questions here:
> What "Fedora" exactly is the image going to contain? Fedora Server?
> Fedora Cloud? Will it be a part of either of those products? If not,
> what is its status, exactly? Who's responsible for it? Is it considered
> a primary or frontline or whatever Fedora deliverable? Who's going to
> test it? How's it going to be promoted in relation to all our other
I gave some tentative answers, but let's get them answered definitively.
Ticket URL: <https://fedorahosted.org/cloud/ticket/65>
Fedora Cloud Working Group Ticketing System
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2014-08-01 from 17:00:00 to 18:00:00 UTC
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup.
I was originally including Cockpit in
but rel-eng raised the concern that
is only listed for Server. Should we include it in Cloud too? Right
now it's promoted as part of the Project Atomic, so I think it'd make
sense to include there.
Perhaps a relevant difference here is that Cloud is more often treated
as cattle instead of pets - disposable stateless systems managed as a
group, and thus there's less need to configure things node by node.
Even then though, Cockpit offers visualization on a per-node level.
Trying to get ahead of the Change process this time =)
I'd like to move Atomic under the Server WG as I feel it's a more
appropriate home for Fedora 22, with the increased scope to bare metal
installation. (Really it crosses both as Atomic should run in all the
clouds that mainline does, but I see Cloud as a specialization of Server
I started a Change page here:
Comments (and improvements to the Change proposal) are appreciated.
So, basically, we have these files:
No need for these. We can delete them... right?
Maybe these should go in /etc/sysconfig
Modify these so they point to /usr/share/google-daemon if possible.
Move these to /usr/share/google-daemon
I'll show a spec in a little while.
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
Ok, I have a working recipe. Check it out:
I am using:
oz-install -d3 -t 10000 f20.tld
oz-customize -d3 f20.tld f20<date>
Tu generate and customize.
It is missing some of the security points:
- root still has a password
- root is not locked
- root can login with a key
- ssh by password is not disabled.
I am waiting for the google packages to be ready so I can lock root
and all. It should be easy to do those things once they're done.
+Felipe, let me know if you need help with anything.