cloud January 2017

cloud@lists.fedoraproject.org

27 participants
73 discussions

Python is missing in Fedora AWS AMIs
by Danishka Navin 29 Dec '22

29 Dec '22

Hi team, Is there any specific reason to drop python from Fedora AMIs in AWS? Regards, -- Danishka Navin http://danishkanavin.blogspot.com http://twitter.com/danishkanavin

6 5

[atomic-wg] Issue #184 `ISO file is missing`
by Pagure 14 Jul '17

14 Jul '17

jberkus reported a new issue against the project: `atomic-wg` that you are following: `` Try to download the ISO at this location, as supplied by GetFedora.org: https://download.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-25-2… You'll find that there is no file there, and your download does not start. There is currently no way to download the Atomic ISO. In fact, it appears that none of the alternate downloads are available for 12/7: http://mirror.math.princeton.edu/pub/alt//atomic/stable/ `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/184

3 14

[atomic-wg] Issue #192 `atomic working group - periodic virtual FADs`
by Pagure 14 Jul '17

14 Jul '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` It would be great if we can have some planned virtual meetings every few months to discuss the atomic working group and current issues that extend into discussions. Should we meet every so often (not necessarily for an entire day) to sync up on issues and work through the backlog of items to clear out cruft and/or promote forgotten priorities? `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/192

2 2

[atomic-wg] Issue #197 `Change size of Root, Docker partitions in F26 Atomic Host storage setup`
by Pagure 13 Jul '17

13 Jul '17

jberkus reported a new issue against the project: `atomic-wg` that you are following: `` The way it is now: Currently, the rootFS is sized at 3GB, fixed, and the Docker partition is 40% of the remaining space. This causes new users to run out of disk space if they do layering, ostree unlock, install a bunch of system containers, or even just run up the logs, even if they have plenty of physical disk space. My suggestion for a new default is: * RootFS: 25% of disk space, with a minimum of 3GB and a maximum of 16GB * Docker Partition: 50% of total disk space (or 65% of remaining space), min 2GB * Unallocated: 25% of disk space. This would mean, for a new install: Disk Root Docker Unallocated 8GB 3GB 4GB 1GB 32GB 8GB 16GB 8GB 200GB 16GB 100GB 84GB `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/197

4 17

[atomic-wg] Issue #193 `Please add Atomic Host and Fedora Cloud Base to AWS Asia Pacific (Seoul) Region`
by Pagure 30 Jun '17

30 Jun '17

mattdm reported a new issue against the project: `atomic-wg` that you are following: `` This [opened in January](https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-seoul-r… and we missed it. (If we were in the Amazon Marketplace, this would happen automatically. Oh well.) See request on mailing list [here](https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproje… Also, once available, don't forget to ask the web team to update the launch pages. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/193

2 5

[atomic-wg] Issue #186 `switch to overlay2`
by Pagure 30 Jun '17

30 Jun '17

walters reported a new issue against the project: `atomic-wg` that you are following: `` <vgoyal> walters: so there are two options. One is changing default to overlay2, which is common across all variants <vgoyal> walters: another new option is specifying where the storage from overlayfs comes from. Does it come from root filesystem or from free space in volume group <vgoyal> for atomic, rootfs is just 3G and if we overlayfs uses rootfs, then it will fill up pretty fast. <vgoyal> so we created a new option in dss, DOCKER_ROOT_VOLUME <vgoyal> if one specifies DOCKER_ROOT_VOLUME=yes, then dss looks for free space in volume group and creates a logical volume, makes a file system on this and mounts on /var/lib/docker/ <vgoyal> now when docker starts, it will put all images and containers in the new volume ( and not logical volume backing rootfs) <vgoyal> given workstation rootfs uses all free space, workstation will not require this by default. <vgoyal> but server and atomic leave free space in volume group and by default that can be used for docker. (like devicemapper graph driver) <vgoyal> so DOCKER_ROOT_VOLUME=yes is required only for server and atomic variants only (and not workstation one) `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/186

2 67

[atomic-wg] Issue #181 `Vagrant cannot create synced folder`
by Pagure 26 May '17

26 May '17

