Add support for enabling Enterprise Support for ADF Provisioned Accounts

[StewartW]

Use Case
When we provision new accounts at the moment - We use terraform to create the account and carry out a series of tasks. One of these is enabling Enterprise Support for the newly created account.

I think exposing a config option on the schema for accounts created via adf-accounts/*.yml would be a great feature for others and allow us to move closer to deprecating TF fully in favour of ADF.

[javydekoning]

In this case, I think we should support all support levels. Also, your approach only allows enabling the ES support level (not removing/downgrading it).

An alternative approach is running a Lambda in the master account, triggered on organization join/invite CloudTrail events.

Or use tags on accounts to determine the support level. Together with a Lambda that runs on a schedule.

[StewartW]

Hey @javydekoning Thanks for the comments :)
As at the moment - Only account creation is supported via ADF - I'm not sure if there's a situation in which we would be removing Support from individual accounts

My understanding of the Support tiers (obviously, you're in a better position to understand them, so correct me if I'm wrong) is that it will work for both ES and Business tiers. I'm not sure how many people would use ADF with Developer Plans.

Likewise, I'm not sure (again, I'll defer to experience) how many customers downgrade their plans.

We have alternative approaches already, but I feel like this would be a good problem to solve for other / potential users as well?

[javydekoning]

It would be a great addition. However, if we build it 'as code' I'd like to see it serve both enabling and disabling. I would also prefer:

support_plan: 'basic|developer|business|enterprise'

Over:

enable_enterprise_support: True|False

Hence the Lambda might need some alterations. Hopefully in the future we can do this through API instead of via support case.

[StewartW]

It would be a great addition. However, if we build it 'as code' I'd like to see it serve both enabling and disabling. I would also prefer:

support_plan: 'none|developer|business|enterprise'

Over:

enable_enterprise_support: True|False

Hence the Lambda might need some alterations. Hopefully in the future we can do this through API instead of via support case.

Yes, actually, I think you could be on to something there.

Totally agree, that the first example make's alot more sense. Happy to make those modifications.
I think that for now It might be as simple as doing a NOOP for the none|developer options for now (Perhaps some console output) explaining why it has no functionality and wrapping the current support request behind the business|enterprise options.

I think that would also give flexibility going forward for future iterations on this. Likewise, it would be good to move to an actual API, rather than the CreateCase API.

However, if we build it 'as code' I'd like to see it serve both enabling and disabling
Sorry, I forgot to ask in my original response.
I think we are both aligned on the enable|disable front
From your experience with customers, how do they tend to disable support for individual accounts. Here, I tend to find that support is enabled until the account is closed.

If we were to do something along the lines of

       support_session = Support(role_in_target_account)
       support_enabled = support_session.check_support_enabled()
       if support_enabled and account.support_plan is 'none':
           support_session.remove_support_subscription()

How would you feel about that?

The same logic could probably be extended to cover enabling support for accounts not created via ADF but I think the async process could result in complications.

[javydekoning]

Instead of check_support_enabled you could use get_support_level. Then use set_support_level to enable/disable ES for now. It will give you a path forward should other options become available.

You could get the support level by running using the DescribeSeverityLevels API. You could deduce the support level based on the available severity levels. Just keep in mind that it would return HTTP400 when on Basic.

Not keen as to only logging to console for the unsupported methods. Pipelines would succeed, leading people to believe it was successful.

Only supporting support_plan: 'basic|enterprise' to start would allow you to continue with the current approach as well as provide a path forward should an API be available in the future.

I'll ask the team to have a look at this to see if they agree.

[sbkok]

I like these suggestions!
@StewartW Could you change the API the way @javydekoning mentioned? Starting with just support_plan: 'basic|enterprise' for now. Plus using the get_support_level API?

In case we ever support developer and business support: we need to ensure someone doesn't accidentally set developer or business, when in fact they are on enterprise support with their organization. Or am I missing a use case that would benefit from this?

[StewartW]

If made the changes, let me know what you think of that approach.
I've kept it in the account creation path, rather than run it every time. However it is capable of identifying if it needs to do anything or not, there's just the small issue of what happens if it re-runs whilst waiting for the ticket to be actioned. Keeping it where it is circumvents this issue until such time there's a better API available for this sort of action.

[bundyfx]

Adding this one into 3.1 milestone, thanks again for your work @StewartW..

@javydekoning + @sbkok Are there any other changes you would like to see before we bring this into v3.1?..

[javydekoning]

Reviewed, looks good! We just need to clearly set expectations.

The use-case here is activating Enterprise Support on account creation ONLY.
We do this by raising an automated support case. ADF will (and should) not trigger any support level change on updates. This functionality should only be used by customers whose Organizations Master account is already activated for Enterprise Support.

I suggest we put emphasis on that in the documentation.

[StewartW]

I've added in some emphasis covering the use-case the the accounts readme file. Let me know what you think, if it's worded properly etc. :)

[sbkok]

Thanks for the patch @StewartW. It will be shipped in the next release of ADF.