Node client deletions before recreating the same client

Chef Infra (archive)
1

hiya. i'm still hoping to hear from the community how this is being
handled...

how are people handling reinstantiating a chef client using the same
node_name (i'm using FQDN)? before i can recreate hostXYZ.chefruulz.com
i first need to delete its previous cryptographic API identity. then the
new hostXYZ.chefruulz.com registers itself with the chef server using
validation.pem.

is there anything else available besides issuing "knife client delete
hostXYZ.chefruulz.com" prior to relaunching the new hostXYZ.chefruulz.com?

i'm assuming at this point i'll need to create a launch wrapper that has
the right privileges to make the API call to delete the previous client,
then launch anew. i think i would wrap this in bash inside a knife ec2
template or something else homegrown.

i just now noticed "knife client reregister" and
Chef Support for Automation & DevOps | Chef. haven't played with it yet. perhaps soon.

thanks,
kallen

On Fri, 06 Jan 2012, kallen@groknaut.net wrote:

hi. hosts are expenable, right? i deploy a host, i kill it and redeploy
it. yay automation. yay cookie cutters.

how are people solving the issue where you need to first run a "knife
client delete -y hostXYZ.chefruulz.com" before you can redeploy that
same host and have it successfully re-register with the chef-server?

my environment is ec2. i'm slowly moving my team away from using
ElasticFox to launch instances, and moving toward launching them
using a smarter script that runs ec2-run-instances command (i'm not yet
ready for knife ec2).

right now i'm knife client deleting by hand, but that blows. i think
i'd rather not add crisco and fishing line to my launch script that
calls the knife client delete first. doing so might involve using ssh
as an API (blech). or maybe calling knife client delete might not be
so gross. i haven't decided yet. this launch script isn't even the
final solution, but it's a step i've taken as an incremental improvement.

what smarter ways y'all're using? even tho i'm not yet using knife ec2,
don't hesitate telling me solutions that use it :>

tia,
kallen

2

Two ways I've handled it are a knife client/node delete at the start of re-provisioning, and preserving the client.pem across rebuilds.

On Jan 18, 2012, at 2:53 PM, kallen@groknaut.net wrote:

hiya. i'm still hoping to hear from the community how this is being
handled...

how are people handling reinstantiating a chef client using the same
node_name (i'm using FQDN)? before i can recreate hostXYZ.chefruulz.com
i first need to delete its previous cryptographic API identity. then the
new hostXYZ.chefruulz.com registers itself with the chef server using
validation.pem.

is there anything else available besides issuing "knife client delete
hostXYZ.chefruulz.com" prior to relaunching the new hostXYZ.chefruulz.com?

i'm assuming at this point i'll need to create a launch wrapper that has
the right privileges to make the API call to delete the previous client,
then launch anew. i think i would wrap this in bash inside a knife ec2
template or something else homegrown.

i just now noticed "knife client reregister" and
Chef Support for Automation & DevOps | Chef. haven't played with it yet. perhaps soon.

thanks,
kallen

On Fri, 06 Jan 2012, kallen@groknaut.net wrote:

hi. hosts are expenable, right? i deploy a host, i kill it and redeploy
it. yay automation. yay cookie cutters.

how are people solving the issue where you need to first run a "knife
client delete -y hostXYZ.chefruulz.com" before you can redeploy that
same host and have it successfully re-register with the chef-server?

my environment is ec2. i'm slowly moving my team away from using
ElasticFox to launch instances, and moving toward launching them
using a smarter script that runs ec2-run-instances command (i'm not yet
ready for knife ec2).

right now i'm knife client deleting by hand, but that blows. i think
i'd rather not add crisco and fishing line to my launch script that
calls the knife client delete first. doing so might involve using ssh
as an API (blech). or maybe calling knife client delete might not be
so gross. i haven't decided yet. this launch script isn't even the
final solution, but it's a step i've taken as an incremental improvement.

what smarter ways y'all're using? even tho i'm not yet using knife ec2,
don't hesitate telling me solutions that use it :>

tia,
kallen

3

Another alternative is to give validation.pem admin rights, or to fix the
chef server to allow validation to update clients. I've already submitted a
patch for that, it has yet to be reviewed.
On Jan 18, 2012 6:49 PM, "Jesse Nelson" spheromak@gmail.com wrote:

Two ways I've handled it are a knife client/node delete at the start of
re-provisioning, and preserving the client.pem across rebuilds.

On Jan 18, 2012, at 2:53 PM, kallen@groknaut.net wrote:

hiya. i'm still hoping to hear from the community how this is being
handled...

how are people handling reinstantiating a chef client using the same
node_name (i'm using FQDN)? before i can recreate hostXYZ.chefruulz.com
i first need to delete its previous cryptographic API identity. then the
new hostXYZ.chefruulz.com registers itself with the chef server using
validation.pem.

is there anything else available besides issuing "knife client delete
hostXYZ.chefruulz.com" prior to relaunching the new
hostXYZ.chefruulz.com?

i'm assuming at this point i'll need to create a launch wrapper that has
the right privileges to make the API call to delete the previous client,
then launch anew. i think i would wrap this in bash inside a knife ec2
template or something else homegrown.

i just now noticed "knife client reregister" and

Chef Support for Automation & DevOps | Chef.
haven't played with it yet. perhaps soon.

thanks,
kallen

On Fri, 06 Jan 2012, kallen@groknaut.net wrote:

hi. hosts are expenable, right? i deploy a host, i kill it and redeploy
it. yay automation. yay cookie cutters.

how are people solving the issue where you need to first run a "knife
client delete -y hostXYZ.chefruulz.com" before you can redeploy that
same host and have it successfully re-register with the chef-server?

my environment is ec2. i'm slowly moving my team away from using
ElasticFox to launch instances, and moving toward launching them
using a smarter script that runs ec2-run-instances command (i'm not yet
ready for knife ec2).

right now i'm knife client deleting by hand, but that blows. i think
i'd rather not add crisco and fishing line to my launch script that
calls the knife client delete first. doing so might involve using ssh
as an API (blech). or maybe calling knife client delete might not be
so gross. i haven't decided yet. this launch script isn't even the
final solution, but it's a step i've taken as an incremental
improvement.

what smarter ways y'all're using? even tho i'm not yet using knife ec2,
don't hesitate telling me solutions that use it :>

tia,
kallen

4

Sorry, I meant you can edit the chef-validator client and set it as an
admin.
On Jan 19, 2012 2:15 AM, "Jesse Campbell" hikeit@gmail.com wrote:

Another alternative is to give validation.pem admin rights, or to fix the
chef server to allow validation to update clients. I've already submitted a
patch for that, it has yet to be reviewed.
On Jan 18, 2012 6:49 PM, "Jesse Nelson" spheromak@gmail.com wrote:

Two ways I've handled it are a knife client/node delete at the start of
re-provisioning, and preserving the client.pem across rebuilds.

On Jan 18, 2012, at 2:53 PM, kallen@groknaut.net wrote:

hiya. i'm still hoping to hear from the community how this is being
handled...

how are people handling reinstantiating a chef client using the same
node_name (i'm using FQDN)? before i can recreate hostXYZ.chefruulz.com
i first need to delete its previous cryptographic API identity. then the
new hostXYZ.chefruulz.com registers itself with the chef server using
validation.pem.

is there anything else available besides issuing "knife client delete
hostXYZ.chefruulz.com" prior to relaunching the new
hostXYZ.chefruulz.com?

i'm assuming at this point i'll need to create a launch wrapper that has
the right privileges to make the API call to delete the previous client,
then launch anew. i think i would wrap this in bash inside a knife ec2
template or something else homegrown.

i just now noticed "knife client reregister" and

Chef Support for Automation & DevOps | Chef.
haven't played with it yet. perhaps soon.

thanks,
kallen

On Fri, 06 Jan 2012, kallen@groknaut.net wrote:

hi. hosts are expenable, right? i deploy a host, i kill it and redeploy
it. yay automation. yay cookie cutters.

how are people solving the issue where you need to first run a "knife
client delete -y hostXYZ.chefruulz.com" before you can redeploy that
same host and have it successfully re-register with the chef-server?

my environment is ec2. i'm slowly moving my team away from using
ElasticFox to launch instances, and moving toward launching them
using a smarter script that runs ec2-run-instances command (i'm not yet
ready for knife ec2).

right now i'm knife client deleting by hand, but that blows. i think
i'd rather not add crisco and fishing line to my launch script that
calls the knife client delete first. doing so might involve using ssh
as an API (blech). or maybe calling knife client delete might not be
so gross. i haven't decided yet. this launch script isn't even the
final solution, but it's a step i've taken as an incremental
improvement.

what smarter ways y'all're using? even tho i'm not yet using knife ec2,
don't hesitate telling me solutions that use it :>

tia,
kallen