jorti reported a new issue against the project: `atomic-wg` that you are following: `` I just launch an unmodified fedora/25-atomic-host box and I get the error that it cannot create the /vagrant synced dir. ``` $ vagrant up Bringing machine 'default' up with 'libvirt' provider... ==> default: Creating image (snapshot of base box volume). ==> default: Creating domain with the following settings... ==> default: -- Name: mail-server_default ==> default: -- Domain type: kvm ==> default: -- Cpus: 1 ==> default: -- Memory: 512M ==> default: -- Management MAC: ==> default: -- Loader: ==> default: -- Base box: fedora/25-atomic-host ==> default: -- Storage pool: default ==> default: -- Image: /var/lib/libvirt/images/mail-server_default.img (41G) ==> default: -- Volume Cache: default ==> default: -- Kernel: ==> default: -- Initrd: ==> default: -- Graphics Type: vnc ==> default: -- Graphics Port: 5900 ==> default: -- Graphics IP: 127.0.0.1 ==> default: -- Graphics Password: Not defined ==> default: -- Video Type: cirrus ==> default: -- Video VRAM: 9216 ==> default: -- Keymap: en-us ==> default: -- TPM Path: ==> default: -- INPUT: type=mouse, bus=ps2 ==> default: -- Command line : ==> default: Creating shared folders metadata... ==> default: Starting domain. ==> default: Waiting for domain to get an IP address... ==> default: Waiting for SSH to become available... default: default: Vagrant insecure key detected. Vagrant will automatically replace default: this with a newly generated keypair for better security. default: default: Inserting generated public key within guest... default: Removing insecure key from the guest if it's present... default: Key inserted! Disconnecting and reconnecting using new SSH key... ==> default: Configuring and enabling network interfaces... ==> default: Rsyncing folder: /home/juan/Vagrant/mail-server/ => /vagrant The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! mkdir -p /vagrant Stdout from the command: Stderr from the command: mkdir: cannot create directory ‘/vagrant’: Operation not permitted ``` `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/181

2 6

[atomic-wg] Issue #196 `moving to docker 1.13 in Fedora 25`
by Pagure 13 Apr '17

13 Apr '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` In the meeting today @runcom brought up the topic of: - removing docker-latest in Fedora (mail thread on that [here](https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-January/msg00037.html)) - moving to docker 1.13 (just released) in Fedora 25 There are some concerns over moving to docker 1.13 but we believe that if we are able to qualify it enough it would be beneficial to go to the latest version so that @runcom doesn't have to manage so many versions of docker. The current proposal is: - first, wait 4 weeks - let some bugs from initial release work itself out - many of us are traveling over the next few weeks anyway so this won't hurt - 2nd, put out update to updates-testing and wait some time for thorough tests to be conducted on the testing ostree. - If there are big issues with 1.13 that don't have a ready fix (performance issues, complicated issues that don't have fixes) then we can unpush 1.13 from updates-testing and put out security fixes etc for 1.12. We'd like to not have to unpush if possible though. Another thing that might be useful is a condensed list of changes from 1.12 to 1.13. @runcom, could you provide us with that information? `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/196

8 18

[atomic-wg] Issue #180 `Future of Fedora Dockerfiles`
by Pagure 22 Feb '17

22 Feb '17

scollier reported a new issue against the project: `atomic-wg` that you are following: `` We need to decide what is going to happen with the Fedora-Dockerfiles repo located here: https://github.com/fedora-cloud/Fedora-Dockerfiles Right now I don't have enough time to maintain these properly. According to these messages: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org… and this one: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org… Looks like the direction is to deprecate Fedora-Dockerfiles. This also impacts all of the images on: https://hub.docker.com/u/fedora/ Where fedora/apache has > 1 million pulls, the rest are in the thousands and lower. So, we just need to decide, support this as a Fedora project and find a co-maintainer, or shut this down? If we shut it down, I'd like to know what the transition strategy is for moving to dist-git so I can add a message to the repo as a redirect. FWIW, I'm in favor of closing it down if the barrier to entry to dist-git isn't to high. Just looking to get final word here. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/180

3 9

next steps for migrating Cloud Base image to Fedora Server?
by Matthew Miller 09 Feb '17

09 Feb '17

I think we had general agreement around what we want to do here: have the Cloud Base Image become instead Fedora Server, but shipped as a cloud image and made available in cloud providers. What are the next steps to actually get there? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud January 2017