Re: [atomic-devel] Hacking on Atomic Host: Achievement: unlocked

On 28/03/16, Jonathan Lebon wrote: > > Any solution for testing that needs to involve a reboot? > > Check out `unlock --hotfix`! It will make the overlayfs > persistent across reboots. > > https://github.com/ostreedev/ostree/blob/master/man/ostree-admin-unlock.xml#L74 Awesome features :) Kushal

Re: [atomic-devel] Hacking on Atomic Host: Achievement: unlocked

On 03/28/2016 10:39 AM, Colin Walters wrote: > I think with the new "ostree admin unlock" verb in OSTree v2016.4 that has > changed: > https://mail.gnome.org/archives/ostree-list/2016-March/msg9.html This is very cool. We should probably blog about this too. -- Joe Brockmeier | Community

Re: [atomic-devel] Hacking on Atomic Host: Achievement: unlocked

> Any solution for testing that needs to involve a reboot? Check out `unlock --hotfix`! It will make the overlayfs persistent across reboots. https://github.com/ostreedev/ostree/blob/master/man/ostree-admin-unlock.xml#L74

Re: [atomic-devel] Hacking on Atomic Host: Achievement: unlocked

On 03/28/2016 10:39 AM, Colin Walters wrote: > One of the goals I have for Atomic Host is that we are doing more integration > testing work than the traditional client-side package assembly model. > > However, in order to achieve that goal, we need to enable developers to > quickly and

Re: [atomic-devel] Parallel installing 1.9 and 1.10

On Mon, Mar 28, 2016, at 10:59 AM, Eric Paris wrote: > At this point there is no known reason (at least to me) not to release > 1.10 because of kube. Is there anything tracking this outside of https://github.com/kubernetes/kubernetes/issues/19720 ? I need to try it myself. > So I don't see a

Re: [atomic-devel] Parallel installing 1.9 and 1.10

On Mon, 2016-03-28 at 10:54 -0400, Daniel J Walsh wrote: > Well a couple of points, we are currently blocked from pushing  > docker-1.10 into fedora 23, because > it will break k8s, and it looks like we could have the same problem > when  > we go to ship docker-1.10 > into rhel in May.If we

Re: [atomic-devel] Parallel installing 1.9 and 1.10

On Mon, Mar 28, 2016 at 10:54 AM, Daniel J Walsh wrote: > > > On 03/28/2016 10:45 AM, Eric Paris wrote: > >> On Mon, 2016-03-28 at 09:27 -0400, Colin Walters wrote: >> >>> Hi, >>> >>> In some of my use cases I have OpenShift/Kubernetes clusters that are >>> primarily certified

Re: [atomic-devel] Parallel installing 1.9 and 1.10

On 03/28/2016 10:51 AM, Antonio Murdaca wrote: On Mar 28, 2016 4:43 PM, "Daniel J Walsh" > wrote: > > We are currently thinking just to use a simple bash script. > > cat /usr/bin/docker > #!/bin/sh > . /etc/sysconfig/docker > [ -e

Re: [atomic-devel] Parallel installing 1.9 and 1.10

On Mar 28, 2016 4:43 PM, "Daniel J Walsh" wrote: > > We are currently thinking just to use a simple bash script. > > cat /usr/bin/docker > #!/bin/sh > . /etc/sysconfig/docker > [ -e "${DOCKERBINARY}" ] || DOCKERBINARY=/usr/libexec/docker/docker-1.10 > exec ${DOCKERBINARY} $@ >

Re: [atomic-devel] Parallel installing 1.9 and 1.10

On Mon, 2016-03-28 at 09:27 -0400, Colin Walters wrote: > Hi, > > In some of my use cases I have OpenShift/Kubernetes clusters that are > primarily certified on 1.9, and so I'd like to keep using that.  But > it'd be useful to be able to quickly try out 1.10 on some of my > nodes, or in cases

Re: [atomic-devel] Parallel installing 1.9 and 1.10

We are currently thinking just to use a simple bash script. cat /usr/bin/docker #!/bin/sh . /etc/sysconfig/docker [ -e "${DOCKERBINARY}" ] || DOCKERBINARY=/usr/libexec/docker/docker-1.10 exec ${DOCKERBINARY} $@ And then allow user to change DOCKERBINARY in /etc/sysconfig/docker. Then we would

[atomic-devel] Hacking on Atomic Host: Achievement: unlocked

One of the goals I have for Atomic Host is that we are doing more integration testing work than the traditional client-side package assembly model. However, in order to achieve that goal, we need to enable developers to quickly and rapidly test combinations of packages and code. Until now,

Re: [atomic-devel] Parallel installing 1.9 and 1.10

On 03/28/2016 10:16 AM, Jason DeTiberus wrote: Does it make sense to configure it through alternatives? alternative changes the target via symlinks in /usr/bin - this is a readonly FS for rpm-ostree based builds. For normal RPM installs, alternatives is an option. On Mon, Mar 28, 2016 at

Re: [atomic-devel] Parallel installing 1.9 and 1.10

Does it make sense to configure it through alternatives? On Mon, Mar 28, 2016 at 9:41 AM, Andy Goldstein wrote: > Ok, makes sense. > > I'm +1 to having the ability to test out newer Docker versions. How would > they ship - in 1 RPM, or multiple? > > On Mon, Mar 28, 2016 at

Re: [atomic-devel] Parallel installing 1.9 and 1.10

Ok, makes sense. I'm +1 to having the ability to test out newer Docker versions. How would they ship - in 1 RPM, or multiple? On Mon, Mar 28, 2016 at 9:38 AM, Colin Walters wrote: > On Mon, Mar 28, 2016, at 09:31 AM, Andy Goldstein wrote: > > Would this be with SCL, or some

Re: [atomic-devel] Parallel installing 1.9 and 1.10

On Mon, Mar 28, 2016, at 09:31 AM, Andy Goldstein wrote: > Would this be with SCL, or some other means? The SCL model/tools become more useful when dynamic linking is in play, but currently in our usage of golang there aren't any beyond a few system ones.  So I think it would work to just have

Re: [atomic-devel] Parallel installing 1.9 and 1.10

Would this be with SCL, or some other means? On Mon, Mar 28, 2016 at 9:27 AM, Colin Walters wrote: > Hi, > > In some of my use cases I have OpenShift/Kubernetes clusters that are > primarily certified on 1.9, and so I'd like to keep using that. But it'd > be useful to be

[atomic-devel] Parallel installing 1.9 and 1.10

Hi, In some of my use cases I have OpenShift/Kubernetes clusters that are primarily certified on 1.9, and so I'd like to keep using that. But it'd be useful to be able to quickly try out 1.10 on some of my nodes, or in cases outside of a Kube cluster. Does anyone have any thoughts on this?