dnf in Dockerfiles
by Joe Brockmeier
Hey all,
So dgilmore pointed out that f22 docker images will not have yum
installed - which means we need to update the Dockerfiles for f22 to use
dnf and not yum.
We probably ought to go through and sanity-check them all to ensure they
work with the f22 image as well before, say, beta.
I'm CC'ing Scott b/c, if I'm not mistaken, he's done quite a lot of the
work so far on the Dockerfiles - but also, I think he's looking for
assistance there in keeping the effort going.
Best,
jzb
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
7 years, 11 months
[cloud] #88: Social Media for Dockerfiles
by Fedora Cloud Trac Tickets
#88: Social Media for Dockerfiles
-----------------------------------+---------------------
Reporter: jzb | Owner: jzb
Type: task | Status: new
Priority: normal | Milestone: Future
Component: Docker Base Container | Keywords: meeting
-----------------------------------+---------------------
We need to work with marketing to tweet about things regularly. I'd like
to put out regular tweets to promote individual Dockerfiles. Thoughts?
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/88>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
8 years, 1 month
[cloud] #99: AMI lifetimes (Cloud WG members vote needed)
by Fedora Cloud Trac Tickets
#99: AMI lifetimes (Cloud WG members vote needed)
-------------------------------------+-------------------------------------
Reporter: oddshocks | Owner: oddshocks
Type: task | Status: new
Priority: normal | Milestone: Fedora 22
Component: Infrastructure & | Keywords: aws, images, vote,
Release Engineering | policy
-------------------------------------+-------------------------------------
This ticket is to discuss and vote on appropriate lifetimes for Fedora
Cloud AMIs on our official and community cloud accounts, as discussed on
the Cloud SIG list this month[1] and in this week's meeting.
Everyone seems to agree that after a final release, all TC, RC, Alpha,
Beta, and scratch builds should be deleted. This makes sense because
there'd be no reason to use any of these AMIs after the final release.
Still, we need to definitively decide on:
1. When should TC, RC, Alpha, Beta, and scratch builds be deleted? (1)
After a final release? (2) Progressively, when a newer build of the same
type comes out? (3) After a set amount of time, depending on the build
type? Note that with (2) or (3), we'd need some way to mark each build
with it's type. I don't think that necessarily happens now.
2. When should final release AMIs be deleted? (1) After a certain number
of newer final releases? (2) After a certain amount of time? (3) Never?
Also note that if we choose any age-based deletion policies, we'd need to
set up some sort of regular polling of *all* our AMIs on both accounts.
We want to hold as few AMIs at one time as is reasonable. There are many
AMIs created for each image build that happens, so our AWS storage charges
will become quite high if we don't keep our accounts clean. Discuss, and
then perhaps a vote?
[1]:
https://lists.fedoraproject.org/pipermail/cloud/2015-March/005087.html
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/99>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
8 years, 1 month
[cloud] #94: Producing Updated Cloud/Atomic Images
by Fedora Cloud Trac Tickets
#94: Producing Updated Cloud/Atomic Images
------------------------------+---------------------
Reporter: dustymabe | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: Cloud Base Image | Keywords: meeting
------------------------------+---------------------
We need to finalize our policy around producing updated images and then
start doing it.
Right now we have loosely decided to release new images once a month or
whenever security updates require it.
Additionally, as part of this we should also decide on a policy that
determines when we stop updating images for a particular release. I
imagine that we don't want to be producing updated images for Fedora X, Y,
and Z all at the same time. Ideally we would only be producing updated
images for the current/latest major version.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/94>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
8 years, 5 months
[cloud] #105: Missing Cockpit RPMs in Fedora Atomic 22
by Fedora Cloud Trac Tickets
#105: Missing Cockpit RPMs in Fedora Atomic 22
-------------------------------+-----------------------
Reporter: jzb | Owner:
Type: defect | Status: new
Priority: blocker | Milestone: Fedora 22
Component: Docker Host Image | Keywords: meeting
-------------------------------+-----------------------
We seem to be missing the cockpit rpm that includes the systemd files
(e.g. /usr/lib/systemd/system/cockpit.socket).
Can we add cockpit-ws for the next update? We'll probably not be able to
respin the images, but an atomic update can pull in the package.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/105>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
8 years, 6 months
[cloud] #97: Maintaining Fedora docker images for f22
by Fedora Cloud Trac Tickets
#97: Maintaining Fedora docker images for f22
-----------------------------------+-----------------------
Reporter: jzb | Owner:
Type: task | Status: new
Priority: blocker | Milestone: Fedora 22
Component: Docker Base Container | Keywords: meeting
-----------------------------------+-----------------------
f22 docker alpha images were not tested or really looked after afaict.
According to dgilmore we have pulled in server pkgs instead of cloud, and
have cockpit packages coming into the container. That's bad. We need to
see who "owns" testing of the base images.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/97>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
8 years, 9 months
basic plan for two-week atomic images
by Matthew Miller
This is a strawman based on my understanding of current abilities,
available software/systems, and of what the developers want. Please
poke holes, reorder, add and subtract, etc.
Phase I
1. F22 trees built nightly (already happening)
2. Images built from those nightly (I think right now only rawhide?)
3. Images go through automated tests, automatically (tunir; not fully
automatic yet, right?)
4. Every two weeks, latest image to pass those tests gets linked
on atomic.fpo, again all automatically (NEEDS DESIGN AND CODE)
- probably need a manual override
- page will present these images with appropriate setting of
expectations ("fedora qa not to blame for anything here").
- need something to happen if there aren't any that pass for
two weeks, which should not happen I hope, but, y'know)
* automatic message about image being out of date
* next successful image automatically posted? Or do we
skip two weeks?
- also needs: commitment to follow and fix if things break
Phase II
5. Ability to include packages from a side tag, repo, something.
All full, legit Fedora packages destined for main repo but maybe at
a different speed. (Implementation needs work)
- possibly initially just selected packages from updates-testing?
Phase III
6. Something to only expose Atomic users to _update sets_ that pass the
tests (because, hey, we have tests!)
7. Presumably, there will be a switch to F23 as base at F23 release;
will there be overlap (beta images) to make that smooth?
8. What else?
Phase IV
9. Expand tests beyond tunir — test installs on hardware, etc.
10. Maybe create a new, special Fedora repository for packages
with version skew mainline Fedora — e.g. newer systemd
or hold older Docker version for some reasons. (Up for
discussion — that's why this is in phase 3!)
11. More what else?
Does this seem basically sane and in line with what people are
expecting? What's missing? What's extra? What's just wrong? :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 10 months
[cloud] #96: Atomic as separate spin (or, going the other way, main cloud edition)?
by Fedora Cloud Trac Tickets
#96: Atomic as separate spin (or, going the other way, main cloud edition)?
-------------------------+---------------------
Reporter: mattdm | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
-------------------------+---------------------
See https://lists.fedoraproject.org/pipermail/cloud/2015-March/004996.html
I'm wondering if we should consider:
A. Move Atomic out of the Cloud Edition, and treat it as a spin, with a
home at "http://atomic.fedoraproject.org/" (not currently valid),
similar to http://kde.fedoraproject.org — with its own design, theming,
etc.
B. The other way around: double down on Atomic as the primary thing the
Cloud WG releases as the Fedora cloud product. Here, the focus would be
more on containers as the basis for the future of "cattle-style"
scale-out computing, and Atomic as Fedora's cool solution for that.
of course, it's always an option to do
C. Keep as it is, with both options presented as equals for different
cases.
Personally, I like "B" from a high-level Fedora perspective, as it's an
opinionated solution for a target use case. That's what we _want_ for the
Fedora Editions — Wrkstation is a software dev desktop, Server focuses on
role deployment via rolekit and cockpit.
On the other hand, it's a pretty big bet on Atomic, and maybe we're not
ready for that (or collectively don't think that it's the right bet).
"C" would be a more cautious wait-and-see approach.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/96>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
8 years, 10 months
Log from this week's meeting
by Kushal Das
===================================
#fedora-meeting-1: Fedora Cloud SIG
===================================
Meeting started by kushal at 19:00:15 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-05-27/fedora-meeti...
.
Meeting summary
---------------
* Roll Call (kushal, 19:00:23)
* Fedora 22 release (kushal, 19:03:54)
* LINK: https://github.com/cockpit-project/cockpit/wiki/Atomic
(nzwulfin, 19:08:47)
* ACTION: kushal will work to get a -latest.box link up for vagrant
boxes (kushal, 19:12:50)
* ACTION: scollier write blog for using Cockpit container on Atomic /
Fedora 22 (jzb, 19:14:00)
* nzwulfin is reviewing the getting started guide based on the release
(kushal, 19:18:10)
* Fedora 23 (kushal, 19:19:02)
* LINK: https://fedoraproject.org/wiki/Cloud/Cloud_PRD (kushal,
19:21:54)
* Open Floor (kushal, 19:34:55)
* ACTION: everyone start working on an agenda for Cloud WG meeting at
Flock (number80, 19:37:13)
Meeting ended at 19:41:03 UTC.
Action Items
------------
* kushal will work to get a -latest.box link up for vagrant boxes
* scollier write blog for using Cockpit container on Atomic / Fedora 22
* everyone start working on an agenda for Cloud WG meeting at Flock
Action Items, by person
-----------------------
* kushal
* kushal will work to get a -latest.box link up for vagrant boxes
* scollier
* scollier write blog for using Cockpit container on Atomic / Fedora
22
* **UNASSIGNED**
* everyone start working on an agenda for Cloud WG meeting at Flock
People Present (lines said)
---------------------------
* kushal (58)
* roshi (21)
* jzb (20)
* number80 (19)
* sgallagh (16)
* scollier (11)
* dustymabe (11)
* zodbot (8)
* nzwulfin (6)
* adimania (4)
* mattdm (4)
* purpleidea (4)
* oddshocks (3)
* jsmith (2)
* maxamillion (2)
* jbrooks (1)
* stefw (1)
* lsm5 (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Fedora Cloud Engineer
CPython Core Developer
Director @ Python Software Foundation
http://kushaldas.in
8 years, 10 months
