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.

Sign up for GitHub

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

Jump to bottom

Do entitlement check before any Azure resources are created #111

Closed
wants to merge 7 commits into from
Closed

Do entitlement check before any Azure resources are created #111

wants to merge 7 commits into from

Conversation

majguo
Copy link
Collaborator

@majguo majguo commented Sep 28, 2021 •
edited
Loading

Description

This PR is to fix the following issues:

Change summary

  • Do entitlement check at the beginning of the deployment

Testing

The following test cases have been passed before opening the PR:

  • Successfully created a tWAS cluster (1 dmgr, 1 worker node & 1 IHS) with an entitled IBMid.
    • The deployment continued after the pre-entitlement check passed;
    • For each VM, the entitlement check will be executed again to ensure only an entitled user can deploy tWAS cluster;
    • Finally user can successfully install a default application DefaultApplication to the cluster and IHS, which is accessible later;
  • The deployment stopped right after the pre-entitlement check failed with an invalid IBMid.
    • No other Azure resources are created;

Here is the preview link for testing.

Signed-off-by: Jianguo Ma [email protected]

@majguo majguo force-pushed the pre-entitlement-check branch from 52ddbf2 to 9d1ccc7 Compare September 30, 2021 00:31
edburns
edburns approved these changes Oct 8, 2021
View reviewed changes
Copy link
Collaborator

@edburns edburns left a comment

Choose a reason for hiding this comment

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

Hello @rk thanks for bringing my focus to this thread. Here is my argument for why the ~8 minute addition is worthwhile:
My interpretation of the spirt of the business agreement IBM and Microsoft entered in March 2021 is that the Marketplace Offers we create support lead generation, prototyping, and awareness raising. At Microsoft, we call this sort of thing “the top of the funnel” (personally I hate the term). For such offers, we want to optimize for frustration minimization. If I was a user testing this stuff out, I’d find the following scenarios so frustrating I might just give up and go to a competitor.
I have an entitlement but there is a typo in the credentials. I’d rather know in 8 minutes than in 20.
I don’t have an entitlement, but I think I do. Again, I’d rather know sooner.
So, I continue to +1 this PR.

@majguo majguo force-pushed the pre-entitlement-check branch from 9d1ccc7 to e2f3c99 Compare October 8, 2021 23:33
@majguo
bump package version
5967868 
Signed-off-by: Jianguo Ma <[email protected]>
@edburns
Copy link
Collaborator

edburns commented Oct 27, 2021

At the 2021-10-26 weekly meeting, we decided the approval of this approach depends on the answer to this question:

Does the time spent (N minutes) doing the entitlement check before Azure resources are created mean that N minutes less time is spent later in the deployment?

If the answer is yes, we can proceed with this approach. If the answer is no, we must find an approach for which the answer is yes before we can proceed, or we must abandon this idea entirely.

@majguo majguo closed this Oct 28, 2021
@majguo
Copy link
Collaborator Author

majguo commented Oct 28, 2021 •
edited
Loading

@edburns @gcharters @NottyCode @git4rk The answer is No unfortunately. The reason why we can't store the result of pre-entitlement check somewhere and pass it to cloud-init scripts during WebSphere VM creation is that hacker can inspect the solution template and mimic the same process/logic to bypass the entitlement check required by WebSphere VM creation, which is not acceptable.

I think the better solution is to refine the entitlement check logic at the IBM side (e.g., using a session or token to cache/carry the entitlement check result), but I don't think it's feasible as for now. So I will just close the PR now and maybe reopen it if a smarter idea comes out in the future.

@git4rk
Copy link
Contributor

git4rk commented Oct 29, 2021

@majguo Are we not able to stop/fail the provisioning right after the entitlement check fails on one or more of the cluster VMs? If yes, then this should also take around 8 mins, right?

@majguo
Copy link
Collaborator Author

majguo commented Nov 3, 2021 •
edited
Loading

@git4rk Entitlement check is executed in cloud-init stage of VM provisioning, but Azure doesn't support to propagate the state of cloud-init script execution which can be used to control the process. That's said, yes, we will wait until entitlement check in all of VMs completed no matter it succeeded or not, as what I observed during the testing before.

For your question:

If yes, then this should also take around 8 mins, right?

As these check are executed in the VM extension running phase which are expected running in parallel, so ideally they won't use 8 mins * number_of_VM in total.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@edburns edburns edburns approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Entitlement check should be done as part of form validation
3 participants
@majguo @edburns @git4rk