Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/1489#issuecomment-215147096
@koushik-das -- I'd say yes, that testing is good enough. If a test can
determine that the default roles allow the expected access to the APIs then
we're good.
There was some discussion of commands.properties deprecation in 2013. In
particular, plugin developers had issues with the way it works. People should
really have been using the annotations by now, but I believe it was not well
communicated and the fact that commands.properties is still around has confused
new developers. From the original discussion, the only reason it was left in
place was in case users wanted to disable APIs entirely by setting the bitmask
of an API to 0. Do we have that functionality covered now?
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201310.mbox/%3c2b439486-9c4b-41b7-a698-b7ade234b...@netapp.com%3E
https://github.com/apache/cloudstack/commit/9f7b4884a7a0bf0b15d94777cff449fde4664af2
Note also that existing installations are not being affected, they have to
choose to use the new mechanism. In theory, I'm fine with some sort of staged
transition where the dynamic checking is opt-in for a release, but I worry that
it will perpetuate the issue we've seen since 2013, and puts a burden on the
community to go back and clean up at some later date. For these reasons, I
think if it's functionally identical on new installs and doesn't affect
existing installs use of commands.properties, we should just cut over.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
