Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISSUE-1231 Enable test environment which don't require importing cluster #1232

Closed
wants to merge 2 commits into from

Conversation

HeartSaVioR
Copy link
Contributor

  • Add "test environment" (ID -1) to environment by default
  • Add "readonly" field to namespace table
    • default: false
  • When readonly is true, default value (localhost) of Storm configuration is loaded
    • it enables such environment to run topology test (good to test), but no more

* Add "test environment" (ID -1) to environment by default
* Add "readonly" field to namespace table
  * default: false
* When readonly is true, default value (localhost) of Storm configuration is loaded
  * it enables such environment to run topology test (good to test), but no more

Change-Id: I027ee81eea1fc1480d0fd287ec13ffa6cc61ec88
@HeartSaVioR
Copy link
Contributor Author

@shahsank3t
I would need UI change to complete the feature: disable option (edit/remove) on environment when rollback field is set to true. Could I get help on this? Thanks in advance.

@HeartSaVioR
Copy link
Contributor Author

@arunmahadevan
This enables fresh new SAM instance to run topology (with importing existing one) test without importing cluster and setting up environment. #1230 even open the possibility to add TCP source and sink for composing test app as well.

@shahsank3t
Copy link
Contributor

@HeartSaVioR Yes sure, I'll help you with the UI changes. Will this rollback field be part of the same environment API? Couldn't find anything related to the field in this PR so just confirming.

@HeartSaVioR
Copy link
Contributor Author

HeartSaVioR commented Feb 28, 2018 via email

@joylyn
Copy link
Contributor

joylyn commented Mar 1, 2018

@HeartSaVioR I have a couple of doubts as follows -

  1. Is the default value for readonly needed to be provided by user when adding a new environment?

  2. In addition to disabling the edit/remove options for readonly namespaces, the "share" option is also disabled for user irrespective of the permission. Is this alright?

@HeartSaVioR
Copy link
Contributor Author

HeartSaVioR commented Mar 1, 2018

@joylyn
The intention of patch is inserting "Test Environment" from the start of SAM when it doesn't exist, and let users (in fact, mostly contributors of SAM) use the environment to test simple scenarios which even don't need Storm cluster (local cluster of Storm would sufficient). readonly field is to prevent users to modify the test environment.

  1. Nope. It is just a flag indicating that it shouldn't be modified from user side.
  2. The namespace should be seen from all of users. Btw, I'm not aware of "share" option for namespace. It should not be needed.

@arunmahadevan Could you help me figuring out that "Test Environment" will be seen from all users? Sadly I'm not clear of ACL entry, and I don't add any ACL entry for such environment.

@ALL
Btw, If name of flag readonly makes confusion, we could find alternatives like builtin, testing and so on. What do you think?

@arunmahadevan
Copy link
Contributor

Could you help me figuring out that "Test Environment" will be seen from all users? Sadly I'm not clear of ACL entry, and I don't add any ACL entry for such environment.

Are we hiding this placeholder Enviroment (e.g. from the enviroment REST API) so that it does not show up in the UI ?

The ACL entries are enforced at the Resource classes and catalog service can query any entry. However I don't see any permission checks currently happening for TestRunResource. We should protect these resources using the ACLs defined for the topology. (like how we protect the topology components using the underlying topology permissions here).

Copy link
Contributor

@arunmahadevan arunmahadevan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments.

Are we hiding the placeholder entry from the REST APIs ?

-- See the License for the specific language governing permissions and
-- limitations under the License.

ALTER TABLE `namespace` ADD `readonly` BOOLEAN NOT NULL DEFAULT false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may be better to name the flag testing or internal

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

internal would be fine to me.

Service streamingEngineService = getFirstOccurenceServiceForNamespace(namespace, streamingEngine);
if (streamingEngineService == null) {
throw new RuntimeException("Streaming Engine " + streamingEngine + " is not associated to the namespace " +
namespace.getName() + "(" + namespace.getId() + ")");
if (!namespace.getReadonly()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isTesting or isInternal based on previous comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK.

@HeartSaVioR
Copy link
Contributor Author

HeartSaVioR commented Mar 1, 2018

@arunmahadevan

Are we hiding the placeholder entry from the REST APIs ?

Nope. It is just guarded with assertion (flag check), and UI should hide the edit functionality on internal.
It doesn't seem to make sense to hide from environment tab and show it for creating/importing/cloning topology. Is it possible? If not, we should just expose it (at least for get/list) to end users.

* change the name of field `readonly` to `internal`

Change-Id: I6267b0087d6031b391c5ccc0824a22989d2d37da
@HeartSaVioR
Copy link
Contributor Author

@arunmahadevan changed the field name.

@arunmahadevan
Copy link
Contributor

@HeartSaVioR , does it require the UI changes to go along with it or can this be merged first ?

@HeartSaVioR
Copy link
Contributor Author

HeartSaVioR commented Mar 2, 2018

@arunmahadevan Better to have follow-up patch since backend will throw exception whereas it is editable in UI, but the follow-up patch can be done after merging. I think @joylyn is following up the issue.

@arunmahadevan
Copy link
Contributor

Raised #1236 for UI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants