I'd like to propose that a small subset of LABEL values be added to the
Dockerfile, to support the generic labels defined here ->
https://github.com/projectatomic/ContainerApplicationGenericLabels
I think adding name, version, release, architecture, build-date, vendor,
url and summary would be a good default set. There should not be any
impact for running containers with this added meta-data outside atomic,
and would help provide additional information that could be referenced
via atomic or cockpit.
Thoughts?
--
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
This event has been changed.
Title: Fedora Release Tools Demo (Live Broadcast)
Hangout: https://plus.google.com/events/csu4snfss35j6dc37hi37s8e3ro
The hangout will be broadcast live & posted at
http://www.youtube.com/watch?v=UO-_WEVYXvo
Q&A - #fedora-meeting
--
Purpose: The purpose of a demo is to show our stakeholders what we
completed this iteration, get feedback from them about the changes & set
some context and expectation with them about our direction.
Demo agenda & previous demos can be viewed here:
http://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tool…
Highlights today:
- Openshift origin on Fedora
- Pungi 4 compose
- Koji signed repos new features
- Fedora's PDC introduction
- Autocloud front end changes
...and some other goodies
(changed)
When: Tue Dec 15, 2015 12pm - 1pm Eastern Time
Where: Hangout on Air / YouTube live stream
Calendar: acarter(a)redhat.com
Who:
* acarter(a)redhat.com - organizer
* twaugh(a)redhat.com
* mmcgrath(a)redhat.com
* server(a)lists.fedoraproject.org
* rel-eng(a)lists.fedoraproject.org
* desktop(a)lists.fedoraproject.org
* kasingh(a)redhat.com
* rcm-tools(a)redhat.com
* aos-devel
* cloud(a)lists.fedoraproject.org
* rbarlow(a)redhat.com
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=ZmM2MW5tYjFldXNyOGg5c…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
cloud(a)lists.fedoraproject.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to modify your RSVP
response. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Dear all,
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2015-12-16 from 17:00:00 to 18:00:00 UTC
At fedora-meeting-1(a)irc.freenode.net
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
Source: https://apps.fedoraproject.org/calendar/meeting/1999/
Hi all,
It is again time to start working towards next Fedora release. Proposal
submission deadline for Fedora 24 is 12th January, 2016 [1].
During the last week's Cloud SIG meeting, we discussed about few
possible features we want to work on. Please file the formal changes in
the wiki, and then update [2] where we are keeping the notes related to
the ideas for Fedora 24 from Cloud SIG.
If you want to learn more about how to file a change request, please go
through [3]. To discuss on any particular idea, feel free to start a new
thread in this list, or reply to this mail in the same thread.
[1] https://fedoraproject.org/wiki/Releases/24/Schedule
[2]
https://fedoraproject.org/wiki/Changes/Features_for_Fedora_24_from_Cloud_SIG
[3] https://fedoraproject.org/wiki/Changes/Policy
Kushal
--
Fedora Cloud Engineer
CPython Core Developer
CentOS Cloud SIG lead
http://kushaldas.in
#141: Vagrant-libvirt Failed for Fedora-Cloud-Atomic 23
---------------------+---------------------
Reporter: aalam | Owner:
Type: defect | Status: new
Priority: blocker | Milestone: Future
Component: --- | Keywords: meeting
---------------------+---------------------
Fedora-Cloud-Atomic-Vagrant-23-20151119.x86_64.vagrant-libvirt.box
I have reproduced same error on my local computer with
sudo python3 -m unittest tunirtests.cloudtests -v
sudo systemctl stop crond.service
sudo systemctl disable crond.service
sudo reboot
I failed to ssh back to system after rebooting.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/141>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
Has anyone else run into this? I've never before run into this
problem, not any version of Server or Workstation. Just cloud, and
I've run into it several times in just a few days.
I'm using public-key authentication to ssh into a Fedora 23 Cloud
Atomic ISO installation upgraded to 23.29. This works most of the
time, until it doesn't and then I always get this.
[chris@f23m ~]$ ssh chris(a)10.0.0.15
PTY allocation request failed on channel 0
If I happen to have an existing login available, even if I restart
sshd the problem isn't fixed. The only fix I've found so far is a
reboot which is more than a bit disruptive. Any ideas?
In the journal host side, it records a bunch of audit stuff, but three
lines that seem particularly relevant yet not illuminating:
Dec 12 12:37:10 f23a.localdomain audit[1]: USER_AVC pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='Unknown permission start for class system
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
[snip]
Dec 12 12:27:25 f23a.localdomain sshd[2029]: error: openpty: No such
file or directory
Dec 12 12:27:25 f23a.localdomain sshd[2032]: error: session_pty_req:
session 0 alloc failed
systemd-222-8.fc23.x86_64
I'd file a bug but I don't even know what to file it against. The full
journal output is here:
http://fpaste.org/3001
--
Chris Murphy
At Flock and on this list and elsewhere, we've talked about making
Fedora Atomic our main edition-level deliverable (while still producing
Cloud Base as something akin to a Spin).
As I understand it, this is officially agreed, but not everyone is
really bought in. I'd like to advocate for and advance this further,
especially since Two Week Atomic is off the ground and running (see
https://getfedora.org/en/cloud/download/atomic.html — thanks
everyone!). Are we ready for the next steps, here?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
OK instead of hijacking some other thread...(sorta too late).
# lsblk -f
NAME FSTYPE LABEL UUID
MOUNTPOINT
sda
=E2=94=9C=E2=94=80sda1 vfat 5956-63D8
/boot/efi
=E2=94=9C=E2=94=80sda2 btrfs f23a
8b0c4840-4fc7-4782-a4c0-25fec8a40dd4 /sysroot
=E2=94=9C=E2=94=80sda3 ext4
908cb4df-410b-47e4-afb1-872255bd1244 /boot
=E2=94=9C=E2=94=80sda4 LVM2_member
9WkBEW-XwcN-8f99-nQOP-E1w8-QiBs-6Xio7a
=E2=94=94=E2=94=80sda5 swap
53f95874-06db-4433-a74b-8dc31105c528 [SWAP]
-bash-4.3# pvs
PV VG Fmt Attr PSize PFree
/dev/sda4 VG lvm2 a-- 426.51g 126.36g
-bash-4.3# vgs
VG #PV #LV #SN Attr VSize VFree
VG 1 1 0 wz--n- 426.51g 126.36g
-bash-4.3# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move
Log Cpy%Sync Convert
docker-pool VG twi-a-tz-- 300.00g 0.00 0.44
What I'd like to know how to do, is get docker to use the thin pool
setup here as backing, instead of Btrfs.
What I tried:
# cp /usr/lib/docker-storage-setup/docker-storage-setup
/etc/sysconfig/docker-storage-setup
I then edited that file making one change such that VG=3DVG since that's
the name of the VG. So it still says to use
STORAGE_DRIVER=3Ddevicemapper.
# systemctl status docker-storage-setup
=E2=97=8F docker-storage-setup.service - Docker Storage Setup
Loaded: loaded
(/usr/lib/systemd/system/docker-storage-setup.service; enabled; vendor
preset: disabled)
Active: inactive (dead) since Thu 2015-12-10 01:09:06 MST; 45s ago
Process: 8008 ExecStart=3D/usr/bin/docker-storage-setup (code=3Dexited,
status=3D0/SUCCESS)
Main PID: 8008 (code=3Dexited, status=3D0/SUCCESS)
Dec 10 01:09:05 f23a.localdomain systemd[1]: Starting Docker Storage Setup.=
..
Dec 10 01:09:05 f23a.localdomain docker-storage-setup[8008]: INFO:
Volume group backing root filesystem could not be determined
Dec 10 01:09:06 f23a.localdomain docker-storage-setup[8008]: Logical
volume "docker-pool" changed.
Dec 10 01:09:06 f23a.localdomain systemd[1]: Started Docker Storage Setup.
# systemctl status docker
=E2=97=8F docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled;
vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/docker.service.d
=E2=94=94=E2=94=80flannel.conf
Active: failed (Result: exit-code) since Thu 2015-12-10 01:09:06 MST; 48=
s ago
Docs: http://docs.docker.com
Process: 8032 ExecStart=3D/usr/bin/docker daemon $OPTIONS
$DOCKER_STORAGE_OPTIONS $DOCKER_NETWORK_OPTIONS $INSECURE_REGISTRY
(code=3Dexited, status=3D1/FAILURE)
Main PID: 8032 (code=3Dexited, status=3D1/FAILURE)
Dec 10 01:09:06 f23a.localdomain systemd[1]: Starting Docker
Application Container Engine...
Dec 10 01:09:06 f23a.localdomain docker[8032]:
time=3D"2015-12-10T01:09:06.240354137-07:00" level=3Dinfo
msg=3D"[graphdriver] using prior storage driver \"btrfs\""
Dec 10 01:09:06 f23a.localdomain docker[8032]:
time=3D"2015-12-10T01:09:06.249931298-07:00" level=3Dfatal msg=3D"Error
starting daemon: SELinux is not supporte...h driver"
Dec 10 01:09:06 f23a.localdomain systemd[1]: docker.service: Main
process exited, code=3Dexited, status=3D1/FAILURE
Dec 10 01:09:06 f23a.localdomain systemd[1]: Failed to start Docker
Application Container Engine.
Dec 10 01:09:06 f23a.localdomain systemd[1]: docker.service: Unit
entered failed state.
Dec 10 01:09:06 f23a.localdomain systemd[1]: docker.service: Failed
with result 'exit-code'.
Hint: Some lines were ellipsized, use -l to show in full.
So there's a disconnect between docker-storage-setup, which is set to
use devicemapper and the volume group named VG, and docker.service
which continues to use the btrfs driver (and then fails for the known
reason that --selinux-enabled is set by default and that's not yet
working until the automatic chcon patch lands).
In the meantime I can just remove --selinux-enabled. But I'd like to
know how to redirect docker to use lvm thinp if that's possible.
--
Chris Murphy