@prabacha / @vsr,

Thanks for your updates to the xCat, and your work to make it a solid experience for the xCat users.

I noticed there were two branches in this bug. Specifically:
lp:~ibmcharmers/charms/trusty/xcat/trunk
and
lp:~ibmcharmers/charms/trusty/xcat/devel

The changelog indicated they were both at the same latest revision (37), but to confirm I ran a diff aginst the branches and they look to be the same, thus I'll be taking a look at the trunk branch.


# Deploying the charm
- A big plus to using workload status, and being descriptive on what action I needed to take. I did a deploy on my local provider with defaults and found the following in my juju status:

[Units] 
ID      WORKLOAD-STATE AGENT-STATE VERSION  MACHINE PORTS PUBLIC-ADDRESS MESSAGE                          
xcat/0  blocked        idle        1.25.0.1 1             10.0.3.153     Please set the XCAT_DOMAIN name. 

I consulted the readme, and did a `juju set xcat XCAT_DOMAIN="my-cluster-name"` and juju status showed me the config-changed hook was firing (as per previous comments) and the installation continued. Nice work here.

- I deployed the charm on local and amazon, after setting the xcat domain I was able to see xCat being "up" in juju status. The instructions indicated to do a juju expose but I am not sure what that accomplishes with out a web UI, and the next instructions have me ssh'ing into the unit. Suggest to add some info in the readme following the expose instructions to let the user know what exposing the service does, and what if any security implications should be considered.

- While juju status showed the service being up when I ssh'ed into the service I was not able to verify the install per the quick-start guide (http://sourceforge.net/p/xcat/wiki/Ubuntu_Quick_Start/#verify-xcat-installation). I got errors asking if the xcat daemon was no up (on both aws and local):
http://paste.ubuntu.com/13137921/

- Looking at the charm tests I see that the xCAT service is not tested as per the xCat Quick-start guide (http://sourceforge.net/p/xcat/wiki/Ubuntu_Quick_Start/#verify-xcat-installation). Suggest to add into the tests to verify xCat is indeed working. This will help give you and the user confidence the service is properly running, and configured correctly.

# Knitpics (nice to have, but won't block promotion to recommended status)

- In the readme it states:
"If XCAT_DOMAIN is not altered by the user, the charm will create a container based on the default domain name of
the system if it exists. If not, the user will have to set the XCAT_DOMAIN name. It is recommended to use default value for         XCAT_REPO="sourceforge.net"."
Suggest to put a code example on how to correct this such as:
    juju set xcat XCAT_DOMAIN="my-cluster-name"

- the the readme under Known Limitations it states:
"When this charm attempts to deploy, and there is no host or domain entry configuration in /etc/hosts, then this charm will halt and log this failure in the juju debug-log.  An override variable for the domain is provided in the install script."
What is the purpose of stating there is an override variable? Is the user meant to take action on it? If it is just used to set the domain value when specified with config suggest to just remove this last line or elaborate on how the user would use the config values in the charm.

- In the Installation section where the override.yaml example is given suggest to give an example yaml such as:
    xcat:
      XCAT_DOMAIN: test-cluster

 - I was kind of lost as to what actions I could do next with the charm and xCat. Reading through the xCat quick start guide I found there was lots more config still left to do. Specifically around, network tables, passwd table, dhcp, and nodes. Also some further investigation into juju add-unit and xCat Deploying Nodes may be very interesting. Juju actions may also be very useful in helping execute xCat jobs.  Keep in mind that is ok to be opinionated as a charm author in writing a charm. The main intent is to write a charm the gets the user, as fast as possible, to using the service.  In this case while the charm does the apt-get install, but leaves a lot of config to be accomplished by the user.  Do you know of any xCat users we could beta test this with?

# Conclusion

Unfortunately I can not give a +1 as I could not verify the xCat service was up and running. Please let me know if I missed a step in verifying, and if I did perhaps we could add this to the charm. Also,please  add charm tests to verify the service is indeed working. Lastly, please consider some of the knitpicks and ping us in #juju on freenode or on the juju mailing list if you would like to brainstorm on how to further build out this charm. 

I want to thank you again for your work on this charm, and your contributions to the Juju community. I am going to put this bug into "In Progress" when you have addressed the above comments please put the bug status back into "Fix Committed"

-thanks,
Antonio