Skip to content
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

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Open

Added enable flag for chef and set it to true by default #20

wants to merge 14 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Mar 29, 2018

Added the enable configuration flag for chef and set it to true by default to ensure backward compatibility.

Copy link
Owner

@eheydrick eheydrick left a 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?

@eheydrick
Copy link
Owner

Part of #18.

@ghost
Copy link
Author

ghost commented Apr 4, 2018

Thanks Eric, Yes I was looking to make chef completely optional. The follow up commits add the following:

  • Backwards compatibility with older config files.
  • Using sensu as a lookup for client name (also with backwards compatibility).
  • Updated the sample config file with the new values.
  • Moved the logic for the deletion of messages out of the individual functions into the main loop.
  • Fixes a bug where if the node was not found in chef the message would never get deleted.

Also fixed up my code so rubycop is happy.

Hope this works for you.

Thanks,

Robbert

Copy link
Collaborator

@majormoses majormoses left a 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.

@@ -1,3 +1,4 @@
:lookup: chef
Copy link
Collaborator

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added that.

@@ -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]}")
Copy link
Collaborator

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?

Copy link
Author

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.

Copy link
Collaborator

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.

Copy link
Owner

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-.

Copy link
Author

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.

webhook(id, instance_id)
chef(id, instance_id, chef_node)
sensu(id, instance_id, chef_node)
node = case @config[:lookup]
Copy link
Collaborator

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?

Copy link
Author

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.

@eheydrick
Copy link
Owner

Thanks @sestary will review soon.

@ghost
Copy link
Author

ghost commented Apr 4, 2018

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

Copy link
Author

@ghost ghost left a 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.

end

AwsCleaner.new.delete_message(id, @config)
Copy link
Author

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```

Copy link
Collaborator

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.

Copy link
Collaborator

@majormoses majormoses left a 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:
Copy link
Collaborator

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.

Copy link
Author

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.

node = case @config[:general][:lookup_type]
when 'sensu'
AwsCleaner::Sensu.get_sensu_node_name(instance_id, @config)
else
Copy link
Collaborator

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'?

Copy link
Author

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.

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? ||
Copy link
Collaborator

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.

Copy link
Author

@ghost ghost Apr 9, 2018

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.

Copy link
Collaborator

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?

Copy link
Author

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.

@@ -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
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update comment to Sensu.

@@ -1,3 +1,7 @@
:general:
:lookup_type: 'chef'
Copy link
Owner

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.

Copy link
Author

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.

@eheydrick
Copy link
Owner

👍 Thanks for splitting that out. I'm going to test out the changes and get this merged in if all looks good.

@majormoses
Copy link
Collaborator

@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.

@eheydrick
Copy link
Owner

Sounds good. I'll have some time to test and review soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants