[atomic-devel] Unified ostree repositories in Fedora

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

TL;DR: If you use f27 atomic workstation or rawhide atomic host/workstation 
then you
   need to add a new remote and rebase.

[f27 atomic workstation]
# ostree remote add --set=gpg-verify=true 
--set=gpgkeypath=/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-27-primary onerepo 
https://kojipkgs.fedoraproject.org/atomic/repo/
# rpm-ostree rebase onerepo:

[rawhide atomic host/workstation]
# ostree remote add --set=gpg-verify=true 
--set=gpgkeypath=/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-primary onerepo 
https://kojipkgs.fedoraproject.org/atomic/repo/
# rpm-ostree rebase onerepo:


Hey Atomic Land,

In Fedora we have migrated to using a single unified repository setup for our
ostree repositories. This means that f28+ all releases will be served out of
the same ostree repo. The repo will be located at 
https://kojipkgs.fedoraproject.org/atomic/repo/.
If you are a current user of rawhide atomic host/workstation or a current user
of f27 atomic workstation please run the above commands on your machine to
move to the new repository setup. Current users of F27 Atomic Host don't need
to do anything at this time.

Please let us know if you have any questions!

Dusty 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqfF5sACgkQMwLb1zlS
5nFPcg/+OHkKWyQcNlulzpNdJyi8tGx3BtmYE5czibhYSJ2iVua6IK3JImI/SWt1
XPm1rtuz5Ldy+vdqLOv6VkGYLDLY6JPz/D6ovyRwAPs3ZXhAZiuws47ZNzQkPeDg
lTTEswCRKb4CVJ0MhCUy12wqMBYecfv9eibvGD01v7vuxEK7e1Ck0/ogIOXGgWsC
gLRj8SEd0f7dc9JTnipFe5NIQDa7I7vTwo3btFUUms4vxuGpctyrbYreKPC71XKG
iyYHTISsOEk5PmghYg3CxoPzCjJsuFo3L6SBPrt734e3G9+dOMbNgaRFv3xFU6mN
LVm9tr6FvFPYT64kidjAllIaxCciSvtDL3Qm6iaptwXeAFFw4q8I1O/jEMwPVfxY
5B2bqLUO+deWudAlcyquvS9ujttNtT/q201FselGLVGoEUZCzL+bt7hMPi5UAm46
wG2dZzrAMMKTu7vTUVNYIxjv96aMdXxpGbJRqn/+z9EPDFxdk904Nwrg5E/utx2R
ta8WKGBnSkLqGxx06T7BcwlWZ5S6ismuIwyiHNfgjPJ2O+RtUQwVshdPDmgVE3rz
AL4/0FqBHIHSBtvaKgR5V5R6Y021ARleQpyYb7F1hq5kipSkaneCXgPW0wMkE3Zs
plLqrSVRB4RGElFT9NLrf6ykS5pkNRZTNnzXxviuPfuzsgt92cg=
=x7VK
-END PGP SIGNATURE-

[atomic-devel] CentOS Atomic Host 7.1802 Available for Download

[Jason Brooks]

