Community Office Hours: Terraform 1.1 Release

welcome everyone to another community office hours for terraform in this one we're going to be covering the 1.1 release we got a lot of new stuff that we're going to talk about a lot of things that have been a long time coming uh but before we get into that i do need to cover our community guidelines which are to be welcoming inclusive friendly and patient at all times be considerate be respectful and be professional now these are all pretty simple but just in case i'm gonna go ahead and throw up a little banner here that just puts that there just in case uh you forget now on our stream today we've got some guests that if you're in uh plugged into our community you've seen around before but it'd probably be good to do some guest introductions so why don't we just go uh first name alphabetical here uh brian why don't you kick us off with who you are and what you do hey everyone uh hey thanks so much cole uh i'm brian fladd i'm a senior software engineer on the terraform provider development experience team and i've been at hashicorp for about four years now i'm chris i'm uh engineering lead over on the terraform practitioner team a team kind of deals a lot with like uh kind of the intersection between terraform oss and cli and terraform cloud and i've also been around coming up on three and a half years almost four years all right hi everyone my name is karen alpers i'm a product manager on the terraform open source project as well as the practitioner team with chris as well and i've been at hashicorp now a little bit over five months hey i'm cole morrison i'm a developer advocate here at hofstra corp all right so let's go ahead and move into what our agenda is for today so first up we're gonna just talk about the whole release uh just in general and then we're going to dive into each of those features we've got some demos for some of those we're going to talk about it from a product perspective practitioner perspective and we'll even get a little bit of insight on what it looks like from the provider perspective as well and then at the end we'll talk about what is up in 2022 as much as we can so why don't we uh go ahead and set the stage for the entire thing we'll be talking about uh this release brings a lot of stuff and before the stream i was actually talking uh to chris because uh back when i started um this whole movement of getting uh tara from cloud more into the core workflow for the practitioner was a big theme and it's finally here uh so corinne i kind of wanted to pass it over to you and just set the stage you know what were the what were the big ideas and themes and what problems and pain points from the practitioner user customer perspective drove the things that became part of this release sure thing all right so tara from 1.1 was just released uh december 8th so if you haven't seen the announcement blog i'd highly recommend diving into it but from a high level the the two core themes that we wanted to ship in this release are basically providing a way to easily and more safely refactor and then secondly to improve the current cli experience for our terraform cloud and enterprise users so to start with the easier and safer refactoring uh as many of you know the traditional ways of refactoring was to use terraform state move from this cli and that could be a very cumbersome error prone process the the general problems that we were seeing were open source users were basically having to rename state objects as well as update their configuration at the same time and managing that could be just a bunch of individual tasks and for our terraform cloud users unless you had admin access on the workspace uh this wasn't really possible at all and even if you did have that access you would need to go ahead and switch to like a local mode in order to do those commands via the cli and then go ahead and and update and again that wasn't really within the core workflows and not a great process for many of our customers as well as just generally smaller teams and then lastly for module authors if you are trying to do some refactoring again you would need to basically release like a new major version to indicate a breaking change as well as do the refactoring and uh this just wasn't ideal and a lot of teams obviously as you grow out your configuration or throughout your entire infrastructure you're going to need to do refactoring at some point in time um and so we are shipped this new mechanism using move statements to do refactoring within the modules like own source code so you can do a plan and then validate all your changes and we'll have a demo of that as well to show exactly what that looks like but basically you can use these move statements to show how you've renamed a resource or a module you can enable counter for each for a resource or a module call and you can also split one module into multiples which is really what a lot of people in the refactoring are going to do and secondly we can talk about uh the cli experience for terraform cloud and chris can walk you through a demo to show you exactly what all the cool things that we did but to give you a high level view of why we wanted to target this was uh terrapin cloud when we first shipped it was really focused on the vcs connection workflow uh there's three overall workflows that a lot of people use it's vcs so something like hooking up your github repo and using that entire workflow to update your terrapin configuration and make sure it goes through like a series of checks however a lot of people who are using or migrating from like open source terraform are probably expecting to use the same workflow that they're accustomed to which is the cli driven workflow and the previous experience just wasn't really as much great and as helpful or uh intuitive as we wanted so we invested a bunch of time into making a cloud integration that was just more representative of what people expect for terraform cloud so previously we went and uh you would hook up a remote backend so you would configure within a back end block remote and then somehow you would need to have this mental model of this is terra from cloud and then if you get errors and those kinds of things be understanding that remote equals terraform cloud and make sure that um you just fully understand that that path and we wanted to make it more easy that when you just signed up for tariff cloud it's just terra from cloud and so we created this new cloud block within the terraform top level settings you can go ahead and configure your host name if you're using terraform enterprise as well as use uh workspace tags so you can update within your own configuration i want to add some tags like networking prod that sort of thing and then you can see within the terraform uh cloud ui that it's represented there as well as within the cli if you want to just look at what workspaces you have and again chris will walk you this demo because me talking to you about it is not going to be as informative as as a demo would be uh and secondly the the big thing that we wanted to tackle was people weren't super aware of terraform cloud's importance in the workflow so people would often think of it because it was in that back end block as just a place where to store state when really the the true value in it comes with remote operations so not only can you store remotely your your state file you can also execute remotely and by putting it up within the terraform top level we're kind of separating it from back ends are for state storage only so what people are used to like storing it with locally or storing it an s3 bucket that kind of thing and now tara from cloud is where you can run remotely as well as to other tasks like sentinel policies those kinds of things and store state and lastly uh i kind of touched on this a little bit but we added a bit more uh helpful error messages just to improve the overall developer experience so things like really just helping the user figure out uh you need to name a workspace or these are the kinds of flows that you need to go through as well as onboarding in general so if you need to reconfigure or you need to migrate state they walk you through the entire process in a much more intuitive manner and that is that is the overall 1.1 release nice nice so it seems like uh you know the theme of of course 1.0 was stabilizing and locking a lot of things and this time around we have a lot of not low hanging fruit we have a lot of mid hanging fruit right around your cloud experience around your module creation experience around some other different flows for your cli experience right and it looks like those all got tackled in this release at least the bigger ones so i wanted to ask chris from an engineering perspective you know when i was being one of the people that worked on this what what did this look like in the background for those of you know people that are interested in what what happened to making this go on to play because i remember talking to you some time ago that it wasn't as simple as we'd just make it right there was a lot of stuff that had to change to bring all these things uh to fruition yeah architecturally speaking uh i mean the remote back end uh was added to terraform in i believe 0.12 was back in 2018. it was kind of built along uh kind of the predecessor to terraform cloud as we know it today there was like a terraform enterprise sas there were a couple of different offerings as we were beginning to uh you know make out a service for terraform where the remote back-end was kind of built in that time and since then you know uh we've we've done a lot more things with the terraform cloud platform and there you know were a lot of edges where you could see that like oh this was actually built for this other thing and we've never had really uh the chance to be able to go back and really correct a lot of those different things uh until this year so and most uh you know a good chunk of 2021 for the practitioner team has been kind of you know starting over to looking at it and being like all right how can we how can we deliver some value and uh kind of bring this the cli driven workflow of terraform cloud um you know into the modern age i guess of terraform cloud so uh yeah it's been a it's been a long journey throughout the year and we're happy to really see it come to fruition here in 1.1 nice nice and you know that to bridge engineering and and product here we obviously have the provider ecosystem which is very much the lifeblood of terraform brian you obviously know a ton about that what does this release do for our folks out there who are working on providers or you know work work with them daily right yeah so from a practitioner's standpoint you know this these refactoring changes that are starting to happen with terraform cli they're really kind of like taking a step back and taking a look at people's workflows in general so you know the typical workflow that people normally apply for a lot of things is make a change in your you know configurations and hopefully push that up to like some sort of version control system uh run terraform apply plan on it then terraform apply and you know rinse and repeat as much as necessary but when you start getting into some of these other scenarios like refactoring configurations or trying to move around things basically uh there's gaps in that where there's no way in the configuration necessarily to make these changes and propose them in a certain way or have guardrails that happen and then you know you go to actually make these changes they require you to go outside of that plan apply workflow you you can you maybe need to run like a state move command or something and yeah it's a little confusing and it's a little awkward sometimes and especially if a lot of folks are working in the same you know modules or same configurations it can get a little hairy sometimes too because you know if you need to make that change it needs to be kind of like done by itself after you've made the configuration change but don't apply in between and so there's there can be a little bit of awkwardness there and this hopefully kind of helps align uh with like a larger vision that uh terraform itself um we really love that plan apply workflow and the more and more ways that we can bring that sort of workflow into uh changes that you want for your infrastructure uh you know i think that's where this is really coming in and super clutch that is such a good way to theme that up how much can we keep and plan and apply i love that nice all right well uh thank you that kind of hit a light bulb at the point where i just drained all my electricity so i'm i'm coming back from being mind blown there brian um so let's go ahead and move into the major features now that we've got the uh the the themes under under our belts here and the first one we're gonna touch on today was the new cloud experience right so everything around that um karen i'm sorry to make you do it again cause i know you just gave us uh an entire album of what was happening so i'm gonna have you drop us in again you can go go a little bit more in depth with this new thing that we're bringing to unifying the cloud experience with the the cli experience and like sure okay so to introduce it we basically in a very short summary shipped a new cloud integration uh it's it is similar to what the remote back-end was doing and like and tends to do the same thing but it is a whole new integration as an alternative or a successor to the remote back-end uh the previous way of connecting to terraform cloud so chris will show you how you can basically define and configure your terrapin cloud connection and you can go ahead and say things like uh this is my workspace name or you could use your workspace tags and uh once you do tariff on it that's go ahead and set that up and you are connected here from cloud and walk through all the steps of going ahead and doing your first uh plan and apply if you also just to quickly plug in if you haven't used here from cloud a lot of people don't know this we actually have a free tier uh it's very generous you can sign up i think up to five people um do remote states remote operations all kinds of things and i highly recommend checking it out um it's a lot easier than hooking up a bunch of separate tools so yes the the cloud backend or cloud configuration the way that you go ahead and and connect to narrative from cloud was in that terraform top level settings um and through that again to summarize the main things that we really wanted to hit was better error messages and better just developer experience in general um clarifying remote state versus remote operations so back ends just to remind you that's for storing state uh the cloud integration itself or tariff on cloud is for remote state and operations plus more things like sentinel policies etc and lastly am i forgetting exactly the the last one oh better understand terra from workspaces in general so tags will walk you through what that looks like but tear from workspace just to quickly tell people uh because it's a little bit confusing if you're used to terraform cli workspaces a workspace is just how you manage a collection of infrastructure and it contains everything that terraform needs in order to to run whatever you're trying to tear from apply so instead of terraform cli is how you would basically rename a state file a terraform cloud workspace is really just everything it is it is like basically a separate working directory nice thank you that was great nice you can trip up your words once there well we have the uh we have a demo so a lot of good stuff there's a lot of things going into this and if you've worked with remote back-ends this is gonna be something you probably are gonna be very excited to see so uh unless we have any other pre-commentary brian or chris i'd love to hand the demo over to you chris and uh sure yeah no karen karen nailed it really um i mean i think that it's it's hard to it's hard to fit in such a small car and talking there in a minute just how much many different things were we were doing with this just because like you know it's it's both like clarification and improvement of of user experience along with some new features i mean there's some some completely new things that were not available previously on the platform before this uh as well as just like kind of clarifying and repositioning like how the cli really works with terraform cloud like what it is you know what i mean so like the remote back end in general right it's kind of confusing to even talk about really like before we even get into the screen here you can you can uh you can hear the word remote used in like four different contexts which is really hard for someone who's coming into terraform to really understand right if you're dealing with like state back-ends that's actually referred to in terraform as remote back-ends right they're all remote back-ends but that's different from the remote back-end right and that back-end is special because it you know is is one that that handles operations it's kind of this this extra added feature that makes it very different from all the other backends which is just a whole i mean we're already getting into a whole lot of mental overhead about what the heck that thing even is right and uh even more than that like you can configure a workspace to run locally with the remote back end which is a remote back end we could just go around in circles all day let's just keep doing this all day long anyways yeah uh yeah let's uh let's get started and take a take a look here all right may the demo gods be with you all right yeah we will we will see okay so oops let's get started there we go all right let's get started um i have like a really basic configuration here uh it uses the random provider one of our most favorite providers which basically just generates these random pet computer names right and they're just they're resources that are stored purely in terraform state in memory and don't actually provision you know any you know cloud infrastructure ever because that's not what we're here to really look at today uh super basic uh random pet block with uh a couple of output animal names in like a trio account of three and then i'll also put in an expression and output terraform.workspace so we're using uh terraform just the local backend local state etc i already applied a couple of times and got everything set up so if i do a terraform workspace list you can see that i'm using three workspaces one is this default workspace and that's the unnamed default workspace that you would use as a terraform user if you basically don't use workspaces you always use a workspace but if you don't use the terraform workspace feature the workspace that you're using is a workspace called default right and you can uh continue to create new you know workspaces with terraform workspace new etc and that's what i did i have three workspaces default prod and staging so if i want to begin using uh this new integration in my cli with terraform cloud the very first thing uh i'll need to do is to log in i need to actually get an authentication token for my local cli uh to work with terraform cloud and i can do that via terraform login and what terraform login is going to do is it's going to prompt me to go ahead and open up my browser and it's going to be the wrong browser because of demo stuff and sorry chris i know it's all right i don't know that's good stuff i did i use firefox and the the uh screencast we're using doesn't like firefox really anyways this is the window that popped up uh i can create an api token i'll just name it as uh you know terraform login call that done and when i go back to my cli i can go ahead and enter in the token and log in and this is what it looks like cute little terraform logo and everything else you can see documentation you can get a little getting started guide do what you want i'm going to use the configuration that we already have up on the screen i've authenticated properly now what i'm going to go ahead and do is actually add that terraform cloud block so my configuration looks like this i have a main.tf on my left and i have just a separate terraform file that i'll use for a back end or terraform cloud again back ends are for storing state including the remote back end using terraform cloud is kind of mutually exclusive of back ends so you don't use a back end anymore you can just go ahead and configure terraform cloud directly and it is now a native integration a part of terraform that adds a bunch of stuff on top of it and isn't just kind of abstracted into its own little corner uh with a back end so now i go ahead and get started is by adding a block that looks like this it's cloud in the terraform settings block i can specify my terraform cloud organization um and the tags the workspace tags that i would like to associate with this particular configuration right so in terraform cloud workspaces are all owned by a particular organization and that's for like all of my infrastructure in my business right it's not a particular configuration with many workspaces it's an organization full of workspaces so in order to associate a subset of those organization workspaces to this configuration on my cli i can actually map using a workspace tags to say hey this configuration i'd like to run it with these workspaces in terraform cloud that's how this new integration works so um when i i can specify really whatever i want i can pretend that like this configuration that i'm moving from uh terraform local uh to terraform cloud maybe has something to do with networking so i'm gonna add the networking tag and maybe i wanna say like oh well this this configuration uh these workspaces i wanna say came from the cli so i'm just gonna use a little colon here and say hey source cli right with that block in place all i have to do is run terraform init and what it will do is it will initialize and if i have existing states like we do here i'll be guided through the process of how i can move from my local terraform to terraform cloud now one of the steps is when you're using terraform cloud you have to have an explicit name for your workspace and you'll notice from the very beginning we had this default unnamed workspace right well when you're moving over to cloud one of the things that you need to do is give that unnamed workspace a name it really doesn't matter uh what it is here for the demo i'll just call it test call it good and then move on next thing that i need to do and again all these steps are dependent on on what you what you had in the first place like if we didn't have a default workspace it wouldn't have asked me it only does the steps that i need to do to complete the migration over to cloud the next thing it's going to ask me to do is hey remember the thing that we just talked about where it's like the organization has all of the workspaces it's all of my infrastructure across my organization it's not just one configuration because of that the way that workspaces are typically done in terraform cloud is that they're named appropriately depending on like their component and their environment and their regions so like for this example with like networking maybe it's called networking prod us east for my networking infrastructure uh that i have in u.s east for the production environment well in order to make that transition or into using terraform cloud workspaces i might want to rename them basically so an easy way to do that instead of just going through one by one or whatever is by giving terraform cloud a pattern based on what the previous workspace was remember we had like prod and staging right well what is prod and staging in the larger grand scheme of things uh we'll say that this is uh networking with the existing workspace name so my workspace that it was before was just prod when we go to terraform cloud it'll now be networking prod and you can do whatever pattern you want you can do a prefix a suffix one in the middle anything like that does that make sense any questions there yeah all right we have we have we have like some other questions but we'll ask them at the end of the day that's good so when i enter value and a pattern a terraform will go out and do is create and migrate all of those existing workspaces and states to terraform cloud and this is what my workspaces now look like both in terraform cli and in terraform cloud if i go browse over to terraform cloud now you can see that these are the workspaces that we just had i actually showed you before those weren't there before they're now completely new workspaces with those states that i had in my local cli migrated over to cloud with their appropriate tags and whatnot so with that in place i can now do a terraform workspace list and i can see exactly what i had before except now i'm fully migrated so i can do it terraform workspace select you know oops no cannot complete that sorry uh let's see here list i can select whichever workspace i want let's just use the staging one that's already selected and now if i do a terraform apply let's do that quick just to get rid of that old state now if i do a terraform apply on that workspace we'll see that we'll get going here in terraform cloud so now the apply is running remotely in terraform cloud you can see this workspace will start churning here in a second and now i'm running remotely in terraform cloud so the process is running now on terraform cloud server from cloud adds a bunch of other features that we're not going to demo here like policy checking cost estimation all those different things and the uh results of that is streamed directly to my my local console right here and it's asking me whether or not i want to continue or not and they do so yeah that's the basic nutshell of moving from your local cli over to terraform cloud um if you got the next time i also show uh so for the remote backend users uh that have already been using the raw back end there's also a very special kind of streamlined migration path where instead of going through and like thinking about renaming workspaces or whatever we can actually streamline you forward uh two workspaces that you were before is that something we're interested in looking at oh yeah yeah yeah let's go for it um and actually before we do that even like let's talk a little bit more about the cloud block here like if you are a back end user while we're on the topic now you might think wow this this looks a lot like the remote back end right well that's intentional that's actually a very much an intentional design feature of this new integration is that we want to get all the benefits that we were just talking about previously on the on the broadcast here while not completely redoing everything and requiring such a hard migration over to this new native integration so it'll actually be very very familiar you can provide a host name just like the remote back end you can do all sorts of things that are very very similar the the part where things change beyond just new features and whatnot is like kind of a revamped user experience uh in the cli so let's pretend for example it's invalid to give a configuration that doesn't have workspaces like you need to be able to map your local and your terraform cloud workspaces appropriately right so if i do a terraform in it with that i get this kind of new revamped error message whereas before you'll probably get a message that's like oh the configuration is valid or oh the remote host responded error 500 or i don't know something very generic something that doesn't really help me a whole lot well the whole point of this integration is to give a more native terraform cloud experience in the cli and you can see that in the error message that we have right here saying that hey you need to tell me how to map my workspaces appropriately here are the different ways you can do it if you choose one this is what's going to happen all the different bit of user context that's much more rich and helpful uh to bring to a cli user so let's uh try out a i gotta kind of reset here uh existing remote back end use case so if i have a remote back-end block that looks like that i'm gonna kind of reset things here okay so uh using the remote back end let's take a look at my terraform cloud organization again the workspaces that we're going to be dealing with in this example are these ones right here billing prod billing staging right my back end configuration was using this thing called prefix which kind of overloads and obfuscates thing in the sense that it encodes my intentions of what the workspace is used for within the name it's very rigid it's kind of hard to deal with the tags you can already kind of see is a big improvement in the new cli integration but let's uh let's take a look so i initialized it saying i need to choose a workspace i'm going to choose that we're using the remote back end and you can already see kind of a difference between what we had before before using that encoding of name you can see i have prod and staging and in terraform cloud they're not called broaden staging they're called billing prod and billing staging because it uses that prefix but let's talk about the migration now so if i'm using the remote back end now i'm user that wants to move on to using the better native integration for terraform cloud how do i do that what does that look like well it really is as simple as getting rid of that block moving to this block which again is remarkably similar it's basically moving that that uh that block name over and then selecting a tag now for the tags you can use whatever you want of course uh but for this example you know we had billing prod billing staging maybe we'll just use a billing tag right so i'll go ahead and do that and then again as always when it comes to the state and workspaces in keraform all i have to do is terraform in it we'll start migrating and this one is different instead of overhead of like oh maybe you have to rename the default workspace maybe you need to provide a pattern or whatever you know you you may have been using terraform cloud before you might have already been using workspace and the workspaces are fully delimited already in terraform cloud so we don't need to like redo that stuff well terraform is smart enough to see that and actually acknowledge that like hey you were using prefix before we we can tell that you were using that so like do you just want to you know make everything right again well yes yes i do i would i would like everything to just work and just kind of be done with it so i'll just say yes and sure enough it exactly migrates over to what it actually is in terraform cloud now building prod building staging i can uh you know do a terraform apply beyond my merry way with the cloud integration instead of uh remote backend whoa yeah yeah it's nice you don't have to worry about like moving things over it's really i mean that was really a big a big design staple uh over the last year is figuring out like okay well we want to make these really big improvements but we don't want to make it overbearing for people to be able to migrate from one to the other right and that i think is a a very good outcome for that uh for that sort of migration so um now we've talked a lot about migrating we've talked a lot about like moving states over whatever let's just spend a couple more minutes talking about more of like the we talked about the ux as well let's talk more about like enhancements like what did we actually fix what did we actually like you know add to it uh i'll mention two things uh one is simply just that terraform dot workspace works right like this if you're if you're a user of the remote back end you might have experienced this for years now where like there's these weird edges where um in this case the default workspace would always be used regardless right you're literally in the documentation that says like you can't use terraform.workspace the interpolation anymore because it just doesn't line up we'll eventually fix it whatever well that was in 2018. 2021 now we're here we did the thing the new cloud integration actually lines that up such that uh it is exactly what you uh would expect which i won't bother demoing here for time uh so that's nice and the other cool thing about that is that because terraform cloud itself uses the integration that we're that we're talking about here this is solved across all of the different workflows so like you don't need to be using cli necessarily uh to get this benefit if you're using like the vcs workflow or whatever this is also fixed in all the different workflows so that's just kind of a nice a nice little edge that's kind of always bothered people for a long time the one thing that we will show um another kind of asked for feature uh over the years has been uh input variables right so um before when you initialize the remote back end and you got started with a configuration let's just go ahead and change something here let's um change the the length the number of random pets uh to a variable let's say r dot pet count go up here and we'll say variable out and oh yeah oh [Music] um before if you ran terraform apply which again we won't bother doing here um you would be presented with an error that uh the variable was not found and the reason for that is uh all of your variables when you moved on to terraform cloud were stored in the workspace itself so you need to go into the workspace into the web ui here and actually configure the variables before you could even get started this was kind of cumbersome and the reason for this and just for fun let's just do and apply to kind of show that off the reason for this um is because it's tough to iterate like imagine like working on the terraform configuration and not being able to just like change the count to be able to to try uh there it is there's no value for it right i don't have it in my terrapin cloud workspace the inability to be able to try things out to like oh what happens if i change this value then what does the plan look like etcetera really tough to do that sort of thing um so now basically uh variables just work you can use an input variable and say like i would like to apply with var equals and i need to escape in my console here pet count equal to we'll say four no that was right no no i did the thing what'd i do oh oh let's save this let's try that uh oh no i think it's to do with my my escaping of my uh of my terminal unfortunately sorry about that oh good it wouldn't be a demo if there wasn't a leak definitely always hey i can escape things on my local terminal correctly look at me go now i did the right thing so now we're uh we're uh we just changed the countdown uh via an input variable so all sorts of little small things like that um yeah i think i think that's uh there's a lot more enhancements there's a lot more a couple other things but uh you know we've talked about it enough so uh yeah that's the terraform cloud integration in terraform 101. nice nice i know like when people would bring up working with terraform cloud for whatever reason there were so many other big things but the input variables was always like the one people would like to be lined to immediately like i can't do that now that's in here um so do those those show up in terraform cloud if you set them from the cli as well right they so the persisted variables in a terraform cloud workspace are there and managed within terraform cloud because there might be values that like you want to keep secret or are sensitive or whatever persisted in the terraform cloud workspace but the input variables or rather the values not even so much the variables uh from the cli kind of allow more of like an iterative like try things out and maybe maybe in the end i would like to then go and actually add that permanently into my terraform cloud workspace nice nice nice so uh as we went through the demo there's a lot of stuff there yeah i wanted to toss the the mic over to brian there any things going through there that you're like i want to highlight this in you know from your perspective from provider perspective from practitioner perspective yeah i think for me just the that kind of like stepping through and getting the ability to on board with terraform cloud or even migrate to terraform cloud i it just felt it feels more natural and the parts where it might be confusing or a little less confusing because so much of it is just asking you directly and providing a bunch of context about why it's asking you these questions um for example like chris explained hopefully pretty well i i thought like you know the differences between workspaces that are local and there's like no name spacing or anything going on and then oh but you if you're doing it up in terraform cloud it's like fully name-spaced and all these good things going on so i think that the ability in there to have all those questions that are being asked and also that really nice thing of like being able to do suffix prefix whatever in there is like super cool i think that'll be very helpful for people yeah when chris when you showed the the uh the moving from migrating i was like this is going to be a nightmare nope i was like oh wow the amount of cold sweat you are saving the world [Laughter] yeah now the uh yeah i mean of all the of all the things just the the simple um clarification of what it is you're doing like before it's like what is what is a remote back end why is a remote back and so different from all the other back ends like i'm used to using the s3 back end but like this other back end does completely different stuff and i don't know why like there's just a lot of kind of weird confusing edges there that i'm glad we were able to smooth out and and the the user experience part of it that brian touched on of just having context and being you know told like all right this might be a problem like this is why etc is just a really big a big improvement i think yeah i think just the the fact that like oh terraform might not be the only thing people are looking at today or you know in their normal work day-to-day workflows uh you know and having like that terminology explained as you go along i think is extremely helpful nice nice now last thing i wanted to touch on before we move move forward obviously we've we've got these bigger features we're going to spend some time on and then the last last three we'll kind of go through them but um corinne something that for for me as a practitioner at least three four years ago that i'd love you to elaborate on was like y'all asked me to get on terraform cloud and it takes like the setup time for me to get going from where the productivity wasn't exactly there and if i'm trying something new if you know i'm used to open source i'm used to free stuff it's going to take me like all day i'm not going to necessarily do it so what impact does this have on like the time for you as a new practitioner or someone who's not on terraform cloud getting onto it yeah that's a good question i mean that was that was pretty much when we even started this project uh no matter what we knew that the setup time had to be shortened like we wanted to like map out the number of steps it took to sign up for terrapin cloud that had to be shrunk by x amount of steps as well as like the migration path like that was the absolute bare minimum was the migration path had to be the easiest thing that was possible and the most intuitive so ideally you wouldn't need to look up docs or something you could just walk through the steps um and that's why you know tara from cloud came out uh as a product was really we wanted to make the easiest and most effective way to use terraform at any scale so even as an individual or a team or a large business so i i think it has a huge huge impact but we're always open to more feedback about how we can make it easier to go and sign up for tara from cloud or use it at any stage in any familiarity you are with terraform speaking of which if people have feedback definitely reach out to me on linkedin or twitter or sometimes i'm on the subreddit as well and i'm always happy to chat with anybody um yeah nice nice all right so before we move into the next feature i did want to zip through some questions here and just to note for those of you tuning in later since this will be up on youtube we will have markers underneath so you can go between features of interest so first one uh uh dj opezius i'm probably botching that username um you asked a question about troubleshooting and debugging variables we actually when we get to the uh type function and the terafrom console command feature at the end we'll actually address that then but i just wanted you to know that we we did see it um the next thing uh chris what ide are you using that was something that dj curry synth wanted to know ide oh i i just use film i i use uh i use vim and um lots of lots of goodies in it i'm one of those uh vim users that actually isn't afraid to like move in and just add whatever whatever package or whatever cool thing uh gives me kind of an ide like experience so yeah nice are you on just vanilla vim or are you using like neovim or neovim neo yeah yeah there we go sweet so there's your answer and then the next one's a little bit more general and it was just around clarity for the terraform workspace command in context of terraform enterprise and terraform cloud and then just other back-ends if if same deal if if you can elaborate more please do but if not could uh any of you who want to take that just maybe give us sort of a a quick bit on what the terraform workspaces are for right the general idea of them and then their usage with terraform enterprise and cloud and then other backends sure i can start with that if we want to do that um yeah so terraform uh workspaces just in open source and cli um are basically nothing more than a state file rename that's all they really are there's nothing anything more complicated than that so when you do a terraform workspace new you're basically just instructing terraform hey when you make the next plan or do the next apply i want you to use this state file instead of that state file and the original use case for that was basically uh creating different uh deployment environments depending on what i showed in the demo there you can have like uh this is my staging infrastructure this is my production infrastructure etc that's all fine and dandy but what terraform cloud does when you move over to using the platform is uh workspaces are now an entire collection of infrastructure kind of with their own working directory [Music] and uh have their own run context basically they're basically their own their own set in terraform clouds adds a whole bunch of stuff on top of that in terms of like persisted input variables uh their own their own state just like oss does policy checking all it's basically the main building block of how you manage multiple configurations and multiple infrastructures in a terraform cloud organization hopefully that answers uh the question there you have it i thought that was that was pretty good if if uh if that wasn't enough just put it in the chat and we'll we'll bring it up again later the other quick question here is just do we have sentinel policies for managing workspaces creation uh on terraform enterprise you do in the form so like if you were to provision there actually is and my team maintains a terraform cloud terraform provider so you can actually provision terraform cloud with terraform itself a lot of people have used like these kind of meta bootstrapping workspaces to be able to provision in terraform cloud with terraform cloud and as part of that main terraform plan apply workflow you can add sentinel policy checking and basically get exactly that like if you're creating new workspaces using this provider using terraform you can validate certain conditions and whatnot uh in sentinel policy checking yeah perfect that was on point all right it looks like that's all the questions we've got for now so let's go ahead and move on to the next really big feature and that is the big change around terraform state move right and i know that this has a lot to do currently especially the the demos and the ideas around around modules which are as you grow your infrastructure's code or something you wind up having to get into and of course if you leverage the ones that we have both are verified ones the ones that come from our partners and community ones that can speed up speed things up for you but if you're creating them it can run into some snafu's that maybe aren't so pleasant so corrine could you uh give us give us the history of this year so like the problem the problem was addressing and then uh take us into uh the feature in general sure thing okay uh to set up basically prior to this release how people would go ahead and refactor their terrapin configurations you basically as as cole mentioned you would need to use terraform state moves via the cli and this presented a lot of different problems and uh i guess like to take a step back really quick i'm assuming many people know why refactoring is necessary but in case you don't um oftentimes when you're building out your infrastructure and it gets more complex and it just gets larger in general you're going to have a very large carbon configuration and you're going to at some point need to move things around to make it easier to make changes uh and just understand exactly what you're creating however uh terraform state the the file itself basically is constantly reconciling what you have in your configuration versus what is out in the real world and sometimes when you're moving things around you want to make sure that you're not actually just destroying and recreating infrastructure obviously because you don't want to take down a critical database or just in general like downtime is not something that you want to do for refactoring purposes uh so we were investigating ways that we can make refactoring easier and we we talked about earlier in the session about making things as much as part of the plan and apply process as possible and this is part of that initiative so how could we make things part of the core terraform plan and apply workflow and so we introduced this new mechanism called move statements and the main things we were looking at in terms of solving pain points were the the three big pain points for our different types of users mainly um just if you're a regular terraform practitioner just someone who's managing infrastructure like a smaller team or just yourself uh basically if you if you're able to do and touch state from the cli that's not something that is super comfortable you don't necessarily always want to touch state and you would need to coordinate a bunch of changes like multiple chain commands via the cli as well as updating your configuration and then if an error arises uh godspeed and trying to figure out exactly where that problem happened is really really difficult and oftentimes you're just trying to make your life easier so uh that wasn't working so the next big pain point we were tackling was for um like module developers and of shared modules as i mentioned earlier if you wanted to go ahead and say okay i refactored a module i want to go ahead and release it out to the the public or to the people that want to go ahead and use this um to do that you would need to go ahead and release a new major version say i have a breaking change and then also deliver uh a bunch of uh basically instructions to the end user like okay now you need to update state and this is the this is the way that you need to do it which again uh extremely manual very error prone not something you want to mess with and then lastly our tara from cloud and enterprise users um oftentimes can only really do anything that is part of the plan operation so refactoring is not something that a lot of people would have access to and if they did so let's say you had admin access on a workspace you would go ahead switch to local do out-of-band changes to refactor and then go ahead and just hope that nothing bad happens and so we really wanted to have a way that across those three personas or three different users you have a way to just refactor more easily and make sure that nothing breaks as that is what our entire jobs are really about getting to the market faster and as well as making sure that things work and aren't down uh so introducing our refactoring mechanism with moved statements these move statements um we'll show in the demo but basically it's just basically say moved from this resource to this resource and you can use it to go ahead and say i'm going to rename a module call i'm going to rename a resource or i'm going to enable account for a module call or resource or split one large module into multiples and this could be uh shared modules that could be splitting into like multiple different individual modules it's a really neat feature and also gives you just kind of this historical context of like where things have moved and then when you go ahead and say tara from plan it will combine all those state updates as well as uh to match your configuration so you don't need to touch state at all and it's part of that whole plan process so you can go ahead and say i know what's going to happen i can validate that that's exactly what i want to do i can apply it and that way all of those people that we talked about that had not ideal workflows that was a bit more manual they can just do this all in one simultaneous step how is that nice yeah yeah i know like for i came from software development and you get used to fast just break it break it break it but once that starts going up that doesn't that's not as fun right so uh we're gonna have a demo here from from brian he's gonna show us how we can avoid the sino evil hear no evil concept hoping things don't uh break uh before we do that chris did you have any any things you want to point out about this before we uh hop back into code um i think another thing i'd just you know touch on is just that like it can't be understated just how awesome it is to bring this stuff into the primary terraform workflow like terraform is all about making an execution plan and applying it and kind of anything that you have to do beyond that that you've had to do in the past like do a state move manually you know munching state and whatnot it's so cool to see that uh you know configuration driven in the primary workflow and it kind of plays into uh what we've been doing with terraform over the last year even before this release so if you're familiar with like 1.0 and what we introduced there we introduce things like replace and refresh only plants the ability to be able to tell terraform i have these intentions that i want uh to be part of an execution plan not just done off on the side willy-nilly in my console but as part of an execution plan this is on that same theme of trying to incorporate the workflows that are required in terraform in that primary workflow nice and now drumroll pass it to brian who's going to show us the way uh i will i guess show the way you know this is the way it is i guess the mandalarian folks put it uh so yeah so what we're going to show off here is i'm going to work through a few iterations here um in general uh what we'll probably refer to this in in general as is just refactoring right we have an existing uh terraform configuration in this case i'll actually go through the whole workflow of starting it up and applying an initial state and then uh you know doing things later on to change and update that state and show off the features here but yeah like the the really neat thing is is that uh you know again kind of anybody who is working on these configurations or even outside the configurations if you're using like you know your github repositories and these sorts of things can propose these refactorings and they'll just be kind of baked in um to the existing workflows so there's no magic permissions needed to suggest these refactorings uh a little bit going forward it's just kind of baked in so super excited again to be showing this off um you know for for this initial demo here uh you can see uh i'm using vs code for the record uh you can see here that uh you know i'm just using the random provider again and in this case our lovely friend the random pet um and here uh you know this this resource uh throughout these demos with like moving things around and making sure that you know nothing is changing that's that's the real important thing to note here is that like as we go through these refactorings we don't want our pet to change we don't want our database to change we don't want our dns records to change uh the idea here being that we're refactoring our configuration to maybe align it more with our team best practices or organization best practices or moving things around just so they make more sense for folks looking at these configurations so as always you know this is this is a configuration that uh is brand new here so you can just see this going uh and we're gonna go ahead and apply it so terraform here is gonna tell us that hey yeah we're gonna create a random pet and we don't know what it is yet so please go ahead and give us we got an awake ostrich that's very exciting i hope everybody's had their coffee because this ostrich is going for it okay so with that okay great we have this ostrich uh what are we gonna do with it uh i don't like this start name for example so we you know starts cool and all but like i don't know let's just call it updated not kind of a boring name but let's just go with it anyway um so what's going to happen here is if i run terraform plan again or you know i can run terraform apply and it'll ask me first you'll see that uh hey wait a minute i refreshed it there's no remote state to refresh so okay great like that was quick um but hey we're going to destroy our poor awake ostrich and recreate a new one that we don't even know what it is yet oh that's scary uh i don't want that so i'm gonna tell terraform now please don't do that that's that's not what we want here so um you know what would we do in this scenario normally in the previous versions of terraform is we'd run this terraform state move and we'd give it the old resource address and the new resource address in the state um you know in this case this is a fairly trivial example uh you know it's just a root resource in the root module with like no extra accounts or forages so nothing special there so we're gonna do that okay now what happens if i ask terraform to plan it okay great hey that was awesome like i didn't have to do anything i was able to refactor my configuration woohoo you know except for all the problems we mentioned before where it was like oh there might be multiple people working on this or there might be multiple changes in flight and coordinating these sorts of activities or having people with the right permissions to apply this sort of change uh can really be kind of you know burdensome to you know a lot of folks so and plus yeah this is air prone i you know you have to go in there and make sure that you're typing in like the correct things like if i just run this again i think it should yeah like it's like a very slow process to get like feedback on these sorts of things um and you have to remember that oh yeah there's that random state move command what is that okay so great now that we have our awesome infrastructure okay let's let's show off what what's what's going on here what is what is all this hubbub about here you know we're talking about these move blocks we're talking about things let's just say i want to make uh let's just call this final and yeah let me actually do that so okay great you know we got this going on now ta-da let's introduce this move configuration block so what we're telling terraform here to do is we had updated as the old name that was originally in there and that's now in this from address and we're gonna rename it to final sure sorry for boring naming here but this will work uh you know we're gonna send that to the two and here that's the random pet that is gonna be final uh hopefully so what's gonna happen now let's see terraform bye all right so we refresh it just like before oh but hey look at this terraform is saying i'm gonna i'm gonna perform this action of moving this for you there's no other magic here there's no other things happening um this could be intermixed with all kinds of other changes so it's not like oh this needs to be explicitly done by itself or anything uh this is just part of a normal plan or apply so we could be creating destroying resources or doing other things just like any other terraform plan so if we say yes hey look our awake ostrich is still here that's wonderful we'd like to see that because we like having that thing around i guess um so that's that that's it basically in a very quick nutshell now we can talk about more advanced scenarios uh because this is where it gets really fun and interesting um so we're gonna move over to our little module here okay so we're gonna start off with a similar setup you know we have a starting pet you know in a root module we can go ahead and just emit this that's great and if we apply this wonderful okay so we're going to create it let's see what animal we get today we're going to know oh we got alive again we got a lively bunch of animals here today very exciting but it's a lionfish this time so that's very exciting okay so great i have this like terraform configuration it's been applied it's been running in production for forever uh you know this lionfish is gonna live for many years uh but hey my team came along and said hey this is like really complicated or like i wanna like put this in a terraform module for example so um let's just say you go ahead and do that right oh maybe i'm gonna create like what we'll just refer to as a pet module here uh and you'll notice it looks almost exactly the same because this is a trivial example but hopefully the idea here makes sense is that okay we can move this over to a module and this configuration can be self-contained it can be shared with other things etc this might not even be local to this uh terraform you know uh configuration it might be some shared you know vcs version control module great so um with that what would we do in this scenario and luckily i have copy pasted myself here to save some time here so what's gonna happen here we want to move from this root thing that is the random pet that lives at the root module and we want to move over to this pet module that we've created so um first things first we don't want this here anymore we're going to comment that out we don't want that pet there we are going to say hey here's module let's talk to that pet module that's you know over here great we can introduce our move block so we're going from this random pet that was named root to this module which i named first and you'll see why in a second uh random pep which is great and you know all we need to do here is make sure that our output is correct so we're going to point back to the output of this module right here which is called name so that's why you see that right there all right so without further ado we are going to terraform apply this and look at this so terraform is already saying hey we are going to move this into that module so nothing special here uh same thing it worked just like before whether you know it was two resources uh at the same root level but now also hey we can move root to module module root etc and we can apply that and we still have our alive very alive and well lionfish here uh ready to go so that's great but hey i really this lionfish has been around for a while now i want to say it's my favorite so like really like i i really why what was i thinking a few years ago i called this first let's let's call it favorite so what we can do here is actually take what was the old address because it used to be called the first module in here uh and let's call it favorite now because this is my favorite pet um we just fix all the references save that and if we apply this terraform yet again we'll do what we're expecting here we can move things we can rename modules we can do whatever we need to do now now comes the interesting one let's say we have our favorite pet here but like oh i don't know i created this module and this just isn't really doing it for me what if i wanted to be that right all right let's just go with that so normally when you do this hey yeah like this might be a public terraform module that was created written somewhere else not in you know managed by you or anything um oh yikes uh i'm gonna have to send instructions to people make sure they keep their line fishes alive uh this is gonna be bad so why don't we make it not bad and actually perform the move in here and i'm gonna just be lazy and copy paste this again so we're just going to rename our random pet from this to that and this is within the module so there's we're not applying this level we're actually applying up up at this level where you know we've defined a favorite thing uh i don't know what's going on um that's awesome though so let's see if terraform will allow us as a module author for example to go move these things and look at that uh so you know terraform is suggesting just as you would expect uh i can move from this to that within the module so like as a module author i could have gone in and done this refactoring and this can live live on so let me let me go ahead and apply this now something very interesting with uh the moved configuration blocks is as especially as module offers for example now that this move is done this move block can stay there but it doesn't have to so something very fun to do is hey if this is a configuration that i just owned like it is here for example i i can go in here and remove this configuration block and terraform is not going to do anything it's not going to be any any different than it was before so for public module authors for example this is great basically for all the changes and refactorings that you want to happen uh you can keep these move statements uh around but let's say in the next major version you want to tell folks hey upgrade to version one then version two the version three so i can clean up my code uh then you can have this sort of workflow for that major release oh i got rid of the move blocks out of my code it's no longer quote unquote cluttering it up and terraform will do the right thing um another interesting fact with these uh move blocks is that in you know i don't have a demo here to show uh but if we do have time i could do a do it live and that could be very exciting uh you should be able to chain these together as well so if i had multiple refactorings that happened over time i might have a from address that points to a two address and then another move block that points to that two address of that previous move block and changes it to another address in the state so theoretically all that should just work as you would expect where you can just go down you know turtles all the way down here and just keep chaining these things together like a chain shop or something so um great so this is awesome i you know i'm kind of showing this off uh you know locally here uh it does work with terraform cloud for example um again we're i'm not doing anything too special here i am using this fancy new cloud block because it's awesome and you should use it too uh but yeah like you know same thing here uh there's nothing special if i if i go and knit my cloud-based thing okay great i'm gonna terraform apply that we're gonna wreak out the terraform cloud we're gonna go run this so waiting for the plan to start doing things gotta love that live streaming output i love that about terraform club too by the way um so great so like hey it's asking us do we want to create a random pet any guesses for what names we're going to get let's see we're going to tell tell terraform yes we will be awake or alive we got an absolute panther this time all right um but again you know there's no magic here uh this is in terraform cloud it doesn't matter i can go in here i can you know change this to new change this to new do this terraform apply that yeah man that's so cool you're right about the whole chaining thing i'm just imagining like as a module author if you if you need to like uh you know do multiple moves or whatever and you have someone that's updating that module more than one i mean maybe it's not a good idea of course but like more than one breaking change ahead or whatever instead of like the right combination of state move commands the ability to be able to just fast forward via all of those uh move statements is pretty awesome yeah yeah it's it's super cool to see it in action i you know hopefully folks will really love this because it's it's super helpful to kind of jump out of that like special workflow and get into the plan apply workflow and hey our panthers sticking around here it's the new thing uh and i think that's all i had to demo for this so uh please ask questions uh happy to answer things very exciting yeah that all looked great ryan thank you so much for sharing that it's uh gives it paints a way forward to do these bigger refactors which is always helpful because you know we're usually trying to think about what we're trying to go as opposed to the implementation of getting the specific thing done so it's nice to see that we have a clear way to get there nice so we do have some questions a good number of questions um but before we do that you know uh corinne or chris were there any things that you that you wanted to point out as we went that you think we're good to highlight honestly no brian you did a great great demo covered all the important bits and pieces uh i i did see a question pop in there about uh count you know for for each was the question uh this absolutely works with count and 4-h as well so i didn't demo it here but you can take for example a resource that maybe has a bunch of account and convert it to for each or convert it to uh those sorts of things where oh i want to move these to different modules and that sort of thing as well so definitely want to call that out as well that count for reacher in there yeah yeah thank you thank you that was one of the questions so nice um so like since we're on those questions why don't we go ahead and answer some of the the other ones so the next question was can i move this resource uh between can i can i move resources between provider so can you you can see the question right there in the uh the chat right ah yes uh that is a great question so the current terraform 1.1 abilities is for moving with the same resource type so for example i can move an aws vpc to an awsvpc or a random pet to a random pet you know the idea is hopefully in the future that there will be some abilities there uh i can't go yeah uh yeah so hey anton um feel free to reach out we can talk more about like specific use cases you can also open up a github issue about like what things that are out of scope for this specific release but you'd like to see in the future and uh we're really really excited about this and especially since a lot of uh our users are constantly needing to refactor their terraform configurations um it's something that we're going to continuously invest in so while we don't have i can't like recommend the dates right now it's something that we're looking into nice nice nice so our next question then is will the moved block be back ported to the 0.13 version i know that this will this answer may not be straightforward but let's uh let's give it a good old try here uh i can't i can't um really give any commitments quite yet we're just really celebrating the 1.1 release that just came out but i'd be really happy to follow up with you about plans on that one nice nice nice yeah that's always the thing uh if if there's not necessarily something that we have on hand right now we're always willing to hop on and have a conversation at the very least put that on our radar right so and then the last question are there plans automatically generate move blocks based off based on a diff with previous runs oh that's interesting yeah i was looking at that one that one it does seem very interesting i'd love anton again if you want to reach out and talk more would love to i think there's a lot of questions to be had in there around like uh user intention right the ability to be able to to figure out user intent from one previous state to another is definitely a tricky and interesting problem so um you know if that uh can be solved that would be awesome but there's a lot of complexity in there to kind of unravel so i'm eager to ponder that one thank you thank you for the answers and uh that's great because i know towards the end we're gonna talk about the future we're gonna say what would people like to see and here we're already seeing some of it so great okay so those were our two uh or two bigger features we've got some smaller quality of life ones among other things that are not i don't want to call them small because their mind means small but they'll just take less time for us to go into so for time why don't we go ahead and move into that third feature we've got some changes to plan and apply as brian and karen have said we're trying to move towards making plan and apply everything happen around this so corrine could you give us uh some uh some of the uh insight and everything in the general overview of what's changed to those two big commands uh sorry one more time i was just looking yeah yeah it's the fun part of live streaming right we've got to have multiple conversations uh then we've got some we've got some bigger changes happening so multiple changes happening to plan and apply i know that uh brian's gonna take us through a demo uh zoomed in on the destroy thing but what since there are so many changes happening in the planet apply what is the goal here uh for these changes in 1.1 to those two commands i'm actually probably going to toss it over to brian i think that he would have a lot more information than i would at this point so off to you sounds good yeah so uh something uh kind of fun that got introduced into terraform 1.1 was uh you know how can we augment some of the terraform plan output when infrastructure is being destroyed one of the questions that gets asked a lot um especially with like larger configurations or complex configuration is oh what what actually caused this destroy of a resource to occur and it might be an instance of something if it's a calendar for each type thing but like what what physically caused this resource to be proposed as being removed for example and again this kind of boils into a little bit of like the refactoring uh work that people might be doing um but you know destroying infrastructure is scary so it's uh when we have the ability to kind of explain things a little bit clearer i think that's helpful for everybody to make it a little less scary and hopefully make a debug if it's necessary to debug a situation um a little bit easier in that sense perfect yeah yeah the more yeah destroying stuff you've always got that like the sweat meme like all right and especially when you go and something pops up and you're like whoa whoa whoa whoa whoa what why where why is that going what's going on yeah so you've got a demo for us here i believe right yeah all right yeah so hey uh you know we're we're gonna we're gonna follow up with more pets here because we love our pets uh but let's go ahead and get this started so i'm to start again from clean slate here and these demos will be much quicker than the last two so don't be alarmed as they go a little bit quicker here so uh in this configuration uh we have a random pet that doesn't have any counter for each or anything um we have a counted uh random pet uh so we're going to create two there and a four each one uh lovely names just first and second within that four each there so uh terraform's gonna propose to add five because it's one plus two plus two that looks great let's go ahead and see what animals we have we have an included cat i hope halibut oh that's fun a smooth manatee uh proven bobcat and an ethical wound all right so um what is what is what is all this annotation stuff our destroy enhancements that we're talking about uh so if i make this change here let's say i remove a resource from the configuration completely what happens normally terraform in previous versions would just say oh hey i'm just destroying this but if we run this we can actually see because removed is not in the configuration anymore that's pretty nice wow okay now i know exactly why that's occurring rather than just the fact that it's occurring so if we go ahead and apply that sorry sorry you held it didn't mean to uh that's great um so you know oh counts great and we're gonna decrease it by one see what happens and in this case oh look now it's telling us uh because the index was out of range hey it used to be two now it's one that that number one index because it's zero based uh is removed so very exciting um sorry animals poor manatee and finally uh you know same sort of thing with for each it's gonna hopefully give us a little bit clearer answer here uh because the key second there is no longer in the for each map so if you can imagine if you have a bunch of modules and a bunch of complicated things going into configuration it may be completely unclear to you why something is occurring especially when it's destroying so the hope here is that having those extra little um you know annotations in there can really help uh debug these sorts of things and make it less scary yeah absolutely that that uh just those little things just you know the little signals here and there make the process more just it adds to the smoothness of the entire thing more the better um thank you was uh there any other things around that you that created chris or friend you wanted to highlight it's pretty straightforward yeah that's awesome i didn't actually know about this feature so that's so cool it is so cool like the the context again like the the the introspection into like why terraform did a thing like what the intentions are uh is really really cool to be able to see as an end user absolutely and uh so far our one question is do we know how many unique pets there are in the random pet resource that is a great question i actually do not know the answer to that off the top of my head but i'm very curious i i don't actually know but there is an rfc for it like there's a there's a ieee like rfc from some yesteryear that it's based off of so you can actually go read the rfc if you really want to you know dig into that that's amazing that reminds me of like the carrier pigeon protocol that exists as an rfc as well you know just in case you need avian care carriers for your packets they got you covered nice well moving right along that was the only questions we had around that uh why don't we go ahead and step into the next feature on our plate here and that was nullable variables so brian since you're going to be doing the demo as well if you would like to to kick us off with some information around it some context uh and of course corrine chris please feel free to jump in and point anything out if it's needed yeah so happy to happy to jump into this one pretty quickly uh this is an interesting case uh where um previously in terraform configurations um and because it kind of existed when terraform 1.0 was released this kind of default behavior kind of has to stick around for a bit but essentially what can happen you can sort of see in this configuration here is that um basically there might be situations where modules might get passed in a null input for example and what would happen in this situation in previous versions of terraform is that this would actually overwrite any sort of default value basically you couldn't convince terraform to give you the module default value for that variable if you pass didn't know it would actually forcibly just pass null through uh so uh in certain a lot of situations actually that can be kind of undesirable because it seems a little bit different than the rest of how like terraform configurations work in general so if you have like a resource and you're you have an uh argument that may or may not be like optionally turned on for example um you would just put null in there and then it would do what you would hopefully expect in that case of like oh if i get to that null case i'm just not going to include this argument at all um but in this case uh this previous versions of terraform this would actually pass this null in so that kind of difference in behavior was kind of the impetus for adding this ability within variables to say they are nullable and you can say whether they can or can't be nullable and you can still keep your defaults or not keep defaults depending on your use case uh so um does any do you have any folks have any questions before i just like dive into this not i all right sounds good let's do it uh so in this case um i'll show off what all the code that's involved here it's very complicated uh is just a we have a terraform module that's local here uh and it has a variable called in it has a default value that is default value is a string um and we have an out that is the output so from our root module here or some other module calling this module um you know we're gonna call into this example module and we're gonna pass in null uh so that's gonna be interesting so this this is the current behavior of all terraform versions even including 1.1 i i wanted to make that clear is that that this behavior is not actually changing and what's interesting here is i i told it explicitly um i want this example output from this this module here to be the out output of this module over here huh that's interesting that's not what i expected i expected default value to be passed through basically so what can we do in this scenario uh in terraform 1.1 there's this new nullable argument that you can pass into variables so if i set this and there's a whole documentation page on it that goes through the different scenarios and what it'll do but in this case i basically want to say uh yeah basically i want my null to actually be respected here i'm not passing it in so hopefully if i talked about it correctly and explained it correctly uh you can actually see it here yes so here now as soon as i put that in now it's actually respecting that default value that existed inside the module so again this is like one of those scenarios where you might be working with multiple modules and trying to conditionally turn on and off things and it can be very confusing to all of a sudden like not have something not show up as an input into a module so that's where that's where this is coming from and the cool thing here is that um you can also kind of get rid of this default and fun doing this correctly excellent so essentially we can have it so oh there's no default and you technically didn't pass it anything here you this is null this is pretending like that line doesn't exist in the configuration now now terraform will give you an error so really cool stuff and again you can use default and nullable with true you can use this nullable with true or false depending on your situation but essentially yeah it's basically just a much more flexible way to and much more consistent way to work with nulls that are getting passed through to resources or modules excuse me nice nice yeah it seems like something too that uh you know as you're going if you're moving quickly you can just fly under the radar and then you just look up and you're like whoa where where where'd everything go where the value go so yeah so was there more to the to the wonderful demo here brian because that was that was no no again uh these last ones are nice and easy so yeah yeah yeah yeah so we do have a question for you here uh if a user wants to use null as an input value even if the module has nullable so what if so what happens in this case if a user really wants to use yeah so the documentation should go through all the different scenarios that's possible here it depends on whether you have default set or not basically but it is possible to say true in here for example and i think what it should do is that there will be no output from the root module if i remember correctly yeah so there you go it's going from that default value and i since we got rid of it from the variable uh now it's saying there's not going to be any value there so it should be doing what you'd kind of expect there as well nice nice nice and then a follow up passing null through the terraform cli i am not positive if that's possible today but uh definitely make sure there is a issue open on the terraform cli repo if it's not possible today sweet sweet and for anyone else watching you know if you have questions answer them even if even if the things aren't there it the only way we're going to know about these things to improve going forward is if y'all bring them up so any feedback you have is always appreciated okay so awesome so nullable variables doing what you would expect especially when you're uh going through modules thank you so much brian and unfortunately i'm gonna have to call upon your demo superpowers again because we got one more feature smaller that is gonna answer a question we had earlier about uh let me go back and find it here just debugging and troubleshooting variables uh so for example to get the values of variables through multiple modules and so this is going to come on to uh the terraform console command so would you like to kick it off here yeah absolutely so yeah in general um when we talk about debugging kind of terraform configurations uh the way that is possible uh today there's kind of two main ways i guess that are possible the the quick one is oh uh you can use outputs for example to kind of oh i want to grab this value and just kind of output it somewhere on the cli just to make it visible that's like a quick and easy way to do something um the other way uh that is possible is with terraform console uh the terraform console command to be specific um and the terraform console command basically if you have a terraform state that exists you can uh call call in the terraform console and you can ask it questions about that state uh so inside of that terraform console which we'll show in a little bit uh it's kind of like a input you know it's like a shell almost uh so basically you give it a quick command whether that be a function say for example i want to run the lookup function on some variable or local without actually modifying my configuration or anything okay yeah you can you can kind of pass that along in there and it'll give you the output of what was going on inside of there just as if you were doing it via configuration um so yeah i i hope that uh sort of gives a little bit of insight into like the 10 000 foot view of uh debugging um you know complex types and variables and things uh uh the feature here in 1.1 is that a type uh type function was added to the terraform console command and basically um when you're working in certain scenarios with very complex configurations or complex uh conditionals sometimes terraform might show some interesting errors uh that you might not expect oh i passed in this this list that looks exactly like this other list on the side of a conditional but terraform's saying it's not and how you would have to debug that before is kind of what was describing where you'd have to go in the terraform console maybe output the you know value itself to try to see if it's kind of obvious what's different there but what this function is then now allowing folks who are doing this kind of advanced troubleshooting to do is actually take a look at the types that terraform internally is seeing so whether that be strings tuples maps uh list sets etc so uh let me dive into that again this will be super this one actually i think is probably the quickest here um so let's go here okay so we have a configuration uh just to keep this very very simple it's a variable with a default value um it looks like a list it's a tuple technically and you'll see that in a second um and then we have this other local here that's another example it's a little bit more complicated looking ooh that looks kind of scary um but hey we want to output uh you know something from either of these two if basically if our original variable was like an empty tuple empty list as it looks like um you know we wanted to output that otherwise we want to output this other thing great so what the heck is going to happen when i run this i run terraform a fly it is gonna say uh the two sides of my conditional don't actually line up and that's a little confusing uh i i don't know i see these you know brackets here that's exciting uh there's brackets here what's going on so if we take a look at terraform console here um it'll give us the same warning just because you know there's actually an error in the configuration but uh it should allow us to do in here is basically i guess yeah we can use this new type function to go say hey oh what is that var uh variable thing it's a tuple with a string in it and we can do the same thing with uh the other one as well and hopefully you know this is just another kind of advanced troubleshooting technique that can be helpful uh where it's like oh i need to get these two things to look exactly alike so terraform is a little bit happier uh how do what do i need to change to make them look exactly the same so in this case you could say oh okay so there's you know objects involved and all these sorts of things that maybe is influencing my terraform is not doing what i expect here and that's really it for this i just wanted to shout it out as just like this advanced troubleshooting technique yeah the more information you can get during that process the better so thank you for uh walking through that we did have a quick question which is why the type function is only available in the console ah that's a great question um i'm not sure of the if there's any technical limitations on it but um there i believe the reasoning behind it was that um it's only kind of applicable to debugging more so than something that would actually be useful to pass around to other things for example there's nothing you can't take this type output and use it for some other place currently within terraform so like another part of the terraform configuration can't take this output and do something useful with it so i believe the idea there was to kind of separate separation of concerns there maybe it's possible that it could be implemented and you could output the type output uh as normal but currently today it's implemented as uh just this in the console awesome thank you for answering that brian thank you for the the questions anton so that brings us to the end of uh the features we were gonna cover today so five really uh really big ones right we had everything with uh tara for the terraform cloud experience and swapping out the remote back ends through that new cloud block which was awesome uh with the moved block so refactoring we went into women in depth with modules there so that's going to help a lot with module authors and refactoring around that area then after that we went through the plan and apply changes to destroy followed by nullable variables and finally here we are at the end seeing the type function uh a lot of good stuff in 1.1 and since we're running a little long on the stream i wanted to kind of accelerate forward to what happens next what's coming next what's in one point two what's in 2022 right i know that you all have us probably have some plans or some knowledge that you can allude to so i wanted to toss that question first towards corinne someone asks you what's coming for terraform 1.2 in 2022 what what would you tell them putting me in the hot seat um yeah so this makes my job really difficult but i can't speak a ton about what we're actually committing to but i will say that we're researching projects right now specifically around improving ways to test terraform modules so if you are interested in providing feedback on that specific utility please reach out i'd love to talk with you and get your use cases down and pretty much that's all i can really say i'm sorry oh good all good and as we're doing this discussion you know for those of you watching if you have any questions or things that you would like to see we've already had some people uh shout out some of those things please put them in because we can we can have some conversation here and let me go ahead and put us back to the uh normal view here so we can see everyone um so continuing with that question uh chris and i i know that in our conversation you said something that you could at least hint to yeah i mean i'll add on to what karen said about about testing as one like i don't know i guess i call it implementation of an even bigger idea and that is like assertions in terraform like we want to be able to to to you know give tooling around making sure that things are behaving as you expect them to maybe before you apply them or maybe after you apply them like uh more so than even just uh testing stuff the broader idea of just being able to have more confidence in asserting conditions uh is kind of something that we're we're toying around with and looking at for terraform one to two and then brian bringing us in from the uh provider perspective if you if you solve an imagery after us throwing four demos on you here no no it's totally fine and uh happy to do it uh you know um something interesting uh totally unrelated to terraform cli here is that you know uh i my team that provider development experience team is uh really excited to have a new provider development framework in the works we've been working really hard on that so definitely want to shout out to that uh that's ongoing work so we can absolutely talk about that um but yeah from uh the terraform kind of core perspective here with the cli and everything um you know i'm i'm hopeful uh that a lot of the research that kind of went into uh making these move blocks possible uh can be expanded further um and i think there's a lot of will and hope there that that can all that could potentially happen so very excited uh for the future there yeah yeah i'd say it even goes back to that to that theme of like you know primary workflow type stuff like i think we've seen a lot of really uh really good success a lot of really good feedback towards taking these things that were kind of like these weird secondary workflows that are like essential to using terraform every day but not part of the primary workflow everything that we've done so far moving in that direction has really really been very positive and a really big improvement so i think you'll probably see a lot more of that in the future awesome so so i know that uh we're coming here towards the end of stuff you know if you have these improvements these issues please reach out to really any of us um go to check out github repo i know that i know that yeah we we hit the things and we may take some time to respond but we do see it so uh please continue being diligent in your feedback we really appreciate it a lot okay so this brings us here to the end of things thank you so much brian current chris joining giving your insights your feedback all the great demos uh answering all the different questions for us it you know it's it's a huge help to the community uh gives us a place for people to come and uh faces to talk to rather than just avatars right on github issues so it's much appreciated um and thank you for everyone who tuned in for contributing to the chat and everything that always helps keeps things lively and uh thank you to all the users customers and members who make all of this possible so uh if you are new to terraform please make sure you check out our learn.hashicorp.com platform our learn platform there we've got all sorts of stuff for beginners intermediate all the way up to very specific use cases so you can get your information there also if you're interested in collaboration being more specific about your feedback seeing what other people are saying check out the github repo and then for everything else terraform dot io our main website is kind of the hub for every single thing else that maybe isn't mentioned here and uh that's pretty much it that brings us to the end of 2021 any last words brian corinne or chris really quickly we actually have a learn tutorial for trying out the new move statements as well as migrating from s3 to teraform cloud i'll quickly send a link and yeah you should all try it out nice yeah let me post that link right inside the chat here so that we've got that up and then chris brian any any last shout outs you'd like to do just thanks to the community it's been fun 2021 and i'm really looking forward to a lot of stuff that we'll get into next year yeah i i definitely want to say uh you know thank you to everybody who contributes whether that be discussions or github issues or you know feature requests and all those sorts of things all the feedback is extremely helpful and thank you for making terraform a great product because it takes a village to build this thing it's not just you know us folks chatting here there's lots of other engineers and product folks and everything involved as well and absolutely the community so it's amazing to see it actually working in progress [Music] nice all right well that wraps up our community office hours for terraform thank you for joining us everyone and i hope you have a happy holidays until next year

Channel: HashiCorp

Views: 732

Keywords:

Id: KwgRkI0a-S4

Length: 101min 30sec (6090 seconds)

Published: Tue Dec 14 2021