Hi Karl,
1. Those servers won't be able to re-register with Scalr. This is something we plan to change later this year, but we aren't there yet. In the meantime, we recommend setting up replication in addition to snapshots (this will be possibe using the installer in 5.3, which we expect to release shortly, though until then you can of course do it manually).
2. You'd need to change the user data for those instances. This is obviously an intrusive process, so we very strongly recommend you use a domain name instead of an IP for the Scalr endpoint.
Cheers,
--
You received this message because you are subscribed to the Google Groups "scalr-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalr-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
What, specifically, needs to be replicated? I'm not intimately familiar with the Scalr internals, I only know of the the "big pieces". Can you point me to a "high availability best practices" document or list of things to do?
Is there any documentation on where that scalr-agent userdata lives? I ask mostly to satisfy my own curiosity as well see how invasive the changes are. I 100% understand that i'd be messing around with things i shouldn't and that you wont be able to help if i come back asking for help w/ those instances.
Additionally, I have one other question:I know that scalr uses chef solo/zero to install it's self. Is there any official support or documentation for using a chef run that i control to deploy the server? Basically, we'd like our entire infrastructure - including the core parts like Scalr to come up. Is using Chef to manage the scalr config.yaml recommended or supported at all?