flapjack / flapjack-diner Goto Github PK

According to the docs, Flapjack::Diner.entities should return an array, but instead it returns a hash. So rather than Flapjack::Diner.entities.each I have to do Flapjack::Diner.entities['entities'].each.

Perhaps this is a bug with flapjack rather than flapjack-diner, but I'll just file it here and let you decide :)

The way the old API operated was useful in scenarios when performing a "sync" operation from another system, such as a CMDB. For example, we have all our contacts, media and notification rules defined in our CMDB, and run a build sync job to create/update/delete those in flapjack.

With the new JSON API, and the corresponding flapjack-diner library, we're no longer able to perform this same type of "sync" operation. We'll need to write code to pull all the existing contacts, media, and rules and make decisions for each as whether we should create, update or delete the contact, media and rules.

This initially sounds like a reasonable amount of work, so I figured I'd get something filed. @jessereynolds mentioned he was working on some code to do this, and I'm looking at doing the same. Preferably, it would be great to have this part of the flapjack-diner package so it can be easily reused/collaborated on.

Only the query string should use + (or %20), the paths must use %20, per http://en.wikipedia.org/wiki/URL_encoding (and see the linked RFCs for more details).

If you get an entity, its links[:checks] array will contain all check ids for that entity

This currently doesn't happen:

pry(main)> entity = Flapjack::Diner.entities_matching(/^foo}/)
=> [{:id=>"123",
:name=>"foo.bar",
:links=>{:contacts=>["142", "182", "352", "852", "46", "40", "4"]}}]

currently we require keys to be symbols for eg create_contacts (at least for the :id key) but when retrieving data the keys returned are strings

lets symbolize all top level keys in returned hashes (and think about deeper level key symbolization)

I tried to update a contact's timezone; however it doesn't work:

irb(main):002:0> Flapjack::Diner.contacts("1398")
=> [{:id=>"1398", :first_name=>"J", :last_name=>"S (BP)", :email=>"[email protected]", :timezone=>"UTC", :links=>{...}}]

irb(main):003:0> Flapjack::Diner.update_contacts("1398", :timezone => "Asia/Bangkok")
=> true

irb(main):004:0> Flapjack::Diner.contacts("1398")
=> [{:id=>"1398", :first_name=>"J", :last_name=>"S (BP)", :email=>"[email protected]", :timezone=>"UTC", :links=>{...}}]

Tried this on both our integration and production instances. Also exit and signin to the console again in case it does caching.

https://github.com/bbatsov/rubocop

We'll probably choose to disable a few cops and configure some others differently to the defaults. If this is easy to do, a larger effort against Flapjack proper might be worthwhile.

Ruby 1.9, see #43 (comment).

Right now, Diner returns 'true' if a request was sent successfully, and 'false' if it failed. Shouldn't it return any data that was sent to it from Flapjack instead?

For example, when I create a new Contact, I would expect to get its unique ID back in response so I can begin tying that contact to rules or entities. The JSON API does actually return this data, and Diner writes it to the API log - but there's no easy way to retrieve it in your code without performing a separate GET action, filtering it, and hoping that there are no duplicated names in your Flapjack setup.

Is there a reason that the simple 'true' and 'false' behavior was chosen over this? Should it be changed?

HTTParty provides a timeout method which sets the connection and read timeout(s). We need to expose this in a method on diner eg

# set http timeout to 5 minutes
Flapjack::Diner.timeout = 300

Refer: flapjack/flapjack#270

Having a cli included with flapjack-diner would be pretty nice. Initially just supporting enabling/disabling maintenance mode would be great to have the framework in place and allow others to add to it as the need arises.

We have been using jwoods flapjack-client which wraps flapjack-diner for this until now. The flapjack-client will need some work to be compatible with the new flapjack-diner and I thought the time may be better spent getting a cli closer to the source to ensure future compatibility.

In our application deploy process we make extensive use of setting/ending maintenance modes from the client. For each potentially affected service the clients check if that service is in a maint mode and then schedules a new one before doing the deploy and at the end of the deploy the maint mode is cleared if the status check are currently OK.

Additionally we have scripts that self check that status of specific checks and then do one thing or another depending on if it's OK or CRITICAL.

Now Flapjack is at 1.2 and there's been 52 commits to diner since the last release (1.0.0), time for a new diner release? '1.2.0' ?

I'm trying to use flapjack-diner to create PagerDuty credentials, but it's failing to submit the request whenever I don't pass a username, password, or subdomain.

