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

add connect Cdn API #601

Open
wants to merge 17 commits into
base: preview
Choose a base branch
from
Open

add connect Cdn API #601

wants to merge 17 commits into from

Conversation

samsadsam
Copy link
Contributor

No description provided.

/// Connect the provider to CDN endpoint.
/// </summary>
/// <param name="cdnEndpoint">The endpoint of the CDN instance to connect to.</param>
public AzureAppConfigurationOptions ConnectCdn(Uri cdnEndpoint)
Copy link
Member

Choose a reason for hiding this comment

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

We allow users to specify multiple Connect calls and the last one always wins.
We are preserving that behavior with ConnectCdn, but with CDN endpoint involved, it's not that intuitive. I think we should throw if Connect and ConnectCdn are invoked together. This should not be allowed:

options.Connect(appConfigEndpoint, tokenCredential)
       .ConnectCdn(cdnEndpoint)

@zhenlan @drago-draganov what do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What is "not that intuitive" ?

Copy link
Member

Choose a reason for hiding this comment

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

Connect is loading from AppConfig service, but ConnectCdn is loading from CDN service. With a setup like above, I would expect my provider to load data from both endpoints.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree with Avani's suggestion - the Connect and ConnectCdn shouldn't be allowed to be used at the same time.

Even if there is such a scenario, users can create two separate configuration builders.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

samsadsam and others added 9 commits October 25, 2024 15:01
…nstance(s) used by the provider (#598)

* Introduced a new `AzureAppConfigurationClientFactory` class to handle the creation of `ConfigurationClient` instances

* remove clients dictionary since we will not have hits and clients are already stored in ConfigurationClientManager

* revert

* add license + remove unused usings

* ran dotnet format

* add capability of fallback to different stores

* add explicit type

* address comments

* remove scheme validation

---------

Co-authored-by: Sami Sadfa <[email protected]>
* add IsAzureAppConfigurationSource

* nit: format

---------

Co-authored-by: Sami Sadfa <[email protected]>
…d when the `optional` parameter is set to true (#599)

* update comment

* address comment

---------

Co-authored-by: Sami Sadfa <[email protected]>
@avanigupta
Copy link
Member

Note: Correlation-Context header should contain a special tag when ConnectCdn is used.

@@ -0,0 +1,72 @@
using Azure.Data.AppConfiguration;
Copy link
Member

@amerjusupovic amerjusupovic Nov 14, 2024

Choose a reason for hiding this comment

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

nit: add mit license comment on new files

@samsadsam samsadsam changed the base branch from main to preview January 23, 2025 13:10
@samsadsam samsadsam changed the base branch from preview to main January 23, 2025 13:41
@samsadsam samsadsam changed the base branch from main to preview January 23, 2025 13:42
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.

None yet

6 participants