Re: How to make 172.30.0.1 (kubernetes service) health checked?

Masters should actually remove themselves, but maybe that regressed. I’ll try to take a look but removing themselves when they receive a sigterm is a good idea. On Sep 10, 2018, at 6:58 PM, Joel Pearson wrote: Hi Clayton, Sorry for the extensive delay, but I’ve been thinking about this more

Re: How to make 172.30.0.1 (kubernetes service) health checked?

Hi Clayton, Sorry for the extensive delay, but I’ve been thinking about this more and I’m wondering if it’s safe to remove a master from the endpoint just before restarting it (say in Ansible), so that failures aren’t seen inside the cluster? Or would something in Kubernetes just go and add the

Re: Binary build info

And coming in 3.11 is an experimental command that lets you add a tar file as a new layer in an image (or as a new “scratch” image), so it’s even easier to tar up your source code as an image, and have builds trigger off the image change. The command is “oc image append —to= [layer as tar.gz]”

Re: Binary build info

On Mon, Sep 10, 2018 at 4:25 AM, Jean-Francois Maury wrote: > Hello, > > I have a question about binary builds. Once a binary build has been > created through the instanciatebinary operation, can we use the clone > operation to respawn a new build ? Will it use the previous input ? >

Binary build info

Hello, I have a question about binary builds. Once a binary build has been created through the instanciatebinary operation, can we use the clone operation to respawn a new build ? Will it use the previous input ? Thanks -- JEFF MAURY Red Hat jma...@redhat.com