cloud April 2017

cloud@lists.stg.fedoraproject.org

20 participants
123 discussions

[atomic-wg] Issue #232 `ssh issue on libvirt based images`
by Kushal Das 14 Jul '17

14 Jul '17

kushal reported a new issue against the project: `atomic-wg` that you are following: `` During our Atomic tests, after disabling the chronyd service, we reboot the VM. After that the ssh serivce is not coming back on time. This VM has one vcpu in it. Sometimes we saw behaviour on Vagrant libvirt (which boots with 2 VCPU(s)), and at least once with Vagratnt Virtualbox before. One such example of failure: https://apps.fedoraproject.org/autocloud/jobs/2188/output#30 https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org… is the thread in the mailing list on the same topic. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/232

6 9

[atomic-wg] Issue #246 `Period of fedimg downtime`
by Dusty Mabe 14 Jul '17

14 Jul '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` There appears to be a period of downtime where fedimg was not uploading AMIs Fedora-Atomic-25-20170226.0.x86_64 EC2 (us-west-2) ami-5051d230 hvm gp2 Fedora-Atomic-25-20170304.0.x86_64 EC2 (ap-northeast-1) ami-8cb2e5eb hvm gp2 Attached is a run of [get_ami.py](https://pagure.io/fedora-websites/blob/master/f/tools/get_ami.py) which shows a gap. Can someone investigate why this happened? <!!image> `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/246

1 3

[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 #261 `Issue Tracker for F26 release blockers`
by Dusty Mabe 10 Jul '17

10 Jul '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` This ticket will be used throughout the f26 release to track potential blocker bugs and/or important bugs for the next release. A blocker bug is a bug that we will choose not to release on if it is not fixed. An important bug is a bug that we want fixed but may choose not to block on. **Blocker Bugs** - **Important Bugs** - none Over time only the description of this bug will be edited for updates. Please do not add comments to this issue. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/261

3 7

[atomic-wg] Issue #269: fedimg: don't use 'builder' instance for uploading AMIs
by Dusty Mabe 05 Jul '17

05 Jul '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` we hit [an issue](https://pagure.io/releng/issue/6761) yesterday because fedimg failed upload all of our AMIs for that day's build of FAH. This is most likely due to the fact that we use a builder instance to pull the cloud disk image and then create the EBS. Bringing up the builder instance can fail (commodity hardware in EC2) and thus can lead to situations like this. It would be much better if we don't use a builder instance. This is being worked on in https://github.com/fedora-infra/fedimg/issues/42. This ticket will track that work that is 'two weeks away' from completion. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/269

2 3

[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 #228 `clarify policy on atomic host support for older Fedora "number" releases`
by Dusty Mabe 28 Jun '17

28 Jun '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` After talking with people from the fedora community and from the atomic WG it has become clear that there is a lot of confusion on our policy for support for N-1 releases of Fedora Atomic Host. First off some terminology: **support**: means that we test and release new 2 week releases for this number release (i.e. we currently test/release new two week releases of Fedora 25 Atomic Host). **N-1**: currently is Fedora 24 Atomic Host **life support**: means that we still push out OSTree updates for the OSTree that backs this number release, but we don't create new image releases and we don't formally test it. Currently we have been offering **support** for the current (N) release of Fedora and **life support** for the previous (N-1) release of Fedora. In the future I'd like to formalize our **support** policy and stop providing **life support** for previous releases once it is no longer a current release. There are a couple of reasons for this: - The level of effort going into N-1 is very minimal and I wouldn't want someone running that to get a false sense of security from it. - If N-1 breaks in releng for whatever reason, spending time on N-1 is not a high priority and I'd like to not have to fix it if it breaks. For F26 I'd like to formally state this policy of **support**ing only the N release. We can also **life support** the N-1 for an agreed upon time period after the N release (30to60 days or something) to allow for transition. Note: There is also some discussion about making Fedora Atomic a rolling release. That is outside the scope of this ticket. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228

5 18

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud April 2017