Making a node use a different manifest

[Roger Sherman]

Hi,

I've inherited an environment that is using Puppet 2.7. We're migrating from one datacenter to another, but we're still running out of the old datacenter. Some of our hardware there is reaching EOL, and it's creating a situation that I, with my limited Puppet experience, am not really sure how to procede. 

We have a node that is fairly critical, that may be dying. Long story short, we have a a server there that has the same resource setup (CPU, RAM, etc), that isn't doing anything, and we want the spare node to take over for the critical node. After much discussion, we think the easiest way to make that happen is by running the puppet manifest for the critical node, on the spare node.

This raises a couple of questions - the one that I'm having the most trouble wrapping my head around is, what is the best method for making the spare node use the critical nodes manifest? I don't think I can just copy and paste it into the spare nodes manifest (it used to be part of a different group of servers), can I? I assume I need to change the hostname...if so, what is the best method for doing so?

Both nodes are running Debain 6 - any and all help would be greatly appreciated.

Thank you,

Roger

[Denmat]

Hi Roger,

Yes you can copy the critical node configuration into the spare node's. 

However, it really does depend on what that critical node does and any special requirements it has. It may have services that might need to be managed across one by one. Or it may require one node to be shutdown before the other come up. 

Anyway, short answer is yes, you can copy the node definitions if that makes sense to do so.

HTH

Den

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b888c8d1-e541-43e3-bb97-d8245651b38a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roger Sherman]

Hi Den, and thank you for the response.

There is some data that will need to be rsynced, but mostly it's drawing from mysql nodes, and not storing or creating data itself.

One issue, though, that I wonder if just copying and pasting into the spare nodes manifest - I need the hostname to change as well. I'm assuming to do that, I delete the certs on the agent and master, and send another certificate request from the agent to the master? Or is there a better way to handle that?

Thank you,

Roger

[jcbollinger]

On Monday, July 7, 2014 8:01:18 AM UTC-5, Roger Sherman wrote:

Hi Den, and thank you for the response.

There is some data that will need to be rsynced, but mostly it's drawing from mysql nodes, and not storing or creating data itself.

One issue, though, that I wonder if just copying and pasting into the spare nodes manifest - I need the hostname to change as well. I'm assuming to do that, I delete the certs on the agent and master, and send another certificate request from the agent to the master? Or is there a better way to handle that?

If you are going to change the spare's hostname (and you are using hostnames as node identifiers, which is the default) then you should clean its current cert from the master, clean the whole /var/lib/puppet/ssl directory from the node, and have the node recertify with the master.  If it happens that you are changing the node's hostname to the erstwhile hostname of the current prod server then you will also need to clean the prod server's cert from the master before it will sign a new cert for the same node identifier.

If you want the current and future servers both to be able to sync to the master during the transition, then you should also be able to make the spare usurp the prod server's identity by wiping the spare's /var/lib/puppet/ssl and putting a copy of the prod server's in its place.  The spare should then receive the same catalogs as the prod server, modulo differences arising from different node facts.  You can do that before changing the spare's hostname, as it is only convention that hostnames match the identifier on their SSL certs.


John

[Roger Sherman]

Thanks John, I think that answers the rest of my question.

I'm actually doing this in stages - the critical node is worker3.blahblah.com, so I'm making spare.blahblah.com into worker4.blahblah.com (with the critical services not started), then I'll be rsyncing, and then shutting down worker3, and changing the hostname of worker4 to worker3.

Thank you, 

Roger