[Puppet Users] Re: Why we wont use zpool ever again

2010-04-07 Thread Martin Englund
Kaspar,

On Apr 7, 10:44 am, Kaspar Schiess  wrote:
> > Use "puppetd --disable" the next time to keep your tools from stampeding
> > over your manual recovery efforts.
>
> I am not sure I understand - I could only boot into failsafe mode at the
> time. And the first real boot came up with puppetd running first thing.
> I can't think of anything to stop that, short of disabling the master.
>
you should have booted into milestone=none instead after the failsafe
boot, the you have time to fix things before the services start.

cheers,
/Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



[Puppet Users] Re: Why we wont use zpool ever again

2010-04-07 Thread Martin Englund
Kaspar,

On Apr 7, 8:31 am, Kaspar Schiess  wrote:

> It is correct that zfs normally wont allow to recreate zpool (issuing a
> warning about the device already being part of a zpool). Only that when
> your OS doesn't know about the pool anymore, you don't want puppet to
> create it on the next boot - you will want to recover it. But I guess
> I've driven that home.
>
when I commissioned Andrew to create the zpool type we tried to make
it as failsafe as possible (e.g. not using "-f", aborting when unsure,
etc). This was one of the cases we didn't think of :)

However, if you do this kind of operation, you should have realized
that the system will come back up without all previous zpools (and zfs
file systems).

> So to reproduce this (for whatever its worth) try deleting
> /etc/zfs/zpool.cache.
>
When I remove /etc/zfs/zpool.cache (in safemode) and then reboot, the
system comes back up without the data pool. This triggers zpool create
to run, but it fails with: " is part of an exported or
potentially active ZFS pool ", and since that failed all my zfs
types depending on that pool failed - no harm done.

So I don't get how you could have lost your pool, as zpool will refuse
to overwrite an existing pool without the "-f". All you would have had
to do was run "zpool import" and you'd been back to normal.

> >> In addition, I totally agree about the complexities surrounding zpool
> >> creation.  
>
> If zpool could create complex setups for me without knowing about device
> names beforehand, it would really be useful for provisioning. This way
> .. its just plain dangerous.
>
For me it depends. I just deployed 40 identical systems, and they all
have 4 disks, two are used for the root pool (to boot form) and two
are used as a data pool. I prefer to do the data pool creation in
puppet over in jumpstart, as it allows me to control more features in
the zpool.

cheers,
/Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Why we wont use zpool ever again

2010-04-07 Thread Kaspar Schiess

So I don't get how you could have lost your pool, as zpool will refuse
to overwrite an existing pool without the "-f". All you would have had
to do was run "zpool import" and you'd been back to normal.


To be perfectly honest with you, I am a bit in the dark about that as 
well. I've done the same experiment in the meantime - with no success. 
Guess the pool was really messed up.


Note that I am not telling anyone not to use zpool - it's just not 
paying off in _my scenario_ anymore. We use large zpools (apart from 
rootpool) in the big data machines only - and I dont mind doing those 
manually.


Sure, I could have thought of not having puppet start on system start 
(as has been suggested elsewhere) - but I must admit that my primary 
concern was fixing the server ASAP at the time, not what puppet could do 
to me once the server was back.


That's just something you don't think of there and then... Hence my 
post. Not wanting to step on anyones toes.


best regards,
kaspar

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.