Added agents CloudFormation template.

[sopel]

This is work in progress (i.e. not ready to be merged) - I'll add more details in the next comment.

[sopel]

@fandrei, @mrdavidlaing - As discussed I've tried to work down the Installation instructions. Agent node, here's the current state of affairs and respective questions:

Create a Windows 2008 R2 instance

• Points 1, 2, 5 are implemented as is.
• 4) Assuming this specification isn't strictly tied to the default Administrator account, I've added an administrative MetricsAgent user instead (similar to the TestAgent user facilitated for the VS2012 Load Test Cluster) - hope that's okay?
  • Q: Do you actually need to log into such an agent? I'm currently returning the remote access credentials in the stack output, but that could be removed if not needed.
• 3) Using Elastic IP addresses obviously doesn't go well with EC2 spot instances, which are only available via Auto Scaling, which doesn't provide any means for associating such an address in turn.
  • Q: Do we actually need these or could that requirement be relaxed (but see below)?
  • Assuming Elastic IP addresses are once again imposed by firewall whitelisting requirements, I've currently worked around it as follows:
  • there is a mandatory parameter ElasticIPAddress
  • I've granted the AppMetrics IAM role the AssociateAddress right
    • Beware: This cannot be constrained to specific addresses, thus it is possible to accidentally disassociate one in use elsewhere already!
  • these preconditions enable the instance to associate the specified ElasticIPAddress with its own instance id on boot

Install NTP service:

It turns out that the Meinberg NTP service installer isn't providing a silent install option, triggering the need for a dedicated base image, which would need to be created semi-manually in each region. I'd appreciate if we could discuss the approach again tomorrow before embarking into this tedious venture.

• All NTP configuration steps thereafter (including provisioning a ntp.conffile) can easily be automated.
  • Q: Presumably the NTP monitor steps aren't needed anymore, if we manage to ensure via automation that the NTP service is running? Or do you in fact need to log in and use the monitor UI once in a while?

Install the AppMetrics.Agent service

I've prepared the installation/configuration, i.e. all fragments but the agent configuration command are already included and just need to be adjusted here and there (e.g. I've used the PowerShell Community Extensions as a sample MSI).

• Big cheers to @fandrei for using Windows Installer btw., this makes things significantly more compliant and respectively easier to automate (see above for one typical downside of skipping this)!
• Q: One change request is that I'd need the MSI unzipped ideally (Windows Installer packages are compressed anyway, so doing it explicitly is actually not required) - could that be adjusted?
• Q: Finally it would obviously be ideal to test this with an actual metrics server - is there currently a staging server available (we can discuss this tomorrow and/or in the flow)?

[sopel]

The aforementioned issues have been discussed in a chat session, here are the relevant results:

Create a Windows 2008 R2 instance

Ad 4) Can stay as is for the time being.

Ad 3) Using an Elastic IP Addresses (EIP) per agent is indeed required and it must be possible to specify them per region accordingly. While CloudFormation offers Mappings for such tasks, these cannot be configured at runtime via Parameters, thus requiring either hard coding respective EIPs in a project specific template or submitting a custom mapping as a list parameter. Given the association must be handled via on instance scripting anyway, the latter seems to be easy enough to implement in order to gain the implied flexibility.

Install NTP service

The assessment of the Meinberg NTP service installer silent install options has been incorrect, insofar a silent installation can indeed be achieved via an INI file approach as facilitated in a respectively complete Chef windows_ntpd cookbook provided by @mrdavidlaing (see recipes/default.rb for details) - this readily available solution is gong to be used here as well accordingly:

A proposal. We keep Load Test cluster component installatino / config manipulation portion in Powershell (since we already have it). For the Metrics collection cluster we use existing Chef recipies. We then compare, and decide which is better under which circumstances for future automation work.

And optionally:

There is also a ciapilatencycollector cookbook. However, its probably only worth using if you find yourself having to create a custom config file from a template - https://github.com/cityindex/cookbooks/blob/master/cookbooks/windows_ciapilatencycollector/recipes/default.rb

Install the AppMetrics.Agent service

A: @fandrei has enabled access to the unzipped MSI as follows:

regarding agent app setup. you can download it directly
http://newconfig.metrics.labs.cityindex.com/setup/AppMetrics.AgentService.msi.zip
or
http://newconfig.metrics.labs.cityindex.com/setup/AppMetrics.AgentService.msi

A: A staging server isn't currently available.

[fandrei]

I've missed point about the staging server. What it's needed for?

[sopel]

Well, just the usually desired test option, i.e. it would be easier for me to test the end to end automation if I could specify a running metrics server for the agents to register with and download the registration from. So strictly speaking I don't need a staging server, but simply any kind of non production metrics server accessible from the agents started via CloudFormation - I had just assumed a staging server might be available anyway somehow ;)

But thanks to your resilient implementation I should be able to dry run the configuration as well, I'm indeed implementing/testing this part currently.

[mrdavidlaing]

@sopel - From an AWS resources perspective, there is no reason not to start a new Appmetrics cluster (or several) for you to test on. However, we do want to keep metrics.labs.cityindex.com running and pointed to the PPE environment, since this data is used to help monitor PPE

On 5 February 2013 13:42, Steffen Opel notifications@github.com wrote:

Well, just the usually desired test option, i.e. it would be easier for me to test the end to end automation if I could specify a running metrics server for the agents to register with and download the registration from. So strictly speaking I don't need a staging server, but simply any kind of non production metrics server accessible from the agents started via CloudFormation - I had just assumed a staging server might be available anyway somehow ;)

But thanks to your resilient implementation I should be able to dry run the configuration as well, I'm indeed implementing/testing this part currently.

— Reply to this email directly or view it on GitHubhttps://github.com/fandrei/AppMetrics/pull/132#issuecomment-13129539.

David Laing Open source @ City Index - github.com/cityindex http://davidlaing.com Twitter: @davidlaing

[fandrei]

Actually we have a staging server, it's used in build-and-test scripts. Or you can use preprod server, if you only need to check if clients can register and download plugins correctly. Or you can deploy your own instance from msdeploy package.

[sopel]

:information_source: this PR has bee superseded by a different approach, namely deploying the agents as Cloud Foundry apps.