On 05/10/2017 10:37 AM, Antonio Murdaca wrote:
On May 10, 2017 16:32, "Colin Walters" <walt...@verbum.org <mailto:walt...@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 <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.
