[atomic-wg] Issue #192 `atomic working group - periodic virtual FADs`
by Pagure
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
6 years, 9 months
[atomic-wg] Issue #197 `Change size of Root,
Docker partitions in F26 Atomic Host storage setup`
by Pagure
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
6 years, 9 months
[atomic-wg] Issue #186 `switch to overlay2`
by Pagure
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
6 years, 10 months
[atomic-wg] Issue #228 `clarify policy on atomic host support for older
Fedora "number" releases`
by Dusty Mabe
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
6 years, 10 months
[atomic-wg] Issue #181 `Vagrant cannot create synced folder`
by Pagure
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
6 years, 11 months
[atomic-wg] Issue #196 `moving to docker 1.13 in Fedora 25`
by Pagure
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
7 years
[atomic-wg] Issue #199 `Plan for Atomic prerelease images`
by Robert Mayr
robyduck reported a new issue against the project: `atomic-wg` that you are following:
``
With F25 Atomic replaced definitely Cloud as Fedora edition, and is now the only "cloud" set on getfedora.org.
Until F25 there was never any plan to produce prerelease images (Alpha/Beta), but now, as it is an edition, websites need to know if cloud-wg wants to change that and produce 2-week prerelease images. Alpha freeze is at the end of February and Alpha will be released at 2017-03-14.
https://fedoraproject.org/wiki/Releases/26/Schedule
The earlier we know your plan the better, because actually we do not have any line coded for a new prerelease page.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/199
7 years
[atomic-wg] Issue #231 `clarify meaning of "rolling" for future fedora
atomic releases`
by Jason Brooks
jasonbrooks reported a new issue against the project: `atomic-wg` that you are following:
``
The Atomic WG has unofficially paid attention to only a single fedora atomic release at a time, specifically, the release based on the current latest stable Fedora release. There's a proposal to formalize this in [issue 228](https://pagure.io/atomic-wg/issue/228).
In the discussion around this issue, @jberkus asked why, if we are to support only a single fedora atomic release at a time, do we not adopt a "rolling" release structure for fedora atomic, where the tree served from the fedora atomic ostree repo is always composed from the current latest stable Fedora release.
In response, @dustymabe suggested that "rolling" could mean many different things, and that we should discuss these many meanings in a future VFAD.
In this issue, we can collect some thoughts on what "rolling" means in advance of this VFAD.
To me, a rolling fedora would match up with what rhel and centos atomic do. There's a single repo, and an upgrade from rhel atomic 7.1 to 7.2 to 7.3, etc. simply involves runnning `atomic host upgrade`. The same would apply to fedora for 25 to 26 to 27, etc.
Currently, fedora users are expected to rebase each six months, in the same way that they might rebase between completely separate streams, such as from fedora atomic to centos atomic.
So, upgrades, today:
```
$ sudo ostree remote delete fedora-atomic
$ sudo ostree remote add fedora-atomic --set=gpg-verify=false $ https://dl.fedoraproject.org/pub/fedora/linux/atomic/25
$ sudo rpm-ostree rebase fedora-atomic:fedora-atomic/25/x86_64/docker-host
$ sudo systemctl reboot
```
Upgrades, in a "rolling" world:
```
$ sudo atomic host upgrade
$ sudo systemctl reboot
```
This would have zero impact on the current two-week release scheme. Just as we tried to release fedora atomic 24 every two weeks up until fedora 25 release day, when we shifted to trying to release fedora atomic 25 every two weeks, and stopped paying attention to the 24 stream, we would, at some future point, be releasing fedora atomic every two weeks based on f2N rpms, switch over to the f2N+1 rpms on or near release day, and proceed from there.
The only difference is convenience and clarity for our users.
Before Dusty cited the many meanings of "rolling" I hadn't even considered additional meanings, but maybe we can list some of those here in preparation for the VFAD.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/231
7 years, 1 month