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

SC-18436: 4-level domain generation for internal endpoints #477

Closed
wants to merge 2 commits into from

Conversation

yuklia
Copy link

@yuklia yuklia commented Feb 1, 2024

Description

Issue: For internal environments, the current system generates the zone with a 2-level domain instead of a 4-level one. This has led to additional manual effort being required on the infrastructure side to override the field.

Current Output:

{
    "glue.de.spryker.toys": {
        "zone": "spryker.toys",
        "type": "Glue",
        "internal": true
    },
    "glue.at.spryker.toys": {
        "zone": "spryker.toys",
        "type": "Glue",
        "internal": true
    },
    // ... (other entries)
}

Expected Output:

{
    "glue.de.yulia-dev.cloud.spryker.toys": {
        "zone": "yulia-dev.cloud.spryker.toys",
        "type": "Glue",
        "internal": true
    },
    "glue.at.yulia-dev.cloud.spryker.toys": {
        "zone": "yulia-dev.cloud.spryker.toys",
        "type": "Glue",
        "internal": true
    },
    // ... (other entries)
}

Action Required: Adjust the system to generate the zone with the correct fourth-level domain for internal environments. This will eliminate the need for manual intervention and ensure consistency in the generated output.

Change log

SC-18436: Adjusted zone generation to 4-level for internal endpoints

Checklist

  • I agree with the Code Contribution License Agreement in CONTRIBUTING.md

@yuklia yuklia force-pushed the zone-generator branch 3 times, most recently from 2e86f10 to 62ff9a4 Compare February 1, 2024 15:27
@yuklia yuklia self-assigned this Feb 1, 2024
@yuklia yuklia force-pushed the zone-generator branch 2 times, most recently from bf4eea3 to aad4b6c Compare February 1, 2024 15:49
Copy link

@vape-spryker vape-spryker left a comment

Choose a reason for hiding this comment

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

LGTM


if (isset($applicationData['endpoints']) && is_array($applicationData['endpoints'])) {
foreach ($applicationData['endpoints'] ?? [] as $endpoint => $endpointData) {
$internal = isset($endpointData['internal']) && $endpointData['internal'] === true;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does it mean, that we should add an internal key per each endpoint and have different configs per the same env?

Copy link
Author

Choose a reason for hiding this comment

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

it mean that we should add internal: true flag to endpoints

            backapi:
                application: zed
                endpoints:
                    backend-api.de.yulia-dev.cloud.spryker.toys:
                        store: DE
                        entry-point: BackendApi
                        internal: true
                    backend-api.at.yulia-dev.cloud.spryker.toys:
                        store: AT
                        entry-point: BackendApi
                        internal: true
 // ... (other entries)

$host = strtok($endpoint, ':');
$zone = $internal ? getFrontendZoneByDomainLevel($host, 4) : getFrontendZoneByDomainLevel($host, 2);
Copy link
Collaborator

Choose a reason for hiding this comment

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

How it will solve the problem for different level, e.g 3 or 5?

Copy link
Author

Choose a reason for hiding this comment

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

this improvement solves the only 1 problem no more no less.

problem statement:
As a cloud engineer I want to spin up dev || test env.
I use *.cloud.spryker.toys domain for my sandbox env.
When I set the domain in deploy.yml file
And run docker-sdk boot command to generate artifacts
I expect that frontend.json will be generated with correct zone: *.cloud.spryker.toys
But actual result is zone: *.spryker.toys -> which is not correct And requires manual effort to change values.


the provided fix solves this problem.

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

Successfully merging this pull request may close these issues.

5 participants