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

Creating an environment from the dev portal doesn't use the manifest default values #34

Open
SimonDraime opened this issue Nov 21, 2023 · 11 comments

Comments

@SimonDraime
Copy link

Hi Team,

As the parameters' default values of the ARM template I use in catalog are defined for a production environment, I set different default values in the manifest.yaml file.
However, when I create an environment from the dev portal it is using the default values of the ARM template instead of the ones defined in the manifest.

It is quite counterintuitive as it is not the values displayed in the dev portal during creation that are actually used.

Is it the expected behaviour? Is it possible to improve that behaviour as it would be very useful to be able to use different manifest files with the same ARM template for different environment type?

@j-rewerts
Copy link
Contributor

Hey @SimonDraime. Thanks for the report! This is definitely a bug, we should be honoring what is defined as the default in the YAML file. I'll let you know when we've got a fix ready.

@j-rewerts
Copy link
Contributor

Though I am curious to understand more about your last part:
it would be very useful to be able to use different manifest files with the same ARM template for different environment type?

We don't currently have this ability in the product. Mind expanding a bit more on what you're hoping to achieve?

@SimonDraime
Copy link
Author

Sorry, I was not very clear on that.

I meant that my catalogs Github repo would contain several environment definitions with each time the same ARM template (a different file but the same content) with a different manifest.yaml.
It would simplify the deployment process for our developer by just choosing a different environment definitions instead of defining the parameters themself.

@j-rewerts
Copy link
Contributor

Ah I really like this idea!
What if we had something like a set of defined parameters on each environment type? When a dev goes to the dev portal and creates the environment, we'll look at the environment type parameters first. Then the parameters that the dev must provide is just whatever is in the environment definition YAML that wasn't in the environment type. This may let you have just a single environment definition but have it vary between dev, prod etc.

@SimonDraime
Copy link
Author

Yes, it would be a good idea to use the environment type to define some parameters that are always the same for a specific environment type.
However, where would you define these parameters' values on the Azure portal, it's not very clear for me how are linked the catalogs and the environment definitions to the environment types? What if you have several environment definitions in your catalog? How to defines the parameters' value for each environment definition in the environment type?

@SimonDraime
Copy link
Author

@j-rewerts Do you have an idea of the timeframe for the fix availability?

@j-rewerts
Copy link
Contributor

Nothing to report currently, I'll follow up once we're getting close to shipping the fix.

@timwebster9
Copy link

This bug still seems to exist. I noticed it while using Terraform for our catalog. If the user doesn't change the default value of the parameters in the portal (and there is no default value for the variable in variables.tf), then the deployment errors because the values of the variables don't get set.

We could just specify default values in the Terraform variables.tf, but then you would have to make sure these are the same as defined in environment.yaml. This duplication would inevitably lead to more problems.

@ericaguthan
Copy link

Thank you for bumping this bug. We are taking a look at it and will update you once a solution is available.

@timwebster9
Copy link

timwebster9 commented Dec 13, 2024

EDIT: I replied to an older message it seems - I should have refreshed the page I guess. I see you've acknowledged the bug, but will leave my reply as is for informational purposes.

Hi @ericaguthan

Sorry I'm not clear. I am referring to the defaults in the environment.yaml. If defaults are present and the user just accepts them without changing them, they still don't get passed through to the IaC.

Maybe this is just a problem when using Terraform?

To reproduce:

  • Create a Dev Center/project with a Terraform catalog
  • include variables in your variables.tf file with no default value
  • include a corresponding parameter for the variable in your environment.yaml file. Give the parameter a default value.
  • Try to create an environment without changing the default value. It should fail with a Terraform error saying the variable is empty and has no default value.

Expected behaviour would be the default value from the environment.yaml to be passed through to the Terraform execution environment. This does in fact occur if the user changes the default value to something else.

I'm happy to open a separate issue if that would help?

@ericaguthan
Copy link

Hi @timwebster9,

This issue is fine to leave open. You are correct that this bug exists and is not just for Terraform. Expected behavior is that the environment yaml is the source of truth so what users see in the DevPortal is what they get. We are taking a look and will update when the fix has hit all regions.

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

No branches or pull requests

4 participants