 Donc, bonsoir, tout le monde, on est là aujourd'hui. Je vais vous parler d'un projet que nous avons travaillé dans pour plusieurs mois maintenant avec Guillaume, qui est un provider Vagrant pour OpenStack. Donc, juste pour vous introduire rapidement, je suis Julien Veuille, à l'art de travailler à Numergie en développement d'OpenStack. Je suis Guillaume et je travaille à Numergie, aussi en Paris, et je développe des applications et des services sur l'application d'OpenStack. Donc, première, vous, vous avez déjà utilisé Vagrant. OK, c'est presque tout le monde. Donc, Vagrant c'est un outil pour créer et détruire des environnements de développement et pour automater la création de vos environnements. C'est répétable, c'est à dire qu'on peut construire des environnements de développement en seconde, on les vend, on les start, on les load. C'est configurable, vous avez seulement un file pour configurer tout votre environnement de développement, c'est un file Vagrant que l'on va voir plus tard. Et c'est facile à utiliser, c'est une simple CLI pour commander vos environnements de développement. Donc, comme je le disais, la première étape c'est de décrire vos environnements dans un file Vagrant. C'est un file Vagrant très simple que juste prendre deux paramètres. La première est la box. Vous pouvez le voir comme l'image d'OpenStack. C'est un système d'opératage que nous allons utiliser pour créer nos instances. Et la deuxième paramètre est un script provisionnel. Dans cet environnement, je veux juste installer le Git et être capable de l'utiliser. Donc, quand vous avez créé votre file Vagrant, dans le même folder, vous avez juste joué Vagrant Up et vous êtes prêt à aller. C'est tout que vous avez besoin de commencer pour créer vos environnements. Donc, comme vous pouvez l'imaginer, Vagrant ménage des instances virtuelles et ces instances ont un cycle de vie. La première, elles ne sont pas créées. Quand vous voulez Vagrant Up, vous êtes active. Vous pouvez suspendre et résumer, vous pouvez arrêter et commencer. Et quand vous détruisent vos environnements, ils vont retourner à ne pas créer. Vous avez des actions vagrantes spécifiques pour exemple SSH, qui vous enable à connecter à votre instance. Vous avez des statuts juste pour voir quel est le state de vos instances et provisioning pour un script provisioning comme Shell script, XOB4, Puppet, Chef ou quelque chose. Et donc, Vagrant ménage les instances de vos instances et il utilise les providers dans Vagrant pour créer et détruire les machines virtuelles. La première est VirtualBox, mais vous avez ces 4 providers built-in. VirtualBox, VMware, Docker et Hyper-V. Et quand je veux Vagrant Up, j'ai une VirtualBox VM qui est créée sur ma machine locale. Si je n'ai que 1 environnement de développement, c'est OK. Je n'ai pas assez de mémoire pour gagner. Mais si je commence à avoir 10, 15, 20 environnements sur ma computer locale, je vais avoir des problèmes. Parce que mes ressources locales sont limitées. Même si vous avez une grande computer fat avec 32 gigabytes de mémoire, vous ne pourrez pas créer autant de environnements que vous voulez. La solution pour cela est que nous avons besoin de trouver plus de ressources et évidemment, nous sommes l'opensaxomite. Donc, où pouvons-nous trouver plus de ressources dans le Cloud? Les ressources Cloud sont virtuelles et limitées. Elles sont juste limitées par votre carte de crédit. Donc, en tant que vous pouvez payer pour vos instances, vous pouvez créer vos environnements sur les ressources Cloud. Avant de parler de l'opensaxomite et de l'opensaxomite, un petit peu plus sur l'opensaxomite. L'architecture de l'opensaxomite est basée sur le système de plug-in. Et la plupart des features de l'opensaxomite sont implémentées comme plug-in. Et dans la communauté, nous pouvons trouver beaucoup de plug-ins pour faire beaucoup de choses comme l'instance de provision. Il y a un plug-in pour configurer les machines host, les machines guest. Avec un plug-in, nous pouvons externer le lifecycle de l'opensaxomite. Nous pouvons externer l'interface de l'opensaxomite, etc. Et bien sûr, les providers sont plug-ins aussi. Et pour l'instant, vous pouvez contrôler KVM, une machine virtuelle utilisant l'opensaxomite de l'opensaxomite. Vous pouvez contrôler l'opensaxomite avec un provider LXC. Et il existe des plug-ins pour externer l'interface avec des providers cloud, par exemple, Amazon Web Services, et nous travaillons sur un provider pour l'opensaxomite. Tout d'abord, pourquoi nous avons besoin d'un provider de l'opensaxomite ? Comme Julien m'a dit, sur votre machine locale ou même sur un single hypervisor, les ressources sont limitées. Et sur un cloud, vous pouvez scale, vous pouvez déployer beaucoup de machines, ou je pense que ce point est obvious pour tout le monde ici. Donc je ne vais pas faire plus en détail ce topic, mais il y a un autre point. C'est l'environnement charable. Quand vous créez un environnement dans votre système locale, vous créez ce environnement pour vous et juste vous. Mais en quelque cas, vous voulez créer un environnement et partager cet environnement avec d'autres personnes, avec votre équipe, par exemple. Et cet environnement est très intéressant et on va parler de cet environnement plus tard dans le talk. Commençons avec un exemple pour voir comment utiliser le environnement et ce qui s'occupe derrière cette scène quand on utilise ça. Donc, nous devons écrire un environnement basé, un environnement basé. Commençons avec un autre environnement, un environnement basé. Et un bloc dans lequel nous configurons notre environnement, et la première chose que nous devons configurer est de connecter à notre stack. Nous avons besoin d'un point d'euro pour connecter à Keystone et à Credential et le tientage de l'arrivée que nous travaillons. Et ensuite, nous devons assurer l'information sur l'instance qu'on veut créer. Et l'information minimum qu'on doit assurer est la flavor et l'image. Et la dernière chose c'est de donner à Vagrant le nom de la portée d'IP pour faire l'instance accessible à l'extérieur de l'open stack et généralement sur l'internet. Avec ce Vagrant file, je peux simplement rassembler Vagrant et cette fois-ci, j'ai offert la option dash dash provider pour dire à Vagrant quel provider il faut utiliser parce que si nous ne faisons pas ça, il va essayer de utiliser le profondeur défaut qui est un box virtuel et ce n'est pas possible. Donc, ce qui s'est passé quand j'ai rassemblé Vagrant 1. Vagrant va envoyer l'authentication query sur Keystone et il va recevoir en retour le token et le service catalogue. Dans ce service catalogue, il va obtenir le NOVA URL et ensuite, il peut envoyer le query au NOVA pour créer l'instance. Mais pour créer l'instance, Vagrant a besoin de l'idée de flavor et de l'idée d'image et dans le file Vagrant, on mentionne l'idée d'image et le nom de flavor. Donc, nous sommes au début de résolver l'idée d'image et de flavor. Ensuite, nous devons résolver l'IP floating. Ce step est un peu plus compliqué mais c'est-à-dire qu'il y a un IP et ensuite, nous pouvons utiliser ce IP pour assurer ce IP pour l'instance. Julien nous parlerons de ce futur plus en détail plus tard. Maintenant, nous pouvons créer l'instance à NOVA et assigner l'IP floating. À ce point, cette instance est probablement en state brille sur l'open stack et nous devons attendre pour l'instance pour être brille et ensuite, attendre pour l'instance pour être accessible avec SSH et quand c'est terminé, nous sommes dans un vélo normal et le vélo peut-être essayer de s'occuper de professeurs et tout. Et ensuite, le vélo up est terminé. Avec ce vélo comme nous l'avons, il s'involte seulement deux services open stack Keystone et NOVA. Pour quelques autres features que nous verrons plus tard, nous poursuivons autres services comme Neutron, Frontstance et Cinder. Donc, dans le provider, nous supportons tous ces native commande Vagrant Up, Arts, Spanner resume, SSH reload provisions mais nous avons aussi développé des features spécifiques que nous parlerons et la première est la génération SSH. Donc, si vous dans le vagon file, Guillaume nous vous montre qu'il n'y a pas de configuration SSH. Donc, aucun path privé, aucun path public, aucun path permanent. Comment ça fonctionne dans l'application, quand vous vous rendez un Vagrant Up, vous vous enlève un Pair SSH, avec les pires et les pires publics. Vous vous enlève l'automatique dans le local des pires publics dans la direction de Vagrant Metadata et vous vous enlève le Pair public pour Nova. Donc, pour commencer, quand nous lançons l'instance, nous vous enlève le nom que nous avons appelé pour Nova et tout va travailler. Et quand vous vous enlève pour l'instance Vagrant SSH, nous allons utiliser la clé privée qui a été générée précédemment pour connecter à l'instance. Donc, si vous avez déjà travaillé avec les providers Vagrant Workspace, AWS, ils ont tous besoin de configuration SSH. Donc, les clés sont générées dans la direction de Vagrant Metadata. Elles sont générées avec le nom Vagrant Generated et Rache. Donc, c'est facile pour vous pour débarguer votre connection SSH avec juste ajouter la clé quand vous enlève le commande SSH. Donc, la configuration SSH n'est plus nécessaire, mais vous pouvez encore override cela. Vous pouvez vous enlève le Pair public votre propre nom pour Nova ou je veux utiliser cette clé privée. Vous avez toute cette option dans le provider. La prochaine feature est l'allocation de l'IP floating. La première façon est d'aller directement sur Vagrant, que je veux utiliser cette ligue de l'IP floating. Cette IP a été déjà allocée et n'a pas été assignée dans votre appui de stock. Nous allons juste utiliser celle-ci et assigner cette IP à l'instance. La plus générée qu'on doit faire c'est d'utiliser le Pair public pour l'IP floating. Et ce que nous allons faire quand vous enlève cette option d'abord, nous allons essayer d'aller pour une already allocée IP qui n'est pas assignée et qui est allée dans cette poudre. Si nous trouvons une, nous enlève et nous assignons. Si nous n'avons pas une, nous allons essayer d'allocer une nouvelle. Et si cela ne l'a pas faite, nous aurons juste faite une configuration de network. Si vous faites ça, les backgrounds ne vont pas donner une configuration de network pour NOVA et cela ne fonctionne seulement si il y a seulement une networks disponibles dans votre tenant. Si vous voulez configurer les networks, vous pouvez le faire. Vous avez besoin d'avoir l'information à l'appui de l'appui ou de l'ID de network. Donc, NOVA expecte un ID et si vous appuyez un nom de network, les backgrounds vont avoir à faire une résolution pour obtenir une liste de networks et pour trouver si il y a une networks avec ce nom pour obtenir l'ID et cela va utiliser cet ID pour aller au NOVA. Et si vous faites ça, vous allez avoir un IP adresse ou si vous n'avez pas l'ID sur votre network, vous pouvez explicitly configurer un IP adresse et ce IP adresse doit matcher avec une subnet déjà existant dans votre network. La prochaine feature est de volume. Si vous avez un volume existant dans votre tenant, vous pouvez attaquer le volume sur l'instance. La configuration est assez similaire pour la configuration de network. Vous pouvez donner l'ID ou le nom. La mécanisation résolution est la même. Et optionnellement, vous pouvez configurer le nom sur lequel le volume sera accessible dans votre système d'application. Nous pouvons aussi appuyer du volume. Dans l'exemple, nous appuyerons d'une image déjà présentée dans le catalogue. Nous pouvons, si vous avez un volume d'instance de specifier l'os.image attribute, nous pouvons utiliser le volume boot attribute et specifier l'ID ou le nom de volume que vous voulez utiliser. Pour écrire l'application, nous avons besoin de beaucoup d'informations d'open stack. Nous avons besoin de l'ID ou le nom, la même pour l'image, le volume, etc. Et, pour obtenir cette information, nous devons aller à l'horizon web console et quand nous utilisons Vagrant, nous ne voulons pas faire ça, parce que l'objectif d'utiliser Vagrant, c'est de le faire simple. Donc, quand nous utilisons Vagrant, nous ne voulons pas aller à d'autres systèmes pour obtenir d'informations. Nous implementons un plugin à l'intérieur du component qui externe l'interface command de Vagrant. Nous devons ajouter un command d'open stack avec des sub-commands. Pour exemple, nous pouvons utiliser Vagrant, l'image list et nous recevrons une liste de l'image dans le CLI et nous pouvons juste appuyer l'ID ou le nom de l'image et le mettre dans le file Vagrant. Nous avons la même pour tous les objectifs d'open stack, les réseaux d'open stack, etc. Et maintenant, nous allons faire une démonstration de notre travail d'open stack. Donc, la démonstration nous involve deux instances. Nous avons des back instances et nous allons installer sur ces instances un database de MongoDB et des instances front-end sur lesquelles nous installons une application web qui connecte le database de MongoDB. Nous avons un volume cinder attaché au database de MongoDB et nous configurons les instances durant la provisioning pour faire le data, le storage de MongoDB sur le volume persistant sur l'instance storage. Je vais juste switch la table. Ok. Donc, nous allons commencer par un fresh tenant sur l'open stack cloud. Vous voyez que nous n'avons pas d'instances. Si je suis allé sur les access securities, nous n'avons pas de keepers. Nous avons deux IPs flottés qui sont déjà allocés mais qui n'ont pas été assignés. Et comme GameSale, nous avons un volume qui est prêt pour stocker le data de MongoDB. Donc, ce que je vais faire ici, si je regarde le contexte de ma direction, j'ai un file de vagon et un sascript Donc, first, je vais voir que je n'ai pas d'instances qui sont en train. Ici, quand j'ai des vagon statues, je vais voir le file de vagon et il dit que j'ai deux instances MongoBack, MongoFront et qu'ils ne sont pas créés. Mais vous voyez ici, il détecte le box virtuel comme un provider. Parce que si je j'ai juste un vagon sans aucune option, j'ai un box virtuel pour gagner ma configuration. Vous pouvez avoir un file de vagon que vous configurez de multiples providers et juste faire un vagon up provider open stack, vagon up provider workspace, n'importe quoi. Donc ici, je vais juste donner l'option provider qui est open stack et je vais le laisser dans un billet OK. Donc, c'est le file de vagon Donc, c'est le file de vagon C'est OK. Donc, c'est le file de vagon Comme vous l'avez dit, c'est juste la fin basique que vous devez faire en vagon. Et ici, je vais configurer mon provider open stack et donner les crédentaux Open stack culturels, noms et passwords configuration of my images et ici, je vais juste dire Sync method none, because by default when you start vagon it will sync your current folder with a slash vagon directory on your instance. Here, we have nothing that we want to share so we just disable it and it go faster. So, this configuration is for the provider but here, I define two instances I will define the Mongo back instance and the Mongo front instance So, all the configuration I add in the previous block will be shared between these two instances. So, just check if everything is OK So, as you said we have a Mongo back instance we want to take a floating IP from a pool to some networks My Mongo back instance will be on a net back network with a static IP a fixed IP address so that it can be joined the same way from my web interface and I have some provisioning script the first one is just install Mongo packages or one Mongo and the second one which is insert data we just create some data in our MongoDB just to show you after on the web interface and here we create just two documents and we insert it we give it as a provisioning of my instance for the Mongo front it's almost the same thing except that here I override the image we have created an image to run faster which already contains almost all the packages we need for this image so we use it and it overwrites the previous configuration in the open stack provider same thing we give it a name we directly assign the floating IP and we attach this instance to another network which is net front so both my instances are on different networks ok so here I just go back so this is the log of my vagant app command and here we are launching the server with the following settings means that we have resolved everything you see that we have the image that is in the vagant file and we have resolved the image reference as Guillaume explained before same for the flavor and for the network so I go in my open stack je peux le zoomer so I should have my two instances created they are both created we both have an IP address the volume that was created before is attached to the Mongo back instance and in access and security I see that I have two keepers that have been generated and if I go back to my shell and I just look at the content of the vagant directory I have the same keeper that is in the metadata folder so this we generate one keeper per instance because when you want vagant commands you can specify on which instance you want to want something for instance I could just vagant up Mongo back and I can proceed per instance I can show you the network configuration so I have my two networks net back net font my Mongo font is attached to this one and my Mongo back is attached to the next one so what we do now just check command line that my instances are active and I will just destroy ah no go to the web interface oh yeah so the goal was to provide a web interface for MongoDB so we will at least show it so here I just take the floating IP of my Mongo font and I have access to Mongo Express which is just a simple UI to visualize your MongoDB database and if I go in my collection cars I see the two documents which I created before in my vagant file in the provisioning script so vagant destroy I love destroy instances so vagant destroy and it should be really fast deleting server one deleting server two and it's done and if I'm fast enough we'll see that the instance are being deleted right now everything has been destroyed the provider we remove everything that was created by the provider it means that in the key pairs on Nova you don't have anymore the key pairs that were generated so you don't have a stack of key that keeps going when you run your development environments and here same in my current folder I still have the folder for my instances which is empty and I think that's all now we'll talk about shareable environment if you want to provide an environment for your team for instance you will define a vagant file with a 1, 2, 3 N machine and you vagrant up and you want to give to your team the capabilities to manage this environment with a vagrant SSH or a vagrant destroyer it can be useful to do that and if we try to it doesn't work if we want to do that let's go with an example it will be more clear if I am on a machine A and I run a vagrant up with a specific vagrant file it will spawn an instance of open stack and then another developer from my team which is on another machine and he wants to do vagrant destroyer it won't work because he don't have the vagrant meta data the dot vagrant directory Julien showed before and what we want to do is make this vagrant destroy possible so to do that we introduce a new plugin which is under development and it will be soon open source at this address the idea is to vagrant up like before and then we want to store the dot vagrant directory on an external storage system object storage for instance is a good candidate and we can run a command vagrant take away push to store all the vagrant meta data then on another machine I will take a vagrant take away pull to get the information and then I can work on the machine B as if I am on the machine A and do a vagrant destroyer SSH or any other command I want this can be useful to work in team as I said before and it's also useful when you work from different computer for instance I often work at home and I create environment and then when I am home I want to destroy it to continue to work on it and I often zip the dot vagrant send it manually and get it back and it's not really optimal so it will be in GitHub in a few weeks and yes sorry but the SSH private key are stored in the dot vagrant directory ah for for this system we don't implement the authentication mechanism but I think it will probably be symmetric symmetric encryption and the key must be already shared between the host of course it's a kind of master key actually we hear when we say push we just zip the vagrant directory and send it so everything that is in the vagrant directory will be available including the private key that was generated ah that was the point you can you will have a storage system actually this will be not a plugin but a set of plugin we will provide a plugin vagrant take away we implement the mechanism of pull and push and then we will implement providers plugin for vagrant take away basically it's just implementing an interface implementing method push and pull and if you want to do this on github no problem for doing that actually if I understand the creation if you have a project on github you don't want to store your vagrant directory on your gith repository because you don't want to share your private key with anyone so here we will have some authentication to have for the storage system yes ah not yet I think ah at the beginning it would at the moment it was a pattern name but now I think it's a fixed name but ah yes it's interesting to do that actually everything in the vagrant file is ruby so you can just write a simple ruby function to do that let's go we just finish and take question after I think ok so just to talk a little about the roadmap what we want to do we have some area we want to improve the first one is to improve the private instances usage right now for each instance in the vagrant file we assign a floating IP and we work with this floating IP to configure, to provision anything what we want to do is to have for a multi machine environment to have only one floating IP we have thought of two way to do this first one is to have a moving floating IP that we assign to the instance we want to provision then when we want to provision another instance to just move the floating IP the second way to do this is to have a proxy server in our instances that will be that needs to be connected to the other instances and we could do all the configuration for this proxy another thing we want to do is to upload the images in glance automatically right now in the US image configuration you need to give the name of an image that is already uploaded and available on your glance catalogue so we want to be able to in the vagrant file give a local path or URL to automatically upload the image in glance and we want to manage snapshots both volume and instances so if you want to contribute first thing if you are a cloud provider we'd really like to inform you because as we heard since Monday there are many ways to install OpenStack, there are many ways to configure OpenStack and we haven't tested the provider on all the different options we have tested on some that are available to us but we really like to test it more broadly to everyone that has an OpenStack cloud developer, same thing test the provider and of course contribute code we have added a label for all the issues in github that is quickwin it's like the low-end gig fridge label in launchpad for OpenStack projects everything that is label quickwin is a simple fix it's related for people that want to start contributing of the project so if you want to just have a look at it go on github for the issues and look for the quickwin label as I said everything is vb, vb and plugins have to be written in vb so everything is on github and thank you for your attention and if you have any questions my only question was maybe I missed it but how did you actually import the settings you need to access your cloud do you just source a file or how actually the credentials because this is my configuration I just give the kiston url and then we resolve the catalog in the response and we have access to nova, neutron but you're using the environment just not to show my password you have an issue to automatically detect this mailing list discussion before the summit talking about various vagrant providers for open stack I'm sure you guys are aware you're not the only people that have taken a stab at this so there was some talk on that mailing list thread it seemed like it would be a good idea to bring this stuff into stack forge try to bring a few projects together it looks like you guys have a lot you've done a lot, you've got a long way to go would you be interested in moving on the stack forge and trying to start it did you guys see the mailing list or are you involved in that there's a syntax that you used in this file where you did a bit shift that I've never seen before you were updating one of the dictionary tell me that it's ruby I just tried it in IRB is networks a dictionary is that a dictionary update the truck is in no way this syntax ah, you just push anytime in the array oh, it's a list and actually in the provider the list is already initialized it's initialized as an empty list as an empty list and we just push anytime in the list volumes so in some of the vagrant machines that I'm managing I would like to be able to have just give me a volume of this big and I want it to be associated and destroyed with the instance we have an issue I think I record it for what I think to do is to put a volume name and if it don't find a volume with this name we created it and if a volume exists just attach it just I didn't show the page we explain a lot of options but we support many many options for instance in the VAM configuration you have 80 zones, security groups, user data we are adding more everyday but if you think something is missing just look at the readme and you will see maybe the option is already here hi great work by the way we happen to use another version of a vagrant opensack provider that you probably have heard of by now so my question and I hope I don't come across as rude or anything but why did you start your own thing instead of building on top of what already existed it's a good question at the beginning we first tried the other plugin but it was I think like one year ago and little more in February January and the plugin was not really active and we had a lot of ideas and we thought that if we make a lot of requests we're not sure it needs to be accepted and there were no tests on the provider wanted to have a full tested project and we had a lot of ideas so we take the choice to create a new one so technical reason the provider was using fog as dependency fog is a multicloud will be library and we are not using it because we wanted to remove this dependency wanted just to have a simple API client to have to do really what we want on the opensack to be really open stack specific and not use a library that is common to other clouds and for instance we only support Keystone API version 2 but we plan to support the version 3 and I think even now fog does not support the Keystone version 3 so there are some limitations like that and we wanted to get rid about that so if you have a look at the source code you will see that the client the client code to call the API is really simple because the opensack API is well designed and it's simple enough to call it directly we just wrap the API code this is for getting all the floating IPs four lines of freebie and we can do anything specific to open stack now we don't do that we can do it with the script yeah it's a 202 accepted it's an asynchronous HTTP code so the question was actually I will repeat the question the question was when I did VagonDestroy we had the response from the CLI so delating server but when I was in my web interface the instance was still in state delating so the question is why do we have this so it's quite simple we just do here an HTTP code on the destroyer endpoint don't remember and once we have the 202 accepted and swear we just go and we leave the the open stack do it's job but we don't check for the it's actually deleted actually we have the same problem if we for instance type VagrantSuspand and then you type VagrantResume you can try to resume the instance or it's still suspending so you get an error and this is a bug file in your system it's under development to correct fixer is in the room yeah sure yeah sure yeah yeah yeah we had the question we had the question at Numergy but the problem is where we want to set the line we like to be able to use it template but only for the configuration of your for instance if you want some network some router, some firewalls we think about adding it but not set right now actually starting point is Vagrant is to make it easy to set up an open stack environment and when you use Vagrant you actually don't want to know about two technical details about the underlying system and when you're using it it requires a lot of knowledge about open stack so I think it's a bit beyond the scope but we often have the question so maybe we can add it for advanced open stack users yeah I think it's interesting because we often have the question I had a question about the take away plug-in I guess you guys are still working on it's kind of a separate use case but after you run take away push and you sort of stash the instances and the sort of thing if you run Vagrant destroy on that same host will that tear it down or is there a way I could stash a Vagrant environment for some other developer to check out the stuff I've been working on while I move on to the next ticket actually it's not fully defined but first thing if we wanted to do a separate plug-in because actually Vagrant take away can be used with other systems that open stack you can use it for with AWS for instance yeah what we want to do is have the Vagrant take away plug-in and add some hooks in our provider where we will say when we do an action that modifies the Vagrant directory we push to the storage system and so everything is always synced between the two instances the configuration can be activated that is activated and if it's activated open stack provider will check if the plug-in Vagrant take away is installed on the system it will always sync with the external system the state of the machine multiple versions of the same it's not but it's a good idea multiple versions of multiple instances with multiple versions of your environment yeah that's a good idea do you not thought about it other questions thank you very much