[atomic-devel] PXE Booting Diskless Atomic - Failed to start switchroot

[Matt Jansen]

Hi all,
I'm trying to use iPXE to boot into a live atomic host. I was able to
successfully create a tree and build the pxelive images using the
build_stage1.sh and build_stage2.sh scripts in the downstream branch of the
sig-atomic-buildscripts github repo.
 When I actually try to
boot a system I receive the following message:

[FAILED] Failed to start switchroot

Looking for more info in the logs I get:
:/# systemctl status initrd-switch-root -l
Failed to switch root: Specified switch root path /sysroot does not seem to
be an OS tree. os-release file is missing.

If it check the /sysroot folder I can see that the squashfs image was
mounted. I can browse into /sysroot/ostree/boot.0/centos-atomic-host/{ID}
and see the entire tree as it is supposed to be.

My iPXE Config is:
#!ipxe
kernel /assets/atomic/new/vmlinuz-3.10.0-693.5.2.el7.x86_64
initrd=initramfs-3.10.0-693.5.2.el7.x86_64.img root=live:
http://matchbox.foo:8080/assets/atomic/new/live-rootfs.squashfs.img
ostree=/ostree/boot.0/centos-atomic-host/81f124c81e835f79bce580ea67f8f8
ba34337b6a244daa5d6b319eb58157fa85/0 debug
initrd /assets/atomic/new/initramfs-3.10.0-693.5.2.el7.x86_64.img
boot

Is there some kind of kernel arg besides ostree= that I am missing that
tells the system to mount the correct os tree? I translated the legacy PXE
file into iPXE since I have an iPXE server but it seems I have all the
parameters.

Thanks for any help you can provide.

Matt Jansen
St. Anthony Falls Laboratory
University of Minnesota Twin Cities

[atomic-devel] Atomic Images for Google Cloud

[Evan Klitzke]

Hi all,

I recently found Project Atomic, and I'm really impressed. I'm interested
in running atomic hosts on Google Cloud, and stumbled across this GitHub
gist by Christoph Görn: https://gist.github.com/goern/d21e5f9bee733a4f30c7
. I was able to follow the instructions and build an image I can use in GCE.

Is there anything I can do to help make publishing these images more
official somehow? I'd love it if there was a "blessed" Google Cloud image
created by Project Atomic available for use. If there are any tasks that I
could help with (anything from writing code, to testing, to writing
documentation) let me know and I'll see if I can help.

Thanks much,
Evan Klitzke
-- 
Evan Klitzke
https://eklitzke.org/

Re: [atomic-devel] a better place for system container images?

[Josh Berkus]

On 11/06/2017 08:29 AM, Giuseppe Scrivano wrote:
> Dusty Mabe  writes:
> 
 - create a projectatomic-devel organization and put them under there
 - put them under projectatomic/ but add devel or upstream in the name of 
 each image.
>>> would a tag be enough?
>> My personal opinion is no. Not many people inspect tags when using images.
> they will still need to specify the tag when pulling or installing the
> image.  It is something like:
> 
> atomic pull --storage ostree docker.io/projectatomic/etcd:devel
> 
> instead of:
> 
> atomic pull --storage ostree docker.io/projectatomic/etcd-devel
> 
> 

The problem with this is that there's no update to the tag when a new
devel build is pushed.  This will make it hard to make sure you're
pulling the most recent image for testing.  Maybe tag with ##devel?  e.g.

docker.io/projectatomic/etcd:0.3devel

-- 
--
Josh Berkus
Project Atomic
Red Hat OSAS

Re: [atomic-devel] a better place for system container images?

[Dusty Mabe]

On 11/06/2017 11:29 AM, Giuseppe Scrivano wrote:
> Dusty Mabe  writes:
> 
 - create a projectatomic-devel organization and put them under there
 - put them under projectatomic/ but add devel or upstream in the name of 
 each image.
>>>
>>> would a tag be enough?
>>
>> My personal opinion is no. Not many people inspect tags when using images.
> 
> they will still need to specify the tag when pulling or installing the
> image.  It is something like:
> 
> atomic pull --storage ostree docker.io/projectatomic/etcd:devel

ahh. I thought you meant a label (not a tag). Yes, a tag is *better*.

