cloud May 2017

cloud@lists.fedoraproject.org

13 participants
84 discussions

[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 #276: Set architecture label in the base container image
by Honza Horak 29 Jun '17

29 Jun '17

hhorak reported a new issue against the project: `atomic-wg` that you are following: `` I believe that setting the architecture label in every layered Dockerfile is not necessary, it might be even problematic once we'll have containers on non-intel platforms, because then we'd need to either maintain more copies of Dockerfiles with different architecture labels or remove it later (when we'll have more layered Dockerfiles to maintain at that point). So, I'd like to propose to set the architecture label in the container base image, so it is inherited in the layered images and we don't need to hard-code it there. Then, setting architecture label should be made prohibited (or obsolete) in https://fedoraproject.org/wiki/Container:Guidelines. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/276

3 4

[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

[atomic-wg] Issue #266: rpmostree_compose Ansible module
by Trishna Guha 28 Jun '17

28 Jun '17

trishnag reported a new issue against the project: `atomic-wg` that you are following: `` As for Ansible module for atomic host we have `atomic_host` and `atomic_image` modules written. The plan/purpose of this ticket is to have rpm-ostree modules get done for Ansible as well. We can perhaps have all the `rpm-ostree` options as Ansible modules so that we really do not need to execute rpm-ostree commands as part of `shell`/`command` modules in Ansible. I wrote `rpmostree compose` Ansible module: https://github.com/ansible/ansible/pull/23209. Can anyone volunteer to review the PR? Bringing in @dustymabe @jberkus @walters @jlebon here. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/266

2 1

[atomic-wg] Issue #273: bodhi: allow fast track from pending->stable for updates with enough karma
by Dusty Mabe 27 Jun '17

27 Jun '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` This is an atomic-wg tracker for https://github.com/fedora-infra/bodhi/issues/632. Since we often have packages that we ask people to test and give enough karma too it would be nice if we can get the update that we "tested before it hit the testing repo" to go straight to stable. This scenario doesn't happen often, but when it does it is because we want an update to get into atomic host faster because it is a high priority update for us and waiting can be a bit depressing. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/273

2 4

[atomic-wg] Issue #263: open up read permission on our AMIs
by Dusty Mabe 26 Jun '17

26 Jun '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` A [BZ](https://bugzilla.redhat.com/show_bug.cgi?id=1423753) came in that requested we open up read permission on our AMIs Sayan wrote a script to do this: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org… Where are we on getting this done? `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/263

3 16

[atomic-wg] Issue #230 `enable ostree gpg verification in our baked images`
by Dusty Mabe 26 Jun '17

26 Jun '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` Now that ostree metadata is signed we should start configuring our media so that the resulting systems verify signatures with something like this: ``` # cat /etc/ostree/remotes.d/fedora-atomic.conf [remote "fedora-atomic"] url=https://dl.fedoraproject.org/pub/fedora/linux/atomic/25/ gpg-verify=true gpgkeypath=/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary ``` Are there any issues that need to be resolved first? `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/230

2 10

[atomic-wg] Issue #277: Enforce ENV usage as a requirement for release label
by Adam Miller 20 Jun '17

20 Jun '17

maxamillion reported a new issue against the project: `atomic-wg` that you are following: `` Currently the [Container Guidelines on LABELS https://fedoraproject.org/wiki/Container:Guidelines#LABELS] *recommend* the use of `ENV` declarations for the `release` but it appears as though this should be a requirement because of the way that python-dockerfile_parse performs ENV inheritance, if this method is not used then we lose `$DISTGIT` and `$FGC` I would like to request that the Working Group vote to make this mandatory in the guidelines. Thank you, -AdamM `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/277

2 4

[atomic-wg] Issue #280: Fedora Atomic/Cloud Test Day
by Dusty Mabe 15 Jun '17

15 Jun '17

dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` Let's create a test day to test the latest F26 Atomic Host images as well as the cloud images from the beta release. We'll optimally time this test day for right after beta is released, but enough time before the next freeze for final so we have time to get some fixes in. Right now the best target for this is Friday June 9th. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/280

2 7

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud May 2017