 Hi everybody, my name is Jamal Kukuru and I am a member of the European Galaxy team at the University of Fireball in Germany. And today in this video I will show you different ways to have an additional five space to your Galaxy server. Here I am in the web page of the Galaxy training material, and from here we move to the Galaxy server administration topic following this link. The tutorial of today is this one, the distributed object storage tutorial, and just before to start with it, I want to advise you that you need to know about something about Ansible and you need to have a Galaxy server help and run. If you need help with both of them, there are other two tutorials here. This one Ansible that describe you what Ansible is and how to use it, and this other one that show you how to install a Galaxy server with Ansible. So here we are, the distributed object storage tutorial. We start by the end of the Galaxy installation with Ansible tutorial. We will use the playbook obtained following this tutorial. And here we are. First of all, so you need to add some new storage to your Galaxy server. Galaxy has a technology named the object store that is kind of a structural layer that the couple galaxies business logic from the details of the storage solution of your choice. This means that the object stores make makes it possible to store data on a wide variety of persons as media spending from local storage to cloud-based solution like Amazon S3 or OpenStack Swift. And the first step, we will see how to create a hierarchical object store into your Galaxy server. The hierarchical object store allow you to, a few words, allow you to read data from the first backend where data exists and allow you to write them always to the first backend of the list of the object store. So as a first point, we need to modify our playbook adding a new variable that let Galaxy knows where is the object store configuration file. This one then move into the shell of the virtual machine where I have a Galaxy server happen running and here we have a directory Galaxy where is the playbook that installed the Galaxy server into this host. So, here we have a file with all the ansible variables and this new variables the object store config file that is one modification to this file but then we need to also instruct Galaxy to know where should find this file and the ansible playbook where to retrieve the file to put in that path. So we move. Moving the Galaxy config templates, here we have the new configuration, the source where the templates and the character ansible playbook should use and the destination where the templates should be written. And that's all for the ansible variables. Then we need to know we need to create the new templates, create a new file and the templates directories, copying from the tutorial. Here are the details of our files. So you can see here is an XML file, you have an object store entity here type your article and the back end section that define two back ends. One with the new data and one with the old data. So this part is where actually the Galaxy server is writing is written is writing the data set. And then we added a new part here, slash data to where we want from now on the Galaxy server have to write the data set. As you can see there is also a tag here holder that define the order which the backend will be used by Galaxy. So, that means that Galaxy will use this backend to read data, if there are data there. And we use this backend is that to read and write data. To make another modification instead this time to the directly to the playbook. Because we need to create the directory the new directory that we will use as a for for for the new backend. Here we have the data to directory. So, now we are ready to rerun the playbook. And that we are at the end, we move to the Galaxy server and try to turn some tools to see if the data set that will be written to the new backend directory. Here I have my Galaxy server, as you can see I have uploaded before a data set. We can check the details of this data set. We can see here that the path is the full path of this data set is into the slash data path. So the whole one. Here we can see that the Ansible playbook had the new file. It finished to run and then we can now move to the Galaxy server and verify if the new data set will be written into the slash data to path. Here I have a simple data set collection of data collection of high samples. For example, we can filter data from this data set for example. There are several species of iris. This data set setosa, versicolor and virginica. For example, I want to filter out the virginica. Rose from the data set and the column is the number five. Okay. There's a very small data set so the tools will run in a few seconds. We have the result, we have only the virginica rose and then we can check the path. Here we are. The data of this data set is less data. So, Galaxy started to write the data set into the new path as expected. And that's all for the hierarchical object store. After that, we can instead prepare a galaxy to use a distributed object store. Rather than searching a hierarchy of object stores until the data set is found, Galaxy can store the idea, the database of the object store in which a data set is located when the data set is created. Again, in a few words, distributed object store allow you to read data from the first weekend where that exists and to write them into a pseudo randomly selected background. So the pseudo random selection is based on the admin specified weights. So as you can see here, the details, we have a different type of the object store distributed one. Again, backend section. That's for our object store configuration file. The backend section where we have two backend defined again with the new data and all data. But instead of the order tag, here we have the weight tag. That described that a sort of holds that galaxy can use to choose which, which backend use in this case, the same way. So, galaxy, galaxy, galaxy will, we're right to this backend with the same. Okay. So we can copy this configuration moving to our server. And we need to modify the templates. And then we run again, the playbook in a few minutes we will have the new configuration happen running in our in our host. So the playbook finished it and we can try the new configuration in the galaxy server here. So here the idea is that I can start some tools and the result should be written sometimes in one backend and sometimes in the other. So let's do this job again. The first one has been written to slash data to, but instead of the second one. Again, slash data to the third one instead and slash data. And, and so on with the other slash data, slash data to. Okay, so it's clear. It's working. So we have a configured galaxy to use a distributed object store and we have seen that some tools start to write data set into one backend and others to the second. That's all for. So if you want to see if you want. You can find more information into the object store configuration example that is available to the galaxy project. There is also a good web page in the galaxy community hub. Just go to the to galaxy project.org and search for galaxy object store. Also here you can have more details and some example of different configuration. That's all for me. I want you to go to the end of the tutorial web page and where you can find the feedback section and please give us your feedback about this tutorial. This allows us to prove our materials. Thank you. Goodbye.