Sorry wrong thread *getting more coffee*
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, se
Why don't you use nodes groups or environments to prevent the second set of
servers to be updated?
Once validated on the first node group, you can easily deploy on the second set.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe f
Why don't you use nodes groups or environments to prevent the second set of
servers to be updated?
Once validated on the first node group, you can easily deploy on the second set.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe f
On Wednesday, February 13, 2013 4:11:40 PM UTC-6, blalor wrote:
>
> There may be, but when we want to upgrade an application and minimize
> downtime, a well-defined window of a checkin period is not sufficient. For
> example, given 10 machines, we need to upgrade 5, validate them, then
> upgra
There may be, but when we want to upgrade an application and minimize downtime,
a well-defined window of a checkin period is not sufficient. For example, given
10 machines, we need to upgrade 5, validate them, then upgrade the remaining 5.
The 5 being upgraded will get pulled out of the load bal
On Tuesday, February 12, 2013 8:37:56 PM UTC-6, blalor wrote:
>
> I'd like to use Puppet for the "last-mile" deployment of our applications,
> starting from a bare VM and ending up with a server that is running a
> specific version of an application. We're using a Puppet master already,
> whi
