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

LWRP Refactor #5

Merged
merged 29 commits into from Mar 10, 2014

Conversation

2 participants
@mal
Copy link

mal commented Dec 8, 2013

The README changes should tell you all you need to know, so this is going to focus on what you don't need to know, but might be useful.

  • Using a custom partial API (v1, v2) found in libraries/
    Ideally this would be replaced with a dedicated API gem, but I couldn't find one that met the needs of this cookbook.
  • Supports non-LWRP based usage, but does introduce breaking changes; suggest version bump to 2.0.0
  • The alert LWRP sort of cheats and leaves it to the user to sort out v1/v2 differences in alert creation, ideally this would be abstracted away, but time/effort etc
  • agent_key is cached in the node's data, override it to nil to force a new read from the API
  • Intended usage is to remove all alerts, and then reapply them because tracking alerts is impractical, this provides two benefits;
    1. old alerts get removed
    2. alerts do not get duplicated
  • :update and :clear are separate actions, so that it's possible to configure the agent without wiping existing alerts
  • It's now a lot easier to use credentials stored in encrypted databags \o/
  • Currently the service management works, but would benefit from serverdensity/sd-agent#58
  • Additionally dpkg_autostart fails to prevent the initial server start due to serverdensity/sd-agent#61

Here's an example of v1 usage:

include_recipe 'serverdensity'

# unless `device` is passed here (see README), the name is used to lookup the node by name,
# for devices created this way, it's more reliable than hostname
serverdensity node.name do
  account 'idio.serverdensity.com'
  username "chef"
  password "this is not a real password at all"
  # dual action, update the device, and clear all alerts (without clear, alerts rapidly start to
  # duplicate as there's no easy way to track them)
  action [:update, :clear]
end

serverdensity_alert 'high-load' do
  # metadata gets sent straight to the API, errors are logged as Chef warnings so as not to
  # interrupt an otherwise successful run
  metadata(
    :userId => ['group'],
    :notificationType => ['email'],
    :checkType => 'loadAvrg',
    :comparison => :>,
    :triggerThreshold => 3
  )
end

and v2:

include_recipe 'serverdensity'

serverdensity node.name do
  account 'idio.serverdensity.io'
  token "000000000000000000000000000000"
  action [:update, :clear]
end

...

Happy to answer any questions you may have, cheers!

@dmytton

This comment has been minimized.

Copy link

dmytton commented Feb 26, 2014

Looks like we can't automatically merge this - possibly due to other similar changes. Can you pull in master to see if that helps?

@mal

This comment has been minimized.

Copy link
Author

mal commented Feb 26, 2014

@dmytton rebased as requested

dmytton pushed a commit that referenced this pull request Mar 10, 2014

@dmytton dmytton merged commit a535186 into serverdensity:master Mar 10, 2014

@dmytton

This comment has been minimized.

Copy link

dmytton commented Mar 10, 2014

This is great - thanks again for contributing!

@mal mal deleted the lwrp branch Mar 11, 2014

@dmytton

This comment has been minimized.

Copy link

dmytton commented Mar 11, 2014

Do you happen to have an example of non-LWRP usage?

@mal

This comment has been minimized.

Copy link
Author

mal commented Mar 11, 2014

The basic usage section of the readme (together with the attribute and recipe sections) sought to cover this, probably not well enough. 😦

I've not tested this specific example, but and it should give you the general idea;

roles/monitored.json

{
  "name": "monitored",
  "description": "Monitored server",
  "override_attributes": {
    "serverdensity": {
      "account": "company.serverdensity.io",
      "token": "00000000000000000000000000000000"
    }
  },
  "run_list": [
    "recipe[serverdensity::alerts]"
  ]
}

I advise against storing your token unencrypted in a role, done here for the sake of simple (single file) example

If you're not using roles, then the attributes can also be overridden in environments and application cookbooks as needed.

Basically set whichever attributes you have (account is required, then you can choose to set either the agent_key, v1 or v2 credentials) by any method, then include the alerts recipe (in a run_list or in another recipe), which will, in addition to installing and configuring the agent, register any alerts stored in the alerts attribute.


EDIT: Just confirmed example works as expected (registers server, installs agent, starts sending data) 😀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.