Re: [atomic-devel] Getting to full deprecation of the projectatomic/ Github organization

[Daniel Walsh]

On 10/1/19 2:35 PM, Farkas Levente wrote:
> Hi,
>
> It'd be very nice to get something useful information about the
> current state and future plan of RH about containerization.
> TL;DR is there anybody who knows anything about it?
>
> IMHO the current communication about containerization is a very bad
> state.
> That's the reason why i choose to reply this thread since imho like
> the content of this mail should have to be announced etc.
>
> Let me describe what i see (which may be wrong) about the whole rh
> containerization.
>
>
> if i'd like to use amazon, google etc there is a full framework for
> everything. i mean registry (virtual) hosts or container runtime
> environment, file storage, sql, nosql storage, messaging logging,
> kubernetes etc...
>
> when i like to use my own eg. private environment than i have to build
> up all of this part of the system. suppose i prefer redhat/centos
> based stuff and plan to be ready in a year. what should i have to do?
>
> probably read the docs...ooohhh which docs and where and what
> here comes the real problems.
>
> so what i need?
>
> a host operating system. which one?
>   - rhel/centos 7 vs 8?
>   - atomic ?
>   - coreos ?
> which one to choose? atomic was rh recommendation and after rh buy
> coreos it's not possible to choose. but atomic was also deprecated. or
> not? it's not even documented on atomic homepage that it's deprcated
> !!! just one hidden blog post about it which refer to that coreos will
> be the future. but there is no coreos since the old one is no longer
> available. there is no rhel/centos coreos. but fedora coreos is not
> even in beta stage! only one page long docs about it!
> do you really thing than a blog post is the best place to know the
> future plan of the whole rh's host os and the future plan?
>
> is there any roadmap/future plan/direction what we can expect? what's
> your plan with some kind of milestone/timeline etc?
>
> or should i choose rhel? which one? rhel-8 has podman-1.0.0 which is
> totally unusable. so it's better if you do NOT choose rhel/centos 8
> over 7.7 (which is imho nonsense). and there not even an update but
> let me write about it later..
>
> ok i don't know which host os to choose and not really helpful any
> docs about it what's more can't know anything about the future plan.
>
RHEL8 version of podman should be updated next month with the release of
rhel8.1, from that point forward it will be updated every three months,
to close to the current release.    Some unfortunate circumstances
caused us to delay release for 6 months.


>
> i need a container framework. which one?
> docker as a primary choice but rh do not support it. the latest
> version is 1.13 and won't be updated. even rh's own docs (openshift
> and kubernetes docs also) start with "delete rh's docker, download
> docker ce from docker and install it". really? that's the way? what is
> the plan for the future?
>
RHEL is moving away from Docker to podman, buildah and skopeo.  For
OpenShift we are using CRI-O for the container engine.


We cover this in this blog

https://www.redhat.com/en/blog/rhel-8-enables-containers-tools-software-craftsmanship-0

Which was the first hit on Google while searching for "rhel8 container
technologies"

>
> kubernetes, openshift or okd? of course it's depend on the host os and
> what is supported on it. even in openshift and okd (which are rh
> products) none of the use rh's rpm and it's version of docker, podman
> or anything like them. what is the future in this case? is there any
> roadmap?
> just read okd docs (which is owned by rh). it's always refer to
> dockerhub's and not rh's container image. it's always refer to docker
> and not podman.
>
If you want to buy a supported version of Kubernetes from Red Hat it is
OpenShift, our enterprise version of Kubernetes. OKD is the upstream of
OpenShift, which used kubernetes for its upstream.  Neither okd or
kubernetes will be packaged directly on RHEL. You need to access to the
OpenShift repos to get the kubernetes package.
>
> ocr-i, podman, etc. can we replace docker by this tools? may be in the
> future...but when? what is the roadmap? what a developer should have
> to use in this own developer machines? on rhel/centos-8 nothing is
> working podman is till in 1.0.0.
Hopefully next month RHEL8.1 and then RHEL8.1.1 to get to podman-1.6
release.
> on rhel/centos 7.7 latest podman can't be use in rootless mode which
> can be the biggest advantage over docker (just see the bugzilla entry
> about it).
We are working to rootless fixed in RHEL7.8 but this is a very old
kernel, and going into the next phase of maintenance mode.  So getting
major changes into the kernel to support usernamespace and fuse file
systems is difficult.
> may be fadora workingbut after in production you can't use what
> you use for development.
> so conclusion:
> - atomic depricated
> - coreos still not in beta no docs
> - rhel/centos 7 not working in rootless mode
> - rhel/centos 8 

Re: [atomic-devel] Getting to full deprecation of the projectatomic/ Github organization

[Daniel Walsh]

On 9/28/19 9:31 AM, Sanja Bonic wrote:
> Should we use this email as a generic call for people to look through
> the repos on Project Atomic and see whether they want to preserve any
> of the remaining ones? If yes, by which date?
>
We need to preserve the projectatomic/atomic code. Since this is in use
on RHEL7.
> On Sat, 28 Sep 2019, 07:02 Daniel Walsh,  <mailto:dwa...@redhat.com>> wrote:
>
> On 9/27/19 7:20 PM, Colin Walters wrote:
> > bubblewrap moved: https://github.com/containers/bubblewrap
> > rpm-ostree moved: https://github.com/coreos/rpm-ostree
> >
> > Of the things remaining...probably the biggest is our docker
> branch: https://github.com/projectatomic/docker
> > I feel like it'd be cleanest if we created a new org for this
> stuff...queue naming bikeshed, I know.
> Can't wait for this to go away...
> >
> > There's also:
> https://github.com/projectatomic/ContainerApplicationGenericLabels
> - did we ever standardize that stuff elsewhere?
> We could move this to containers.
> > I think if we got those bits done we could probably mass-archive
> the remaining repos.
> >
>

Re: [atomic-devel] Getting to full deprecation of the projectatomic/ Github organization

[Daniel Walsh]

On 9/27/19 7:20 PM, Colin Walters wrote:
> bubblewrap moved: https://github.com/containers/bubblewrap
> rpm-ostree moved: https://github.com/coreos/rpm-ostree
>
> Of the things remaining...probably the biggest is our docker branch: 
> https://github.com/projectatomic/docker
> I feel like it'd be cleanest if we created a new org for this stuff...queue 
> naming bikeshed, I know.
Can't wait for this to go away...
>
> There's also: 
> https://github.com/projectatomic/ContainerApplicationGenericLabels - did we 
> ever standardize that stuff elsewhere?
We could move this to containers.
> I think if we got those bits done we could probably mass-archive the 
> remaining repos.
>

Re: [atomic-devel] Install CRI-O on Atomic Host

[Daniel Walsh]

On 1/30/19 2:02 PM, Colin Walters wrote:
>
> On Tue, Jan 29, 2019, at 2:31 PM, mabi wrote:
>> Ah ok so standard CentOS would do it... I guess I missed the point, I 
>> thought Atomic Host is THE distribution to go with when using such 
>> platforms like okd.io/OpenShift...
> An interesting topic here is whether saying "Fedora/CentOS/RHEL" means *not* 
> {Fedora, CentOS, RHEL} Atomic Host.  I don't think so; or to avoid double 
> negatives, I think Atomic/CoreOS style systems are part of the family. 
>
> Now, your question gets to a larger problem we've struggled with around 
> OpenShift/Kubernetes and platform choices and how we manage things.  If 
> you've noticed for OpenShift 4.0 we're doing something fundamentally 
> different here with Red Hat CoreOS by baking in the kubelet/cri-o to the host 
> directly.
>
> Some people often forget that the rpm-ostree technology underlying Atomic 
> Host has package layering; I briefly went to the https://cri-o.io/ web page 
> but the link it has for CentOS RPMs is wrong as far as I can tell.  But if 
> the RPMs exist it almost certainly works to do `rpm-ostree install cri-o`.  
> But really this is more about OKD.
>
>
>
Right you can get CRI-O and OKD installed on atomic host as layered
packages.  But it will not be updated via the atomic upgrades.

Re: [atomic-devel] Install CRI-O on Atomic Host

[Daniel Walsh]

