-
Notifications
You must be signed in to change notification settings - Fork 780
Deployment Stacks (bicep destroy
-like functionality)
#2690
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
Comments
In the next month to two months we will be releasing a private preview of "Deployment Stacks" which will improve overall lifecycle management of bicep/ARM deployments -- including a destroy-like functionality. Little bit of info here in the meantime: cc @bmoore-msft |
Hi team, any update on when to expect "Deployment Stacks" preview or a page to find out more? |
Getting very close! Hoping the private preview is available in the next 2-3 weeks. |
Are we there yet? 😬 |
The private preview just started last week, but we are onboarding folks in waves. Please sign up at https://aka.ms/getStacks and we will do our best to onboard you soon! |
@alex-frankel Is this private Preview still available? Thanks! |
@monojit18 - shoot me an email with your github username and I'll get you onboarded (ok, I know your github username but I added that for anyone else interested). bmoore at microsoft |
@bmoore-msft Done as you suggested. |
can access private preview, yet ?? |
@mdizcalvinoaz400-01 -- have you emailed bmoore at microsoft dot com? He can onboard you. |
thanks, ok i will do it |
bicep destroy
in Bicep's future?bicep destroy
-like functionality)
Are you still onboarding new people? |
Yes - just shoot me an email with the userId you want onboarded... |
Is this feature coming to AzureGov anytime soon ? |
Should be in USGov at public preview |
@alex-frankel - redirected here from #8877 - I don't fully understand what this feature is about, can you confirm how it is supposed to solve the problem where today, it is not possible to deploy a P.S my next idea to solve this problem is to layer an "incremental mode" deployment on top of the complete mode deployment, i.e to deploy the private endpoint into its own resource group deployed with incremental mode - will report back here if that works. |
Here is a more detailed overview on Stacks that we did recently: https://www.youtube.com/watch?v=tPrpsKVEhSU&t=224s Stacks defines a set of resources that it manages based on what is deployed in the bicep code/ARM template. Since the NIC is auto-created, it is not part of the template, and will not get deleted when you re-deploy the stack. |
Hello @alex-frankel any update on it? Can we already use deployment stack futures for subscription target scope in bicep? |
Is there any status of the development of Deployment Stacks |
Our goal is to release Deployment Stacks in Public Preview sometime in May. If you would like to try the private preview in the meantime, we would be happy to onboard you. Let us know and @apclouds can help take care of that. |
So how would you tear down the stack in this scenario? As the nic is auto created but nevertheless used by private endpoint, I'd expect tearing down a stack to fail due to the unknown nic still being in use potential? Or if it succeeds the auto created nic will be left around? |
We don't delete anything not explicitly in the bicep file that was deployed with the stack, so either the NIC will be around or the stack deploy would fail if other resources can't be cleaned up until the NIC is deleted. There is no system today that we can hook into to tell us about auto-created resources like this. We will have to think through the best way to do with this (if there is a good way at all) |
It sounds like this original issue should be reopened perhaps if stacks isn't the answer after all? #8877 |
If the ask is to allow manual creation of the NIC for the private endpoint, then that will have to be an ask to the Networking Resource Provider team. I can share these issues with them, but it may also be helpful to open a support case. We definitely are supportive of this btw - in general, we try to encourage RPs to not implicitly create resources as it makes things generally harder to manage overall. It's not an issue that we can explicitly help with since it is all handled by the Networking RP. |
My support case was closed several months ago - they stated the product team was aware of the issue. Whether that is true or the right team has the right information is a bit beyond my control. Perhaps you could ensure it's atleast on the correct teams radar? I am reluctant to go through a second support case. |
I passed it along to NRP and will share what I hear back |
Hi @ChristianPejrup, I've onboarded you to the preview. Looking forward to your feedback! |
Hi @apclouds , I would like to be onboarded for the preview as well. |
@apclouds me too would like to try out the preview :) |
@apclouds I'd love to have a play with the preview features too |
I've added you all to the preview, thank you for taking the time. Please feel free to raise issues for any feedback. Thanks! |
@apclouds : I would like to have access to the deployment stacks preview features if its possible. thanks |
@apclouds same here, on getting access. Is there a Microsoft Form or some method of self-service way to do this? for example, this form for OpenAI services within Azure |
Hi @apclouds, could I also receive an invite to the preview please? |
Hi @apclouds , I would like to be onboarded for the preview as well. We're going to try using it for our deployment. |
I've added you all to the preview, thank you for taking the time. Please feel free to raise issues for any feedback. Thanks! |
Hello @apclouds, I would also like to get access to deployment stacks private-preview if possible. |
Hello @kolendomichal - I've granted you access to the preview. We are on pace for Public Preview this summer. Looking forward to your feedback! |
Hi @apclouds, please could you add me the Deployment Stacks preview. Very keen to get stuck in and start testing this. |
Hi @DanoThom - I've granted you access to the preview. Looking forward to your feedback! |
@apclouds Hello, if possible I would also like to get access to the preview please :) |
Hi @mattias-fjellstrom - thanks for the interest. You can now find the latest preview release at aka.ms/deploymentStacks Looking forward to your feedback! |
Closing - deployment stacks is now available in public preview! Please check it out: |
Is your feature request related to a problem? Please describe.
We use Terraform now, but exclusively use Azure for our cloud services. With the introduction of Bicep, the case for using Terraform has weakened. However, we very much appreciate Terraform's ability to use Infra as Code both for resource creation and destruction. Currently, ARM / Bicep / Templates only allow for resource creation via IaC.
Describe the solution you'd like
Would it be possible to add a
destroy
feature analogous to Terraform's? I understand that ARM does not maintain state, and instead checks resources against what is currently deployed and creates based upon deltas.I am sure this process of creation via deltas is very complicated, but it does seem from the outside that destruction based upon deltas would be complicated, but in a very similar way. It seems that maintenance of metadata (probably a JSON file) could manage this by "remembering" the associated Infra as Code resource creation. This metadata could have the same lifecycle as everything else associated with
az group deployment delete
. If no such deployment exists, thenbicep destroy
would fail with an error stating that. If there is any conflict (eg, the deployment has a different subnet associated than the resources are currently using), there can be some interactive decisioning on how to handle it.I do not claim this is easy, but just very similar to the delta already being performed, I would think.
PS. I looked in all issues and could not find this already mentioned. That surprised me, so apologies if it has already been discussed. An honest effort search found nothing.
The text was updated successfully, but these errors were encountered: