[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, 7 months
[cloud] #109: vagrant libvirt images only have 3G disk
by Fedora Cloud Trac Tickets
#109: vagrant libvirt images only have 3G disk
--------------------+--------------------
Reporter: eparis | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords:
--------------------+--------------------
In a conversation with cwalters he said:
ok here's the deal, qcow2 is a thin-provisioned disk format, fedora uses
40GB by default for vagrant
that's defined here: https://pagure.io/releng/blob/master/f/scripts/build-
cloud-images#_68
now where's that 3GB coming from? here: https://git.fedorahosted.org/cgit
/spin-kickstarts.git/tree/fedora-cloud-base-vagrant.ks
that includes https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree
/fedora-cloud-base.ks#n46
that's outside the VM
now inside, cloud-init normally starts and uses "growpart" early on boot
except in vagrant, it's disabled because hardcoded ssh keys and stuff
so typing: growpart /dev/vda 1
then resize2fs /dev/vda1
i'd say this is really a fedora build system bug - the kickstart should
match the qcow2
it's a one liner fix to spin-kickstarts
-----
So while his commands work I couldn't find a way to get them in early
enough to solve my disk space usage problems. But something is wrong when
vagrant+libvirt images are only 3G and don't auto-grow, for sure.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/109>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
8 years, 7 months
Fedora Cloud website ideas?
by Máirín Duffy
Hi :)
Since Atomic will be the primary focus of this WG (F24+,) the
presentation of the Atomic and cloud images on the main Fedora website
should be updated to reflect that. (See [1] and [2].)
Last week, Matthew and I talked about how we might do this; the idea we
thought might work best is the following:
--
- Consider replacing the “Cloud” edition slot on the front of
getfedora.org with a Fedora “Atomic” edition brand.
- Convert getfedora.org/cloud to focus instead solely on Atomic (maybe
redoing the URL to getfedora.org/atomic.
- Build out a separate cloud image resource site (similar to
arm.fedoraproject.org, which is focused on all ARM-related builds across
Fedora) with the full set of Cloud Base images (and maybe Fedora Docker
containers too?) Then, pull these in to the Atomic edition site via a
link in the “Other Downloads” section. (cross link back to atomic from
cloud.fpo too.)
--
I find it hard to understand if something like this might work without
visuals, so I put together a (very, super-duper, fantastically rough)
mockup for this new cloud.fedoraproject.org:
https://github.com/fedoradesign/fedora-spins/blob/master/cloud/cloud-mock...
I pretty much just threw it into the arm.fpo template; it's quite a bit
more cluttered in terms of instructions / explanation needed for various
image types than arm.fpo, so I think the layout should be reconfigured
quite a bit to get rid of the cluttered feel.
That being said -
- Do you think a site like this for the base cloud images would work
well, given enough prominence on the main Fedora website as well as the
Atomic product site? Is this the kind of list of images/AMIs a cloud
image user is going to find most helpful?
- Should the docker image live on here? Or would that be better served
by a more generic 'other images' site for Fedora images?
- Is the installable image a cloud base image or an atomic image? Who
would use it and why? Does it belong here as well?
~m
[1]
https://lists.fedoraproject.org/pipermail/cloud/2015-September/005832.html
[2] http://blog.linuxgrrl.com/2015/09/15/fedora-atomic-logo-idea/
8 years, 7 months
Fedora 23 cloud image (and, for that matter, minimal anything) bloat
by Matthew Miller
Fedora-Cloud-Base-20141203-21.x86_64.qcow2: 151M
Fedora-Cloud-Base-23_Beta-20150915.x86_64.qcow2: 275M
In just one year — 82% more awesome?
I'd really like this to stay below 200MB as a competitive threshold.
Or, if we're going to be bigger than that, be bigger for REASONS, not
just accretion.
tl;dr: grub2 is a lot to blame, but there seem to be some new
questionable dep chains from systemd, and general dep growth across the
board.
Disk use at first boot:
[f21]$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 359M 19G 2% /
[f23b]$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 578M 19G 4% /
RPMs installed:
[f21]$ rpm -qa | wc -l
226
[f23b]$ rpm -qa | wc -l
264
Top 20 rpms by reported size:
$ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
120417342 glibc-common
42307839 kernel-core
25000497 python-libs
22438155 systemd
14623272 coreutils
14000291 glibc
11282056 ruby-libs # hey, at least we lost this
10845519 glib2
10593004 selinux-policy-targeted
9389116 cracklib-dicts # https://bugzilla.redhat.com/show_bug.cgi?id=865521
9078043 python-boto
8792531 util-linux
7084188 bash
6669884 gnupg2
5844544 yum
4893790 policycoreutils
3786564 file-libs
3540004 shadow-utils
3458312 groff-base # who doesn't love groff?
2997717 tar
$ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
125195206 glibc-common
86298752 linux-firmware # sadface, but hard
53291365 kernel-core
36004297 grub2-tools # this is ridiculous
28453336 python3-libs # 13% growth
27233273 systemd # 21% growth
16648994 grub2 # *sigh*
14486819 glibc
14287847 coreutils # this package got _smaller!_
11143743 glib2
11129880 selinux-policy-targeted
9389116 cracklib-dicts
9261499 python3-boto
9237998 util-linux
9224255 fedora-logos # this is also grub's fault.
7517574 gnupg2
7143418 bash
6574678 python3-pip # :(
5888883 hwdata # this is ALSO grub's fault
5423400 xkeyboard-config # really???? looks like a systemd dep chain
involving plymouth
Okay, let's look on disk:
[f21]$ sudo du -sh * 2>/dev/null|sort -h
[...]
36K home
40K root
228K run
21M boot
22M etc
34M var
276M usr
[f23b]$ sudo du -sh * 2>/dev/null|sort -h
[...]
40K root
264K run
16M etc
45M boot # ugh
171M var # oww
463M usr # oww oww oww
Breakdown:
- boot is mostly grub, but initramfs is also doubled
- var: DNF cache is full of stuff! 123M... oh, hey, that wasn't
there when we booted. `df -h /` is now up to 702M. Maybe multiple
repos would help here, or some other more clever design. Does
every cloud image in the world _really_ need to replicate
dependency data so I can `dnf install
/usr/share/minetest/builtin/mainmenu/init_simple.lua`?
- usr:
* linux-firmware is the biggest thing here
* python3 is another good chunk
* also kernel modules, but, eh, whatchagonnado
* oh, and of course, grub2.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 7 months
two-week atomic status update
by Matthew Miller
Update on
https://fedoraproject.org/wiki/Changes/Two_Week_Atomic
Status update:
1. Images are produced nightly
- uh, right now, F23 image seems like it might be broken
2. Testing system works and is waiting to go into production
- open questions on vagrant and openqa, but those have made progress
- Kushal is going to work on getting this into production next week
3. Adam estimates a day for getting release engine into production
after that
4. And then some time from Ralph and Robyduck to integrate into website
Note: Because Cloud WG voted to aim focus change to Atomic as
post-23, this will go on
https://getfedora.org/en/cloud/download/atomic.html rather than on
new https://getfedora.org/en/atomic/.
So, right now:
Plan A: at F23 release, have images produced via this Two-Week Atomic
be what's shown on that getfedora download page, rather than the images
from the general gold compose ("traditional")
Plan B: at F23 release, use the images from the traditional compose.
Switch to Two-Week images two weeks later.
Colin says that the Atomic dev team is good with switching to F23 as
the base at F23 release -- no known need to lag.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 7 months
Agenda item proposal -- Explore the possibilities of SCAP for the benefits of Fedora Cloud WG (whole Fedora)
by Jan Lieskovsky
Hello folks,
(not sure this is the expected way how to propose a new meeting agenda item
for some of the future WG meetings. If not, kindly point me to the right way.
Thanks).
Would like to propose item -- explore the possibilities of SCAP for the
benefits of Fedora Cloud WG
Purpose of the meeting:
* we would like to introduce the SCAP Security Guide project / OpenSCAP ecosystem
to the WG (the set of packages we are currently working at),
* issues (related with functionality provided by the WG) we see
right now when developing SCAP content,
* proposal for possible cooperation -- in order to be able to enhance
the list of rules applicable for the Cloud product, we would like to:
* hear Fedora Cloud WG expectations on the content,
* share our expectations on the content && get feedback on them,
* maybe set up a way for more close cooperation
Our expectation is to present short slides (introduce SCAP to the WG,
what's already done, what we would like to implemented yet, would like
to hear your feedback on those, and areas where we need input from the
WG in order to progress better / more quickly [mainly related with which
tasks to prioritize etc.]).
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
8 years, 7 months