The CentOS Atomic SIG has released an updated version
(https://wiki.centos.org/SpecialInterestGroup/Atomic/Download) of
CentOS Atomic Host (7.1802), a lean operating system designed to run
Linux containers, built from standard CentOS 7 RPMs, and tracking the
component versions included in Red Hat Enterprise Linux Atomic Host.

This release rolls up all package minor updates that shipped through
the month of February, including, most significantly, a newer version
of rpm-ostree with support for overriding base packages during package
layering operations. (see below for more details)

CentOS Atomic Host includes these core component versions:

* atomic-1.20.1-9.git436cf5d.el7.centos.x86_64
* cloud-init-0.7.9-9.el7.centos.2.x86_64
* docker-1.12.6-71.git3e8e77d.el7.centos.1.x86_64
* etcd-3.2.11-1.el7.x86_64
* flannel-0.7.1-2.el7.x86_64
* kernel-3.10.0-693.17.1.el7.x86_64
* kubernetes-node-1.5.2-0.7.git269f928.el7.x86_64
* ostree-2017.14-2.el7.x86_64
* rpm-ostree-client-2017.11-1.atomic.el7.x86_64

rpm-ostree override

While it's been possible to layer new packages onto the base CentOS
Atomic tree for some time now, overriding existing base packages with
layered alternatives either wasn't possible or was considered
experimental. Version 7.1802 now allows for overriding base packages.

For example, the origin-clients package that includes OpenShift
Origin's "oc" tool conflicts with the kubernetes-client package
included in the base tree. You can use package layering and overrides
to install the openshift-release rpm, remove the conflicting rpms, and
install the origin-clients rpm:


# rpm-ostree install centos-release-openshift-origin
# rpm-ostree override remove kubernetes-client kubernetes-node -r

# rpm-ostree install origin-clients -r

# oc cluster up
Starting OpenShift using openshift/origin:v3.7.0 ...
Pulling image openshift/origin:v3.7.0
...


Download CentOS Atomic Host

CentOS Atomic Host is available as a VirtualBox or libvirt-formatted
Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image.
For links to media, see the [CentOS
wiki](https://wiki.centos.org/SpecialInterestGroup/Atomic/Download).

Upgrading

If you're running a previous version of CentOS Atomic Host, you can
upgrade to the current image by running the following command:


# atomic host upgrade


Release Cycle

The CentOS Atomic Host image follows the upstream Red Hat Enterprise
Linux Atomic Host cadence. After sources are released, they're rebuilt
and included in new images. After the images are tested by the SIG and
deemed ready, we announce them.

Getting Involved

CentOS Atomic Host is produced by the CentOS Atomic SIG
(http://wiki.centos.org/SpecialInterestGroup/Atomic), based on
upstream work from Project Atomic (http://www.projectatomic.io/). If
you'd like to work on testing images, help with packaging,
documentation -- join us!

The SIG meets every two weeks as part of the Project Atomic community
meeting at 16:00 UTC on Monday in the #atomic channel. You'll often
find us in #atomic and/or #centos-devel if you have questions. You can
also join the atomic-devel
(https://lists.projectatomic.io/mailman/listinfo/atomic-devel) mailing
list if you'd like to discuss the direction of Project Atomic, its
components, or have other questions.

Getting Help

If you run into any problems with the images or components, feel free
to ask on the centos-devel
(http://lists.centos.org/mailman/listinfo/centos-devel) mailing list.

Have questions about using Atomic? See the atomic
(https://lists.projectatomic.io/mailman/listinfo/atomic) mailing list
or find us in the #atomic channel on Freenode.

Re: [atomic-devel] Kubernetes manual setup

[Muayyad AlSadi]

> Well actually... the main way I've used these system containers is
> with the ansible scripts at:
> https://github.com/kubernetes/contrib/tree/master/ansible but those
> have been deprecated.
>

You can say that they have been moved to
https://github.com/kubernetes-incubator/kubespray

>

Re: [atomic-devel] Kubernetes manual setup

[Chris Negus]

I started writing the content for Kubernetes on Fedora, based on all of your 
comments. Here's the approach I'm taking:

* Documenting kubeadm approach. It seems to work nicely as Jason describes.
* Pointing to minikube as an alternative vanilla Kubernetes setup for Fedora.
* Pointing to minishift, openshift-ansible, "oc cluster up" as alternatives for 
trying Kubernetes via OpenShift
* Demonstrating both Fedora and Fedora Atomic, stressing the value of Atomic 
for deploying containers.

Speak up if you think this is wrong. I'll share the doc once it's a bit more 
solid so everyone can have at it.

Colin, we're cutting the manual Kube setup (using system containers) from RHEL 
docs this coming release. Would it still be of value to showcase an example 
using Kube from system containers for the upstream case?

-- Chris Negus


- Original Message -
> On Wed, Feb 21, 2018, at 12:34 PM, Chris Negus wrote:
> 
> > In my mind, this means that someone trying out vanilla Kubernetes will
> > start with some OS outside of the Fedora/RHEL/CentOS ecosystem. My
> > question is, is it okay to let this content die? Or should we encourage
> > some way to still manually use Kubernetes on Fedora (Atomic or not)?
> 
> This is a pretty deep question with a lot of implications and history
> involved.
> Let me start by stating something that's fairly obvious: Kubernetes is pretty
> popular!  There are multiple "distros" of Kubernetes now, including now *two*
> products owned by Red Hat.
> 
> My personal opinion (now) is that we are primarily producing a base operating
> system; we need to
> support these different Kubernetes distributions; as well as non-Kubernetes
> cases.
> Including Kubernetes directly in AH was clearly a historical mistake, one
> that
> we are just finally digging ourselves out from.  Part of the issue here is
> that
> in Atomic we are introducing *two* entirely new ways to deliver software;
> via system containers as well as package layering now.  And Kubernetes could
> be done via both.
> In practice, I think system containers for Kubernetes make a lot of sense
> because
> then you get a natural decoupling of the base OS from your container service;
> they
> live at different cadences.  But it's been a challenge because it's quite
> different
> from all of the other ways to run Kube.
> 
> Kubernetes *also* is an excellent use case for the Fedora "Modularity" effort
> - having
> just one version of Kubernetes included in the "Everything" repository
> doesn't make
> sense when upstream supports multiple.
> The way I would describe this then is that we are providing technology that
> is intended
> to support this use case, and we also need to be participating in issues that
> cross
> the OS/Kubernetes boundary (for example: SELinux policy, host update
> management).
> So I think our current efforts at having system containers for upstream
> Kubernetes maintained by
> "us" are indeed the right approach - we need to ensure the basics work.
> Ideally
> of course we have more people gaining traction/buy-in in the upstream
> Kubernetes community.
> In practice I think a whole lot of that is mostly "non-Atomic" CentOS/RHEL
> using RPMs
> or just plain dropping binaries in /opt - hopefully we can get some of the
> upstream
> community using the technologies we've developed here.  But it's tricky
> because
> we have other Kubernetes distributions like OpenShift which are also a
> primary use case.
> 
> Anyways another important thing here is: we need to *clearly* distinguish the
> "dev/test"
> scenario from the "production" use case.  For the "dev/test" case there's
> minikube/minishift
> as well as `oc cluster up` which I use a lot (and a major bonus of using
> Linux as
> a desktop including Fedora Atomic Workstation is that you can `oc cluster up`
> directly
> on metal and avoid virt overhead).
> 
> 

[atomic-devel] [Fedocal] Reminder meeting : Atomic Working Group Weekly Meeting

[dusty]

Dear all,

You are kindly invited to the meeting:
   Atomic Working Group Weekly Meeting on 2018-03-07 from 16:30:00 to 17:30:00 
UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
This is the meeting for the Fedora Atomic Working Group. We typically go over 
previous meeting action items and then cover all tickets with the meeting 
keyword: https://pagure.io/atomic-wg/issues?status=Open=meeting

More information available at:
[https://fedoraproject.org/wiki/Atomic_WG#Meetings](https://fedoraproject.org/wiki/Atomic_WG#Meetings)


Source: https://apps.fedoraproject.org/calendar/meeting/6952/

[atomic-devel] REMINDER: WGs/SIGs to solicit bullet/talking points for F28 Beta release announcement

[Jan Kurik]

I would like to ask representatives of Fedora Working Groups and Spins
and Labs SIGs to work with the Fedora Marketing team and solicit
bullet points for the F28 Beta release announcement.

As an inspiration you can use the old F27 Beta Release Announcement
[1] and the new F28 Talking points [2].

[1] https://fedoramagazine.org/fedora-27-beta-released/
[2] https://fedoraproject.org/wiki/Fedora_28_talking_points

Thanks and Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

Re: [atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

what about requiring sudo to do nsenter? (even when using runc rootless)



On Mon, Mar 5, 2018 at 4:09 PM, Giuseppe Scrivano 
wrote:

> Muayyad AlSadi  writes:
>
> > when using runc
> >
> > $ mypid=`runc list | tail -n 1 | awk '{print $2}'`
> > $ nsenter -a -t $mypid /bin/sh
> > nsenter: reassociate to namespace 'ns/cgroup' failed: Operation not
> permitted
> > $ sudo nsenter -a -t $mypid /bin/sh
> > # worked fine
> >
> > but when using bwraps
> >
> > $ mypid=`bwrap-oci list | tail -n 1 | awk '{print $2}'
> > $ nsenter -a -t $mypid /bin/sh
> > nsenter: reassociate to namespace 'ns/net' failed: Operation not
> permitted
> > $ sudo nsenter -a -t $mypid /bin/sh
> > nsenter: failed to execute /bin/sh: No such file or directory
>
> I guess that is an issue in bwrap as it internally uses chroot instead
> of a pivot_root.  This PR should probably fix the problem you are
> seeing:
>
>   https://github.com/projectatomic/bubblewrap/pull/256
>
> Giuseppe
>