[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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





On Thu, May 11, 2017 at 9:11 AM Daniel Walsh <dwalsh redhat com> wrote:
On 05/10/2017 10:37 AM, Antonio Murdaca wrote:


On May 10, 2017 16:32, "Colin Walters" <walters verbum org> 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.


+10 on that. Create a drop-in replacement...


 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]