[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, 4 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, 4 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, 5 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, 6 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
6 years, 7 months
next steps for migrating Cloud Base image to Fedora Server?
by Matthew Miller
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
6 years, 9 months