Namespacing Rudy in shared accounts

[Fluxx]

I was wondering if it was possible to add some kind of namespacing functionality to rudy? We have multiple separate projects that all use the same AWS account, and we'd like to use Rudy to manage each one independently without too much hassle.

Currently, the pain points for this are only in a couple places:

1. Rudy hard codes a SDB domain of rudy_state. Therefore, multiple applications using rudy on the same AWS account can see each others machines.
2. A few of our projects have the same named role - i.e. two projects have a redis role. If both projects are in the same AZ and use the same role, their security group names clash.

I'm happy to code the fixes to these, but I wanted to get some feedback and guidance on it first:

1. It looks like Rudy::DOMAIN is baked in pretty close. Rudy::Huxtable looks to be the only place in practice where it's actually used , thoughRudy::Metadata sets a @@domain class variable for itself from Rudy::DOMAIN to be used in some of the metadata domain CRUD methods, but I didn't see where those CRUD methods were used other than in tests.
2. Security group names seem to be based on the Rudy::Huxtable#current_machine_group It looks like a simple change to these methods is all it would take to fix the security group issue.

I think you might be able to kill two birds with one stone by adding an app_name global. This could be used as a prefix to the SDB domain (app_name_rudy_state) and as part of the security group grp-us-west-1b-app_name-staging-app.

Thoughts?

[delano]

Ya this makes total sense. Originally I'd expected people would use different accounts for each project but it's not always like that in practice. It's also confusing when you're managing multiple projects to have several machines called m-us-east-1b-prod-fe-01.

A few things:

• Instead of app_name, call it something like project to account for infrastructures that aren't app related.
• To make it backwards compatible with existing environments, if a value isn't set to the new global, it should not appear in the machine name or SDB domain.
• It should be possible to set the value in the defaults and on the command-line, but not in the machines config (it could confusing in there).

Everything inherits from Huxtable so most of the changes will be in there. If you need anything let me know.

[Fluxx]

Thanks for the feedback. I'll start working on a patch for this today.

Instead of app_name, call it something like project to account for infrastructures that aren't app related.

Oh, I like project much better! I'll use that. :)

To make it backwards compatible with existing environments, if a value isn't set to the new global, it should not appear in the machine name or SDB domain. It should be possible to set the value in the defaults and on the command-line, but not in the machines config (it could confusing in there).

Yeah that all makes sense, and had the same ideas.

Everything inherits from Huxtable so most of the changes will be in there. If you need anything let me know.

This is where I'm still a little fuzzy on how state is kept inside Rudy.

So any class that includes Huxtable gets access to @@config and @@global class variables. And it appears that those variables (re)load their configuration via the Huxtable.update_config method, which looks to be called in CLI::Base. Is that the only real place where configuration is setup and then loaded? And then all other classes that are used have to include Huxtable and then reference @@config and @@global in their class bodies?

What exactly is the distinction between @@config and @@global? Is config meant to represent config items coming from your Rudyfile and then @@global comes from the command line? If that's true, where does @@global options override the options from @@config?

As far as adding a command line global option, do you just need to add a field to Global and then the global to bin/rudy?

[delano]

It looks like you've figured this out for the most part from the other pull request so I'm going to close this issue.

And ya, @@config represents the items coming from Rudyfile and @@global is the command line options. I kept them separate b/c there are some non-obvious challenges in merging. (Although the end result is somewhat opaque -- definitely something I want to improve.)