Imported Google Group message. Original thread at: https://groups.google.com/forum/#!topic/tyk-community-support/-Gwvf7af2f0 Import Date: 2016-01-19 21:10:56 +0000.
Sender:Thorsten Zenker.
Date:Monday, 4 May 2015 08:41:46 UTC+1.
Hey Martin,
looking for a way to add tyk dashboard to a running tyk gateway setup.
Have:
- tyk running with two api definitions, same org_id
- tyk is setup to use analytics …
“enable_analytics”:true,
“analytics_config”: {
“type”: “mongo”,
“csv_dir”: “/tmp”,
“mongo_url”: “mongodb://localhost/tyk_analytics”,
“mongo_db_name”: “tyk_analytics”,
“mongo_collection”: “tyk_analytics”,
“purge_delay”: 10
}, …
- api access data is in tyk_analytics.tyk_analytics
Did this (likely this was wrong…):
- ./tyk-analytics --neworg --newuser
Result:
no api data is shown in dashboard
Questions:
What is the best way to move from tyk gateway with existing api definitions to dashboard support?
Thorsten
Imported Google Group message.
Sender:Martin Buhr.
Date:Monday, 4 May 2015 10:09:18 UTC+1.
Hi Thorsten,
It really depends on what features you want to use with Tyk Dashboard.
To see analytics and all keys:
Run ./tyk-analytics --newuser and when you are asked to select an organisation select None, this creates a super user (not tied to an org).
If you log in as this user you will be able to see all the old data and keys.
To have everything managed by Tyk Dashboard (including key creation), that’s when it gets a bit tricky - super user can create them but they no longer belong to a specific organisation and since the definitions are text files they are also not managed, these would need importing first.
What do your OrgIDs look like?
To move to a fully managed solution, you might need to re-issue access tokens and retire old ones.
It’s quite easy to import API definitions (you can literally cut and paste them into an importer), but recreating organisation ids is tricker because in the dashboard they are ObjectIDs and created dynamically.
So to get limited functionality, it’s quite a quick process.
To go all-in, there may be teething pains :-/
It’s not something we’ve thought about to be honest, so we might need to look at scripting a solution.
I hope that helps you (somewhat)
Thanks,
Martin
Imported Google Group message.
Sender:Martin Buhr.
Date:Monday, 4 May 2015 10:29:04 UTC+1.
Hi Thorsten,
Thinking about it some more, I think you could move across quite easily, but you would eventually need to retire old keys and create new ones so everything is fully managed.
Also, you would not be able to access old analytics data after you do the transition (only the super user would).
Here’s how:
- Create your new orgs and new users (only if you need APIs to belong to a different organisation)
- For each org you have, log in as that user and import the API definition as a new API, make sure you leave the api_id field as is because it means it will be retained into the DB based version and tyk dashboard will be able to match access rules.
- Switch your Tyk configuration over to use the DB as its source instead of the file-based definition
- Make sure hash_keys is off, it is on by default in the new versions, this can break things for old installs
- Make sure that hash_keys is the same value in your Tyk_analytics.conf (it behaves differently if they are hashed)
- Check that the listen_path is set correctly for the APIs (they should be retained)
- Restart your Tyk nodes
Tyk should now route traffic properly for your old APIs using the new dashboard managed definitions and still respect your old keys, however you can now create new ones (they will be different - longer most likely) and those new keys will generate analytics data keyed to those Orgs you’ve added).
You will still be able to see the old data and the data being generated by the old keys through your super user.
Once the new keys are in place everything should be ok and you are ready to go 
Thanks,
Martin