 All right, so it's probably a good time to hand over to Martin then. So Martin has been a long time, Helm maintainer, works for IBM, wrote a lot of the, did a lot of work on Helm 3, has done a lot of work on documentation, has been one of the, he's probably at this point, either the number one or number two most frequent answer of questions in the issue queue and also the author of the Helm 2-3 Migration Plugin. So Martin is going to kick it off with a discussion of how to do these kinds of migrations. Go ahead, Martin. Okay, thanks very much for that Bridget. So, and thank you Matt as well for the introduction. So what I'd like to speak to you about today, I suppose really it's a follow on from the great background and breakdown that Matt has done around between Helm v1 right over to v3 now and the different changes that there are and the reason why we, why if you have Helm 2 releases why you'll need to migrate over to Helm v3. So this, we're going to base this around to the plugin that we've written to help you in this migration. So as Matt said, I'm a core maintainer in Helm and I work over at IBM and there's my social if you want to reach out to me. So I suppose one of the questions that often come in is do I need to migrate to Helm v3? And this is always a few interesting questions around this and why you'd need to migrate, et cetera. I suppose I'll jump down a second. One of them is if you haven't used Helm v2 or you don't have any existing Helm v2 releases then you can just use Helm v3. So I start an afternoon. So it's not necessary for you to look into migration. If you do, then this is for you. So Matt mentioned it earlier, one of the reasons why because v2 is going to end of life in the middle of November. So the support had begun and Helm v3 is known to current supported release and has been out for the last, close on a year now in November. One other thing and it came up in the chat as well. This is something else always with migration is people are asking around the charts. The charts need to be migrated and the answer for that is no, not necessarily. So generally when you're looking at your charts Helm v3 will still be able to render the API version v1 charts except for what we mentioned a few minutes ago around the CRD install hooks and the default name creation but you can give it a flag note to create the namespace on the fly if you want. And around the CRD install hooks it's a matter of you're updating to use the newer version of CRDs if you want your CRDs installed in that way. And the final thing is why the migration is here. I think Matt went through really, really well on that is the whole idea of the changes underneath the hood and it's mostly around the release metadata and how that format has changed and the way we store it inside the cluster and also I suppose around the local configuration as well that has changed. So what are your two options when you're looking at migration? If any of the criteria has touched you earlier on that you want to, that you need to use some of the releases that you've deployed using Helm v2. How do you work around that then? So there's two patterns we can look at and the first one, the Strangler pattern is really looking at gradually phasing out your Helm v2 deployment. So what you do there is that for any new deployment of charts you're going to use Helm v3 and then as time goes on Helm v2 will be phased out bit by bit until eventually Helm v2 doesn't have any more deployments that all the deployments then or the releases are now managed by Helm v3 and it can be removed. The other approach and it's the one we're going to talk about today in the talk here is the in situ or when you want to migrate to straight over from your you want to bring your Helm v2 releases over to Helm v3 and let Helm v3 manage them so that you can do rollbacks or upgrades afterwards. So that's what we're going to look at in the demo and what we're talking about here. So why would you choose this? I suppose the key one here is as I've been saying is if you want to reuse the existing resources from Helm v2 be that your configuration local configuration for example plugins you've installed repositories you've installed or any maybe chart starters that you use and primarily I suppose the releases that you have so for example if you've deployed versions of I don't know Redis, MongoDB etc and you want to keep maintaining them and managing them from Helm well then this is what you want to do is to migrate that over so that the release information can be taken as Matt said in the old format loaded out of the cluster and mapped across into new format and restored in the particular namespaces and with particular naming that Helm v3 expects and we'll go through that when we're in the demo we'll show we'll show how you where the old formats were where the new formats are and we'll show it with the plugin how it does the mapping across and the plugin is the way we recommend because it does the automation of this and it's not something you want to do in a manual approach especially you won't want to really look at trying to script this because it's just the mapping here is really needs to be wrapped up in something like the plugin so you can have a look at the code inside the repo and see what's involved so what am I going to cover in the demo we're going to start off having the two versions of Helm sitting by side by side and they're going to point to a particular cluster and what I love is pre-prepared some releases that have been deployed using Helm v2 and it'll also have plugins and repos already configured then we look at showing how to move or do a convert of the Helm v2 release metadata over to Helm v3 and then how we can look at it then we'll be able to then look at it using Helm v3 we will look at also the cleanup of those particular releases and we'll also look again then at doing that with a release in different namespace to show that how the data is going to be stored in Helm v3 in the different namespaces as opposed to in v2 when it's stored in the Taylor namespace and then we'll also look at which happens for a lot of people they might have different versions of clusters that they're using from a particular system so we look at here using kubeconfig how Helm and also the plugin connects across to the different systems and basically different clusters and then we can see here that we can make the changes in there as well and then finally we look at full cleanup so in between we probably do one by one release cleanups and then we look at the full cleanup at the end of that so okay let's swap over to the demo okay because I'm blind here could someone help me out and see can you see your terminal yep we can see it thank you Bridget okay so let's kick off so first of all look at the Helm versions we've out here I'm going to Helm 2, I'm going to just call Helm so you can see here I'm using 216.12 you can see here that it's got the client in the server part and then if we look at Helm 3 which I'm calling Helm 3 you can see here that it's just got the client version and what I'm using here 3.1.3 for some reason okay so that's great so first of all let's have a look at what repos so I'm just using bitnami and jet stack at the moment and any plugins that I have installed and then when we look at Helm 3 we can see I have no repos installed and when we look at our plugins I've known installed either so what we're going to do from here is we're going to look at and let's have a look at just watch okay so I have 3 releases deployed example Nginx and Redis so what we're going to look at here is first of all we're going to look at the configuration so moving over the repos and the plugins and merging with any plugins or repos that I might put into Helm 3 so we're probably going to add the 2.3 plugin in a minute and then we're going to look at after that then look at the releases and see how we go on that so first of all let's install the plugin so we can look at the migration so now when we look at the plugin list we can now see that we've installed the 2.3 plugin and let's have a look at the plugin so when you run in the command you just run your Helm 3 release any plugin you're running you just run the Helm binary the name of your plugin and we'll have a look at the help on this so you can see here that there's 3 main commands outside of the help command so we've cleaned up convert and move so the first one we're going to look at is the move command so what the move command does is it's for the moving or the copying over of configuration from Helm 2 to Helm 3 so for example what we said there the plugins list the repo list and if you have any starter charts are copied over so that Helm 3 can now use them in the convert it'll be for the conversion of releases so the moving of releases over to Helm 3 so or the copying of releases over to Helm 3 so that Helm 3 can then manage those releases and then finally the cleanup is the removal of release data, tiller data and configuration so let's kick off with having a look at the move command so you can see here there's not very many flags to it and it does what it says on the 10 it's the migrating of the configuration over to Helm 3 so I think we're going to give that a go now each one of these commands has a flag dry run and that enables you to see what the command is going to be going to do or what's it going to run and the different operations it will do before you actually hit run before you actually decide to go with the command so it gives you an idea of if you're unsure what you're running it against to make those changes or not so if we hit this okay alright I'm just missing the config so you can see here with somebody are the commands around the cleanup and the configuration they will ask you if you're sure of the command because once it's done it may be difficult to roll back from that so that's why you get the warning on that so you can see here what's going to happen is it's going to move over the config and the data and some of the cache from the from the setup in Helm v2 which was stored usually in your home dot helm patch in now into using more standard format for different OS's for example for Linux it's using the XTG specification so things like using dot cache and dot local share and dot config and then using probably user accounts on windows etc like that so just using a more standard metaphor per OS then just using the dot helm account so let's kick it off and see what happens so when I accept that then if I then have a look at my plugin list I can now see that I've inherited the two plugins from Helm v2 the diff and the maccubes apis and then if we look at the repo list we can see that we now have the bitnami and the jet stack labels and we have those particular repos that just shows you when you're doing the configuration if you want to move that over I suppose that's an optional step as well in considering that do you want that configuration or you're just going to add your own configuration from new for example because when you install as we showed Helm tree out of the box there are no repos added so basically it's up to you then what repos you want to add after that but I suppose if you want to maintain some of the repos from before then it's a good idea to copy them over so the next part really is probably the main part of the migration and that's around your particular releases so you can see here we've tree releases and if we look at this we're going to migrate across the engine x release the redis release and there are two releases we would like Helm v3 to manage when we're moving over to Helm v3 and before we get rid of Helm v2 so when we look at our Helm tree what differs here as well is that we no need to give it the all namespaces because if we don't and we just go Helm ls then we'll just see any of releases that have been deployed into the current namespace whatever your current namespace may be in this situation I'm using a kind cluster so I think at the moment it's the default namespace that's been used okay so you can see here we've no releases for Helm tree so what we want to do now is let's migrate over the engine x release so also to look at this as well is that engine x has got two revisions so those revisions need to be brought over as well or they are the different history for example it probably is an upgrade if we look at history on it we can see here that it was an install and then an upgrade so the command for running for running the the migration of the releases is the convert command okay and I'll just put the command up here so what does this command do so what this command does is it and Matt would have touched it in the the theory in the history behind it is that it's going to look for the different releases that a particular teller instance has in its namespace so the default teller uses the cube the cube system namespace it will basically look for the particular release in that particular namespace it will by default Helm v2 used config maps now you could also configure it to use secrets but by default it was using config maps so it pulls out the release information or the different release versions that are stored as config maps or secrets in that namespace it then maps that data from the Helm v2 format into the Helm v3 format and it then stores those release versions in the namespace of the release so two big things there is the mapping of the release format and now they're going to be stored in the namespace of that the release was deployed in and not in the namespace of your teller which if it's by default is cube system so some of the flags that might be of interest to you here is you can specify the namespace of your teller so if your teller is in a different namespace outside of the cube system and as Matt said some people use one to many tellers if they wanted the ability to try and provide some multi tenancy there's also people that wanted to use an alternative to having teller in the cluster or running outside of the cluster they use teller less so you can also put in a flag for that if your teller is not in the cluster and also is the ability to what we're touching in a while is to use cube configuration to point to different clusters and different contexts of clusters so Helm by default uses disability to point to clusters so whatever your cube configuration is or what context it is that's the particular cluster that it will point to and the same here with the plugin so let's go with this so before I go on folks is there any questions out there will you touch on or will I keep on going at the moment it might be worth clarifying the what's going on with the stable repository which is to say that people are a little bit confused about the stable repository there will be a blog post with more details coming out soon but do you want to talk about that a little bit do it's going to be mirrored it's going to be available on charts.helm.sh yeah I suppose yeah just maybe Matt wants to touch on more we can come back to that let's get this question about the exact thing you were just doing too can we summarize that the Helm 3 2-3 move will only move things around on my local machine but won't touch the actual Kubernetes cluster okay that's a very good question yeah I'll just stay on this for a moment and we can come back afterwards because I want to be more aligned on what's the to better describe around the stable etc if that's okay so yeah that's a very good question so the configuration is your local configuration that's on your system it has nothing to do with the cluster and we'll see this in a while where I'm going to have my Helm V2 binary and my Helm V3 binary and they have their local configuration for example their repositories and their plugins and they can also point to different clusters and the configuration will stay the same but the clusters will be different has that helped to clear that up? it should be a follow-up question to that can I change my cluster from multiple machines do I need to run the move on all these machines? yes so your configuration is per your Helm binary so the Helm binary or the Helm command that you run that accesses its configuration from where it's run from the system it's run on so it stores its configuration on that particular system so if you have a different Helm binary in another system or you have a different if you have it on another system then you need to update the configuration in that other system as well okay great clear as mud a new question will Helm 3 provide the ability to specify your cube context via environment variables not already possible similar to how we can configure a shell to use a specific context for cube cuddle with cube cuddle context yes the flags are there already so if you look here and they're in they're with Helm as well so you can see your cube context and cube config so you can specify it on the fly as well but the default is it uses a cube config file first if you don't specify it okay how do we verify all of our Helm v2 charts have been migrated to Helm v3 how do we that is a charts issue that I mentioned earlier isn't really anything to do with migration as such so that's to do with so what you can do is if you're the maintainer of your charts or if you're using charts that are maintained by somebody else the way you can test is that api version is v2 in the chart if it is not v2 it's a v1 style chart which can be used both in Helm v2 and Helm v3 so is it fair to say the short answer is your charts will almost certainly work unless you have some very specific corner cases but you will almost certainly be able to use your old charts yes and the corner cases would be the crd install hooks and also it won't create a namespace on the fly in Helm v3 unless you give it a flag which is I think generate namespace when you're doing an install or upgrade ah interesting question how do I identify the actual version of Helm either in the Kubernetes cluster or in my actual charts you you won't be able to determine so the version of Helm doesn't have anything to do with the chart so I suppose the analogy I can think of Helm itself is like a power tool and charts are like the bits that you put into the power tool so I suppose charts are where the value are it's where you're asking what you want to deploy and then Helm is the engine to do that deployment so to take that chart to render it and to give it a Kubernetes API server whether you use Helm v2 engine or the Helm v3 engine is irrelevant unless you get a bit that can fit properly in for example if there's an issue with the CRD install hooks how do you find in your cluster I'm going to show that in a few minutes you would know by Tiller will be installed in the cluster for Helm v2 for Helm v3 you won't know because it's only a binary running on your system it's something you run it's only a client another question if you're using an umbrella v1 chart to deploy many charts at once using requirements.yaml will the 2-3 chart sorry will the 2-3 tool convert the chart and dependency charts no the 2-3 tool has nothing to do with converting charts the conversion of charts are done by the maintainers of the chart so be that if it's you that owns the chart or maintains the chart or if you're using a chart from somebody else then it's work going to the repository where that chart is hosted and seeing if there's an API v2 version of the chart so with the migration we're concerned with the migration of the the local configuration and the release data not it has nothing to do with the charts themselves we'll go on while we have a chance and we can come back again let's get one more question in comparing contrast Helm v3 and flux CD flux CD is another piece of software I'm not sure it's specifically related to Helm um I can't I don't have an answer for that one at the moment if that's okay I don't either but I will drop a link into the chat from what I found about what flux CD is you can certainly read about that do we want to talk briefly about how the fact now covers how to point your Helm 2 or 3 client to the new chart repository archive there's a link in the chat about it but basically you can point your Helm 2 or 3 client to the new chart repository um just pointing that out okay so what do we want what do we yeah sorry you've got me there what you want me to do on that oh I was just saying I don't know if people want to scroll up to that link that Matt Butcher dropped in a little bit ago but that might be relevant okay is the link in there yep um it's just the troubleshooting section of the FAQ okay do you I want to let you get back to your demo Martin yeah let's get if you can if you can drop me the link that'll be great because this is still this is coming out on the fly now isn't it yeah okay all right let's get let's get back to demo on this so here what I mentioned earlier is uh just before the questions is that we talked about we want to bring over metadata so picking up the release metadata mapping it into new format and storing it into the particular namespace so if we take a look at engine X to start with let's look at the dry run of that and you can see here that what it's going to do here is it's going to create a new uh release version v1 and v2 um in the particular format for v3 but it's not going to touch the Helm v2 unless we ask it to delete it you can give it the flag uh v2 that releases or you can wait and delete it yourself manually now one of the key aspect of this is it's just the release data or the state information for Helm we're not going to touch any of the Kubernetes objects that were deployed in the particular chart it's just that metadata of state that Helm uses so if we look at this so let's give it a run without the dry run and let's see what happens okay so we can see now that it's created the particular release versions and it also tells us that that the v2 release information is still there so if we go entry ls this time list we can now see we've engine X and we can see here that the data in it is from earlier today when I set up the particular because if we look at the time now it's much later so you can see here that's the particular the last time it was deployed and if we look at Helm list we can see that it's from earlier today the time differences are there because previously it wasn't used in the time zones it just used the local time in Helm when it showed the listing in Helm v2 okay so now we can see here that we have the release information for Helm v3 and Helm v2 and that if we look at we can see here that we have the particular deployment still running it's a basic engine X server and we also have a particular example chart which we showed earlier that's running so when we talked earlier about and Matt talked earlier about the data that was there for v2 and the data that's now there for v3 we can see here when we have a look in here and what we're doing in this situation is it's using a particular label all on tiller and all different namespaces so if you have different instances of tiller running then you would see data like this stored in different namespaces or if you change the particular label of who the owner is then possibly you'll have to change the label here as well but you can do that with the plugin where you can give it a different label if you're using different label for your tiller and you can also give it a different namespace if you have different instances of tiller running as well and you can see here that we have all the information stored here that we have for the listing and you can see here that there's two pieces of release information because there's version 1 and version 2 and these need to be stored for the management that Matt described earlier around the rollbacks etc you want to do with your particular release now when we look at it for v3 you can see this time we're looking at the owner by default is going to be the owner is going to be owner equal to helm in small letters and you can see here that we have two versions of an engine x and that's what we've converted over at the moment so that shows you what happens when you do the migration over of the release data from helm v2 to helm v3 so now if we look at this the next probably part of this is I just want to touch on the cleanup and this is something that has the plugin as evolved from users have looked for this capability and pushed this capability is around the idea that instead of when we first looked at the design of the plugin we say alright we're going to provide cleanup people will do their migrations over to different releases and then they'll want to clean up everything but what we found over time is people want the capability of actually I would like to clean up my releases one by one so when I do the migration over I want to make sure that that release is working and then I clean up that release so what we might do in this situation is if we do an upgrade let's do an upgrade of that of the of the engine x release but we're going to upgrade now in helm v3 not in helm v2 and I know the particular chart that was deployed was part in bitnami so when I go to upgrade that I then end up with an error on this situation so the error here is the hint here is it's telling you you need to run the repo update so that's one thing with the configuration that we found and we haven't found a very nice solution to it was that there's problems with the cache that's stored so between v2 and v3 and we just found that the solutions to it that went into the helm core or into the plugin weren't we're just going to be too complicated so what we've decided on that was that if you end up with problems like this which are repos when you do the upgrade that you can just do an update on it and that'll align the repos back up so when I do the update like that with helm v3 and then I go and do the upgrade we can see here that it seems to have succeeded now I suppose this is a bit of a superficial upgrade because I haven't changed anything in the settings but if we go we can see here we're now going to revision tree and if we look at our secrets we can see here that it's been updated to version tree you can see here the date has now changed from to the current time and if we look at if we look at our v2 we can see that v2 has now not been touched so these are some of the ways that people are starting to use the plugin we would be saying to move along and do your migrations as much as possible for the one reason here that that if you try working with helm 2 and helm 3 simultaneously i.e making changes or upgrades with helm 2 while you've helm 3 you could end up with clashes in the cluster where you have cluster-wide resources so to be just aware of that so now what I talked about is having a look at the cleanup so you can see with the cleanup there's a lot of similar flags that we had with the migration of the release data and you can see also there's a couple of ones down here where you can do individuals like do cleanup of releases like using dot.release cleanup or you can do tiller cleanup or you can also use the dot.name flag which is where you want to just remove the release data from v2 for a particular release so that's what we're going to use here so if we go and we try the dry run on this again so you get this warning because once this release data is gone it's gone out of cluster and helm v2 will no longer be able to manage that release so you can see here what it's going to delete it's going to delete the two release versions all the history and the information about that release engine x so let's give it a go now we can see that we have the two releases have been deleted and if we go to helm ls we can now see when we do a list we can see that that the engine x release has now been removed it's no longer in v2 and if we look at the config maps it's gone out of the cluster and then if we have a look at a list on helm 3 we can see that engine x is there and if we look at we can see here that the kubernetes resources that were to be deployed as defined in the chart are running so that's one thing to note here is that and I'll say it again is that the plugin does not go near the deployed resources it's the release data that it's going to do the mapping for helm v3 okay so I'm just going to have one quick go at doing the the redis I'm going to do a migration of redis because it's in a different namespace you can see here it's been deployed in the redis namespace so I won't look at the the do a dry run etc on this I'm just going to go for it and run it okay so that's migrated over and if we go helm 3 ls we see nothing because as I say the list you know for helm 3 the commands now are based on the on the namespace you're running as a user so whatever your current namespace context is that's what it's going to run your command against so that's why I need to put in all namespaces and we can now see that we have redis here and we have a data from earlier today and we'll now clean it up from now we'll clean up the the the redis installation from from helm v2 just getting the commander so we can see here we're running the same again we give it the name redis because that's a release we want to release we want to remove alright so when we go we can now see that the redis has been removed and we can see here that we can see here when we check in the cluster we can see here that the redis service is still running in the cluster okay so that's looking at the configuration force, the local configuration and then looking at how do we map our how do we map our different release information over to v2 okay so I just going to change gears slightly a minute so what I'm going to look at here is that if I go across to a different cluster with some people are doing if I just change for the moment I'm just going to change the context of the cluster okay lovely let's try this okay that worked that's good so this time what we're doing is we've just watched the context of the cluster that we're looking at so the previous cluster was a kind cluster 17 I'm looking at a client cluster 16 here and when I when I do Helm LS this time you can see here that there's a different release and if we do Helm 3 LS you can see that it has no releases even if I put it in the nameswis okay okay if I can spell I forgot the dash okay so you can see that what we're looking at is a different cluster at this stage so you can see this when we look in the cluster this time we're looking at basically just one deployment which is demo my chart okay so what we're going to do this time is we will migrate over this release information and then we'll do some cleanup after that so I think someone asked that about what we have here is we have two version we have the binaries Helm v2 and v3 binaries that basically the clients can point to different clusters and work off those different clusters so the version you see here there's a tiller instance running in this cluster because it's Helm v2 but there's no need for that service for Helm v3 and when we're in the previous cluster there's a different instance because obviously it's a different cluster so if we now do we do convert demo and now we look at the listing of that we can see now that we have that particular release now being managed also by v3 now what we can do look at then is one of the flags I talked about a minute ago if you wanted to you're happy enough with you've made all the conversion of your releases over and you're happy that you want to clean up the release information you can use the release cleanup flag okay so when you go Helm ls then you'll find nothing and when you look at the config map there's no release information stored in the cluster there so the final part of that is on this cluster only you might say okay I no longer have any more release information here I will no longer be using Helm v2 to use this cluster anymore to do my deployments etc so I can get rid of the tiller so when you're looking for tiller you will be looking for whatever namespace you put it into and whatever the label that's used usually you'll have a label app equal to Helm so to get rid of that we just use the cleanup flag for this and what this will do is it will remove the tiller instance from if we look at the dry run it will remove the tiller instance from the cluster so if we run it so once we run this we will no longer be able to run Helm against this cluster because of the fact that tiller is no longer there to communicate with so if we go Helm this this time we can see you can find tiller does Helm 3 still work yes it does and then if we go back to and if we see what's still running inside the cluster what has been deployed out you can see here we still have our demo release so we're going to go back now again to the origin cluster and we'll just show finish off by doing a full cleanup of Helm Helm v2 when you're finished so if I just okay and we look here again we can see here in space I'll see that Redis is there as well so we've now come to you've come to the stage where this you want to get rid of the tiller instance in here any release information that's left you're happy you've done all your conversions over and you've also you don't need Helm v2 anymore so you don't need the configuration so you want everything deleted in one go so first things on that if there's any releases you haven't migrated over you need to delete those releases first and the reason for that is the plugin does not touch any of the objects that have been deployed into Kubernetes as defined in the chart so it's just looking after the release metadata in the cluster so if you don't delete beforehand the release metadata will be gone and the objects that have been deployed by that release will then be orphaned so what I do first in that is I go Helm delete example because it was just an example release that I was using I don't need to manage over Helm v3 so I just get rid of it now you can use purge if you want it doesn't really matter because we're going to be deleting the release metadata afterwards so if you go to a list you can see here that the release history or metadata is still hanging around but that's okay we're going to clean that up in a minute so when we do the delete this time let me just get the command so I'll be faster we can now clean up without any of the flags obviously we'll have a look at the dry run on this to see what it's going to do and you've been warned in here saying to you that basically you may not be able to use any release information afterwards with Helm v2 so it's telling you the fact here that all the release metadata and all your configuration are going to be removed so Helm v2 will no longer be usable so when we kick this off so you want to be sure before you do this that you've done all your migrations you're happy with the migrations your configuration has come over and that you're ready that you're happy with your Helm v3 and you're ready to go forward with Helm v3 so when we kick off the clean off here okay so let's have a look you can see your tillers there no longer if we do we can see it's no longer in there and then we can also see that the home directory has been removed or the configuration directory or the other Helm directory is gone okay it's no longer available and so you know the situation where essentially all your left is with the Helm v2 binary and any of your deployments etc are now gone and are now being managed by Helm v3 so if we go back to Helm v3 we can see here that we have engine x and redis the releases that we migrated over if we look at our repo list we can see here with bitnami and jet stack and if we look at our plugin list we can see here that we have the plugins that were migrated over for us the two here and then also the two to three plugin that we have there so that's pretty much it when you're going through your migrations it's really do you need any of the configurations if you do bring them over and then which releases do you want to keep you want to keep and bring with you I suppose the advice we give around this too is that if you haven't been managing your history size in Helm v2 before you do the migrations up either clean up some of that history or you can also specify a flag if I can just look at it now I'll take it off my head flag here release versions max so if you give it that value it will take the last number of release versions and drop the rest of it so it will only convert over that many so if you say 10 it will take 10 of the latest release versions that are there so there are a few things to look out for and once the great thing about this plugin is once you've done your migrations over you finish with your different instances of Helm v2, your different Taylor instances etc you no longer need this plugin so it's just for getting your conversions over there and being able to manage some of the resources that you've deployed with Helm v2 so I'm just going to go back quickly to the deck and we can answer more questions then Bridget if that's okay okay there's a question that I think is a lot so perhaps we could just point them to the fact of what are the main command differences between v2 and v3 I'll drop a link in with more detail but Martin do you want to tell us about some of the ones that really stand out for you you put me on the spot today Bridget you're really catching me out I have migration in my head what are the ones so delete has no become uninstall the repo searches have changed if I can remember as well I think have a look at the fact actually because you put me on the spot or is Matt Butcher going to help me out here but Butcher has been looking vigorously in the background with this question I dropped a link in I think that a lot of people probably will find that because so many of the old commands now they won't see a lot of hands-on differences no they won't but I think we'd prefer for people to move on because if we've made them aliases they're going to go out eventually going to be removed probably in hell and four a lot of the reasons for the changes are only was being really good work by Adam Reese and Matt Fisher is around we wanted the the client to be more like cube control or whatever you want to call cube control so we wanted it to be similar to that and one of those ones that really really kind of cause reconciliation was the removal of the ability to create a namespace on the fly when you were doing a deployment or an installation or an upgrade and the reason behind that was you can't do that with cube control so we said well you shouldn't be able to do with helm as well we ended up then having to put in a generic namespace flag because there was such a backlash against it but I think what we're trying to do is we really want to get that consistency with cube control and that client because you know if you've been using Kubernetes you know you know we want helm to be a similar type of experience or the other way around if you started your Kubernetes experience with helm which a lot of people do you know when you go over into cube control you're okay using that client so that was one of the reasons behind it and I think probably going to the FAC is probably the best way to do that the other thing as well and it's something we didn't mention is just coming to my head is helm init you no longer need to init so the initialization was for the ability to put Taylor into the cluster and set up configuration that needed to be set up out of the box which helm tree the nice part of this is any configuration can be set up on the fly or can be lazy created and we don't need it straight out of the box so they're the reasons for that because that question actually has come up a lot where's my helm init gone and as we said earlier it's still just the client so yeah so will I just finish up the recap and then we go into any other questions then Bridget would that be best? Sure absolutely yeah so just to recap on it is look helm v2 is going into life the middle of next month our recommendation and suggestion strong suggestion is please try and move over to helm v3 as soon as possible because there will be no more updates to helm v2 and we really think helm v3 definitely brings you more simplicity and more security and just around I suppose maybe that bit more robustness from stuff that has been learned as Matt has said from when helm v2 was first created to the way Kubernetes has progressed in those three or four years so if you already are using helm v2 and you do not care about your releases that you deployed with helm v2 then just start using helm v3 and get rid of helm v2 if you do care about the releases you deployed which I think most people will do then we suggest you start using helm v3 to start managing that so you start migrating over and then you start removing cleaning up your helm v2 as you go along till eventually you just have helm v3 and that's why we came up with the idea of the plugin tool and this goes way back to Seattle I'd say in 2000 and I was going to say 8 but in 2008 we were all much younger 2018 I would think is the right one there and that came up in a deep dive talk actually with Matt and Adam so we want the ability for you to move it over you do not really look if you want to go in and have a look at the internal formats of the data but it's better that the tool does it for you because it makes it much easier so these are the reasons why you want to do that migration over so I think that's about it and a few resources there if you want to take a look at FAQ is down there as well actually so if you want to have a look at that so Bridget, fire away wonderful Martin thank you so much let's see one more question and you may be able to put Butcher on the spot to answer this one which is will helm v2 be able to access charts that were stored by sorry will helm v3 be able to access charts stored by helm v2 in a private repo passable problems in the past and wondering will v3 be able to use existing charts out of a private repo in this case ACR but the question I suppose applies to any private repository the answer I'm going to say that is yes and that person is going to come in with a use case probably this evening or tomorrow do it this evening because I'll be finished for the day this is the one chance I've got to joke as well Bridget I got really serious there on the command line I think but no on a serious answer yes you should be still able to use that repo so we have added a lot of capabilities and some brilliant capability was added by Josh Jaliski with the ability to use OCI registries okay so prior to know our registries were I suppose HDP based registries where you could get out of it and we had the different repos which is something we touch in a few minutes because I think Matt has been putting a good dock with the together with the chart maintainers like Matt Farina and Scott have been doing a lot of work around the stable and stuff which we touch on in a few minutes but the idea here is that you're still able to get your repos and that you can touch repos now like an OCI registry like Docker for instance and you can get your charts out of that so that's still at experimental but I would imagine in the not too distant future that we go to full-scale feature because of the fact that it's getting nearer and nearer to completion of the work that's been done on it but yes you can get at your repos still. Great and Butcher do you have anything to add on that? No unless you want me to talk now a little bit about the repos the part that I kind of skipped over real fast. Right right yeah if you want to add a little bit more clarity because Martin got asked in the middle of his demo about what's going on with the repositories and I know you had some info for that. Yeah sorry I had all too much I didn't want to answer Bridget because the fact that I didn't I didn't want to say something that may be not totally right so I think I think Matt's probably the best person to answer it. Okay yeah sure I can answer first of all thank you all for holding all your hard questions until it was Martin's turn to answer them I very much thank you Martin does too. I don't appreciate that either and I have to say I did say to Bridget just get in there and ask me questions in the middle of it and I was on a flow about you know where I moved through migration and it's no one of those things where you go I regret saying to Bridget ask me the questions in the middle of it but no questions are always good so yeah so I did briefly in the November 13th 2020 doom and gloom slides talk about needing to move repositories so let me just explain briefly what's going on so the chart repository is the code that we work on for the charts lives in github.com slash helm slash charts then the CI pipeline builds them and puts them into a Helm chart repository and the Helm chart repository has been hosted for years out of a Google storage bucket that bucket is going to go away on November 13th so we have a backup that will be hosted by github itself that will be charts.github.com slash stable and slash incubator for the two different ones so I have I wrote the documentation for all of this and I dropped it in the yeah Bridget just dropped the blog post and there's some documentation in the Helm FAQ for Helm 3 that explains how to move from one repo to the other Helm 2.17 will attempt to do some of this for you but not all of it because we don't break anybody but the short version is on November 13th you'll need to be pointing at the new stable and incubator repos if you want to keep using those now keep in mind again those repos aren't going to be getting any new updates or patches or anything like that those repos will be in maintenance it will be in archive mode from that point on but if you have an automatic CI system or if you're frequent users of the stable or incubator repository it's probably a good idea to switch over to those new ones anyway so the FAQ is out in the documentation we talked about it a little bit on the Helm 5 year birthday blog post Matt Farina one of the other core maintenance has written a blog post that will get published soon it really talks through the details of that so keep an eye on the Helm blog for sort of a walkthrough of what you need to do about that I think that kind of covers the basics of it so one more thing to add to that November 13th list