dougmcclure / ila-open-beta Goto Github PK

Issue:Complexity.
In the repository the file system directory structure is being used to reflect a point in time view of the project. This leads to significant complexity (in code, documentation and understanding) which is a barrier to entry for the project.
eg1. Scenario1 directory.
eg2. CentOS58 directory.
eg3. The blog also refers to using the /Scenario1/box1/Vagrantfile to bring up the standalone box which is confusing when its has nothing to do with Scenario1.

Proposed enhancement.
Remove these directories and refactor repository in an attempt to standardise the associated development workflow.
Create a singular shared directory within the repository and move components into it.
Update the instructions in the README.md to reflect the change in instructions to be the approximate of :

git clone repo onto local machine.
download ILA driver from intenet into /shared on local machine.
cd /box1 && vagrant up. To bring up single box scenario.
cd /box2 && vagrant up. To bring up multi box scenario.

Utilise git tags to reflect point in time features. The blog can then point at the tag to download the repo image that reflects the blog entry. As the blog rolls on, the main branch is updated to reflect the latest, but previous entries each have a tag to reflect the main branch at that point in time allowing the user to implement each experiment historically if desired.

Doug said ..
Can you think of anything we should rename, relocate, etc. I'd like a good naming scheme for the provisioning scripts that shows their function - order - role in a scenario, etc. Same for directories holding stuff unique to one box or scenario.

c835722 said ..
I think the script names should reflect the generalisation of the deployment unit they pertain to rather than the product name. The product names (which keep changing) defeat people trying to understand what the "solution" provides.
So my suggestion would be to refactor the provisioning scripts around how the deployment unit participates.
eg. syslog-server, application-server. These terms the vast majority of the public understand whereas SCAA and ILA not so much.

Further, this is part of ongoing project refactoring to continuously improve the readability and thus simplicity of the project

Identify/Create box
Attempt Install
Identify needed patches, drivers, hacks
Create shell provision script
Document and share, blog about it

For some reason, during the vagrant up process for box1 the final provisioning script (box1_installScenario2.sh) doesn't cleanly end and return back to the Windows command prompt. Everything processes fine and I've had to CNTRL-C out to get back to the prompt. Not sure why this is happening - and only for box1.

Milestone 2 driver was released today. I'll capture my notes here for refreshing Scenario 1 for use with this.

What I know will need changing:

• New silent install script
• New LFA
• Update vagrantfile to point to updated provisioning scripts (or update existing?)
• Update these as needed:
  config.vm.provision :shell, :path => "../shared/download_prereq.sh"
  config.vm.provision :shell, :path => "../shared/grp1-provision-scaa-d1.sh"
  config.vm.provision :shell, :path => "../shared/grp1-provision-scenario.sh"
• Update box2 provisioning scripts to account for new LFA, other?

Please review, test and comment on my first pass at Scenario 1.

Project needs to develop a mechanism that can be run to validate the componentry is working.
This can then be used to ensure changes are not committed to the repository until the test passes.
This ensures the "feature" branch do not break the project before being merged to "develop"

I've put out my first cut at Scenario 1 for use in evaluating Smart Cloud Analytics for Applications (SCAA) (fka IBM Log Analytics).

This will allow for a stand alone CentOS 6.4 box to be spun up and have the OpenBeta driver 1 installed along with the included DayTrader sample scenairo data for WebSphere and DB2 logs.

Additionally, a second CentOS 6.4 box can be spun up and have WebSphere Liberty installed along with a sample Online Polling application. The OpenBeta driver 1 log file adapter (LFA) is installed on this box and configured to send the Online Polling application logs to SCAA on the first box. SCAA is configured to accept these logs automatically and have a number of quick searches set up for easy search across live application logs.

I'm interested in any feedback, especially with getting this up and working. SCAA feedback is appreciated here as well but is most appropriate to be placed in the SCAA OpenBeta forum here.

In some of my testing using a RedHat 6.4 base box I've built, I'm struggling with being able to eliminate a network problem or build problem. I can install nightly builds, ssh into the vagrant box from my host but can't reach the default ILA url/port.

I need to identify if I need to move to a bridged network setup.
I need to know if my setup, boxes I'm using, etc. is correct or if I have a problem with installed build.
I need to know best setup for multiple VM scenario.

I question myself b/c I have this working with milestone driver 1 on the CentOS 5.8 box with only the default vagrant network setup. Why wouldn't this work with newer builds and RedHat 6 base box? My gut tells me it's on my side.

TODO: Figure the best set up for vagrant and networking that will allow me to demonstrate multiple vagrant boxes spun up, communicating, shipping logs to ILA for more realistic blog articles on how to use ILA.

In the root directory there are 3 files with web markup in them.
Consolidate them into a singular set of straightforward instructions that best reflect the project.
Remove the old versions.
Update master branch so github touchdown page reflects these changes.

The Vagrantfile currently points at 9988.
If user follow instructions they will not receive Log Analytics console at 2200.
Suggested fix.

Update Vagrantfile to:
config.vm.network :forwarded_port, guest: 9988, host: 2200

Update Vagrant config line in blog from:
config.vm.network :forwarded_port, guest: 9988, host: 9988
to:
config.vm.network :forwarded_port, guest: 9988, host: 2200