None of these is actually required for PagerDuty access - I tested by submitting only a service key to Flapjack using a curl call, and it was able to push alerts.

Flapjack::Diner.create_test_notifications_checks(CHECK_ID(S), [TEST_NOTIFICATION, ...])

Is this supposed to be:

Flapjack::Diner.create_test_notifications_checks('foo:http', 'bar:http', [TEST_NOTIFICATION, ...])

or

Flapjack::Diner.create_test_notifications_checks( { 'foo:http', 'bar:http' } , [TEST_NOTIFICATION, ...])

or something else entirely?

The README should be updated to clarify this.

Once Flapjack's JSONAPI gateway is a little further along, enhance flapjack-diner to support that alongside its current API gateway support.

Once this PR is merged - flapjack/flapjack#828 - we'll need to add the endpoints to diner.

Hi, let me know if I should split these into separate issues.

Flapjack::Diner.create_contacts([{
  :id         => '123',
  :first_name => 'john',
  :last_name  => 'smith',
  :email      => '[email protected]',
  :timezone   => 'UTC',
  :tags       => ['foo', 'bar', 'baz'],
  :media => {
    :email => {
      :address => '[email protected]', 
      :interval => '60',
      :rollup_threshold => '120'
    }
  }
}])

1. If I create a new contact with Diner with the above code, it will actually create both the contact and the email address medium for it. This is very useful, but I had to discover it myself as README.md doesn't even say that ":media" can be set.
2. Several update methods reference ":add_tag" and ":remove_tag" in README.md. So far at least, they don't appear to exist for any of the resource types. Are these just going to be added later?
3. The header for "create_contact_pagerduty_credentials"'s section says "create_contact_media", and the header for "delete_notification_rules" says "delete_contacts."

When I try and go to any page other than the first page on checks, I get the following error. Here is an example url that I would go to. http://flapjack:3080/checks?page=2

2016-09-28 14:10:16 - ArgumentError - '2' must be an Integer greater than 0.:
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-diner-2.0.0b1/lib/flapjack-diner/argument_validator.rb:22:in 'validate'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-diner-2.0.0b1/lib/flapjack-diner/request.rb:22:in 'block (2 levels) in initialize'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-diner-2.0.0b1/lib/flapjack-diner/request.rb:22:in 'each_pair'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-diner-2.0.0b1/lib/flapjack-diner/request.rb:22:in 'block in initialize'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-diner-2.0.0b1/lib/flapjack-diner/query.rb:16:in 'instance_eval'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-diner-2.0.0b1/lib/flapjack-diner/query.rb:16:in 'validate_params'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-diner-2.0.0b1/lib/flapjack-diner/request.rb:21:in 'initialize'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-diner-2.0.0b1/lib/flapjack-diner/resources.rb:27:in 'new'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-diner-2.0.0b1/lib/flapjack-diner/resources.rb:27:in 'block (3 levels) in included'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-2.0.0/lib/flapjack/gateways/web.rb:251:in 'block in class:Web'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1611:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1611:in 'block in compile!'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:975:in '[]'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:975:in 'block (3 levels) in route!'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:994:in 'route_eval'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:975:in 'block (2 levels) in route!'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1015:in 'block in process_route'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1013:in 'catch'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1013:in 'process_route'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:973:in 'block in route!'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:972:in 'each'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:972:in 'route!'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1085:in 'block in dispatch!'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 'block in invoke'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 'catch'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 'invoke'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1082:in 'dispatch!'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:907:in 'block in call!'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 'block in invoke'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 'catch'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in 'invoke'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:907:in 'call!'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:895:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:225:in 'context'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:220:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-1.6.4/lib/rack/commonlogger.rb:33:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:219:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-1.6.4/lib/rack/methodoverride.rb:22:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/flapjack-2.0.0/lib/flapjack/gateways/web/middleware/request_timestamp.rb:12:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:225:in 'context'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:220:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-1.6.4/lib/rack/nulllogger.rb:9:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/rack-1.6.4/lib/rack/head.rb:13:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:182:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:2013:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1487:in 'block in call'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1787:in 'synchronize'
/usr/local/rvm/gems/ruby-2.2.2/gems/sinatra-1.4.7/lib/sinatra/base.rb:1487:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/puma-3.6.0/lib/puma/server.rb:578:in 'handle_request'
/usr/local/rvm/gems/ruby-2.2.2/gems/puma-3.6.0/lib/puma/server.rb:415:in 'process_client'
/usr/local/rvm/gems/ruby-2.2.2/gems/puma-3.6.0/lib/puma/server.rb:275:in 'block in run'
/usr/local/rvm/gems/ruby-2.2.2/gems/puma-3.6.0/lib/puma/thread_pool.rb:116:in 'call'
/usr/local/rvm/gems/ruby-2.2.2/gems/puma-3.6.0/lib/puma/thread_pool.rb:116:in 'block in spawn_thread'

