stelligent / canaryboard Goto Github PK

Hey there--

I'm trying to set up CanaryBoard against a PostgreSQL DB to circumvent some issues with OpsWorks (it doesn't get along particularly well with sqlite). Not sure if this is entirely supported, but I got most of the way there before I hit this issue and was wondering if there was a simple fix or if I'm just wasting my time.

The issue is when we try to use the API we get 500 errors that look like this:

PG::UndefinedColumn: ERROR:  column projects.project_id does not exist
LINE 1: SELECT "projects".* FROM "projects"  WHERE "projects"."proje...
                                                   ^
: SELECT "projects".* FROM "projects"  WHERE "projects"."project_id" IN (1)

I captured the SQL queries going into psql, and this is what we see:

2014-04-04 19:09:39 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG:  statement: SELECT "services".* FROM "services" 
2014-04-04 19:09:39 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG:  statement: COMMIT
2014-04-04 19:09:39 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG:  statement: SELECT 1
2014-04-04 19:09:39 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG:  statement: SELECT  "users".* FROM "users"  WHERE "users"."api_key" = '1cc9dc6cc92a4831ccf4bafc8705a580' LIMIT 1
2014-04-04 19:09:39 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG:  statement: SELECT "projects"."id" FROM "projects" 
2014-04-04 19:09:39 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG:  statement: SELECT "projects".* FROM "projects"  WHERE "projects"."project_id" IN (1)
2014-04-04 19:09:39 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:ERROR:  column projects.project_id does not exist at character 44
2014-04-04 19:09:39 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:STATEMENT:  SELECT "projects".* FROM "projects"  WHERE "projects"."project_id" IN (1)
....
2014-04-04 19:17:57 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG: statement: SELECT 1
2014-04-04 19:17:57 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG: statement: SELECT "users".* FROM "users" WHERE "users"."api_key" = '1cc9dc6cc92a4831ccf4bafc8705a580' LIMIT 1
2014-04-04 19:17:57 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG: statement: SELECT "projects"."id" FROM "projects" 
2014-04-04 19:17:57 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:LOG: statement: SELECT "projects".* FROM "projects" WHERE "projects"."project_id" IN (1)
2014-04-04 19:17:57 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:ERROR: column projects.project_id does not exist at character 44
2014-04-04 19:17:57 UTC:ip-10-245-141-58.us-west-2.compute.internal(59120):canaryboard@canaryboard:[13223]:STATEMENT: SELECT "projects".* FROM "projects" WHERE "projects"."project_id" IN (1)

So I went into the DB and looked around the projects table:

canaryboard=> select * from projects;
-[ RECORD 1 ]----------------------------
id          | 1
name        | ASG are properly configured
created_at  | 2014-04-04 19:09:39.614168
updated_at  | 2014-04-04 19:09:39.614168
description | 

So the first project got in, but then when it tried to query it, it failed. I think the issue is the name of the ID field. In the output of the select * query, it shows the projects table ID field just being named "id". But in all the queries being issued by the app, it's looking for "project_id" which doesn't exist.

Here's how I set up my database.yml:

development:
  adapter: "postgresql"
  database: "canaryboard"
  encoding: "utf8"
  host: "jd7iccqomwvx0f.cwxmz3ebuvta.us-west-2.rds.amazonaws.com"
  username: "canaryboard"
  password: "password"
  reconnect: true
  port: 5432

production:
  adapter: "postgresql"
  database: "canaryboard"
  encoding: "utf8"
  host: "jd7iccqomwvx0f.cwxmz3ebuvta.us-west-2.rds.amazonaws.com"
  username: "canaryboard"
  password: "password"
  reconnect: true
  port: 5432

So, questions I have:

• Is there anything that would prevent CanaryBoard from working with postgresql?
• Am I doing anything stupid when configuring this?
• If neither of those, any ideas why it's messing up the column name?

Thanks!

.j.

From Brian/Jonny 20140325 7:34 pm:
We're experiencing an error when doing a migration in AWS opsworks. Is this file correct? Shouldn't the API key be added to the users table instead of the user_id being added to an api_keys table (which doesn't seem to exist when I login to the database). Here's the file in question:

and here's the error we're getting:
root@rails-app1:/srv/www/canaryboard/current# rake db:migrate
== AddUserIdToApiKeys: migrating =============================================
-- add_column(:api_keys, :user_id, :integer)
rake aborted!
An error has occurred, this and all later migrations canceled:
SQLite3::SQLException: no such table: api_keys: ALTER TABLE "api_keys" ADD "user_id" integer
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
root@rails-app1:/srv/www/canaryboard/current# 

From Paul 20140325 9:30 pm (this can be ignored):
All we need is master, if that's what you're asking. We've been deploying on AWS from day one.

From Alex 20140326 7:55 am:
This migration from a year ago can be deleted altogether. It is related to the ApiKey model which was removed long ago in favor of going with more general User model instead. Was this app already deployed on AWS by the time the migration appeared in the codebase (May 7, 2013)?

From Alex 20140326 7:55 am:
If this migration is affecting your deployment in this way, you can delete it from master altogether. Migrations are not supposed to be run on fresh installs anyway.

My initial request stated: "Provide capability of Admin to show certain columns (currently called "projects”) to one or more organizations. All columns/rows are hidden to non-Admin users by default."
Alex - In the new implementation, how do we show columns/rows to a certain user?

Approximately, when do you expect the DynamoDB implementation to be completed?

Hey guys,

I followed the instructions here and set up CanaryBoard, however neither the set-indicators.rb nor update-indicators.rb scripts will work. I get the following error:

/usr/lib/ruby/1.9.1/json/common.rb:148:in `parse': 746: unexpected token at 'HTTP Token: Access denied. (JSON::ParserError)
'
    from /usr/lib/ruby/1.9.1/json/common.rb:148:in `parse'
    from update-indicator.rb:13:in `get'
    from update-indicator.rb:28:in `<main>'

I also see this access denied if I go to localhost:3000/api

Has anyone else encountered this issue? Thank you! (I get the impression that I missed something trivial but I went over the documentation several times to make sure)

Right now the sample gists referenced in the readme are linked to Paul's account. We should move those into the repo itself so that we don't have to bother Paul to change them, and you can view them without having to go to the website after you've already cloned the repo.

Several changes/additions I'd like to see for CanaryBoard:

• Require all users to login to see CanaryBoard status
• Admin should have capability to create Organizations
• Admin should be able to create other users and assign them to Organizations. Organization should be a required field.
• Provide capability of Admin to show certain columns (currently called "projects”) to one or more organizations. All columns/rows are hidden to non-Admin users by default.
• Non-administrators should not be able to see or modify other users’ profiles
• Change “projects” to “columns” (in API and elsewhere)
• Change “services” to “rows” (in API and elsewhere)
• Provide context menu to link to Event History and Problem Source URL (e.g. URL to Jenkins Pipeline error). By default (when clicking on the indicator) it continues to go to the Problem Source URL
• Provide a way to show the particular Github commit hash associated with a particular build on the front page of CanaryBoard (small letters)
• Convert datasource (i.e. SQLite) to DynamoDB
• When scrolling to the bottom, the hover status is truncated. See the screenshot attachment.