-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added enable flag for chef and set it to true by default #20
base: master
Are you sure you want to change the base?
Conversation
…ckward compatability
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @sestary thanks for the contribution! A few comments. In order to maintain backwards compatibility with existing configs we should have chef enabled by default like here. Also note that it would still use chef to determine the node name even if chef support were disabled. We should document that in the README.
I'd love to support integrations with other systems - right now it's tied to chef but there's no reason it has to be. We're you looking to make chef support entirely optional?
Part of #18. |
Thanks Eric, Yes I was looking to make chef completely optional. The follow up commits add the following:
Also fixed up my code so rubycop is happy. Hope this works for you. Thanks, Robbert |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I think this looks good. I have a couple of comments/questions to address.
config.yml.sample
Outdated
@@ -1,3 +1,4 @@ | |||
:lookup: chef |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this should be quoted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added that.
lib/aws-cleaner.rb
Outdated
@@ -30,15 +30,15 @@ def self.client(config) | |||
# call the Chef API to get the node name of the instance | |||
def self.get_chef_node_name(instance_id, config) | |||
chef = client(config) | |||
results = chef.search.query(:node, "ec2_instance_id:#{instance_id} OR chef_provisioning_reference_server_id:#{instance_id}") | |||
results = chef.search.query(:node, "ec2_instance_id:#{instance_id[2..-1]} OR chef_provisioning_reference_server_id:#{instance_id[2..-1]}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a chef server currently to test this against can you show me the output of this or explain this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This removes the "i-" part from the instance ID in case you don't have that. I do the same on the sensu side since we don't have that part in our client names.
I tested it on a quick chef install and it seemed to work but don't have a full chef install to test against. I'm ok omitting this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to address this separately and will be starting a new job next week so I will have a chef and sensu server to test with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that should be removed since it's going to break lookups for the instance. Ohai populates that attribute with the actual instance-id and it will always include i-
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have reverted that, I figured since it was the "search" api that was being called it would also search partial strings it seemed to work on my quick test with chef but since I don't use it I'm fine with reverting it.
bin/aws_cleaner.rb
Outdated
webhook(id, instance_id) | ||
chef(id, instance_id, chef_node) | ||
sensu(id, instance_id, chef_node) | ||
node = case @config[:lookup] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This option name seems too ambiguous to me, short variables are good but maybe making it a bit more verbose will do some good here. maybe something along the lines of lookup_type
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have updated it to lookup_type. That is a bit more clear.
Thanks @sestary will review soon. |
I added another option to listen for multiple states and completely ignore messages that don't match these states, this means other programs will be able to listen to the same queue. Let me know what you think. Thanks, Robbert |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know how you want to handle this. I did make the change in the last commit.
bin/aws_cleaner.rb
Outdated
end | ||
|
||
AwsCleaner.new.delete_message(id, @config) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about this and discussing with a colleague, right now the message is deleted when it is not deemed relevant like when the state is not "terminated", however if you have another process looking at the same SQS queue for "running" events this could cause messages to get lost. Should this be moved to before the else statement so it looks like this? That way the message is only deleted once processed and not when it is ignored, the other side affect is that if you have nothing else listening you will have extra messages queuing up that will never be processed.
end
AwsCleaner.new.delete_message(id, @config)
else
@logger.info('Message not relevant, ignoring...')
end```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the expectation has been that this queue is only used for aws-cleaner
I would not want to mix this and say application queues there is no real cost to using a seperate queue. I'd like to hear more of a real world justification before wanting to go down this route.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I am 👍 but I think we are seeing too much scope creep for my comfort. Let's get the minimum required changes in within the scope of the issue and then discuss and enhance further afterwards.
README.md
Outdated
By default aws-cleaner assumes that removing from sensu is desired as this was one of its core intentions. To allow people to leverage this without sensu you can disable it via config: | ||
By default aws-cleaner assumes that the lookup will be done against chef as this was one of its core intentions. This can be configured for sensu via config: | ||
|
||
You can disable sensu via config as well to skip removing the client from sensu: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not indicate that you can disable removing from chef.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the read me a little, but the section of chef is a little further down in the read me, but I have clarified the README a bit in the next commit.
bin/aws_cleaner.rb
Outdated
node = case @config[:general][:lookup_type] | ||
when 'sensu' | ||
AwsCleaner::Sensu.get_sensu_node_name(instance_id, @config) | ||
else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be when 'chef'
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No this should be when chef, since the variable set to "chef" plus any invalid value would default to use chef.
lib/aws-cleaner.rb
Outdated
return false if message_body['detail']['instance-id'].nil? && | ||
message_body['detail']['state'] != 'terminated' | ||
def process_message(message_body, config) | ||
return false if message_body['detail']['instance-id'].nil? || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets use the &&
to keep the existing behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is my only problem, since we use one queue to monitor the "running" state notifications with aws-watcher and prefer not to add multiple queues since it's more to manage. We already have a queue/process for every AWS region.
Would it be ok to add a config parameter to delete irelevant messages that is set to true by default, that way by default the existing behavior is kept but it can be overwritten. I was thinking I can add that either in the main loop or the process_message function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome to see others using that project and the use case makes sense to me.
I'd still prefer it to be in 2 separate PRs though personally @eheydrick what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have separated the changes. I will submit another pull request for the message handling.
lib/aws-cleaner.rb
Outdated
@@ -58,6 +58,37 @@ def self.remove_from_chef(node_name, chef, config) | |||
end | |||
|
|||
module Sensu | |||
# call the Chef API to get the node name of the instance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
update comment to Sensu.
config.yml.sample
Outdated
@@ -1,3 +1,7 @@ | |||
:general: | |||
:lookup_type: 'chef' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thinking this variable should node_name_provider
or something like that to be clear what exactly is being looked up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in the last commit.
👍 Thanks for splitting that out. I'm going to test out the changes and get this merged in if all looks good. |
@eheydrick looks like the user is no longer on github so we should test it and if we need any other changes we are gonna need to make them ourselves. |
Sounds good. I'll have some time to test and review soon. |
Added the enable configuration flag for chef and set it to true by default to ensure backward compatibility.