> I'm in the process of upgrading my puppet from 2x to 3.2.1.
>
> During my testing i found that it appears that puppet node deactivate isn't
> removing nodes from storeconfigs.
So it should work and in my experience it often does. Most cases I
hear about this failing is when the Puppet code you are using doesn't
purge or handle the removal of exported resources. Another problem is
when the node itself is not truly deactivated, any bit of noise from a
deactivated node will reactivate it (for example) or perhaps the
deactivation didn't work due to certificate naming mismatches ...
Double check your puppetdb.log to make sure the command went through
for the deactivate:
2013-06-21 13:18:11,979 INFO [command-proc-45] [puppetdb.command]
[24574550-742d-4e70-bf98-011ae049b046] [deactivate node]
puppetdbclient1.vm
Then try a query against the API, to see if it has been removed:
# curl -H "Accept: application/json"
http://localhost:8080/v2/nodes/puppetdbclient1.vm
{
"name" : "puppetdbclient1.vm",
"deactivated" : "2013-06-21T12:21:45.334Z",
"catalog_timestamp" : "2013-06-21T12:20:42.368Z",
"facts_timestamp" : "2013-06-21T12:20:42.123Z",
"report_timestamp" : "2013-06-21T12:20:17.000Z"
}
You can see the 'deactivated' field here, if it contains a date its
deactivated. Active nodes should have 'null'. When you do a full query
for the resources, you shouldn't be able to find a resource for the
certname you deactivated either:
curl -H "Accept: application/json"
"
http://localhost:8080/v2/resources?query="
I'd double check all of this first, and make sure the operation on the
PuppetDB is indeed succeeding for yourself first. Btw, these
instructions are PuppetDB 1.3.x specific so if you have an older
revision the instructions may differ.
How are you generating this file? Its hard to make any specific
conclusions here, is this a concat pattern or a query inside a
template? If you can provide code it would be helpful.
Thanks.
ken.