Allow custom command role ACL files on classpath in Static Role API Checker

[ProjectMoon]

Commit Message

This commit has a small refactoring of cloud-plugin-acl-static-role-based
to allow it to read files on the classpath that might have a different name
than "commands.properties". It also allows more than one file to be read from.

Rationale: Third-party plugins may want to keep their API command access level
configuration separate from the main file so as to reduce configuration
maintenance work during packaging and deployments.

Testing Performed

Ran the simulator locally and connected to it with Cloudmonkey. Ran sync and then executed some API commands to verify that they are not blacklisted (i.e. not found because CS could not read the file on the classpath).

[asfbot]

cloudstack-pull-requests #301 FAILURE
Looks like there's a problem with this pull request

[ProjectMoon]

Looks like the Oracle VM3 build failed in the pul request check. Is that a problem on the master branch currently?

[rohityadavcloud]

LGTM, though we need to test it by producing packages. In theory, the /etc/cloudstack/management should be on classpath so this should work.

[ProjectMoon]

Is there anything I can do to assist with the testing?

[rohityadavcloud]

@ProjectMoon can you share any test results? Is the spring xml gets into the compiled jar from users' perspective, how may I configure a different properties file, any docs in this regard?

[ProjectMoon]

This would be a step-by-step way of how I tested the change. We will use mycommands.properties as the example.

1. Add the new properties file name to the list in the Spring XML and then compile CloudStack.
2. Create mycommands.properties.in in client/tomcatconf. Build should move this to WEB-INF/classes after compilation as mycommands.properties.
3. Move some commands from commands.properties.in to mycommands.properties.in
4. Build and run client with Jetty server.
5. Use cloudmonkey sync command to verify it's reading all 479 commands in from both files.

In a production environment the administrator would just drop a new properties file on the classpath somewhere, typically the classes directory of WEB-INF.

[rohityadavcloud]

@ProjectMoon my concern here is -- you're still making changes in the XML to make it work during build time, is there a way to make it configurable like rabbitmq plugin so one can add the xml at some place in /etc/cloudstack/management to change/add file names in the XML. (pardon my ignorance, I'm not well versed with spring)

[ProjectMoon]

Yes, that is correct it would need to be done during build time. I can add a way to make the list of files configurable. I think it would be best to make a properties file that has a key and a comma-separated list of files to find on the classpath.

I don't want to stick make a new properties file with just one line though. Are there any properties file that go into /etc/cloudstack/management where I could stick this key-value?

[rohityadavcloud]

@ProjectMoon can you rebase and re-submit the PR, the travis tests seems to be failing.

[ProjectMoon]

Pull request branch has been updated.

[asfbot]

cloudstack-pull-requests #489 FAILURE
Looks like there's a problem with this pull request

[asfbot]

cloudstack-pull-requests #490 SUCCESS
This pull request looks good

[asfbot]

cloudstack-pull-requests #654 SUCCESS
This pull request looks good

[blueorangutan]

@weizhouapache a [SF] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.