On Tue, Sep 17, 2013 at 7:26 AM, Rob Reynolds wrote:
> So far it sounds like option A, but I think there was a thought started
> here that you could just order everything so that the reboot occurs last.
> Then if there is an issue along the way, the next run (provided it doesn't
> also error) wil
Likewise A.
I was part of the initial discussion earlier yesterday, and to me this felt
like the most pragmatic thing to do under the circumstances.
On Tue, Sep 17, 2013 at 10:51 AM, Andy Parker wrote:
> On Tue, Sep 17, 2013 at 7:26 AM, Rob Reynolds wrote:
>
>> So far it sounds like option A,
On Monday, September 16, 2013 11:12:58 AM UTC-5, Andy Parker wrote:
>
> On Mon, Sep 16, 2013 at 6:56 AM, John Bollinger
>
> > wrote:
>
>>
>>
>> On Monday, September 16, 2013 6:48:17 AM UTC-5, Andy Parker wrote:
>>>
>>>
>>> The problem with this picture for being able to batch operations
>>> to
On Sep 12, 2013, at 1:15 PM, John Bollinger wrote:
>
>
> On Wednesday, September 11, 2013 3:14:41 PM UTC-5, Luke Kanies wrote:
> On Sep 11, 2013, at 12:32 PM, John Bollinger wrote:
>
>>
>>
>> On Wednesday, September 11, 2013 11:58:55 AM UTC-5, Trevor Vaughan wrote:
>> This definitely works
We had a good turnout for a somewhat impromptu hangout to talk about data in
modules.
me
henrik
blkperl / William
nibalizer / Spencer
Sage
Randm / Vincent
daenney
ashley p
dan bode
I put my notes up as a gist, please take a look and LMK if I missed anything or
mischaracterized something you sai
Okay, now to introduce my bias into the conversation now that others have
responded.
A - always want to reboot even if other unrelated events fail.
On Tue, Sep 17, 2013 at 10:54 AM, Ethan Brown wrote:
> Likewise A.
>
> I was part of the initial discussion earlier yesterday, and to me this
> fe
On Tue, Sep 17, 2013 at 9:35 AM, Henrik Lindberg <
henrik.lindb...@cloudsmith.com> wrote:
> On 2013-17-09 5:44, Henrik Lindberg wrote:
>
>> On 2013-16-09 19:28, Andy Parker wrote:
>>
>>> On Mon, Sep 16, 2013 at 7:58 AM, Henrik Lindberg
>>> So we just talked about this on IRC. I think the outcome w
I was able to get a bit of info about what the read queue is as the catalog
is being executed. It looks like there are some times (this is just by
eyeballing it, haven't crunched any numbers) where we can get a run of
several packages that could be batched together.
The branch that contains the ch
There's some places where there is 19 packages on the ready queue in that
example catalog.
On 17 September 2013 18:48, Andy Parker wrote:
> I was able to get a bit of info about what the read queue is as the
> catalog is being executed. It looks like there are some times (this is just
> by eyeb
On 2013-17-09 5:44, Henrik Lindberg wrote:
On 2013-16-09 19:28, Andy Parker wrote:
On Mon, Sep 16, 2013 at 7:58 AM, Henrik Lindberg
So we just talked about this on IRC. I think the outcome was:
* We agree that undef is really messed up right now
* Variable references should be strict
*
On 2013-17-09 18:55, Andy Parker wrote:
On Tue, Sep 17, 2013 at 9:35 AM, Henrik Lindberg
mailto:henrik.lindb...@cloudsmith.com>>
wrote:
On 2013-17-09 5:44, Henrik Lindberg wrote:
On 2013-16-09 19:28, Andy Parker wrote:
On Mon, Sep 16, 2013 at 7:58 AM, Henrik Lindberg
On Mon, Sep 16, 2013 at 8:11 PM, huang ming wrote:
>
> I want the puppetmaster can sign the manifest. avoid some guys publish
> dangerous manifest to agent. like exec{"foo": command=>"rm / -rf";}
>
> there is a software named samhain. it's a integrity checker and host
> intrusion detection sys
So far it sounds like option A, but I think there was a thought started
here that you could just order everything so that the reboot occurs last.
Then if there is an issue along the way, the next run (provided it doesn't
also error) will cause the reboot to happen.
Which could technically meet bot
On Mon, Sep 16, 2013 at 4:19 PM, badgerious wrote:
> If we support this functionality and there is a failure during the catalog
>> run after a reboot at the end has been requested, what would be your
>> expectation for the system.
>>
>
>> Would you expect it to:
>>
>
>> A) still reboot
>>
> B) no
14 matches
Mail list logo
