[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
Fedora 22 is out, Fedora 23 is coming :)
by Kushal Das
Hi,
Thank you everyone for a great Fedora 22 release. Things are stable now,
before we can understand we will be in the alpha freeze for Fedora 23.
So this is a good time to start working on the new features list for Fedora
23. 23rd June is the last date to submit a new system wide change
for Fedora 23, 11th August is the alpha release for Fedora 23.
Below I have written few points which came up in different discussions.
Please feel free to comment/add/delete in this thread.
* Better user documentation for cloud. We need something better than
wiki.
* Notification of pending updates in the base image. After login the
user should get a motd message saying which all updates are pending (I
have worked on this part time before).
* Reduce the base cloud image size (we also have
https://fedorahosted.org/fedora-badges/ticket/378 )
* testCloud (pushed back from Fedora 22 change list).
* https://github.com/vmware/tdnf this might help us to go another step
closer to remove Python stack from the cloud image.* Having a better
* workstation to cloud story (came up in the last week's meeting).
Kushal
--
Fedora Cloud Engineer
CPython Core Developer
Director @ Python Software Foundation
http://kushaldas.in
8 years, 9 months
ANNOUNCE: Oz 0.14.0 release
by Chris Lalancette
All,
I'm pleased to announce release 0.14.0 of Oz. Oz is a program
for doing automated installation of guest operating systems with
limited input from the user. Release 0.14.0 is a bugfix and feature
release for Oz. Some of the highlights between Oz 0.13.0 and 0.14.0
are:
* Fix a bug in checksum checking (this should work again)
* Add a global lock around pool refresh; should get rid of a
user-visible failure
* Support for Debian 8
* Support for Ubuntu 15.04
* Support for Fedora 22
* Support for installing aarch64 guests
* Support for installing POWER guests
* Support for install arm 32-bit guests
A tarball and zipfile of this release is available on the Github
releases page: https://github.com/clalancette/oz/releases . Packages
for Fedora-21, Fedora-22, EPEL-7, and EPEL-6 have been built in Koji and will
eventually make their way to stable. Instructions on how to get and
use Oz are available at http://github.com/clalancette/oz/wiki .
If you have questions or comments about Oz, please feel free to
contact me at clalancette at gmail.com, or open up an issue on the
github page: http://github.com/clalancette/oz/issues .
Thanks to everyone who contributed to this release through bug reports,
patches, and suggestions for improvement.
Chris Lalancette
8 years, 10 months
draft of Every-two-week Fedora Atomic Host change proposal
by Matthew Miller
Fun fact — you can't use "biweekly" in any useful way, because it means
both once every two weeks *or* twice a week. So dumb. I guess I could
have said "fortnightly", but Atomic is supposed to conjur futuristic,
sciency images, not Ren Faire.
Anyway, a draft for your feedback, commentary, and etc.:
https://fedoraproject.org/wiki/Changes/Two_Week_Atomic
It's a wiki, so feel free to just fix any blatent tyops or whatnot, and
*definitely* feel free to sign up as a co-owner for any part of the
work you'd like to help with or take responsibility for. You'll note
that I signed myself up for "cheerleading", so that's taken... we'll
need people to sign up for actually doing stuff, too. :)
(I'm going to post this to the atomic-devel list at Project Atomic,
too. Note that in the change proposal I suggested using that as the
contact email for the change — that's not meant to exclude any of the
awesome people here, but I figured if we're breaking this out from the
main Fedora Cloud edition, it made sense for it to have its own list,
and rather than invent a new one, decided to point to the existing one.
If people here think something else would be better, that's fine with
me!)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 10 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