Running version 2.0 of Flapjack.

https://github.com/flpjck/flapjack-diner#notification_rule

This method is supposed to take 2 arguments according to the documentation. I've just tried it in the console while debugging and it takes just the id.

The published gem on Rubygems is 1.3.0 from March 19th, which doesn't have important patches added since then, namely d691742.. Can you please bump patch and push a new release?

Just going through some of the commands in the README:

pry(main)> Flapjack::Diner.downtime_report_entities
TypeError: no implicit conversion of String into Integer
from /Users/sarah/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/bundler/gems/flapjack-diner-0c144b4f97db/lib/flapjack-diner.rb:391:in `[]'

Input from our app into FlapjackDiner#update_notification_rules

id: "3eb72c3a-76d7-412a-ad0e-29e9a90d2c70"

attributes:

{"tags"=>nil,
 "regex_tags"=>nil,
 "entities"=>["some-entity-id"],
 "regex_entities"=>nil,
 "time_restrictions"=>
  [{"end_time"=>"2014-10-28 00:00:00",
    "rrules"=>[{"validations"=>{"day"=>[1, 2, 5, 6, 0]}, "rule_type"=>"Weekly", "interval"=>1, "week_start"=>0}],
    "exrules"=>[],
    "rtimes"=>[],
    "extimes"=>[],
    "summary"=>"Weekly on Sundays, Mondays, Tuesdays, Fridays, and Saturdays",
    "start_time"=>"2014-10-27 00:00:00"}],
 "unknown_media"=>nil,
 "warning_media"=>["email", "sms"],
 "critical_media"=>["email"],
 "unknown_blackhole"=>false,
 "warning_blackhole"=>false,
 "critical_blackhole"=>false,
 "links"=>{"contacts"=>[""]},
 "entity_tags"=>[]}

Flapjack Diner log

PATCH http://flapjack-server-example.org/notification_rules/3eb72c3a-76d7-412a-ad0e-29e9a90d2c70

[
    {
        : op=>"replace",
        : path=>"/notification_rules/0/tags",
        : value=>nil
    },
    {
        : op=>"replace",
        : path=>"/notification_rules/0/regex_tags",
        : value=>nil
    },
    {
        : op=>"replace",
        : path=>"/notification_rules/0/entities",
        : value=>[
            "some-entity-id"
        ]
    },
    {
        : op=>"replace",
        : path=>"/notification_rules/0/regex_entities",
        : value=>nil
    },
    {
        : op=>"replace",
        : path=>"/notification_rules/0/unknown_media",
        : value=>nil
    },
    {
        : op=>"replace",
        : path=>"/notification_rules/0/warning_media",
        : value=>[
            "email",
            "sms"
        ]
    },
    {
        : op=>"replace",
        : path=>"/notification_rules/0/critical_media",
        : value=>[
            "email"
        ]
    },
    {
        : op=>"replace",
        : path=>"/notification_rules/0/unknown_blackhole",
        : value=>false
    },
    {
        : op=>"replace",
        : path=>"/notification_rules/0/warning_blackhole",
        : value=>false
    },
    {
        : op=>"replace",
        : path=>"/notification_rules/0/critical_blackhole",
        : value=>false
    }
]

It looks like that time_restrictions is skipped in FlapjackDiner

README.md lists a checks method that will return all checks, or a specific set if IDs are passed to it as arguments. I've tried running it both ways, and all that gets returned is a blank line.

The Flapjack JSON API docs don't list an endpoint for GETting checks - is this another leftover from before the JSON API was added?

What do you think about a syntax like this?

def unscheduled_maintenances(entity, options = {})
  path_options = {:entity => entity, :check => options.delete(:check)}

  perform_get_request('unscheduled_maintenances', path_options, options) do
    validate :path  => :entity, :as => :required
    validate :query => [:start_time, :end_time], :as => [:time, :required]
  end
end

This is only a cosmetic change, and therefore maybe not that important. However, I think it is much more obvious to the developer, what the expected functionality is.