[X-POST] New guide focusing cloud users
by Kushal Das
Hi all,
i started a new guide [1] focusing Cloud users. Currently we have
different guides spread over different wiki pages, and blog posts. But
we don't have any single place which at least points to the current
and updated docs. I first suggested about this during Flock cloud
working group meeting.
The docs are written using reStructured Text format, using sphinx
project. When Fedora docs team comes up with the new tooling, they can
just pull in the files from here. The source can be found at [2].
Right now it contains a very few things I just put in today. Because i
am using readthedocs.org here, any commit will be reflected on the
docs very fast. I am yet to add the download chapter. Feel free to
add anything you think is important for our users, PR(s) are always
welcome.
[1] http://fedoracloud.rtfd.org
[2] https://github.com/fedora-cloud/fedoracloud
Kushal
--
Fedora Cloud Engineer
CPython Core Developer
http://kushaldas.in
8 years, 7 months
nightly fedora 22 composes
by Dennis Gilmore
Hi all,
we have set up a process to do a compose nightly for Docker base image, Cloud
Images and Atomic installer isos based on Fedora 22 the results will land in
http://dl.fedoraproject.org/pub/alt/stage/ in a directory 22-<date>/
These composes should be the basis for the two week deliverable. One thing I
would like to do but we will need to figure out how best to do it is to have a
report come to the cloud list when the compose is complete and give some
useful info like kernel version, docker version, kubernetes, version etc.
Regards
Dennis
8 years, 7 months
Cloud (_Atomic) selinux labels and restorecon
by Chris Murphy
FYI:
restorecon changes many file labels following a clean install
https://bugzilla.redhat.com/show_bug.cgi?id=1259018
This bug is not Cloud specific, but because Cloud_Atomic is read-only
it can't be fixed with restorecon. I mention this in the bug.
I don't know the quantity of metadata changes: selinux policy,
permissions, all other xattr, happen in the course of a release; but
in an "Atomic" context it looks like only option is to duplicate the
affected files to uniquely set new metadata on just that file in a
particular tree. The alternative, changing the metadata on the
hardlink, punches through to the original file in a completely
different tree, affecting all trees, and is therefore not atomic. (On
Btrfs this duplication can be made efficient with reflinks instead of
hardlinks, but that's trivia.)
--
Chris Murphy
8 years, 7 months