Improve defaults #17
Improve defaults #17
Conversation
|
Did you ever know that you're my hero? Seriously, though, thanks for this. It's been on the list for a while. A couple quick questions but, overall, I love it. |
| default_config :flavor_id, '2' | ||
| default_config :server_name, nil | ||
| default_config :public_key_path, File.expand_path('~/.ssh/id_dsa.pub') | ||
| default_config :flavor_id, 'performance1-1' |
There was a problem hiding this comment.
Have you been using the performance flavors and seen an improvement in TK run times? It's not much for a temporary server, but the smallest performance flavor is 2x the price of the smallest overall.
There was a problem hiding this comment.
The runtime is basically the same, but the new servers boot way faster. My tests usually take around 10m so that's $0.006 per test run with the perf1-1 servers, even if its 2x, the actual monetary difference is pretty small.
There was a problem hiding this comment.
Oh and re: boot time, the new ones are 45-60s instead of ~5m.
|
@coderanger Cool cool. Thanks for the info. |
|
\m/ While I have your attention, I was wondering if they public_key_path stuff is even needed at all. It could just store the root PW in the server state and use that for the connection. |
|
It's not strictly necessary and, thinking about it now, I'm not sure I'm strongly for or against it. I could imagine key-based access being helpful if someone had a cookbook that, to satisfy some security rule, alters a server's root password. Of course, there could also be a cookbook that removes all but a set of specified keys. I'm not sure how likely either of these scenarios is to ever occur. Servers configured to not allow direct root access might be more of a concern; I'd have to play around with TK's sudo options a bit more than I have. I do sort of like the idea of keeping all the cloud drivers roughly similar and/or eventually converging them over time, and other cloud environments do seem to be more key-based than Rackspace's, for whatever that's worth. For example, I'm pretty sure I've seen an OpenStack deployment that never returned a root password at all. Short answer: /shrug. If you'd prefer the keys go away, they probably could with minimal impact on anybody, so just let me know. Have a good holiday if you're celebrating one today, or a rad Wednesday otherwise. |
|
So the reason I ask is that I'm moving my cookbooks into Travis and my options seem to be either check a key pair into git (which renders every box launched effectively public) or regenerate a key every time. |
|
Ah, okay. So, when a build starts in Travis, the VM has no SSH keys? Interesting. What if either (a) the default keys went away and it used only the root pass unless you had a key in your .kitchen.yml, or (b) the default changed to looking for a key to use and, in the absence of one, using the root pass? |
|
That seems like a good mix :-) |
This makes the defaults a bit nicer, including automatic image ID lookup, reading API username/key from standard environment variables, and updating the default flavor ID to the new server types.
I also replaced all uses of
stub()withdouble()to prevent rspec from showing deprecating warnings.