On 1/29/19 7:31 PM, mabi wrote:
> Ah ok so standard CentOS would do it... I guess I missed the point, I
> thought Atomic Host is THE distribution to go with when using such
> platforms like okd.io/OpenShift <http://okd.io/OpenShift>...
>
> So maybe another question: what is CentOS Atomic Host good for?
>
Running general container runtimes like podman and buildah. 
>
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, January 29, 2019 7:24 PM, Daniel Walsh 
> wrote:
>
>> On 1/29/19 12:41 PM, mabi wrote:
>>> Thanks for your answer.
>>>
>>> Now this would be for a production server for okd.io 3.11 that's why
>>> I chose CentOS Atomic Host. As far as I know Fedora is not for
>>> production server usage right?
>>>
>>> So my question is: what do people use for production okd.io with
>>> cri-o as container runtime?
>>>
>> Standard OS's  Fedora/CentOS/RHEL.
>>
>>>
>>>
>>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Tuesday, January 29, 2019 1:20 PM, Daniel Walsh
>>>  <mailto:dwa...@redhat.com> wrote:
>>>
>>>> I would figure you need it on Fedora CoreOS.  We did some
>>>> experimenting with CRI-O in a system container but decided this
>>>> caused too many issues.
>>>>
>>>>
>>>> On 1/29/19 11:50 AM, Scott McCarty wrote:
>>>>> Chris/Derrick,
>>>>>     Have either of you ran into this?
>>>>>
>>>>> Best Regards
>>>>> Scott M
>>>>>
>>>>> On Fri, Jan 25, 2019 at 12:56 PM mabi >>>> <mailto:m...@protonmail.ch>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I would like to use CRI-O (https://cri-o.io/) on CentOS Atomic
>>>>> Host along with or instead of Docker but it looks like there
>>>>> are no cri-o packages for Atomic Host:
>>>>>
>>>>> # rpm-ostree install cri-o
>>>>> Checking out tree 4b20905... done
>>>>> Enabled rpm-md repositories: base updates extras
>>>>> rpm-md repo 'base' (cached); generated: 2018-11-25 16:00:34
>>>>> rpm-md repo 'updates' (cached); generated: 2019-01-24 13:56:44
>>>>> rpm-md repo 'extras' (cached); generated: 2018-12-10 16:00:03
>>>>> Importing metadata [=] 100%
>>>>> error: No package matches 'cri-o'
>>>>>
>>>>> Is there any other ways I can get CRI-O running on Atomic
>>>>> Host? and/or is it planned to be also available on Atomic
>>>>> Hosting in the near future?
>>>>>
>>>>> Regards,
>>>>> Mabi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> -- Scott McCarty, RHCA Product Management - Containers, Red Hat
>>>>> Enterprise Linux & OpenShift Email: smcca...@redhat.com
>>>>> <mailto:smcca...@redhat.com> Phone: 312-660-3535 Cell:
>>>>> 330-807-1043 Web: http://crunchtools.com Learning Container
>>>>> Engines by Demo: https://goo.gl/zMrLqR
>>>>>
>>>>
>>>
>>
>

Re: [atomic-devel] Install CRI-O on Atomic Host

[Daniel Walsh]

On 1/29/19 4:54 PM, mabi wrote:
> Thanks Chris for the tip regarding the extra repository to add, I will try it 
> out.
>
> Now I am wondering so what does Red Hat officially recommend or support if 
> one wants to use OpenShift (from okd.io) with CRI-O as container runtime?
>
> I can't find any official documentation mentioning which base OS should be 
> used if someone wants to use okd.io with cri-o... I thought that would be 
> CentOS Atomic Host but it looks line I am wrong here...
I would suggest Fedora. 
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, January 29, 2019 2:52 PM, Chris Negus  wrote:
>
>> I don't know the answer to the bigger question, since my understanding is 
>> the Red Hat doesn't support the use of CRI-O outside of OpenShift. As to 
>> getting CRI-O on a CentOS Atomic host, CRI-O isn't in the enabled repos by 
>> default. Add something like this to 
>> /etc/yum.repos.d/CentOS-OpneShift-Origin.repo:
>>
>> [centos-openshift-origin]
>> name=CentOS OpenShift Origin
>> baseurl=http://mirror.centos.org/centos/7/paas/x86_64/openshift-origin/
>> enabled=1
>>
>> Then you should be able to "rpm-ostree install" cri-o and cri-tools to try 
>> out CRI-O.
>>
>> -- Chris Negus
>>
>>> - Original Message -
>>>
 I would figure you need it on Fedora CoreOS.  We did some experimenting
 with CRI-O in a system container but decided this caused too many issues.
 On 1/29/19 11:50 AM, Scott McCarty wrote:

> Chris/Derrick,
>     Have either of you ran into this?
> Best Regards
> Scott M
> On Fri, Jan 25, 2019 at 12:56 PM mabi  mailto:m...@protonmail.ch> wrote:
>
> Hello,
>
> I would like to use CRI-O (https://cri-o.io/) on CentOS Atomic
> Host along with or instead of Docker but it looks like there are
> no cri-o packages for Atomic Host:
>
> # rpm-ostree install cri-o
> Checking out tree 4b20905... done
> Enabled rpm-md repositories: base updates extras
> rpm-md repo 'base' (cached); generated: 2018-11-25 16:00:34
> rpm-md repo 'updates' (cached); generated: 2019-01-24 13:56:44
> rpm-md repo 'extras' (cached); generated: 2018-12-10 16:00:03
> Importing metadata [=] 100%
> error: No package matches 'cri-o'
>
> Is there any other ways I can get CRI-O running on Atomic Host?
> and/or is it planned to be also available on Atomic Hosting in the
> near future?
>
> Regards,
> Mabi
>
>
> --
> -- Scott McCarty, RHCA Product Management - Containers, Red Hat
> Enterprise Linux & OpenShift Email: smcca...@redhat.com
> mailto:smcca...@redhat.com Phone: 312-660-3535 Cell: 330-807-1043
> Web: http://crunchtools.com Learning Container Engines by Demo:
> https://goo.gl/zMrLqR
>

Re: [atomic-devel] Install CRI-O on Atomic Host

[Daniel Walsh]

On 1/29/19 12:41 PM, mabi wrote:
> Thanks for your answer.
>
> Now this would be for a production server for okd.io 3.11 that's why I
> chose CentOS Atomic Host. As far as I know Fedora is not for
> production server usage right?
>
> So my question is: what do people use for production okd.io with cri-o
> as container runtime?
>
Standard OS's  Fedora/CentOS/RHEL.
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, January 29, 2019 1:20 PM, Daniel Walsh 
> wrote:
>
>> I would figure you need it on Fedora CoreOS.  We did some
>> experimenting with CRI-O in a system container but decided this
>> caused too many issues.
>>
>>
>> On 1/29/19 11:50 AM, Scott McCarty wrote:
>>> Chris/Derrick,
>>>     Have either of you ran into this?
>>>
>>> Best Regards
>>> Scott M
>>>
>>> On Fri, Jan 25, 2019 at 12:56 PM mabi >> <mailto:m...@protonmail.ch>> wrote:
>>>
>>> Hello,
>>>
>>> I would like to use CRI-O (https://cri-o.io/) on CentOS Atomic
>>> Host along with or instead of Docker but it looks like there are
>>> no cri-o packages for Atomic Host:
>>>
>>> # rpm-ostree install cri-o
>>> Checking out tree 4b20905... done
>>> Enabled rpm-md repositories: base updates extras
>>> rpm-md repo 'base' (cached); generated: 2018-11-25 16:00:34
>>> rpm-md repo 'updates' (cached); generated: 2019-01-24 13:56:44
>>> rpm-md repo 'extras' (cached); generated: 2018-12-10 16:00:03
>>> Importing metadata [=] 100%
>>> error: No package matches 'cri-o'
>>>
>>> Is there any other ways I can get CRI-O running on Atomic Host?
>>> and/or is it planned to be also available on Atomic Hosting in
>>> the near future?
>>>
>>> Regards,
>>> Mabi
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> -- Scott McCarty, RHCA Product Management - Containers, Red Hat
>>> Enterprise Linux & OpenShift Email: smcca...@redhat.com
>>> <mailto:smcca...@redhat.com> Phone: 312-660-3535 Cell: 330-807-1043
>>> Web: http://crunchtools.com Learning Container Engines by Demo:
>>> https://goo.gl/zMrLqR
>>
>>
>

Re: [atomic-devel] Install CRI-O on Atomic Host

[Daniel Walsh]

I would figure you need it on Fedora CoreOS.  We did some experimenting
with CRI-O in a system container but decided this caused too many issues.


On 1/29/19 11:50 AM, Scott McCarty wrote:
> Chris/Derrick,
>     Have either of you ran into this?
>
> Best Regards
> Scott M
>
> On Fri, Jan 25, 2019 at 12:56 PM mabi  > wrote:
>
> Hello,
>
> I would like to use CRI-O (https://cri-o.io/) on CentOS Atomic
> Host along with or instead of Docker but it looks like there are
> no cri-o packages for Atomic Host:
>
> # rpm-ostree install cri-o
> Checking out tree 4b20905... done
> Enabled rpm-md repositories: base updates extras
> rpm-md repo 'base' (cached); generated: 2018-11-25 16:00:34
> rpm-md repo 'updates' (cached); generated: 2019-01-24 13:56:44
> rpm-md repo 'extras' (cached); generated: 2018-12-10 16:00:03
> Importing metadata [=] 100%
> error: No package matches 'cri-o'
>
> Is there any other ways I can get CRI-O running on Atomic Host?
> and/or is it planned to be also available on Atomic Hosting in the
> near future?
>
> Regards,
> Mabi
>
>
>
>
>
>
>
>
> -- 
> -- Scott McCarty, RHCA Product Management - Containers, Red Hat
> Enterprise Linux & OpenShift Email: smcca...@redhat.com
>  Phone: 312-660-3535 Cell: 330-807-1043
> Web: http://crunchtools.com Learning Container Engines by Demo:
> https://goo.gl/zMrLqR

Re: [atomic-devel] docker optionsin /etc/sysconfig/docker

[Daniel Walsh]

On 06/02/2018 12:29 PM, arnaud gaboury wrote:



On Sat, Jun 2, 2018 at 4:21 PM Colin Walters > wrote:




On Sat, Jun 2, 2018, at 8:30 AM, arnaud gaboury wrote:
>
>  # systemctl edit docker.service
> [Service]
> Execstart=
> ExecStart=/usr/bin/dockerd --selinux-enabled
> # systemctl restart docker
> # docker run fedora cat /proc/self/attr/current
> system_u:system_r:container_t:s0:c81,c142#

See:
/usr/lib/systemd/system/docker.service
You need all that stuff in the default ExecStart= to have the
config files work.


I am confused between /etc/sysconfig/docker and 
/etc/docker/daemon.json. It seems to me there is some redundancy. As a 
note, I run Arch and the /etc/sysconfig has been removed since long.

After some tests:

--
1- no /etc/docker/daemon.json, no /etc/sysconfig/docker, no 
docker.service override

# docker run fedora cat /proc/self/attr/current
system_u:system_r:spc_t:s0#
2- no /etc/docker/daemon.json, no /etc/sysconfig/docker, 
docker.service override

# docker run fedora cat /proc/self/attr/current
system_u:system_r:container_t:s0:c499,c950#
3- /etc/docker/daemon.json, no /etc/sysconfig/docker, no 
docker.service override

# docker run fedora cat /proc/self/attr/current
system_u:system_r:container_t:s0:c471,c600#
4- no /etc/docker/daemon.json, /etc/sysconfig/docker, no 
docker.service override

# docker run fedora cat /proc/self/attr/current
system_u:system_r:spc_t:s0#
-

As you can see, some settings will not work. As for my "test", 
solution 3 (/etc/docker/daemon.json, no /etc/sysconfig/docker, no 
docker.service override) is the one I will use.



Ok you can add the selinux-enabled field to /etc/docker/daemon.json 
(Although I am not aware of the syntax.) I thought you were doing this 
testing with the Projectatomic/docker.  It looks like you are working 
with the upstream docker-ce, which I am sad to say seems to not enable 
selinux by default at least on Arch.

Re: [atomic-devel] docker optionsin /etc/sysconfig/docker

[Daniel Walsh]

On 06/01/2018 04:31 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 9:49 PM Daniel Walsh <mailto:dwa...@redhat.com>> wrote:


On 06/01/2018 01:52 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 7:46 PM Daniel Walsh mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 01:44 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 7:12 PM Daniel Walsh
mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 01:08 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 6:53 PM Daniel Walsh
mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 12:33 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 6:25 PM arnaud gaboury
mailto:arnaud.gabo...@gmail.com>> wrote:

    On Fri, Jun 1, 2018 at 6:19 PM Daniel Walsh
mailto:dwa...@redhat.com>>
wrote:

On 06/01/2018 12:07 PM, arnaud gaboury wrote:



    On Fri, Jun 1, 2018 at 5:04 PM Daniel
Walsh mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 10:58 AM, arnaud
gaboury wrote:
> I am switching from fedora server
to Atomic.
>
> In the old world, my
"/etc/sysconfig/docker" file had the
content:
> OPTIONS="--selinux-enable"
> Now, after running the script
container-storage-setup to create a thin
> pool volume, the file with options
is now
> "/etc/sysconfig/docker-storage" and
has the following content:
> -
>
DOCKER_STORAGE_OPTIONS="--storage-driver
devicemapper --storage-opt
> dm.fs=xfs --storage-opt
>
dm.thinpooldev=/dev/mapper/vg--docker-docker--pool
--storage-opt
> dm.use_deferred_removal=true
--storage-opt
dm.use_deferred_deletion=true "
> -
>
> Nothing about SELinux. Is it
expected? Shall I write this option
> somewhere else?
>
> Thank you.

I think it should have that flag. If
you run a container what does cat
/proc/self/attr/current show?



# docker run hello-world
.
# cat /proc/self/attr/current
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023#




Should have been more clear

docker run fedora cat /proc/self/attr/current


What does this command show?


Of course I would prefer

podman run fedora cat /proc/self/attr/current


I didn't know this command...so many new stuff
to learn !


--
 % man podman
No manual entry for podman


:-(   snif



Thats weird.

rpm -q podman
podman-0.5.4-1.git1f2e2a2.fc28.x86_64

Their should be man pages. You doing this on atomic
host?


YES.

Atomic host excludes man pages.
You can read lots of docs on podman at
https://github.com/projectatomic/libpod/

Man pages are here
https://github.com/projectatomic/libpod/blob/master/commands.md

You never showed me the output of the docker command.



Sorry for this confusion


root@control2➤➤ ~ # docker run fedora cat /proc/self/attr/current
Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
e71c36a80ba9: Pull complete
Digest:
sha256:7ae08e5637170eb47c01e315b6e64e0d48c6200d2942c695d0bee61b38c65b39
Status: Downloaded newer image for fedora:latest
system_u:system_r:spc_t:s0#

Re: [atomic-devel] docker optionsin /etc/sysconfig/docker

[Daniel Walsh]

On 06/01/2018 01:52 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 7:46 PM Daniel Walsh <mailto:dwa...@redhat.com>> wrote:


On 06/01/2018 01:44 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 7:12 PM Daniel Walsh mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 01:08 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 6:53 PM Daniel Walsh
mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 12:33 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 6:25 PM arnaud gaboury
mailto:arnaud.gabo...@gmail.com>> wrote:

On Fri, Jun 1, 2018 at 6:19 PM Daniel Walsh
mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 12:07 PM, arnaud gaboury wrote:



    On Fri, Jun 1, 2018 at 5:04 PM Daniel Walsh
mailto:dwa...@redhat.com>>
wrote:

On 06/01/2018 10:58 AM, arnaud gaboury wrote:
> I am switching from fedora server to Atomic.
>
> In the old world, my
"/etc/sysconfig/docker" file had the content:
> OPTIONS="--selinux-enable"
> Now, after running the script
container-storage-setup to create a thin
> pool volume, the file with options is now
> "/etc/sysconfig/docker-storage" and has
the following content:
> -
> DOCKER_STORAGE_OPTIONS="--storage-driver
devicemapper --storage-opt
> dm.fs=xfs --storage-opt
>
dm.thinpooldev=/dev/mapper/vg--docker-docker--pool
--storage-opt
> dm.use_deferred_removal=true
--storage-opt dm.use_deferred_deletion=true "
> -
>
> Nothing about SELinux. Is it expected?
Shall I write this option
> somewhere else?
>
> Thank you.

I think it should have that flag. If you
run a container what does cat
/proc/self/attr/current show?



# docker run hello-world
.
# cat /proc/self/attr/current
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023#




Should have been more clear

docker run fedora cat /proc/self/attr/current


What does this command show?


Of course I would prefer

podman run fedora cat /proc/self/attr/current


I didn't know this command...so many new stuff to
learn !


--
 % man podman
No manual entry for podman


:-(   snif



Thats weird.

rpm -q podman
podman-0.5.4-1.git1f2e2a2.fc28.x86_64

Their should be man pages. You doing this on atomic host?


YES.

Atomic host excludes man pages.
You can read lots of docs on podman at
https://github.com/projectatomic/libpod/

Man pages are here
https://github.com/projectatomic/libpod/blob/master/commands.md

You never showed me the output of the docker command.



Sorry for this confusion


root@control2➤➤ ~ # docker run fedora cat /proc/self/attr/current
Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
e71c36a80ba9: Pull complete
Digest: 
sha256:7ae08e5637170eb47c01e315b6e64e0d48c6200d2942c695d0bee61b38c65b39

Status: Downloaded newer image for fedora:latest
system_u:system_r:spc_t:s0#
Ok that indicates SELinux is disabled in the daemon.  Adding back the 
--selinux-enabled will fix this issue.


Lokesh, Franticek, the docker we are shipping on atomic host does not 
have SELinux enabled?







I did in one previous email (06:25)

-
  # podman run fedora cat /proc/self/attr/current
Trying to pull docker.io/fedora:latest...Getting
<http://docker.io/fedora:latest...Getting> image source signatures
Copying blob
sha256:e71c36a80ba912dd7a5a9f2f2d6136c148afa19bc7d024bd616b74a0bc7a2774
 82.57 MB / 82.57 MB
[

Re: [atomic-devel] docker optionsin /etc/sysconfig/docker

[Daniel Walsh]

On 06/01/2018 01:44 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 7:12 PM Daniel Walsh <mailto:dwa...@redhat.com>> wrote:


On 06/01/2018 01:08 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 6:53 PM Daniel Walsh mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 12:33 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 6:25 PM arnaud gaboury
mailto:arnaud.gabo...@gmail.com>>
wrote:

On Fri, Jun 1, 2018 at 6:19 PM Daniel Walsh
mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 12:07 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 5:04 PM Daniel Walsh
mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 10:58 AM, arnaud gaboury wrote:
> I am switching from fedora server to Atomic.
>
> In the old world, my "/etc/sysconfig/docker"
file had the content:
> OPTIONS="--selinux-enable"
> Now, after running the script
container-storage-setup to create a thin
> pool volume, the file with options is now
> "/etc/sysconfig/docker-storage" and has the
following content:
> -
> DOCKER_STORAGE_OPTIONS="--storage-driver
devicemapper --storage-opt
> dm.fs=xfs --storage-opt
>
dm.thinpooldev=/dev/mapper/vg--docker-docker--pool
--storage-opt
> dm.use_deferred_removal=true --storage-opt
dm.use_deferred_deletion=true "
> -
>
> Nothing about SELinux. Is it expected? Shall
I write this option
> somewhere else?
>
> Thank you.

I think it should have that flag. If you run a
container what does cat
/proc/self/attr/current show?



# docker run hello-world
.
# cat /proc/self/attr/current
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023#



Should have been more clear

docker run fedora cat /proc/self/attr/current


What does this command show?


Of course I would prefer

podman run fedora cat /proc/self/attr/current


I didn't know this command...so many new stuff to learn !


--
 % man podman
No manual entry for podman


:-(   snif



Thats weird.

rpm -q podman
podman-0.5.4-1.git1f2e2a2.fc28.x86_64

Their should be man pages. You doing this on atomic host?


YES.

Atomic host excludes man pages.
You can read lots of docs on podman at
https://github.com/projectatomic/libpod/

Man pages are here
https://github.com/projectatomic/libpod/blob/master/commands.md

You never showed me the output of the docker command.


I did in one previous email (06:25)

-
  # podman run fedora cat /proc/self/attr/current
Trying to pull docker.io/fedora:latest...Getting 
<http://docker.io/fedora:latest...Getting> image source signatures
Copying blob 
sha256:e71c36a80ba912dd7a5a9f2f2d6136c148afa19bc7d024bd616b74a0bc7a2774
 82.57 MB / 82.57 MB 
[=] 20s
Copying config 
sha256:cc510acfcd701a409014118d5f417f0022520802a26c650866b8a9594d75f3a7
 2.29 KB / 2.29 KB 
[] 0s

Writing manifest to image destination
Storing signatures
system_u:system_r:container_t:s0:c377,c551#
-


Thats the output of podman, I need docker.

Re: [atomic-devel] docker optionsin /etc/sysconfig/docker

[Daniel Walsh]

On 06/01/2018 01:08 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 6:53 PM Daniel Walsh <mailto:dwa...@redhat.com>> wrote:


On 06/01/2018 12:33 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 6:25 PM arnaud gaboury
mailto:arnaud.gabo...@gmail.com>> wrote:

On Fri, Jun 1, 2018 at 6:19 PM Daniel Walsh
mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 12:07 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 5:04 PM Daniel Walsh
mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 10:58 AM, arnaud gaboury wrote:
> I am switching from fedora server to Atomic.
>
> In the old world, my "/etc/sysconfig/docker" file
had the content:
> OPTIONS="--selinux-enable"
> Now, after running the script
container-storage-setup to create a thin
> pool volume, the file with options is now
> "/etc/sysconfig/docker-storage" and has the
following content:
> -
> DOCKER_STORAGE_OPTIONS="--storage-driver
devicemapper --storage-opt
> dm.fs=xfs --storage-opt
> dm.thinpooldev=/dev/mapper/vg--docker-docker--pool
--storage-opt
> dm.use_deferred_removal=true --storage-opt
dm.use_deferred_deletion=true "
> -
>
> Nothing about SELinux. Is it expected? Shall I
write this option
> somewhere else?
>
> Thank you.

I think it should have that flag. If you run a
container what does cat
/proc/self/attr/current show?



# docker run hello-world
.
# cat /proc/self/attr/current
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023#



Should have been more clear

docker run fedora cat /proc/self/attr/current


What does this command show?


Of course I would prefer

podman run fedora cat /proc/self/attr/current


I didn't know this command...so many new stuff to learn !


--
 % man podman
No manual entry for podman


:-(   snif



Thats weird.

rpm -q podman
podman-0.5.4-1.git1f2e2a2.fc28.x86_64

Their should be man pages. You doing this on atomic host?


YES.

Atomic host excludes man pages.
You can read lots of docs on podman at
https://github.com/projectatomic/libpod/

Man pages are here
https://github.com/projectatomic/libpod/blob/master/commands.md

You never showed me the output of the docker command.

docker run fedora cat /proc/self/attr/current

BTW Podman is new container runtime for running pods and containers, 
modeled after the Docker CLI, but does not use a container daemon to do 
it's thing.


---
root@control2➤➤ ~ # man podman
No manual entry for podman
root@control2➤➤ ~ # rpm -q podman
podman-0.5.3-2.gitdc3f9df.fc28.x86_64
root@control2➤➤ ~ # rpm -q man-pages
man-pages-4.15-1.fc28.noarch
root@control2➤➤ ~ # rpm -q man-db
man-db-2.7.6.1-13.fc28.x86_64
-





 # podman run fedora cat /proc/self/attr/current
Trying to pull docker.io/fedora:latest...Getting
<http://docker.io/fedora:latest...Getting> image source
signatures
Copying blob
sha256:e71c36a80ba912dd7a5a9f2f2d6136c148afa19bc7d024bd616b74a0bc7a2774
 82.57 MB / 82.57 MB
[=] 20s
Copying config
sha256:cc510acfcd701a409014118d5f417f0022520802a26c650866b8a9594d75f3a7
 2.29 KB / 2.29 KB
[] 0s
Writing manifest to image destination
Storing signatures
system_u:system_r:container_t:s0:c377,c551#
 

Re: [atomic-devel] docker optionsin /etc/sysconfig/docker

[Daniel Walsh]

On 06/01/2018 12:33 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 6:25 PM arnaud gaboury 
mailto:arnaud.gabo...@gmail.com>> wrote:


On Fri, Jun 1, 2018 at 6:19 PM Daniel Walsh mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 12:07 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 5:04 PM Daniel Walsh
mailto:dwa...@redhat.com>> wrote:

On 06/01/2018 10:58 AM, arnaud gaboury wrote:
> I am switching from fedora server to Atomic.
>
> In the old world, my "/etc/sysconfig/docker" file had
the content:
> OPTIONS="--selinux-enable"
> Now, after running the script container-storage-setup
to create a thin
> pool volume, the file with options is now
> "/etc/sysconfig/docker-storage" and has the following
content:
> -
> DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper
--storage-opt
> dm.fs=xfs --storage-opt
> dm.thinpooldev=/dev/mapper/vg--docker-docker--pool
--storage-opt
> dm.use_deferred_removal=true --storage-opt
dm.use_deferred_deletion=true "
> -
>
> Nothing about SELinux. Is it expected? Shall I write
this option
> somewhere else?
>
> Thank you.

I think it should have that flag. If you run a container
what does cat
/proc/self/attr/current show?



# docker run hello-world
.
# cat /proc/self/attr/current
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023#



Should have been more clear

docker run fedora cat /proc/self/attr/current


What does this command show?


Of course I would prefer

podman run fedora cat /proc/self/attr/current


I didn't know this command...so many new stuff to learn !


--
 % man podman
No manual entry for podman


:-(   snif



Thats weird.

rpm -q podman
podman-0.5.4-1.git1f2e2a2.fc28.x86_64

Their should be man pages. You doing this on atomic host?



 # podman run fedora cat /proc/self/attr/current
Trying to pull docker.io/fedora:latest...Getting
<http://docker.io/fedora:latest...Getting> image source signatures
Copying blob
sha256:e71c36a80ba912dd7a5a9f2f2d6136c148afa19bc7d024bd616b74a0bc7a2774
 82.57 MB / 82.57 MB
[=] 20s
Copying config
sha256:cc510acfcd701a409014118d5f417f0022520802a26c650866b8a9594d75f3a7
 2.29 KB / 2.29 KB
[] 0s
Writing manifest to image destination
Storing signatures
system_u:system_r:container_t:s0:c377,c551#
 

Re: [atomic-devel] docker optionsin /etc/sysconfig/docker

[Daniel Walsh]

On 06/01/2018 12:07 PM, arnaud gaboury wrote:



On Fri, Jun 1, 2018 at 5:04 PM Daniel Walsh <mailto:dwa...@redhat.com>> wrote:


On 06/01/2018 10:58 AM, arnaud gaboury wrote:
> I am switching from fedora server to Atomic.
>
> In the old world, my "/etc/sysconfig/docker" file had the content:
> OPTIONS="--selinux-enable"
> Now, after running the script container-storage-setup to create
a thin
> pool volume, the file with options is now
> "/etc/sysconfig/docker-storage" and has the following content:
> -
> DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper --storage-opt
> dm.fs=xfs --storage-opt
> dm.thinpooldev=/dev/mapper/vg--docker-docker--pool --storage-opt
> dm.use_deferred_removal=true --storage-opt
dm.use_deferred_deletion=true "
> -
>
> Nothing about SELinux. Is it expected? Shall I write this option
> somewhere else?
>
> Thank you.

I think it should have that flag. If you run a container what does
cat
/proc/self/attr/current show?



# docker run hello-world
.
# cat /proc/self/attr/current
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023#



Should have been more clear

docker run fedora cat /proc/self/attr/current

Of course I would prefer

podman run fedora cat /proc/self/attr/current

Re: [atomic-devel] docker optionsin /etc/sysconfig/docker

[Daniel Walsh]

On 06/01/2018 10:58 AM, arnaud gaboury wrote:

I am switching from fedora server to Atomic.

In the old world, my "/etc/sysconfig/docker" file had the content:
OPTIONS="--selinux-enable"
Now, after running the script container-storage-setup to create a thin 
pool volume, the file with options is now 
"/etc/sysconfig/docker-storage" and has the following content:

-
DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper --storage-opt 
dm.fs=xfs --storage-opt 
dm.thinpooldev=/dev/mapper/vg--docker-docker--pool --storage-opt 
dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true "

-

Nothing about SELinux. Is it expected? Shall I write this option 
somewhere else?


Thank you.


I think it should have that flag. If you run a container what does cat 
/proc/self/attr/current show?

[atomic-devel] Podman-0.4.4 was just releeased.

[Daniel Walsh]

This version no longer  requires the Buildah package to be installed but 
can still do podman builds.  It is 36 Mb in size and I believe should 
now be considered for inclusion into the atomic host by default as a 
container runtime.

Re: [atomic-devel] Proposing moving https://github.com/stefwalter/oci-kvm-hook into projectatomic

[Daniel Walsh]

On 02/16/2018 02:33 PM, Colin Walters wrote:

On Fri, Feb 16, 2018, at 2:29 PM, Daniel Walsh wrote:


Does this actually work?

Yes =)   For example it broke and we fixed it e.g.:
https://github.com/stefwalter/oci-kvm-hook/pull/4


I would figure the device cgroup would prevent
use of the kvm device inside a container unless you also modified the
cgroup?


podman run --device /dev/kvm

I guess the thing is personally, I see it as quite safe to expose
the KVM device nowadays, and having to annotate containers
explicitly for it is annoying, particularly in the Kube/OpenShift
case.  That said the linked thread above contains a proposal
for the Kube equivalent of this.


Finally we have a different way of handling this in CRI-O and Podman, 
but I will open an issue when this gets moved.  There is a new config 
file to allow us to only use the hook if necessary.

Re: [atomic-devel] Proposing moving https://github.com/stefwalter/oci-kvm-hook into projectatomic

[Daniel Walsh]

On 02/16/2018 02:23 PM, Colin Walters wrote:

Hi,

In working on our CI (and just locally in containers in general), I
find https://github.com/stefwalter/oci-kvm-hook to be very, very
useful.  Yes, there are other ways one can do it; see the thread in
https://github.com/stefwalter/oci-kvm-hook/issues/5

I propose moving it into our organization to raise its visibility and
have it not be "owned" by one person in general.

Any thoughts/objections?  (Or other ways people do qemu-in-containers?)

Does this actually work?  I would figure the device cgroup would prevent 
use of the kvm device inside a container unless you also modified the 
cgroup?



podman run --device /dev/kvm

...


Will also add the device.

And for those stuck in the past :^)

docker run --device /dev/kvm

Re: [atomic-devel] Atomic BOF at RH Summit

[Daniel Walsh]

On 02/15/2018 05:43 PM, Josh Berkus wrote:

Folks,

An Atomic BOF session has been confirmed for RH Summit in May.  I will
be organizing it since Sanja won't be at this year's Summit.

Who will be at RH Summit?  I'd like 4-6 people to talk about various
Atomic projects before we take questions.

I will be there and would be glad to cover a variety of tools. Just hope 
that we don't have a conflict on the schedule.

Re: [atomic-devel] atomic pull from containers-storage

[Daniel Walsh]

On 02/01/2018 04:36 AM, Thorsten Scherf wrote:

On Thu, Feb 1, 2018 at 5:16 AM, Chris Negus  wrote:

- Original Message -

HI,

there was already a similar request on the list before for which I
have a follow-up question.

Let's say I have an image created by buildah and the the image has
been written to the storage location as defined in
/etc/containers/storage.conf. The default is
/var/lib/containers/storage. Now I want to pull the image from this
storage and store it into an ostree repository using the atomic tool.
This does't seem to work.

Let's take a look at the buildah default storage:


# sudo buildah images
IMAGE ID IMAGE NAME
CREATED AT SIZE
0e04578ef6b7 docker.io/library/foobar:latest
Jan 28, 2018 09:48 251 MB

When I try to pull this image with atomic, it does not work as expected:

# sudo atomic pull --storage ostree containers-storage:foobar:latest
The image `containers-storage:foobar:latest` is not fully qualified.
The default registry configured for Skopeo will be used.
FATA[] Invalid source name
docker://containers-storage:foobar:latest: invalid reference format

Is this because atomic does not support the containers-storage
transport? What else should I use in order to pull an image from this
storage?

I can't find "containers-storage" referenced in any atomic man pages. There is 
ostree storage, but I couldn't get that or containers-storage to work as a place to pull 
from. Maybe someone who knows more that I do could shed some light on this.

Same here. I think that would be a RfE for atomic.


One thing that did work is to push the image created by buildah to a registry, then use 
atomic pull. With the docker-distribution service running on the local host, I did this 
after building an image with buildah named "foobar":

# buildah push --tls-verify=false foobar:latest localhost:5000/foobar:latest
# atomic pull --storage ostree http:localhost:5000/foobar
# atomic images list | grep foobar
localhost:5000/foobar   latest   a76583269cbd   2018-01-31 22:04   31.29 MB 
  ostree

I tried that too. But on a build system where I build images with
buildah to avoid the need to have any docker service installed, I just
want atomic to be able to pull an image out of the storage that is
used by buildah.

Cheers
Thorsten

Yes now that podman is almost ready, we will add containers/storage 
support to atmomic.  Just need podman packages.

Re: [atomic-devel] Docker version updates planned?

[Daniel Walsh]

On 12/13/2017 01:51 PM, Richard Alloway wrote:

Hi!

I've been taking a look at Atomic OS in my "free" time and have 
noticed that it is shipped with Docker 1.12.x and/or 1.13.x.


Those branches appear to be deprecated.

Are there any plans to move to the 17.x.x series (Docker CE/EE)?

Thanks!

-Rich

-
He's just this guy... ya know?!
-


We are sticking with the docker version that is supported by kubernetes 
for now.  Our plan going forward is to ship newer versions of docker in 
a system container.  My goal is actually to remove container runtimes 
from atomic host and allow users to choice the version of container 
runtime they want either through System Containers or using rpm-ostree 
layering.

[atomic-devel] New blog on CRI-O support for Kubernetes

[Daniel Walsh]

https://medium.com/cri-o/cri-o-support-for-kubernetes-4934830eb98e

Re: [atomic-devel] Creating a new repo called libpod.

[Daniel Walsh]

On 11/01/2017 11:25 AM, Dusty Mabe wrote:


On 11/01/2017 11:17 AM, Daniel Walsh wrote:

Basically we are looking to move kpod out of the
kubernetes-incubator/cri-o project to allow it to grow on its own.  We
plan on building out the library for creating container pods to such an
extent that CRI-O could use it as well as kpod.

Since kpod is outgrowing the original goals of the CRI-O project we
thought it best to move it to its own repository.

We plan on continuing to have kpod, buildah, cri-o and skopeo all able
to share the same containers/storage and containers/image libraries.

Unfortunately installing them all on a system will mean you get statically
compiled duplicate copies of containers/storage and containers/image. I think
in recent go versions "shared library" support has been getting better. Could
we start to do some of this for our go tools that use common libraries?
Well this is no worse then what we have now, since kpod and crio were 
not sharing the same code base.

As shared libraries become better we will definitely take advantage.



Note: There is a good change the kpod will change it's name, but for now
we will keep it as kpod, and the repo will be based on the library name
to prevent confusion.


Dan

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/06/2017 10:14 AM, Mark Wielaard wrote:

On Mon, 2017-09-18 at 16:48 +0200, Tomas Tomecek wrote:

we managed to move tools container from Fedora Dockerfiles github
repo to Fedora infra [1]. As a side effects, we put systemtap in a
dedicated container.

We would very much appreciate your feedback here

What determines what goes into tools and what in a separate container
(like systemtap). I see the tools container has strace, gcc, gdb, perf,
etc. But not other development tools like binutils, elfutils and
valgrind. Will those be added or will they come in some separate
container?

Thanks,

Mark

Right now there is a an effort going on to shrink the tools container, 
it has grown huge.


I would prefer you create a debug container and put all of these tools 
in there.

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:55 PM, Frank Ch. Eigler wrote:

Hi, Dan -

On Thu, Oct 05, 2017 at 01:49:48PM -0400, Daniel Walsh wrote:

[...]
But really for something like this, it would be better to just run
it --privileged.  There is [no] security confinement present in what
you are doing.

Yup.  I thought "atomic run --spc" would imply "docker run --privileged"
but it doesn't seem to.

- FChE
___
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


No it looks like it is just running the label that is in the container 
image.

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:47 PM, Frank Ch. Eigler wrote:

Hi, Dan -



Could you show the docker line that atomic run is executing?

% atomic run --spc candidate-registry.fedoraproject.org/f26/systemtap 
/usr/share/systemtap/examples/io/iotop.stp
docker run --cap-add SYS_MODULE -v /sys/kernel/debug:/sys/kernel/debug -v 
/usr/src/kernels:/usr/src/kernels -v /usr/lib/modules/:/usr/lib/modules/ -v 
/usr/lib/debug:/usr/lib/debug -t -i --name systemtap-spc 
candidate-registry.fedoraproject.org/f26/systemtap 
/usr/share/systemtap/examples/io/iotop.stp

... which fails.  But a hand-run % docker run, with "--security-opt
label:disable" added in the front works for me.



The LABEL would be the preferred way.

Sure, just someone(tm) needs to find the Dockerfile in git.  I
couldn't find it from a dozen minutes reading
https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
and pals.


- FChE


But really for something like this, it would be better to just run it 
--privileged.  There is on security confinement present in what you are 
doing.

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:38 PM, Jeremy Eder wrote:

I don't see any avc when it fails while label:disable is set.
I ran semodule -DB and retried.  I now see dontaudit stuff but still 
no interesting denials.


I'm not sure if you were talking to me or Frank with the atomic 
command line...


I pulled the label out docker inspect on the systemtap image so I can 
run it manually.  Here is what I am running.

All I have added is the --security-opt label:disable part.

# docker run --security-opt label:disable --cap-add SYS_ADMIN -v 
/sys/kernel/debug:/sys/kernel/debug -v 
/usr/src/kernels:/usr/src/kernels -v 
/usr/lib/modules/:/usr/lib/modules/ -v /usr/lib/debug:/usr/lib/debug 
-t -i --name systemtap 
candidate-registry.fedoraproject.org/f26/systemtap 
<http://candidate-registry.fedoraproject.org/f26/systemtap>



Should be SYS_MODULE not SYS_ADMIN or maybe both.

I also tried with --security-opt seccomp:unconfimed.  That did not help.

Adding --privileged to the above command line, and systemtap works.

This is likely the key difference between why systemtap has always 
worked in the rhel-tools container...the label on that image includes 
--privileged.




On Thu, Oct 5, 2017 at 1:25 PM, Daniel Walsh <dwa...@redhat.com 
<mailto:dwa...@redhat.com>> wrote:


On 10/05/2017 01:18 PM, Jeremy Eder wrote:

setenforce 0 works...security-opt label:disable does not.

On Thu, Oct 5, 2017 at 1:06 PM, Daniel Walsh <dwa...@redhat.com
<mailto:dwa...@redhat.com>> wrote:

On 10/05/2017 01:00 PM, Frank Ch. Eigler wrote:

wcohen forwarded:

[...]

 [root@dhcp23-91 ~]# atomic run --spc
candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>
<http://candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>>
 docker run --cap-add SYS_MODULE -v
/sys/kernel/debug:/sys/kernel/debug -v
/usr/src/kernels:/usr/src/kernels -v
/usr/lib/modules/:/usr/lib/modules/ -v
/usr/lib/debug:/usr/lib/debug -t -i --name
systemtap-spc
candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>
<http://candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>>
  [...]
 ERROR: Couldn't insert module

'/tmp/stapNEjJDX/stap_4f013e7562b546a0316af840de9f0713_8509.ko':
Operation not permitted
[...]

I bet
# setenforce 0
makes it work for you.  As per audit.log:

type=AVC msg=audit(1507222590.683:7940): avc:  denied  {
module_load }
for  pid=7595 comm="staprun"
scontext=system_u:system_r:container_t:s0:c534,c921
tcontext=system_u:system_r:container_t:s0:c534,c921
tclass=system permissive=1


- FChE
___
devel mailing list -- de...@lists.fedoraproject.org
<mailto:de...@lists.fedoraproject.org>
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>


Rather then putting the system into permissive mode, you
should run a privileged container or at least disable SELinux
protections.


docker run -ti --security-opt label:disable ...





-- 


-- Jeremy Eder


Could you show me the AVC you get when you do the label:disable?





--

-- Jeremy Eder

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:18 PM, Jeremy Eder wrote:

setenforce 0 works...security-opt label:disable does not.

On Thu, Oct 5, 2017 at 1:06 PM, Daniel Walsh <dwa...@redhat.com 
<mailto:dwa...@redhat.com>> wrote:


On 10/05/2017 01:00 PM, Frank Ch. Eigler wrote:

wcohen forwarded:

[...]

   [root@dhcp23-91 ~]# atomic run --spc
candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>
<http://candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>>
 docker run --cap-add SYS_MODULE -v
/sys/kernel/debug:/sys/kernel/debug -v
/usr/src/kernels:/usr/src/kernels -v
/usr/lib/modules/:/usr/lib/modules/ -v
/usr/lib/debug:/usr/lib/debug -t -i --name
systemtap-spc
candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>
<http://candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>>
  [...]
 ERROR: Couldn't insert module
'/tmp/stapNEjJDX/stap_4f013e7562b546a0316af840de9f0713_8509.ko':
Operation not permitted
[...]

I bet
# setenforce 0
makes it work for you.  As per audit.log:

type=AVC msg=audit(1507222590.683:7940): avc: denied  {
module_load }
for  pid=7595 comm="staprun"
scontext=system_u:system_r:container_t:s0:c534,c921
tcontext=system_u:system_r:container_t:s0:c534,c921
tclass=system permissive=1


- FChE
___
devel mailing list -- de...@lists.fedoraproject.org
<mailto:de...@lists.fedoraproject.org>
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>


Rather then putting the system into permissive mode, you should
run a privileged container or at least disable SELinux protections.


docker run -ti --security-opt label:disable ...





--

-- Jeremy Eder


Could you show me the AVC you get when you do the label:disable?

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:11 PM, Frank Ch. Eigler wrote:

Hi, Dan -


[...]
Rather then putting the system into permissive mode, you should run
a privileged container

"atomic run --spc " fails similarly on f26, despite its
underlying "docker run --cap-add SYS_MODULE ..." parts.


or at least disable SELinux protections.

docker run -ti --security-opt label:disable ...

Is there an atomic(1) command line equivalent for this?  Or would
one have to put the security-option bits into the Dockerfile LABEL?


- FChE
___
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Could you show the docker line that atomic run is executing?  The LABEL 
would be the


preferred way.

Re: [atomic-devel] Who got accepted to Kubecon?

[Daniel Walsh]

On 09/28/2017 10:29 AM, Josh Berkus wrote:

Folks:

- who got a talk accepted to KubeCon US?

Mrunal got CRI-O Talk accepted.

- who didn't get a talk accepted but wants to go anyway?

I got rejected. But I plan on going and presenting at openshift commons.


Let me know, I need to figure out passes for the conference.

Re: [atomic-devel] Can anyone do DevOpsDays Boston?

[Daniel Walsh]

On 09/06/2017 05:16 PM, Josh Berkus wrote:

This is kinda last-minute, but I'm hoping some folks in the Boston area
might be interested in proposing an Open Spaces session on Atomic, new
container tools, or other of our projects at DevOpsDays Boston.

If you're interested in going, I can cover your registration from
community funds.  However, you need to promise to pitch an Open Spaces
session.

https://www.devopsdays.org/events/2017-boston/program/

I can do the 18th and do propose a talk on New Container Tools 
CRI-O/Buildah/Skopeo/System Containers.

Re: [atomic-devel] Lunch on Thursday for team meeting during Flock?

[Daniel Walsh]

On 08/21/2017 08:16 PM, Josh Berkus wrote:

Folks,

Since pretty much no evenings are available, could folks meet up durning
Thursday Lunch to do an Atomic WG meeting/discussion?


SGTM

[atomic-devel] Buildah is all about getting your container images fit.

[Daniel Walsh]

New Blog on some interesting advantages of using Buildah to build 
container images.


http://www.projectatomic.io/blog/2017/08/buildah-getting-fit/

Please Social Media this.

Re: [atomic-devel] Announcing CRI-O 1.0.0-beta.0

[Daniel Walsh]

On 08/03/2017 10:05 AM, Mrunal Patel wrote:


We are happy to announce the release of CRI-O v1.0.0.beta.0 
. 
With this release, we added support for OCI 1.0 specifications.
Big thanks to our maintainers and contributors from Red Hat, Intel, 
SUSE, Hyper, IBM and others.


Highlights of the release:

  * OCI 1.0 runtime and image specifications support.
  * Additional registry support.
See
https://medium.com/cri-o/default-container-registry-revisited-50b32dd808fe

  * Daemon pids-limit support.
cri-o daemon now supports a default pid-limit on all containers to
prevent fork-bombs. This is configurable by admins through a flag
or /etc/crio/crio.conf.
  * Configurable image volume support.
See

https://medium.com/cri-o/cri-o-configurable-image-volume-support-dda7b54f4bda


  * Bugs and stability fixes.

We are continuing to focus on bugs and stability improvements for 1.0.

Thanks,

CRI-O team.


Please Social Media this out.

https://medium.com/cri-o/announcing-cri-o-1-0-0-beta-0-f593637343b2

Re: [atomic-devel] [aos-devel] Announcing CRI-O 1.0.0-beta.0

[Daniel Walsh]

On 08/03/2017 10:05 AM, Mrunal Patel wrote:


We are happy to announce the release of CRI-O v1.0.0.beta.0 
. 
With this release, we added support for OCI 1.0 specifications.
Big thanks to our maintainers and contributors from Red Hat, Intel, 
SUSE, Hyper, IBM and others.


Highlights of the release:

  * OCI 1.0 runtime and image specifications support.
  * Additional registry support.
See
https://medium.com/cri-o/default-container-registry-revisited-50b32dd808fe

  * Daemon pids-limit support.
cri-o daemon now supports a default pid-limit on all containers to
prevent fork-bombs. This is configurable by admins through a flag
or /etc/crio/crio.conf.
  * Configurable image volume support.
See

https://medium.com/cri-o/cri-o-configurable-image-volume-support-dda7b54f4bda


  * Bugs and stability fixes.

We are continuing to focus on bugs and stability improvements for 1.0.

Thanks,

CRI-O team.


Please social media this out.

https://medium.com/cri-o/announcing-cri-o-1-0-0-beta-0-f593637343b2

[atomic-devel] New CRI-O blogging site just went up.

[Daniel Walsh]

 https://medium.com/cri-o

Re: [atomic-devel] SELinux and romana add-on: need advice for romana devs on correct labels

[Daniel Walsh]

On 07/10/2017 04:25 AM, ascanio.al...@gmail.com wrote:

Ooops - that should read

"Currently it does not work with SELinux: it installs a host mount from
/var/lib/romana inside the  pod without a transition."

romana devs ask: "adding those three lines (to) romana-services and romana-agent
would fix it, but is it better to be more specific?
(spc = super-privileged container. happy to go with spc_t if there's no other 
suggestion)"

The "three lines" refers to what kubeadm's etcd pod uses, viz.,
securityContext:
 seLinuxOptions:
   type: spc_t


Any advice is greatly appreciated.

Anthony

If you label the content in /var/lib/romana as Container content, then 
this should work fine without spc_t.  Allowing confinement with SELinux.


Not sure if kubeadmin allows you to force the relabel automatically 
yet.  In docker this is done with


-v /var/lib/romana:/var/lib/romana:Z

This would cause the container runtime to label /var/lib/romana on the 
host correctly.


You could do this manually by executing

chcon -Rt svirt_sandbox_file_t /var/lib/romana

On the host.  This second option sets the label to a shared label, which 
would allow the romana container to run with SELinux confinement. But it 
is not as good as the first option, since this label could be 
read/written by other containers if they can gain access.

[atomic-devel] Wrote a new blog for OpenSource.Com on evolution of containers.

[Daniel Walsh]

https://opensource.com/article/17/7/how-linux-containers-evolved

If  you like it, please social Media this message out.

Re: [atomic-devel] cri-o, buildah and skopeo packages available via Ubuntu PPA and CentOS Virt SIG

[Daniel Walsh]

Remember you can't run SELinux and Overlay at the same time on 
RHEL/CENTOS until 7.4 kernel is released.

On 07/05/2017 04:45 PM, Mrunal Patel wrote:

cc'ed Nalin

On Wed, Jul 5, 2017 at 1:06 PM, Clayton Coleman > wrote:


Hrm, maybe when:

   CGroup: /system.slice/crio.service
   ├─ 8525 /usr/bin/crio --debug
   └─12888 storage-untar

/var/lib/containers/storage/overlay2/b4f07a49d6fdaf35b0cc6829bed2cfca98cef91b43c513152269365484ec0cfb/diff

Is running, it hangs

On Wed, Jul 5, 2017 at 4:05 PM, Clayton Coleman
> wrote:

`sudo crioctl image list` hangs while downloading images
(maybe it's only the first image)?  Turned on crio, started
openshift, before the first image was pulled it hung when I
tried to image list, but subsequent ones worked fine.

On Wed, Jul 5, 2017 at 2:54 PM, Antonio Murdaca
> wrote:



On Jul 5, 2017 8:47 PM, "Clayton Coleman"
> wrote:

On centos-7.3 ish:

[vm]$ sudo crio --debug
DEBU[2017-07-05 18:47:09.094408134Z] [graphdriver]
trying provided driver "overlay2"
FATA[2017-07-05 18:47:09.096470565Z] driver not supported

post install. Something special I have to do to get
overlay2 working on centos?


This is probably missing a configuration option in
/etc/crio/crio.conf

Where is the dist-git for cri-o in centos? I might check
it and fix it.

Clayton, you should add this under "storage_option" in
cri-o configuration file to get rid of that failure:

"overlay2.override_kernel_check=1"


On Wed, Jul 5, 2017 at 1:57 PM, Lokesh Mandvekar
> wrote:

Hi list,

I have packaged up cri-o, buildah and skopeo for
Ubuntu and CentOS. To get
them, just do:

(On Ubuntu 16.04.2 LTS and 17.04, install the
Project Atomic PPA)
% sudo apt-add-repository ppa:projectatomic/ppa
% sudo apt-get update
% sudo apt-get install cri-o buildah skopeo

(On CentOS 7, install the Virt SIG repo)
% sudo yum install

https://lsm5.fedorapeople.org/centos-release-container-1-3.el7.noarch.rpm


% sudo yum install cri-o buildah skopeo

Reviews/feedback/bugs appreciated :)
Thanks,
--
Lokesh
Freenode, OFTC: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

Re: [atomic-devel] Upcoming Events: call for speakers/staff plus funding & swag

[Daniel Walsh]

On 06/29/2017 06:19 PM, Josh Berkus wrote:

Folks:

The following events are important to us for promoting Atomic Host,
Cockpit, and other technologies.  I am looking for speakers, booth
staff, and other participants.  Both travel funding and assistance with
proposals and talks is available for all of these events.

Additionally, any Project Atomic contributors who work an event are
entitled to a spiffy Project Atomic embroidered shirt or a fleece (some
advance notice required to order, may take a long time to get them to
Asia and Europe) (If I promised you one, and you didn't get it, please
ping me offlist).

Please note that there's a couple of CfP deadlines in the below, coming
up soon.

Please share with teammates as appropriate.

Open Source Summit Los Angeles (LinuxCon):
Dates: September 11-14
Needed: Booth Staff, Additional people for Atomic BOF

http://events.linuxfoundation.org/events/open-source-summit-north-america

Linux Plumber's Container Microconference
Dates: September 13-15
Location: Los Angeles, CA, next to OSSummit
Needed: Linux internals participants
(will ask for booth duty at OSS-LA)

http://www.linuxplumbersconf.org/2017/containers-microconference-accepted-into-linux-plumbers-conference/

ContainerCamp UK
Dates: September 9
Location: London
Needed: Speakers, Booth Staff
CfP Deadline: **July 14, 2017**
https://2017.container.camp/uk/

Open Source Summit Prague
Dates: October 23-25
 Location: Prague
 Needed: Speakers, BOF organizer, Booth Staff
 CfP Deadline: **July 8, 2017**
http://events.linuxfoundation.org/events/open-source-summit-europe

KubeCon North America
Dates: December 6-8
 Location: Austin, TX
 Needed: Speakers, Booth Staff
 CfP Deadline: August 21

http://events.linuxfoundation.org/events/cloudnativecon-and-kubecon-north-america

I will be at KubeCon, and potentially Linux Plumbers.


Please respond if you can help with any of the above!  Thanks!

[atomic-devel] New SELinux/Container Blog

[Daniel Walsh]

http://danwalsh.livejournal.com/76358.html

Please social Media it.

Re: [atomic-devel] Shutting down ask.projectatomic.io, moving to StackExchange, needs your help

[Daniel Walsh]

On 06/14/2017 10:31 AM, Matthew Miller wrote:

On Wed, Jun 14, 2017 at 02:14:05PM +, Joe Brockmeier wrote:

create some tags.

How does one follow this?  Is there a way to setup a notification if
anyone mentions keywords?

No way that I know of, unfortunately.

Not keywords, but you can subscribe to tags (optionally, across all
sites on the network): https://stackexchange.com/filters

For example, here's all SELinux questions:
https://stackexchange.com/filters/229659/selinux

and here's all Fedora questions:
https://stackexchange.com/filters/204064/fedora


Ok added filters for


projectatomic, atomichost, buildah, cri-o kpod

Re: [atomic-devel] Shutting down ask.projectatomic.io, moving to StackExchange, needs your help

[Daniel Walsh]

On 06/13/2017 01:59 PM, Josh Berkus wrote:

One more thing:

Does anyone have over 1500 reputation on StackOverflow?  We want to
create some tags.

How does one follow this?  Is there a way to setup a notification if 
anyone mentions keywords?

[atomic-devel] New blog on CRI-O and Kubernetes, Please social media this.

[Daniel Walsh]

http://www.projectatomic.io/blog/2017/06/6-reasons-why-cri-o-is-the-best-runtime-for-kubernetes/

Re: [atomic-devel] Packages added/removed from F25AH -> F26AH

[Daniel Walsh]

On 06/05/2017 11:37 AM, Dusty Mabe wrote:

Please reply-all when responding to this mail.

I've been doing some F25->F26 exploration and notice there are quite a
few packages added and removed between F25 and F26. Let's go through
these and make sure each addition/removal makes sense.

You can mostly ignore the "Upgraded" section. Feel free to look at those
too to see if there is anything that looks odd.


```
Upgraded:
   GeoIP 1.6.10-1.fc25 -> 1.6.11-1.fc26
   GeoIP-GeoLite-data 2017.04-1.fc25 -> 2017.05-1.fc26
   NetworkManager 1:1.4.4-5.fc25 -> 1:1.8.0-3.fc26
   NetworkManager-libnm 1:1.4.4-5.fc25 -> 1:1.8.0-3.fc26
   NetworkManager-team 1:1.4.4-5.fc25 -> 1:1.8.0-3.fc26
   acl 2.2.52-12.fc25 -> 2.2.52-14.fc26
   atomic 1.17.2-1.fc25 -> 1.18.1-2.fc26
   atomic-devmode 0.3.6-1.fc25 -> 0.3.7-1.fc26
   attr 2.4.47-16.fc24 -> 2.4.47-18.fc26
   audit 2.7.6-1.fc25 -> 2.7.6-1.fc26
   audit-libs 2.7.6-1.fc25 -> 2.7.6-1.fc26
   audit-libs-python 2.7.6-1.fc25 -> 2.7.6-1.fc26
   audit-libs-python3 2.7.6-1.fc25 -> 2.7.6-1.fc26
   authconfig 6.2.10-14.fc25 -> 7.0.1-1.fc26
   basesystem 11-2.fc24 -> 11-3.fc26
   bash 4.3.43-4.fc25 -> 4.4.12-5.fc26
   bash-completion 1:2.5-1.fc25 -> 1:2.5-2.fc26
   bind99-libs 9.9.9-4.P8.fc25 -> 9.9.9-5.P8.fc26
   bind99-license 9.9.9-4.P8.fc25 -> 9.9.9-5.P8.fc26
   boost-iostreams 1.60.0-10.fc25 -> 1.63.0-5.fc26
   boost-program-options 1.60.0-10.fc25 -> 1.63.0-5.fc26
   boost-random 1.60.0-10.fc25 -> 1.63.0-5.fc26
   boost-regex 1.60.0-10.fc25 -> 1.63.0-5.fc26
   boost-system 1.60.0-10.fc25 -> 1.63.0-5.fc26
   boost-thread 1.60.0-10.fc25 -> 1.63.0-5.fc26
   bridge-utils 1.5-13.fc24 -> 1.5-14.fc26
   btrfs-progs 4.6.1-1.fc25 -> 4.9.1-2.fc26
   bubblewrap 0.1.8-1.fc25 -> 0.1.8-1.fc26
   bzip2 1.0.6-21.fc25 -> 1.0.6-22.fc26
   bzip2-libs 1.0.6-21.fc25 -> 1.0.6-22.fc26
   ca-certificates 2017.2.14-1.0.fc25 -> 2017.2.14-1.0.fc26
   ceph-common 1:10.2.4-2.fc25 -> 1:10.2.7-2.fc26
   checkpolicy 2.5-8.fc25 -> 2.6-1.fc26
   chkconfig 1.8-1.fc25 -> 1.10-1.fc26
   chrony 2.4.1-1.fc25 -> 3.1-4.fc26
   cloud-init 0.7.9-4.fc25 -> 0.7.9-5.fc26
   cloud-utils-growpart 0.27-16.fc25 -> 0.27-17.fc26
   cockpit-bridge 137-1.fc25 -> 141-1.fc26
   cockpit-docker 137-1.fc25 -> 141-1.fc26
   cockpit-networkmanager 137-1.fc25 -> 141-1.fc26
   cockpit-ostree 137-1.fc25 -> 141-1.fc26
   cockpit-system 137-1.fc25 -> 141-1.fc26
   conntrack-tools 1.4.3-1.fc25 -> 1.4.4-3.fc26
   container-selinux 2:2.14-1.fc25 -> 2:2.16-1.fc26
   coreutils 8.25-17.fc25 -> 8.27-5.fc26
   coreutils-common 8.25-17.fc25 -> 8.27-5.fc26
   cpio 2.12-3.fc24 -> 2.12-4.fc26
   cracklib 2.9.6-4.fc25 -> 2.9.6-5.fc26
   cracklib-dicts 2.9.6-4.fc25 -> 2.9.6-5.fc26
   criu 2.12-1.fc25 -> 3.0-1.fc26
   crypto-policies 20160921-4.gitf3018dd.fc25 -> 20170531-1.gitce0df7b.fc26
   cryptsetup 1.7.5-1.fc25 -> 1.7.5-1.fc26
   cryptsetup-libs 1.7.5-1.fc25 -> 1.7.5-1.fc26
   curl 7.51.0-6.fc25 -> 7.53.1-7.fc26
   cyrus-sasl-lib 2.1.26-26.2.fc24 -> 2.1.26-32.fc26
   dbus 1:1.11.12-1.fc25 -> 1:1.11.12-1.fc26
   dbus-glib 0.108-1.fc25 -> 0.108-2.fc26
   dbus-libs 1:1.11.12-1.fc25 -> 1:1.11.12-1.fc26
   device-mapper 1.02.136-3.fc25 -> 1.02.137-6.fc26
   device-mapper-event 1.02.136-3.fc25 -> 1.02.137-6.fc26
   device-mapper-event-libs 1.02.136-3.fc25 -> 1.02.137-6.fc26
   device-mapper-libs 1.02.136-3.fc25 -> 1.02.137-6.fc26
   device-mapper-persistent-data 0.6.3-1.fc25 -> 0.6.3-5.fc26
   dhcp-client 12:4.3.5-2.fc25 -> 12:4.3.5-6.fc26
   dhcp-common 12:4.3.5-2.fc25 -> 12:4.3.5-6.fc26
   dhcp-libs 12:4.3.5-2.fc25 -> 12:4.3.5-6.fc26
   diffutils 3.3-13.fc24 -> 3.5-3.fc26
   dnsmasq 2.76-2.fc25 -> 2.76-3.fc26
   docker 2:1.12.6-6.gitae7d637.fc25 -> 2:1.13.1-13.git51eb16e.fc26
   docker-common 2:1.12.6-6.gitae7d637.fc25 -> 2:1.13.1-13.git51eb16e.fc26
   dracut 044-78.fc25 -> 044-181.fc26
   dracut-config-generic 044-78.fc25 -> 044-181.fc26
   dracut-network 044-78.fc25 -> 044-181.fc26
   e2fsprogs 1.43.3-1.fc25 -> 1.43.4-2.fc26
   e2fsprogs-libs 1.43.3-1.fc25 -> 1.43.4-2.fc26
   efibootmgr 14-3.fc25 -> 14-3.fc26
   efivar-libs 30-4.fc25 -> 30-4.fc26
   elfutils-default-yama-scope 0.169-1.fc25 -> 0.169-1.fc26
   elfutils-libelf 0.169-1.fc25 -> 0.169-1.fc26
   elfutils-libs 0.169-1.fc25 -> 0.169-1.fc26
   emacs-filesystem 1:25.2-2.fc25 -> 1:25.2-2.fc26
   etcd 3.1.3-1.fc25 -> 3.1.3-1.fc26
   expat 2.2.0-1.fc25 -> 2.2.0-2.fc26
   fcgi 2.4.0-29.fc24 -> 2.4.0-30.fc26
   fedora-logos 22.0.0-3.fc24 -> 26.0.1-1.fc26
   fedora-release 25-2 -> 26-0.7
   fedora-release-atomichost 25-2 -> 26-0.7
   fedora-repos 25-4 -> 26-0.9
   file 5.29-4.fc25 -> 5.30-6.fc26
   file-libs 5.29-4.fc25 -> 5.30-6.fc26
   filesystem 3.2-37.fc24 -> 3.2-40.fc26
   findutils 1:4.6.0-8.fc25 -> 1:4.6.0-12.fc26
   fipscheck 1.4.1-11.fc25 -> 1.5.0-1.fc26
   fipscheck-lib 1.4.1-11.fc25 -> 1.5.0-1.fc26
   flannel 0.7.0-2.fc25 -> 0.7.0-3.fc26
   freetype 2.6.5-9.fc25 -> 2.7.1-9.fc26
   fuse 2.9.7-1.fc25 -> 2.9.7-2.fc26
   fuse-libs 2.9.7-1.fc25 -> 2.9.7-2.fc26
   gawk 4.1.3-8.fc25 -> 4.1.4-3.fc26
  

Re: [atomic-devel] Thinking about CRI-O and Docker on Atomic Host

[Daniel Walsh]

On 06/01/2017 01:19 PM, Antonio Murdaca wrote:



On Jun 1, 2017 17:58, "Colin Walters" > wrote:


I've seen some interesting work on CRI-O for Kube/OpenShift. But
I'm wondering about what people are thinking the future of
docker.service and /usr/bin/docker is (particularly for Atomic Host).

The particular intersection with AH is handling container storage;
AIUI right now you can't have CRI-O and Docker share the same
storage pool.

So...should a CRI-O installer `systemctl stop docker.service;
systemctl mask docker.service`
and reuse the partition we've set up for /var/lib/docker?  Or do we
expect people to set up a separate partition?
(It feels like the answer is probably "both")


CRI-O can't actually use the Docker storage transparently. Either you 
use skopeo to copy images from Docker to cri-o storage or you start 
from scratch.


CRI-O supports  "overlay" storage, (Formally overlay2, we have dropped 
the old overlay driver).  CRI-O storage is in 
/var/lib/containers/storage while docker is in /var/lib/docker. They 
will not share the same storage, although all of the other container 
tools that we are building like skopeo and buildah will be able to share 
storage with CRI-O.  I am fine with moving to a single / with overlay by 
default for both docker and CRI-O.



Perhaps in the big picture for the single-node case we point people
at `oc cluster up` etc?  (Which itself should be a system
container probably
to avoid the obvious bootstrapping problem?)

Re: [atomic-devel] Having abrt on Atomic Host

[Daniel Walsh]

On 05/30/2017 06:29 AM, Daniel Walsh wrote:

On 05/29/2017 11:57 PM, Dusty Mabe wrote:


On 05/29/2017 08:20 PM, William Brown wrote:

On Wed, 2017-05-24 at 11:44 -0400, Daniel Walsh wrote:

On 05/19/2017 01:46 AM, Niranjan M.R wrote:

Greetings,

I would like to know what is the status of having Abrt on Atomic 
Host. I see there
was a old thread[1], but could not figure out if there was any 
work being done in

that regard.

I have 2 use cases here

A. Having abrt collect crashes from application containers
B. Having abrt collect crashes of process running on Atomic hosts 
(like docker).


Any update on the above would be helpful.

1. 
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-February/msg00026.html

abrt should be packaged as a System container.


That doesn't seem right. I think that while we should have the goal to
containerise things, there is a point where *too much* is reached. I
think this is a good example (as is SSSD)

atomic host should have "just enough" to make running containers a good
system, and being able to admin them effectively, but without *over
complicating* the system.

I think that shoving everything (like abrt, sssd) in containers is a
mistake because these are clearly in the atomic layer, and there is no
benefit to the complexity of containerising them.

* Do I need abrt to move at a different rate to my atomic base (no)
* Does containerising it have a tangible benefit over non (no)
* Does it add complexity (yes)

Rather than living at extremes, we should be taking a more reasonable
approach to this design I think.


I tend to agree here. Previously things had to go into either the base
atomic host or they had to go into a container. Now we have package
layering, so there is a middle ground.

I say let's keep the base relatively small like what we have today.
For things that are low level utilities/services we can either choose to
include them in the base or not. If not the user still has the option
of layering them in using `rpm-ostree install pkg`. With the livefs
work that is going on upstream we might even be able to rid ourselves of
the dreaded reboot for package layering.

For higher level services and applications container(verb) away!

Thoughts?
Dusty


I am fine with layering it or installing it as an system container.

But I would argue against the differentiation about low level tools 
being installed as container images.


I believe the future is container images and having precanned system 
container images is an excellent solution


to loots of tools that  you want to use to enhance the atomic host.

Realize that just because a piece os software is installed as a system 
container does not mean it needs to use ANY container technology.


Running software using systemd technology to run the software as a 
chroot is fine.  Executing one command inside of the container is fine.


A system container is JUST a way to deliver bundeled software from a 
Container Registry to a host, as opposed to delivering it in an RPM 
where it would require deep bundling with the host.



Lastly, if we don't show use cases where distribution packages are 
shipped in system containers, then others people wanting to ship 
software will continue to fallback on the traditional RPM based installs.

Re: [atomic-devel] Having abrt on Atomic Host

[Daniel Walsh]

On 05/29/2017 11:57 PM, Dusty Mabe wrote:


On 05/29/2017 08:20 PM, William Brown wrote:

On Wed, 2017-05-24 at 11:44 -0400, Daniel Walsh wrote:

On 05/19/2017 01:46 AM, Niranjan M.R wrote:

Greetings,

I would like to know what is the status of having Abrt on Atomic Host. I see 
there
was a old thread[1], but could not figure out if there was any work being done 
in
that regard.

I have 2 use cases here

A. Having abrt collect crashes from application containers
B. Having abrt collect crashes of process running on Atomic hosts (like docker).

Any update on the above would be helpful.

1. 
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-February/msg00026.html

abrt should be packaged as a System container.


That doesn't seem right. I think that while we should have the goal to
containerise things, there is a point where *too much* is reached. I
think this is a good example (as is SSSD)

atomic host should have "just enough" to make running containers a good
system, and being able to admin them effectively, but without *over
complicating* the system.

I think that shoving everything (like abrt, sssd) in containers is a
mistake because these are clearly in the atomic layer, and there is no
benefit to the complexity of containerising them.

* Do I need abrt to move at a different rate to my atomic base (no)
* Does containerising it have a tangible benefit over non (no)
* Does it add complexity (yes)

Rather than living at extremes, we should be taking a more reasonable
approach to this design I think.


I tend to agree here. Previously things had to go into either the base
atomic host or they had to go into a container. Now we have package
layering, so there is a middle ground.

I say let's keep the base relatively small like what we have today.
For things that are low level utilities/services we can either choose to
include them in the base or not. If not the user still has the option
of layering them in using `rpm-ostree install pkg`. With the livefs
work that is going on upstream we might even be able to rid ourselves of
the dreaded reboot for package layering.

For higher level services and applications container(verb) away!

Thoughts?
Dusty


I am fine with layering it or installing it as an system container.

But I would argue against the differentiation about low level tools 
being installed as container images.


I believe the future is container images and having precanned system 
container images is an excellent solution


to loots of tools that  you want to use to enhance the atomic host.

Realize that just because a piece os software is installed as a system 
container does not mean it needs to use ANY container technology.


Running software using systemd technology to run the software as a 
chroot is fine.  Executing one command inside of the container is fine.


A system container is JUST a way to deliver bundeled software from a 
Container Registry to a host, as opposed to delivering it in an RPM 
where it would require deep bundling with the host.

Re: [atomic-devel] Having abrt on Atomic Host

[Daniel Walsh]

On 05/19/2017 01:46 AM, Niranjan M.R wrote:

Greetings,

I would like to know what is the status of having Abrt on Atomic Host. I see 
there
was a old thread[1], but could not figure out if there was any work being done 
in
that regard.

I have 2 use cases here

A. Having abrt collect crashes from application containers
B. Having abrt collect crashes of process running on Atomic hosts (like docker).

Any update on the above would be helpful.

1. 
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-February/msg00026.html


abrt should be packaged as a System container.

Re: [atomic-devel] Openshift Origin + CRI-O

[Daniel Walsh]

On 05/10/2017 10:37 AM, Antonio Murdaca wrote:



On May 10, 2017 16:32, "Colin Walters" > wrote:


On Wed, May 10, 2017, at 10:08 AM, Antonio Murdaca wrote:

> I've started working on the integration between Openshift Origin and
> CRI-O some time ago with nice initial results.

Nice work!

> For anyone who wants to step in and try out Openshift Origin and
CRI-O, I've
> created some scripts to setup a Fedora 25 VM to be provisioned for
> Openshift Origin and CRI-O (works with 26 probably, but totally
> untested on fedora atomic hosts).

Let me break this out since I think it's an interesting topic! 
It's not a criticism,

but more of an architectural point.
The Ansible `dnf` module doesn't (yet) work on AH.  But even if it
did,
I think installing development tools directly on a host should be
considered an anti-pattern:

- hosts: all
  remote_user: root
  tasks:
- name: install stuff
  dnf: name={{ item }} state=latest
...
- golang
- btrfs-progs-devel

Basically, I think all builds should be done in a container.  If
you then want to install
the *result* (e.g. an RPM) on the host, that makes sense. On the
AH side, we
now have support for local RPM install (but not yet *live*
installs).  Personally
for development/hacking I tend to use `ostree admin unlock` still
with a flow
like this:

container$ sudo make install DESTDIR=/host

Although lately I've switched to only sharing /srv, so it's two steps:
container$ sudo make install DESTDIR=/srv/install
host$ rsync -rlv /srv/install/usr /usr/

The "no devel tools on the host" is also a goal of
https://fedoraproject.org/wiki/Workstation/Atomic



Nice! Thanks for the suggestion Colin, though, I still have to find 
some time to exercise that playbook for atomic to fix it :( but it's 
on my todo (or open to contributors :P)


We should move this example to a container image rather then an RPM, to 
make it easier for users to swap it in and out.

[atomic-devel] How do we get packages into Debian

[Daniel Walsh]

We have been placing a bunch of repositories onto Projectatomic.io and
these projects are being built into packages for Fedora and sometime
RHEL/Centos.

Does anyone know if any have been built into Debian/Ubuntu?  If not how
do we get them built for the Debian based distros?  How do we encourage
packagers to do the packaging?

Re: [atomic-devel] looking for feedback on running kubernetes in system containers

[Daniel Walsh]

If these config changes should be in the standard etcd/flanneld 
containers please open pull requests to fix this on 
github.com:projectatomic/atomic-system-containers


On 04/28/2017 03:08 PM, Jason Brooks wrote:

On Fri, Apr 28, 2017 at 1:05 AM, Spyros Trigazis  wrote:

Hi,

So far, I have only tried etcd, works well but the only piece missing is
a way to pass TLS credentials which is quite important for certain
deployments like ours. My next goal is flannel. Flannel will require
TLS creds as well. To do it, I rebuilt the image to bindmount them.

The ansible scripts handle this, and they put the certs in
/etc/etcd/certs -- I'm bind mounting /etc/etcd to accommodate this.
Where do you put your certs?

It's a similar situation w/ flannel, w/ certs in /etc/flanneld/certs.


To be honest, I didn't try kube components because the version isn't
newer than the one in fedora-atomic and since we don't use ansible
we need some modifications. If kube was newer I would be more
motivated :).

Good idea. I just built rawhide versions of these containers that you
can check out by swapping the tag fc25 for rawhide. They have kube
1.6.1. I haven't tested them yet, though.

Jason


Spyros

On 27 April 2017 at 18:59, Jason Brooks  wrote:

I've been working on running kubernetes, flannel and etcd in system
containers, and setting up a cluster using the ansible scripts at
kubernetes/contrib.

I wrote a blog post about it here:

https://jebpages.com/2017/04/11/testing-system-containerized-kube-and-friends/

These are my system containers:

https://github.com/jasonbrooks/atomic-system-containers/tree/kube-containers

and my ansible branch:
https://github.com/jasonbrooks/contrib/tree/system-containers/ansible

I've changed the etcd and flannel containers to bind mount config dirs
in /etc, so that the ansible can config them using the same operations
it'd use for non-system containers. I'm using tmpfiles.d to put a link
to the etcdctl from the container into /usr/local/bin/etcd because
ansible expects and needs etcdctl to be on the host to set up the
flannel network, and linking to the etcdctl from the container again
lets us reuse the same ansible operations as for non system container
case.

The kube containers are based on the ones I'm maintaining in the
fedora and centos container registries, and they also get configs from
bind mounted /etc/kubernetes. Like with the etcd container, I'm
creating a link from the kube-apiserver container's kubectl to
/usr/local/bin/kubectl on the host, because the kube-addons service
expects kubectl to be on the host.

I've been using f25-based containers, but this should work with centos
containers, too.

Anyway, if you're interested in this topic, I'd appreciate it if you
gave my post / github forks a look and let me know what you think /
what I'm doing terribly wrong / etc. :)

Thanks, Jason

Re: [atomic-devel] Storage for system containers

[Daniel Walsh]

On 04/28/2017 01:09 PM, Giuseppe Scrivano wrote:

Hi,

Dusty Mabe  writes:


i'm going to show how little I know with this question, but would it be possible
to have a separate partition for system containers that was essentially xfs + an
overlayfs of the host filesystem?

yes we could do that, we will just need to use a separate OSTree
repository, so that it won't be shared with the OS.  This is possible
already today, as the OSTree storage to use is configurable.
The disadvantage is that files in common with the host will still need
to be copied in the new repository.

Regards,
Giuseppe


Ok, We should be able to support both environments, where you want to 
maximize disk space savings by taking advantage of sharing OS Content 
with the Host OS by running your system container storage on the same 
disk as /usr.  If you want to totally isolate your container content 
from the host, we can mount /var/lib/containers on an separate 
partition/disk and keep storage isolated.  The only problem here is that 
/var/lib/docker would need to be modified to use 
/var/lib/containers/docker.  From CRI-O/buildah and all container 
storage we store by default in /var/lib/containers/storage.  With the 
move to ThePackageFormallyKnownAsDocker (TPFKAD), we should move the 
default storage to /var/lib/containers/TPFKAD.

Re: [atomic-devel] Announcing CRI-O 0.3

[Daniel Walsh]

On 04/28/2017 12:42 PM, Mrunal Patel wrote:


We are happy to announce the release of CRI-O v0.3 
. 
With this release, we are passing all the k8s node conformance tests.


Big thanks to our maintainers and contributors from Red Hat, Intel, 
SUSE, Hyper, IBM, and others.


Highlights of the release:


1. Streaming exec support

2. Port forwarding support

3. Lots of bug fixes


Now only the Attach API is remaining in terms of features. Also, we 
are continuing to test with k8s.


Please try it out and let us know if you see any bugs!


Thanks,

CRI-O team.


This is awesome.  Now we need to get past the OpenShift test suite...

Re: [atomic-devel] Storage for system containers

[Daniel Walsh]

On 04/27/2017 06:44 AM, Giuseppe Scrivano wrote:

Daniel Walsh <dwa...@redhat.com> writes:


On 04/24/2017 01:56 PM, Dusty Mabe wrote:

NOTE: please reply-all when responding to this message


In Fedora Atomic Host if we use system containers as advertised
we end up using `atomic pull --storage ostree` which by default
throws images into /var/lib/containers/atomic/. This is on the
root filesystem which may be undesirable.

Since in Fedora 26 the new version of container-storage-setup allows
us greater control over a "CONTAINER_ROOT" should we consider trying
to make sure both ostree storage and docker storage get placed under
that CONTAINER_ROOT?

The current default [1] is to just mount the CONTAINER_ROOT on
/var/lib/docker.

Dusty

[1] 
https://src.fedoraproject.org/cgit/rpms/docker.git/tree/docker.spec?h=f26#n535


Perhaps we should just mount a partition at /var or move
/var/lib/docker to /var/lib/containers/docker and make a symbolic link
from /var/lib/docker-> /var/lib/containers/docker.

Mounting a partition at /var wouldn't work with system containers.

System containers are stored in the OSTree storage and on Atomic Host
they are checked out to /ostree/deploy/$OS/var/lib/containers/atomic/ so
that the checkout and the OSTree storage are on the same file system.
This is required to use hard links instead of copying files from OSTree.

Regards,
Giuseppe


Thanks for giving us a clue.   This breaks the assumptions that spawned 
this conversation.


We want to keep system containers on the same file system as /usr, and 
since we use OSTRee


and most system containers will match the arch, then we should see a lot 
of sharing so much smaller


disk usage then if they were standard docker images.   Dusty what do you 
think?  I guess we should think about increasing the size of the "root" 
file system to handle the need of system containers.

Re: [atomic-devel] Many new dependencies in f25 updates-testing

[Daniel Walsh]

On 04/26/2017 01:12 PM, Colin Walters wrote:


On Wed, Apr 26, 2017, at 12:57 PM, Jonathan Lebon wrote:

I traced it down to:

http://pkgs.fedoraproject.org/cgit/rpms/atomic.git/commit/?h=f25=7d15e4a0be2db29deda4b92a039a041d81bbe205
http://pkgs.fedoraproject.org/cgit/rpms/atomic.git/commit/?h=f25=cb845639e7388bb9aa3b5aef7dabffa3434b1ae1

I.e. atomic needs to build RPMs for the system container
work.

I propose we revert that dependency and revisit the rpm construction
upstream.  Any objections?
___
cloud mailing list -- cl...@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org


Sounds good to me.

Re: [atomic-devel] Storage for system containers

[Daniel Walsh]

On 04/25/2017 03:44 PM, Josh Berkus wrote:

On 04/25/2017 12:08 PM, Dusty Mabe wrote:


On 04/25/2017 08:25 AM, Daniel Walsh wrote:

On 04/24/2017 01:56 PM, Dusty Mabe wrote:
Perhaps we should just mount a partition at /var or move /var/lib/docker
to /var/lib/containers/docker and make a symbolic link from
/var/lib/docker-> /var/lib/containers/docker.


I like the approach of /var/lib/docker -> /var/lib/containers/docker.

Is this something we should pursue?

Aren't we going to have to call it /var/lib/containers/moby pretty soon?


Yes. Old habits die hard.