> 
> instead of:
> 
> atomic pull --storage ostree docker.io/projectatomic/etcd-devel
> 
> 
>>> Most of the time, changes to the image are bug fixes.  There is not
>>> really much development happening in the system container itself, so I
>>> don't see much disadvantage if these changes are propagated quickly.
>>
>> If there's not much changes going on then why can't we use the distro
>> registry which has a process for rebuilding images periodically to account
>> for CVEs? I know the Fedora registry is not perfect, but would like for us
>> not to fragment and have so many different places to pull a system container
>> from. 
> 
> do we prevent in some way that users using an image from
> registry.fedoraproject.org/f26/* will not keep using it once the new
> versions, that have a complete different name, are out?

I'm pretty sure once f25 is EOL those container images will no longer
be available since they won't be receiving updates.

> 
> We want a centralized place where we can find all the updated binaries
> based on what we have in the upstream repository without any human
> intervention to sync them.
> Some of the images are not based on Fedora, so we would need at least to
> split them between the Fedora and the CentOS registries.
> 

/me wishes we could build fedora and centos based layered images in the same
way so it would be the same process for both IMHO.

Re: [atomic-devel] a better place for system container images?

[Jason Brooks]

On Mon, Nov 6, 2017 at 12:57 AM, Giuseppe Scrivano  wrote:
> Hi,
>
> I'd like to find a better place where to move the system container[1]
> images that I am currently building under docker.io/gscrivano.
>
> CRI-O and Docker them are already used by the OpenShift installer to get
> the latest version available.
>
> My preference is to move these images under "docker.io/projectatomic".
> We can't use the Fedora or CentOS registries since we want to build
> these images automatically.  The downstream registries will be used only
> for a subset of these images.

+1 to automatically building all of the system containers at
https://github.com/projectatomic/atomic-system-containers in docker
hub under the projectatomic namespace.

This is much better than the status quo of using a variety of personal
namespaces. Latest is master, additional tags based on branch if
desired, but latest --> master is the main thing I'd like.

Jason

>
> The goal is to build the images automatically on every PR merged.
> Occasional builds (maybe daily?) will prevent to miss changes in the
> base layers or in the installed rpms.
>
> Thoughts?
>
> Thanks,
> Giuseppe
>
> [1] https://github.com/projectatomic/atomic-system-containers
>

Re: [atomic-devel] a better place for system container images?

[Giuseppe Scrivano]

Dusty Mabe  writes:

>>> - create a projectatomic-devel organization and put them under there
>>> - put them under projectatomic/ but add devel or upstream in the name of 
>>> each image.
>> 
>> would a tag be enough?
>
> My personal opinion is no. Not many people inspect tags when using images.

they will still need to specify the tag when pulling or installing the
image.  It is something like:

atomic pull --storage ostree docker.io/projectatomic/etcd:devel

instead of:

atomic pull --storage ostree docker.io/projectatomic/etcd-devel


>> Most of the time, changes to the image are bug fixes.  There is not
>> really much development happening in the system container itself, so I
>> don't see much disadvantage if these changes are propagated quickly.
>
> If there's not much changes going on then why can't we use the distro
> registry which has a process for rebuilding images periodically to account
> for CVEs? I know the Fedora registry is not perfect, but would like for us
> not to fragment and have so many different places to pull a system container
> from. 

do we prevent in some way that users using an image from
registry.fedoraproject.org/f26/* will not keep using it once the new
versions, that have a complete different name, are out?

We want a centralized place where we can find all the updated binaries
based on what we have in the upstream repository without any human
intervention to sync them.
Some of the images are not based on Fedora, so we would need at least to
split them between the Fedora and the CentOS registries.

Giuseppe

Re: [atomic-devel] a better place for system container images?

[Stephen Milner]

On Mon, Nov 6, 2017 at 10:50 AM, Dusty Mabe  wrote:
>
>
> On 11/06/2017 08:29 AM, Giuseppe Scrivano wrote:
>> Hi Dusty,
>>
>> Dusty Mabe  writes:
>>
>>> On 11/06/2017 03:57 AM, Giuseppe Scrivano wrote:
 Hi,

 I'd like to find a better place where to move the system container[1]
 images that I am currently building under docker.io/gscrivano.

 CRI-O and Docker them are already used by the OpenShift installer to get
 the latest version available.
>>>
>>> Are you saying the openshift installer uses docker.io/gscrivano now?
>>
>> yes, docker.io/gscrivano/cri-o-centos and docker.io/gscrivano/cri-o-fedora
>> are used for the CRI-O system container.
>>
>>
>>> I understand that we want upstream images for "latest" content in an 
>>> upstream
>>> repository but we have to be careful that people know they shouldn't use it 
>>> in
>>> production or otherwise rely on these images long term. I think putting 
>>> them under
>>> projectatomic/ on docker hub might not be clear enough. Ideas:
>>>
>>> - create a projectatomic-devel organization and put them under there
>>> - put them under projectatomic/ but add devel or upstream in the name of 
>>> each image.
>>
>> would a tag be enough?
>
> My personal opinion is no. Not many people inspect tags when using images.

Maybe we should find out how OpenShift solves this with their image
builds? Or, if the worry is people just use latest all the time, we
could keep latest tag as the latest non-dev release with dev images
tagged with dev in the name, or alpha/beta/0.X/etc..

>>
>>
>>> Openshift has a set of images they put out to the hub but they also have a
>>> team of people that do release engineering. One option would be to try to
>>> get them to agree to own the images and pushes to docker hub under the 
>>> openshift
>>> namespace.
 The goal is to build the images automatically on every PR merged.
 Occasional builds (maybe daily?) will prevent to miss changes in the
 base layers or in the installed rpms.
>>>
>>> Having the latest build pushed automatically to a registry is super useful,
>>> but mostly for the developers, not as much for users.
>>>
>>> I really don't want someone reading a blog post where the author uses these 
>>> images
>>> and the reader then running them forever. Having "devel" in the name of the 
>>> image
>>> URI will certainly help with that. Maybe I'm being too difficult.
>>
>> I don't think these images should get into the openshift namespace, as
>> most of them are not really connected to openshift.
>
> OK.
>
>
>>
>> Most of the time, changes to the image are bug fixes.  There is not
>> really much development happening in the system container itself, so I
>> don't see much disadvantage if these changes are propagated quickly.
>
> If there's not much changes going on then why can't we use the distro
> registry which has a process for rebuilding images periodically to account
> for CVEs? I know the Fedora registry is not perfect, but would like for us
> not to fragment and have so many different places to pull a system container
> from.
>
>> Even if we build them on the Fedora registry, they will still not work
>> "forever" as the Fedora release number is part of the image name.
>
> Yes, For whatever reason that was a decision made by Fedora to break up
> images and namespace them that way. I don't think it is a bad thing, though.

Agreed. Fedora specific images being split by version number makes
sense to me as well.

> Ultimately the projecatomic namespace [1] on docker hub is a tirefire of dead
> projects at this point other than maybe papr and asciibinder. There is no 
> formal
> process for retiring things or releasing them or making sure they don't have 
> CVEs.
> This model doesn't work and I'd prefer for it to go away complete IMHO.

The current "tirefire" model doesn't work, I agree. I believe we
already agreed on removing the old images from the projectatomic
namespace. However, I disagree that projectatomic on docker hub is a
bad location for images created by the Atomic team. While helping out
the openshift ansible team I found it very frustrating to try to
support 4 different registries and many more namespaces.

We can't be perfect, but we can make things better :-)

-- 
Thanks,
Steve Milner

Atomic | Red Hat | http://projectatomic.io/

[atomic-devel] [Fedocal] Reminder meeting : General Atomic Community Meeting

[jberkus]

Dear all,

You are kindly invited to the meeting:
   General Atomic Community Meeting on 2017-11-13 from 16:00:00 to 17:00:00 UTC
   

The meeting will be about:
This is the general Atomic community meeting, in order to coordinate across 
projects and discuss topics of general interest.

irc.freenode.net, #atomic

Topics for the meeting should be decided on the atomic-devel@projectatomic.io 
mailing list ahead of the meeting.


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

Re: [atomic-devel] a better place for system container images?

[Colin Walters]

On Mon, Nov 6, 2017, at 03:57 AM, Giuseppe Scrivano wrote:

> The goal is to build the images automatically on every PR merged.
> Occasional builds (maybe daily?) will prevent to miss changes in the
> base layers or in the installed rpms.

Let's write down these requirements/requests in an issue for Fedora rel-eng to
get fixed?  We could probably help with that too.
I'm sure there are other containers that want something like this.

What we have now for OSBS is pretty slow/cumbersome for sure, but
it can be fixed.

I don't mind doing this as a short term tactical thing, but beyond
what Dusty is saying, other issues are around multi-arch builds, signing,
ensuring the source code is available, etc.

Re: [atomic-devel] a better place for system container images?

[Dusty Mabe]

On 11/06/2017 08:29 AM, Giuseppe Scrivano wrote:
> Hi Dusty,
> 
> Dusty Mabe  writes:
> 
>> On 11/06/2017 03:57 AM, Giuseppe Scrivano wrote:
>>> Hi,
>>>
>>> I'd like to find a better place where to move the system container[1]
>>> images that I am currently building under docker.io/gscrivano.
>>>
>>> CRI-O and Docker them are already used by the OpenShift installer to get
>>> the latest version available.
>>
>> Are you saying the openshift installer uses docker.io/gscrivano now?
> 
> yes, docker.io/gscrivano/cri-o-centos and docker.io/gscrivano/cri-o-fedora
> are used for the CRI-O system container.
> 
> 
>> I understand that we want upstream images for "latest" content in an upstream
>> repository but we have to be careful that people know they shouldn't use it 
>> in
>> production or otherwise rely on these images long term. I think putting them 
>> under
>> projectatomic/ on docker hub might not be clear enough. Ideas:
>>
>> - create a projectatomic-devel organization and put them under there
>> - put them under projectatomic/ but add devel or upstream in the name of 
>> each image.
> 
> would a tag be enough?

My personal opinion is no. Not many people inspect tags when using images.

> 
> 
>> Openshift has a set of images they put out to the hub but they also have a
>> team of people that do release engineering. One option would be to try to
>> get them to agree to own the images and pushes to docker hub under the 
>> openshift
>> namespace.
>>> The goal is to build the images automatically on every PR merged.
>>> Occasional builds (maybe daily?) will prevent to miss changes in the
>>> base layers or in the installed rpms.
>>
>> Having the latest build pushed automatically to a registry is super useful, 
>> but mostly for the developers, not as much for users.
>>
>> I really don't want someone reading a blog post where the author uses these 
>> images
>> and the reader then running them forever. Having "devel" in the name of the 
>> image 
>> URI will certainly help with that. Maybe I'm being too difficult.
> 
> I don't think these images should get into the openshift namespace, as
> most of them are not really connected to openshift.

OK.


> 
> Most of the time, changes to the image are bug fixes.  There is not
> really much development happening in the system container itself, so I
> don't see much disadvantage if these changes are propagated quickly.

If there's not much changes going on then why can't we use the distro
registry which has a process for rebuilding images periodically to account
for CVEs? I know the Fedora registry is not perfect, but would like for us
not to fragment and have so many different places to pull a system container
from. 

> Even if we build them on the Fedora registry, they will still not work
> "forever" as the Fedora release number is part of the image name.

Yes, For whatever reason that was a decision made by Fedora to break up
images and namespace them that way. I don't think it is a bad thing, though.

Ultimately the projecatomic namespace [1] on docker hub is a tirefire of dead
projects at this point other than maybe papr and asciibinder. There is no formal
process for retiring things or releasing them or making sure they don't have 
CVEs.
This model doesn't work and I'd prefer for it to go away complete IMHO. 

[1] https://hub.docker.com/u/projectatomic/

Re: [atomic-devel] a better place for system container images?

[Stephen Milner]

On Mon, Nov 6, 2017 at 8:29 AM, Giuseppe Scrivano  wrote:
> Hi Dusty,
>
> Dusty Mabe  writes:
>
>> On 11/06/2017 03:57 AM, Giuseppe Scrivano wrote:
>>> Hi,
>>>
>>> I'd like to find a better place where to move the system container[1]
>>> images that I am currently building under docker.io/gscrivano.
>>>
>>> CRI-O and Docker them are already used by the OpenShift installer to get
>>> the latest version available.
>>
>> Are you saying the openshift installer uses docker.io/gscrivano now?
>
> yes, docker.io/gscrivano/cri-o-centos and docker.io/gscrivano/cri-o-fedora
> are used for the CRI-O system container.
>
>
>> I understand that we want upstream images for "latest" content in an upstream
>> repository but we have to be careful that people know they shouldn't use it 
>> in
>> production or otherwise rely on these images long term. I think putting them 
>> under
>> projectatomic/ on docker hub might not be clear enough. Ideas:
>>
>> - create a projectatomic-devel organization and put them under there
>> - put them under projectatomic/ but add devel or upstream in the name of 
>> each image.
>
> would a tag be enough?

I feel like a tag would be enough. I'd rather not have yet another
namespace if possible. The -devel would be slightly better but I
believe tagging should suffice.

>> Openshift has a set of images they put out to the hub but they also have a
>> team of people that do release engineering. One option would be to try to
>> get them to agree to own the images and pushes to docker hub under the 
>> openshift
>> namespace.
>>> The goal is to build the images automatically on every PR merged.
>>> Occasional builds (maybe daily?) will prevent to miss changes in the
>>> base layers or in the installed rpms.
>>
>> Having the latest build pushed automatically to a registry is super useful,
>> but mostly for the developers, not as much for users.
>>
>> I really don't want someone reading a blog post where the author uses these 
>> images
>> and the reader then running them forever. Having "devel" in the name of the 
>> image
>> URI will certainly help with that. Maybe I'm being too difficult.
>
> I don't think these images should get into the openshift namespace, as
> most of them are not really connected to openshift.

I agree. While they are used in openshift in specific configurations
the images have a wider case of use.

> Most of the time, changes to the image are bug fixes.  There is not
> really much development happening in the system container itself, so I
> don't see much disadvantage if these changes are propagated quickly.
> Even if we build them on the Fedora registry, they will still not work
> "forever" as the Fedora release number is part of the image name.

-- 
Thanks,
Steve Milner

Atomic | Red Hat | http://projectatomic.io/

Re: [atomic-devel] a better place for system container images?

[Giuseppe Scrivano]

Hi Dusty,

Dusty Mabe  writes:

> On 11/06/2017 03:57 AM, Giuseppe Scrivano wrote:
>> Hi,
>> 
>> I'd like to find a better place where to move the system container[1]
>> images that I am currently building under docker.io/gscrivano.
>> 
>> CRI-O and Docker them are already used by the OpenShift installer to get
>> the latest version available.
>
> Are you saying the openshift installer uses docker.io/gscrivano now?

yes, docker.io/gscrivano/cri-o-centos and docker.io/gscrivano/cri-o-fedora
are used for the CRI-O system container.


> I understand that we want upstream images for "latest" content in an upstream
> repository but we have to be careful that people know they shouldn't use it in
> production or otherwise rely on these images long term. I think putting them 
> under
> projectatomic/ on docker hub might not be clear enough. Ideas:
>
> - create a projectatomic-devel organization and put them under there
> - put them under projectatomic/ but add devel or upstream in the name of each 
> image.

would a tag be enough?


> Openshift has a set of images they put out to the hub but they also have a
> team of people that do release engineering. One option would be to try to
> get them to agree to own the images and pushes to docker hub under the 
> openshift
> namespace.
>> The goal is to build the images automatically on every PR merged.
>> Occasional builds (maybe daily?) will prevent to miss changes in the
>> base layers or in the installed rpms.
>
> Having the latest build pushed automatically to a registry is super useful, 
> but mostly for the developers, not as much for users.
>
> I really don't want someone reading a blog post where the author uses these 
> images
> and the reader then running them forever. Having "devel" in the name of the 
> image 
> URI will certainly help with that. Maybe I'm being too difficult.

I don't think these images should get into the openshift namespace, as
most of them are not really connected to openshift.

Most of the time, changes to the image are bug fixes.  There is not
really much development happening in the system container itself, so I
don't see much disadvantage if these changes are propagated quickly.
Even if we build them on the Fedora registry, they will still not work
"forever" as the Fedora release number is part of the image name.

Regards,
Giuseppe

Re: [atomic-devel] a better place for system container images?

[Clayton Coleman]

On Nov 6, 2017, at 8:09 AM, Dusty Mabe  wrote:



On 11/06/2017 03:57 AM, Giuseppe Scrivano wrote:

Hi,


I'd like to find a better place where to move the system container[1]

images that I am currently building under docker.io/gscrivano.


CRI-O and Docker them are already used by the OpenShift installer to get

the latest version available.


Are you saying the openshift installer uses docker.io/gscrivano now?


My preference is to move these images under "docker.io/projectatomic".

We can't use the Fedora or CentOS registries since we want to build

these images automatically.  The downstream registries will be used only

for a subset of these images.


I understand that we want upstream images for "latest" content in an
upstream
repository but we have to be careful that people know they shouldn't use it
in
production or otherwise rely on these images long term. I think putting
them under
projectatomic/ on docker hub might not be clear enough. Ideas:

- create a projectatomic-devel organization and put them under there
- put them under projectatomic/ but add devel or upstream in the name of
each image.

Openshift has a set of images they put out to the hub but they also have a
team of people that do release engineering. One option would be to try to
get them to agree to own the images and pushes to docker hub under the
openshift
namespace.


We’ll probably need to do this for origin and centos no matter what.



The goal is to build the images automatically on every PR merged.

Occasional builds (maybe daily?) will prevent to miss changes in the

base layers or in the installed rpms.


Having the latest build pushed automatically to a registry is super useful,
but mostly for the developers, not as much for users.

I really don't want someone reading a blog post where the author uses these
images
and the reader then running them forever. Having "devel" in the name of the
image
URI will certainly help with that. Maybe I'm being too difficult.


Thoughts?


Thanks,

Giuseppe


[1] https://github.com/projectatomic/atomic-system-containers

Re: [atomic-devel] a better place for system container images?

[Dusty Mabe]

On 11/06/2017 03:57 AM, Giuseppe Scrivano wrote:
> Hi,
> 
> I'd like to find a better place where to move the system container[1]
> images that I am currently building under docker.io/gscrivano.
> 
> CRI-O and Docker them are already used by the OpenShift installer to get
> the latest version available.

Are you saying the openshift installer uses docker.io/gscrivano now?

> 
> My preference is to move these images under "docker.io/projectatomic".
> We can't use the Fedora or CentOS registries since we want to build
> these images automatically.  The downstream registries will be used only
> for a subset of these images.

I understand that we want upstream images for "latest" content in an upstream
repository but we have to be careful that people know they shouldn't use it in
production or otherwise rely on these images long term. I think putting them 
under
projectatomic/ on docker hub might not be clear enough. Ideas:

- create a projectatomic-devel organization and put them under there
- put them under projectatomic/ but add devel or upstream in the name of each 
image.

Openshift has a set of images they put out to the hub but they also have a
team of people that do release engineering. One option would be to try to
get them to agree to own the images and pushes to docker hub under the openshift
namespace.

> 
> The goal is to build the images automatically on every PR merged.
> Occasional builds (maybe daily?) will prevent to miss changes in the
> base layers or in the installed rpms.

Having the latest build pushed automatically to a registry is super useful, 
but mostly for the developers, not as much for users.

I really don't want someone reading a blog post where the author uses these 
images
and the reader then running them forever. Having "devel" in the name of the 
image 
URI will certainly help with that. Maybe I'm being too difficult.

> 
> Thoughts?
> 
> Thanks,
> Giuseppe
> 
> [1] https://github.com/projectatomic/atomic-system-containers
> 

[atomic-devel] a better place for system container images?

[Giuseppe Scrivano]

Hi,

I'd like to find a better place where to move the system container[1]
images that I am currently building under docker.io/gscrivano.

CRI-O and Docker them are already used by the OpenShift installer to get
the latest version available.

My preference is to move these images under "docker.io/projectatomic".
We can't use the Fedora or CentOS registries since we want to build
these images automatically.  The downstream registries will be used only
for a subset of these images.

The goal is to build the images automatically on every PR merged.
Occasional builds (maybe daily?) will prevent to miss changes in the
base layers or in the installed rpms.

Thoughts?

Thanks,
Giuseppe

[1] https://github.com/projectatomic/atomic-system-containers