cloud July 2015

cloud@lists.fedoraproject.org

21 participants
75 discussions

[cloud] #109: vagrant libvirt images only have 3G disk
by Fedora Cloud Trac Tickets 23 Sep '15

23 Sep '15

#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

1 3

[cloud] #108: Create text for Fedora cloud Flyer
by Fedora Cloud Trac Tickets 20 Sep '15

20 Sep '15

#108: Create text for Fedora cloud Flyer --------------------+----------------------- Reporter: kushal | Owner: Type: task | Status: new Priority: normal | Milestone: Fedora 22 Component: --- | Keywords: meeting --------------------+----------------------- https://github.com/sanjayankur31/fedora-flyer-cloud We need text for the same. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/108> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 13

[cloud] #113: Ship with firewall on by default
by Fedora Cloud Trac Tickets 09 Sep '15

09 Sep '15

#113: Ship with firewall on by default -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: meeting -----------------------+--------------------- We should most likely be including the iptables-services rpm which start iptables up on system boot and restores rules that represent a "sane default". It has been my experience in the past that the firewall has been configured.. Not sure when the default configuration got moved into a separate rpm but we should restore it. It is easy to configure and poke holes in the firewall (via cloud-init) or some other mechanism so this shouldn't be too big of a deal. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/113> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 3

[cloud] #106: No longer provide 32 bit image
by Fedora Cloud Trac Tickets 09 Sep '15

09 Sep '15

#106: No longer provide 32 bit image ------------------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Cloud Base Image | Keywords: meeting ------------------------------+--------------------- We have discussed this quite a bit in the past. I believe with proper communication we can stop delivering 32 bit cloud images for F23. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/106> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 18

using fstrim to save some space in cloud images
by Dusty Mabe 31 Aug '15

31 Aug '15

Hey all, Have we considered running fstrim against our cloud image filesystems before we package it up? I wrote a small script to do it (inside a container) at [1]. Looks like we can save ~28M: [root@f22 xzimg]# ls -lh ./ total 1.3G -rw-r--r--. 1 root root 3.0G May 22 00:13 orig.raw -rw-r--r--. 1 root root 147M May 22 00:13 orig.raw.xz -rw-r--r--. 1 root root 3.0G Jun 17 16:52 trimmed.raw -rw-r--r--. 1 root root 129M Jun 17 17:21 trimmed.raw.xz [root@f22 xzimg]# du -sh ./* 517M ./orig.raw 147M ./orig.raw.xz 489M ./trimmed.raw 129M ./trimmed.raw.xz [1] - https://gist.github.com/dustymabe/ad4be48c948c2e601b85

4 5

Local DNSSEC resolver & Containers
by P J P 25 Aug '15

25 Aug '15

Hello, -> https://lists.fedoraproject.org/pipermail/cloud/2015-January/004867.html As per the previous discussion above, I was able to use iptables(8) DNAT rule to divert DNS traffic from Docker containers to a DNSSEC resolver on the host at 127.0.0.1:53. Please see: -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#Docker_.2… One needs to enable local 'lo' routing via 'docker0' bridge and add the DNAT rule to divert DNS requests to the local resolver. Above configuration is working good on F22 with Docker version 1.6.0, build 9d26a07/1.6.0. I'd like to hear if you have any comments/suggestions/inputs about the same. Because when the local DNSSEC feature goes live(F23), it would be required to add such configuration on the host, so that the container applications could take full advantage of the DNSSEC resolver. IMO, Docker daemon is best suited to make the required configuration changes on the host. Because one, it already adds few iptables(8) rules on the host. And second, it checks host's name-server settings in '/etc/resolv.conf' and copies the non-localhost(127.0.0.1) servers to the container. When localhost(127.0.0.1) is the only name-server on the host, it defaults to using Google public DNS servers inside containers. It should be fairly straight forward for the Docker daemon to enable local 'lo' routing and add the DNAT rule upon detecting '127.0.0.1' as name-server on the host. Your comments/suggestions/inputs are most welcome. Thank you. --- Regards -P J P http://feedmug.com

2 2

Fedora Vagrant images in atlas.hashicorp
by Lalatendu Mohanty 30 Jul '15

30 Jul '15

Is there any specific reason we dont have Fedora images in atlas [1] cloud? I just checked and found that Fedora name space is available in atlas. So I have created the Fedora organization (Before someone takes it). I would be happy to transfer the ownership of it if we agree to make use of it. [1] atlas.hashicorp.com [2] https://atlas.hashicorp.com/fedora Thanks, Lala

1 0

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by Dusty Mabe 27 Jul '15

27 Jul '15

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2015-07-29 from 17:00:00 to 18:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://apps.fedoraproject.org/calendar/meeting/1999/

1 0

Maintaining Fedora-Dockerfiles
by Lalatendu Mohanty 24 Jul '15

24 Jul '15

I was looking at the Fedora-Dockerfiles git repo and realised that in current state it is difficult to maintain the dockerfiles for 3 versions of Fedora i.e. F21, F22 and Rawhide. One of the issue is the change from yum to dnf (dnf does not work in F20) in the dockerfiles. Though F20 is not in the supported versions, but this is a classic example of difference between versions of Fedora. To handle this issue I will suggest to have different branches for each releases and keeping the master for rawhide. After every Fedora release we can create branch from master for that release and keep the master branch for rawhide. However I understand this is more work for us, but IMO we need to follow this or something for easy maintenance of the files. [1] https://github.com/fedora-cloud/Fedora-Dockerfiles.git Thanks, Lala

3 2

[cloud] #97: Maintaining Fedora docker images for f22
by Fedora Cloud Trac Tickets 22 Jul '15

22 Jul '15

#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

1 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud July 2015