 Sometimes you get questions on the live stream, so I'll post the link to that here in Zoom chat just so we know where it is. So thanks everyone for joining the meetup today. We have Sonak Roy with us today. He is from Accenture. He's also one of the Hyperledger Bevel maintainers. And today he'll be speaking about Automated Hyperledger Fabric Network with Bevel and Bevel Operator If you have any questions throughout the event, we certainly encourage you to ask. You could just type your question in Zoom chat. And then we can take those as we go. And then if you're watching this on YouTube, you can type in the YouTube chat too. And with that, I will hand it over to Sonak. Yep, thanks David and welcome everyone. Yep, so this is more of a workshop as well as a discussion on how to use Hyperledger Bevel with Hyperledger Bevel Operator Fabric, which is which we onboarded into Bevel at the start of this year, I guess. And yeah, so this is more of an automation rather than like doing the manual processes that you generally follow when using Hyperledger Bevel Operator Fabric. So I would, yeah, thanks for everyone else who was, you know, kind of not speaking beyond mute. And then you can always ask the questions on this Zoom chat as well as YouTube chat. I think YouTube chat is preferable because it stays the question Zoom chat will disappear after the end of the session. But yeah, and I'll ask Subhijit, this is my colleague from Accenture as well, he's here. So I'll ask Subhijit to, you know, check keep an eye and maybe David as well to keep an eye on the questions because I cannot see the YouTube questions. Right, so I'll start with sharing my screen. Yeah, so this is basically my dev environment. And just before we start, I'll give you a brief on Hyperledger Bevel and Bevel Operator Fabric for the new joiners or newcomers who are not that experienced with Hyperledger Bevel. So Hyperledger Bevel is an automation framework which which you can use to deploy different DLT networks like Hyperledger Fabric, Hyperledger Indie, Bezu, even Corda, Enterprise Corda and Gokorum as a format of substrate now on your choice of Kubernetes cluster basically. So it's production worthy. So that means we Hyperledger Bevel can be directly used in production. We have secret management via Vault and we have continuous integration and delivery via GitOps. So that was the first, you know, the introduction of Hyperledger Bevel when we used it. And then recently we also incorporated Bevel Operator Fabric into the Bevel kind of umbrella because that's also a deployment tool you'll use to deploy only fabric. So the first difference between Bevel and Bevel Operator Fabric is that Bevel Operator Fabric is only deploys fabric whereas Bevel you can use to deploy other networks as well. So how it generally works with Bevel is for a very simplistic approach. I'm giving an example. It's not actually that, that that simple is that we, you have a network YAML file which is which called network. We generally in Bevel terms we call it network YAML. So basically that's a configuration file is a YAML file where you write all the configurations that you want the network to be in. And then you, we have Ansible playbooks. So you provide that input as an input to the Ansible playbook. And like say example, the playbook is Deploy Network or the playbook is Create a channel. And once you provide that and then you just execute the playbook and by the, then Bevel that automation will do all the setup like certificate creation and then updates and user creation. For example, in case of fabric and then deployment of peers, orders or validator nodes in case of this. So that's the summary. Bevel Operator Fabric is, as I said, is an operator framework. So the update on Bevel is that we are trying to move to a more operator Kubernetes operator framework kind of option. So the first foray into was taking into the HLF operator and call this is now called Bevel Operator Fabric. And then we aim to with your support with the community support, we aim to get support for like Hyperledger, Bezu as well as Corda as a similar concept using operator. Say you run it using QCTL, HLF and then create peer. That's the sample that you have for operator fabric. So with that, so that's the basic is there, I can see some chats. Is there any question or just hello? No question. Just asking for YouTube links. All right. Okay. So with that, I'll start in the description basically. So as I was saying, Bevel uses this network YAML automation and also based the core Bevel I mentioned uses Vault for secret management where you store all the certificates, the public keys as well as the private keys and also some passwords. For example, you have a CouchDB password or a MySQLDB password. You can store that and then securely get it into your Kubernetes environment. And also it uses GitOps. Now, GitOps is a concept where you check in, it's basically operations via Git. So you check in on update of file and then GitOps, we use the flux operator in that case for basically in Bevel. Then flux operator will get the latest check-in that you have made from that particular bunch. You can configure a specific branch. You have to configure a specific branch and then it will update the Kubernetes cluster with the latest from that Git. So what happens is when you do the initial deployment of the network, for example, you basically just create files and check it in and then flux will take it from there. And then the advantage with that is if you want to change it, for example, you want to increase the memory or the CPU from a Kubernetes point of view or change the Docker images that you are passing to the Kubernetes to the Helm you can just update the files and then do a Git commit and Git push. Then flux will automatically take care of you. So that's the concept of GitOps. But then when with operator, you don't need to do that. Operator is a different approach. I guess many of you have used the operator here, Bevel operator fabric basically already and it comes with all these commands like Qubectl, HLF, you have to install more CLIs locally on or another Kubernetes cluster the operator basically and then you run the Qubectl, HLF commands to set that up. It doesn't use need vault or GitOps. So you can use the same commands to update, create update the network, for example, adding a peer or removing a peer or updating a peer basically. Okay. So coming with that, so I'll show you the difference first between these two. So again, I'll explain how taking into account that there may be some new people here. So Bevel is this is, it's called BAF demo, but it is the Bevel repository. And it has these platforms folder and under platforms, we have all the supported platforms, Basu Fabric Indy, Substrate Corda, Enterprise Corda and Quorum. Shared is like a common platform, common for all. So like all the common program, common code is here and all the specific code is here. And then under Fabric, you will have these charts, configurations, images, releases and scripts. So charts contain all the Helm charts. Now our Helm charts are now available on GitHub as a Helm repo as well. And then you have the configuration, which are the Ansible roles and examples. So in that you have under configuration, you have the samples folder where all the different samples are provided. You see a lot of samples for Fabric because Fabric is the most popular used in for Hyperledge Bevel, a network that is used. And hence, you have different, we have provided different samples for different operations. So in that one is the, the newest one is the network operator Fabric YAML. And the normal one is the Fabric V2. And I've just compared the two so that you can see what's the difference. So if you see the first difference is that the version of Fabric that is supported. So by default, Fabric, Bevel operator Fabric supported supports 2.5.3 as well. We are yet, we are from a Bevel point of view, not yet done. Next thing is still ongoing. But so 2.2.2 is the latest one that we supported, but I think we'll be finishing 2.5.x sometime soon. This is the first difference. The second difference, of course, is for using operator, you have to use the ENV type as operator. Here ENV type was anything because you will deploy on different clusters. So depending on the cluster or the environment, you can, you can name it as such. But for, for using operator, it must be operator. So this is a must as I mentioned it as do not change this. And the proxy is STO whereas the proxy for normal Bevel was HAProxy. Why is STO is because HAProxy, sorry, Bevel operator Fabric itself only supports STO right now. I didn't want to change that to HAProxy and create all different, you know, branch out of it. So we're just supporting STO as well on Bevel side. Retri count is either retry for checks. I don't think it matters. These are matters for operator Fabric because you don't have retries and all generally in this. The rest of the, you know, configurations are same. Between the two, you have the consensus mechanism. I think anyway, for 2.5, the only consensus is raft. But I've kept the format same. Then you have the orderer section where you also have the orderer certificates. It can be stored locally. For the chain, for the chain course part is not, we have, we are not yet supporting the chain course via the Fabric operator Fabric. But of course, it is supported by a normal Bevel. But the idea is that you can, you should be able to use the operator, the Fabric console, which is supported in operator to create the, or deploy chain course or its own specific commands to deploy the chain course. So I've not made it in an kind of the automation way. But yeah, if anyone is interested to incorporate that, please feel free to create a PR, an issue and a PR. So rest are kind of same. The major difference that you'll notice is that there is no vault section and there is no GitHub section for the operator. So as I said, in operator, all the secrets are stored directly as Kubernetes secrets and there is no GitOps. So you will use the just kubectl hlf function commands to manage the network. So you don't have GitOps and you don't have vault. So that's, those are the mainly, I would say, three major differences between current network YAML and the operator network YAML. And I'm using the same example of our supply chain which has like five organizations where the first organization, the first organization is the order organization and you have like four PR organizations each having one PR. So that's, that's the explanation. And right. Any questions for now? Let me check. I think it has most of them have been replied by Suvijit. Anything, Suvijit, from YouTube? No, nothing as of now. Okay. Okay. So with that, so that's the examples I already have formatted, you know, filled the network operator fabric. It's, yeah, network operator fabric here. So this is the example. So what you will generally, same as with Bevel, what, what you do is update these things, these username passwords, et cetera, here in the network YAML file, and we'll pass that to the site.yaml, which is our master or the main second. That is our main playbook. So you'll also use your update, your proxy, because the STO should be configured according to the proxy. And, and then what you will update is mainly because I'm using AWS here. So our cloud provider is AWS. So you will also have to provide the AWS access key and secret key. And, and the details to the Kubernetes, basically the Kubernetes cluster region. I don't think region is generally used, but mainly the context and the cluster config file, which is the kubeconfig.yaml, so those paths. And yeah, with that, you are ready. Of course, if you want to add more organizations or delete some organizations, you can, you can delete the organization or create another organization. When Bevel was designed, it was mainly for each organization being deployed on a different cluster. And that is why you have these getting repeated. So you can follow the same model in operator as well, or when using operator fabric, you can have multiple organization, multiple clusters for each, for the same network. But in, in, of course, in, in this example, I'll use the same cluster for all the organizations. But it should, it will be applicable, accessible from externally as well, because we will be using STO as the, as the proxy provider. Right? So with that, so this is the command that we use, which is same command as in, as in Bevel for deployment. So Ansible Playbook shared platform shared configuration site.yaml, that's the main yaml file. And then I'm providing a path to my updated network yaml, which of course doesn't have cluster region, but actually, as a US one, and then all the passwords, et cetera. And I will execute that. And so what this playbook does is a lot of different things, of course, but for initially, it will check for the validity of the, that's what is happening now. It's checking for the validity of the network yaml using the, the AJB validate. And then we will install STO, because STO is not, was not, may not be, not have been installed, will install STO. It will also deploy the HLF operator on the cluster, which is, which are, those are the prerequisites anyways. And once that is done, then it will, depending on how you have configured the yaml file, it will create like the order organization and the peer organizations. And after that, it will also create the channel. And do we end that channel? Because as I said, the chain code deployment, we have not support yet, but please feel free to, if you want to do that yourself, you can feel free to do it. And we can create an issue and, and we are always open to new peers. All right. Well, this is happening. Any burning questions? Nothing on the chat though. So yeah. So right now, as you can see, we are installing the STO ingress controller. So I have lens here as well, which you will, I'll show on the, so that you can see what is happening on the cluster. So as you can see, the STO pod is getting deployed. And I've deployed the STO as how it is required by the bevel fabric, operator fabric to be deployed to be configured. So that's, that's how it is configured. It's more or less default. The only thing that is, is that we are using the default ports, which is port 80 and 443. And that is why you see that the peer ID is mainly or the orderer GRPC addresses are have 443. In the read me, I have also mentioned that this 443 is mandatory. Because if you remove this, then fabric doesn't understand that, you know, it says that the port is missing, especially because it's actually trying to access the GRPC port via this address. It is a GRPC address. So it doesn't automatically think that it is a 443 port. Sean, there's a question from Dominic asking about why we don't support deployment of chain codes yet on operator fabric. Oh, no, that is because we don't have time to do it. We don't didn't have time to do it. So if some, if you are able to do it, then yeah, you can send a PR. It's open and you have all the instructions on how the chain code works. Deployment works on on the bevel operator fabric. Anyways, and you can, I mean, this is basically the automation part, as I was saying, because if you have gone through the demo videos of HLF, HLF operator, bevel operator fabric, you would have noticed that it is like you have to give the commands step by step, like create, create order, create CA, etc, etc. But this is the automation part. So you after this net basic network is created, you can deploy the chain code by using the commands directly as has been specified in operator fabric. So if C now is trying to create a CA server for org, for each org, and I'll go and see what's happening on the lens. Yeah, so again, all this basically automation takes taking care of everything. So we have each namespace for each organization. That is how bevel works. And in each namespace, it is trying to create the supply the CA pods. So yeah, so they are running. And if we check the operator side as well, which is which appears and has this HLF Kung Fu software. Yes. So if we see here, you can see that yeah, the the CS have been created. And the status is not showing because yeah, so you can see the status is running. So that means they're successfully created. If there is any other status, then that means it is basically not not working properly. Can check the logs as well. I can see the order is getting created now. And you can you will see the very difference different in the speed that it is happening. Because operator fabric, of course, is much faster because you are not not using not doing the vault authentication. And first of all, in normal bevel, you will have to first create or create the authentication between vault and Kubernetes and then do everything. And secondly, we are not using GitOps because GitOps is like a polling kind of informed method, which will pull after one minute or two minutes. And only then you will get this and that is why we have so much weights in in in bevel, usual bevel. But in here, it is it's very fast. It's command just like giving a command prompt, it takes some seconds, as you see, like the peer and order, the peer is taking some time because it's provisioning the the couch DB, etc. Like as a PVC. So it's taking some time, but it is it is much faster. And then bevel, mainly because they were not using GitHub services. So yeah, so that's the order one, two, three have been set up. Now if I go and check the actual services, so you have this, you can see that the orders have been created and this state surrounding and the age, I just created right now, it's not something that I created earlier. Can now the peers also should be created. Some of them are not yet. Yes. So the peers are also here. We have, as per my organization or my network gamble, we have four peers, each only peers zero. So one peer each organization. So that these are pending. Yeah, as you can see, the status is also changing. Yes. So now now they're running, and now all the peers should be running. I will to log of the peer. Yep. So the peer has been has run, so has been created. Now we are creating the channel. Same concept as we do for for bevel, you create all the peers and then we create the channel channel configuration is at the top. So this is the channel, all channel is a channel name. And that's what you see, it's trying to create this, this channel, the channel should be created now. Yeah, so the channel is also created. See here, it says all channel is running. And you can see in warehouse peer logs, that the all channel Genesis block was created. And I think that's all. Now we'll, it's just doing all the, all the things. Yeah, this is basically complete. So you see, it's super fast in that way. As well as I, yeah, so after main channel, I think the final thing that we do is create the follower channel, which is basically kind of creating the anchor peers. So if you see here, yeah, they were all they're all running. And hence you have this message saying that the membership view has changed. And this is the current view, which means this, this is warehouse peer. So warehouse peer has connection to carrier store and manufacturer. Yeah. And then yeah, basically that's pretty much we're almost done in half an hour. I can, I can explain how the code and all that works. And maybe that will inspire you to add the support for, for chain code, chain code by your, by yourself or someone who is interested to get, get their hands dirty, can, can always help because we always look for contributors. Right. Any questions or other discussion? There you go. Yeah. Shannan, there's a question on the chat. Long question. I think you should read it or do you want to read? All right. I'm, I'm all right. How much is it possible to use this approach in a productive multi-company setup, being that companies have different separate infrastructure? Yeah. So this one definitely can be used. Of course, we have not done a POC as such, but it, you most likely have to do a POC first, that it will actually work. But in general, from the current, we have a multi, like both order and peer scenario as well, but that's supported on the, on normal, you know, usual bevel, not operator fabric. But in general, what I would go is how, how you go about deploying basically. So I would say, yeah, deploy the orderer first and then share the order certificates with, and the addresses, the public certificates, definitely, with, with the other companies and then they can deploy their own, just the peers, for example, and use the order certificates. And yeah, you can, you can definitely use different Kubernetes versions, but yeah, keep in mind that bevel is supported on one point. I think one point current is 1.23. We'll move to 1.24 or five directly once we upgrade our ambassador, because that's the main upgrade that is going on right now. But yeah, 1.23, it also works on 1.22 anyways. Yeah, you're using kind, which is, which is fine. I think, I think the main problem that we faced with kind is memory issues and the actual deployment of kind itself, after the kind, because we use kind and also mini-cube. And there the maximum we could get, especially for fabric, was, was just to deploy the one orderer with one raft node and, and two, two peers. After that, it would crash. But yeah, if you have a more powerful machine and, you know, a huge memory like 64 GB RAM and all that, then you should be okay to use kind. But both bevel and operator fabric is, is mainly designed for, for actual Kubernetes environments or more production environments. Okay, so in the meantime, I'll show you how actually it works, how we kind of go about, go about the deployment. So all, all our playbooks are here under configuration. So all these are all playbooks, which means they are, these are the, basically the operations that you can do using the Ansible command. We are trying to move away from Ansible, but we couldn't find any other better replacement, which you will use just one command other than shell script, which you will just use one command, and it will do everything automatically. The other option, as, as you know, with operator fabric is that you have to use multiple commands like you have to use a, or just write a shell script again to have say orderer one, two, three, four, etc. But with, with the current design that we have in bevel is, is you can just, you need to only change the network YAML. So if you want another orderer, five orders, I've created three. If you want five, you just add another orderer with all the configuration files, information, and you can just copy paste and change the name of the orderer to three, four, and five. And if you deploy using this site.yaml, it will work. And you don't have to, you know, run the command again and again. So how the network operator, this is deployment file that we, that actually ran behind the scenes. How it works is, we have a temporary build directory where the temporary files are created. So that was, that will remove so that, you know, when you're deploying, you have a fresh installation. And then, of course, it creates the first of all, it will create the namespace for each organization. And then it will create the storage class. In our case, the storage class was already created. So, so it was, it didn't create. So that, all that check is also here in, in our Ansible roles that if something is already there and you are doing the same thing, it doesn't actually try to do it again and waste time. Yeah. And then it creates the CA server and then registers the user the, for each, because you have to use, register a user to use the CA. Then you, then we are creating the order nodes. Then we are creating the peers. And then we have to register the admin users for each organization. Then we create the main channel, which is the all channel. And then we do the join channel, which is how you do use, is basically creating the for follower channels. And that's, that's all, as I said, we are, we're finishing at this level. Now all the code or the configuration, I would say is, as you see, is in this folder roles operator. So these are the files. So you have operator create CA follower, et cetera, et cetera. So if you, if someone wants to add a chain code, create chain code or, you know, update chain code things, you have to, you can do it here. I'll give a simple, yeah. So CA server, I'll give a very simple example. So it's just, as you see, it's just a single command. So if you're running it locally, like without bevel or Ansible, then you will most probably, you know that you will most probably use this command, right? Directly here in your command line, saying QCTL, HLF, CA create, blah, blah, right? And that's what is, it's all doing. So it's just that we are providing an abstraction and reading all these parameters from, you can update here, you can add it in the network YAML as well. I don't think the, the GI is the gigabits can be a passed on. It has to be, is hard coded more or less. But yeah, you can, you can pass the URL. You can pass the cloud provider storage class name, basically we're using AWS. And then then version, which is, this is the CA image version. So yeah, all that is basically parameterized. Similarly, if I go to orderer, so orderer, yeah, the only thing that I have added here is a check that first checks that if the CA server is available, this is the check. Because if it doesn't, it's not available, then it should not go forward. Because CA is important for orderer to work. So once the CA server is available, then it, yeah, again uses the same QCTL, HLF, order, or the node create command, which is provided by operator. Yeah, and similar parts. And the only difference is that I've looked it over how many ever orders you want to create. And that is why I said, like, if you just increase the number of orders to five from three, it will, it will just work. You don't have to run this yourself. And there is a wait here for the orders to start. And then once the orders are started, we get the TLS certificates. As I said, that these are the public certificates that you will generally use in your production environment that you will share offline with your other peers so that they are able to connect to the order. Because fabric by default is secure. So in that case, if you just have the IP address or the order address, it will not work. You will also need to access, have the CSR certificate. Okay, so there was a question, then can you share procedure or script you use for kind setup? No, we don't have, we don't use kind. We have some previously used mini cube, but we don't generally share the setup because the setup always differs from machine to machine and operating system to operating system. So you'll have to follow the actual, you know, the guidance for kind itself. Otherwise, yeah, we have tried it earlier for many years since BAF. We used to call Bevel as Blockchain Automation Framework BAF. Since then, the same questions have come, but unfortunately, it had never worked. It was not one code to rule them all kind of scenario because everyone has a different machine and a different version of mini cube. Mini cube also or even kind keeps on changing. And yeah, it's very difficult for us to keep up with those. We'll rather focus on the development of Bevel itself. Yeah, so there was a question like about the other planned supported, etc. So certificate renewal backup recovery. I'm not sure, Shubhajit, correct me. Is that, are these supported in operator fabric? I think the certificate renewal is there. I don't think recovery or backup is there, but I'm sure about the certificate renewal. Yeah, so the concept is that anyway, we have not tried, in this example, the demo that I gave you, we are not trying to redefine operator fabric. It's just whatever features operator fabric has provided. I have used or we have used it, a subset of it to make it easier. So the certificate renewal and all, if it is already supported by operator fabric, you can just run it after these as well. You can just type whatever is the command cube CTL, HLF certificate renewal. I'm not sure. It's not on top of my head. That command to do your certificate renewal. Yeah, as like similar here, because you will know what your order images and order names, etc. have already been created. So you can use them and even your STI is running. So you can use that directly. Backup recovery, I guess you were talking about the whole Kubernetes cluster backup or recovery. In that case, yeah, for both for Bevel and operator fabric, I don't think it is kind of inherently supported in there. It is more or less an operation or like a network operations kind of thing. So you will, when you will anyway have your own agency and processes that you use backup the Kubernetes cluster itself. I think there are multiple tools available in the market, which using which you can backup whole Kubernetes cluster. And going back to the other exam, you know, the same question, if we go back to what Bevel in general supports, as you see here, we have so many operators, so many separate different playbooks for the use of operators. But we'll also try to move forward, moving forward, we'll, you know, not use the Ansible, as I said, in all the cases, maybe we'll only use the Ansible to deploy the basic network, like how I did, and then use either the already existing fabric operations console to deploy and then do the renewals, et cetera, deploy chain code, for example, with the life cycle, I think it is very easy to do the chain code deployments using operator, sorry, fabric operations console. But yeah, so these are the, you know, these are the things that we now support on Bevel. You have, you know, adding an organization, adding a peer, things which it was explained on Discord recently that what is the difference that adding organization is adding a whole organization and adding a peer is adding one new peer, say peer one or peer two, to an existing organization. We also have the chain code upgrades. We also have external chain code support now, where you can deploy external chain code. Of course, the Docker image, et cetera, the coding of the, of the chain code has to be done by yourself. According and packaging of the chain code has to be done by yourself is here, you're just deploying the network. Then yeah, user certificates, this is quite an old feature now on Bevel. You can, you can manage basically refresh the user certificates because by default, Bevel certificates expire after one year. And we also did the setup, the cactus connector support. So basically you can deploy the cactus version of cactus connector on, on the same network so that you can go and connect, connect with other networks, connect from other networks into the fabric network that you have deployed. That's how, you know, provided by cactus. Any more questions, burning topics? We want to discuss any questions on, on YouTube? Subhijit? Is a question on chat about plans for adding more operational activity? Yeah, which I guess I already answered that. So the Bevel team is constantly looking for contributors. If you are interested to see certificate location, or I don't think laser truncation is supported by operator fabric itself. So maybe in that case, you'll have to send a PR for operation fabric first. And but the certificate renewal, et cetera. Yeah. So anyone who is interested, you know, please, these, these are the features that are already supported in operator fabric. But yeah, they're manual, not done via a single command like, like this. So if you are, if you want to see it as a single command, then you can all happy to please feel free to contribute. Or if you just want to use it yourself without contributing, you can anyway run as I was explaining QCTLHLF commands. There was a question about what is the overall goal for this tech. So interesting question. The overall goal for this tech, which by tech, I'm assuming you're saying hyper ledger Bevel and the operator fabric. So the overall goal for this tech is making deployment of DLT networks easier and consistent so that people are not trying to reinvent the wheel. They don't have to follow different approaches like Kubernetes, for example, or when you try to deploy core network or follow the manual steps in trying when trying to deploy a base of network. So we're trying to provide a single kind of similar a singular approach, which, which is Bevel to deploy your production, what the networks and you can do it via operator fabric as well. Because that's anyway the model that will support going forward. There was a question on support this on ARM processor. I'm not sure what what is the so you want to run Ansible on ARM processor? Is that the question Gangadhar? Right. So yeah, so I we don't test on ARM processor because yeah, no one has came up come up with with that request. I think there were some questions earlier that it is supported on ARM, etc. But yeah, if Ansible is supported, it should be. But our current code is mainly open to based or Linux based. And this is normally x86 processor. Yeah, so we are not we have not tested on Mac M1 or M2, because from our research, we don't think that a lot of network operations are happening from Mac, especially for production. It's this basically more or less Linux or Ubuntu. But you can I mean, we have in all the playbooks, you can not this one. Yeah, in this one, yeah, so playbooks, these three things are there. You I'm sure if you just update it with ARM in from install the OS and the architecture, these two fields, it's going to work, though we have not tested. Yeah, right. Yeah, Satish has a very good question. How do I configure the Ansible to connect to the k8s cluster in the network AML or specifically playbook? Yeah, so yeah, it is very good question. It is configured. The connection is via just these three parameters in the network AML. So you don't actually connect internally because Ansible has a lot of Kubernetes. What is it called plugins, I would say, so that you connect to the Kubernetes cluster. But we are using the local so installing Qubectl, etc locally, wherever you are running the Ansible from. And that is what side dot ML does. It's also installs the required prerequisite software, for example, Qubectl and Qubectl HLF plugin for the operator. So once that is done, then we just pass the connection context basically. And that's how you connect to Kubernetes cluster. And each the k8s part is separate for different separate organizations. So if you are managing your, if you have access to multiple Kubernetes clusters from the same machine, for example, this machine, then you should be able to deploy multiple Kubernetes, sorry, multiple the same fabric on multiple Kubernetes clusters. Is it possible to add a new organization in existing network? It is, I think it's, I've not supported it on the automation part, but with fabric network operator, sorry, bevel operator fabric, it should be able, you should be able to add a new organization easily into an existing network. Yeah, I think that's what we are doing anyways, when I run this command, or is it yeah, this peer, so here, as you see, creating the peer node, we are anyway kind of adding a new peer each time. So if you can, you have, you follow the same process of creating the CSR server for that particular organization. And then I deploy, or create the peer node using the kubectl hlf peer create command. And then the main thing is adding the channel, I think, or updating the channel. Any further questions? Okay, what channel can we seek support? Yeah, you can, the discord is there always. We have a, do you have a link for discord? Or David, discord is there, you know, you can, I think you have the access. Yeah, I just posted a link. There's a page on our wiki with a lot of details about how to get an invite and where our channel, some of the channels are. Yeah, yeah. So for both bevel, the traditional bevel, and bevel operator fabric, these are the commands, sorry, the channels. So if you post, if you can find some answer already, which have been asked here. And for operator fabric, this is the channel for you can ask questions about get support on operator fabric, just the operator fabric itself. Yeah, and yes, you have to get access to this channel. But I guess whoever is working with hyper ledger should have get access anyways. If your organization wants to organize a training or implementation. So I think training wise, we do, we do have these kinds of meetups, you can follow the meetup channels. I'm not sure which which hyper ledger channel you join, you can join, you know, join them and follow specific topics like hyper ledger bevel or space a fabric. Because you may be interested in fabric, so you can go through the training. We also have hyper ledger global forum, which happens almost every year. And where we do more deep dive workshops. For private custom training, I don't think we have any kind of David, do we have any kind of channel via hyper ledger where we can have a custom training? Let me get a link here. Just one second. So the Linux foundation does offer trainings. We don't currently have one specific to bevel, but maybe that's something Sonnec you and I should talk about when we think like there's a level of maturity and bevel is at the point where you know it's ready for that. But you can take a look at the training page to see what courses and certifications we do offer for hyper ledger projects. So that's something and we do have a training team. They do have the ability to offer if that's something you want to offer like onsite courses. But the main model of our courses is self-paced online courses. And again, we usually focus our trainings on graduated projects. But again, Sonnec, when you think that bevel is at the point where we should start thinking about training, we could talk about the graduation process and getting training going and everything. We are going to go for version one by end of this year. But yeah, it's not as the version one that we wanted. But I think it is we have enough users on that sort. I gather from the questions that we have on bevel channel itself and even operator fabric that we have a lot of users who face similar issues. So yeah, our training, I guess, yeah, we can discuss it separately David, that I think we can get training even if it is, you know, say non-graduated. But let's see. But I think in the meantime, the best thing are these series of, you know, you've done a workshop earlier this year, you've done this meet up. I think, yeah, as you said, if people want to look for, keep an eye on our channels, we'll do these periodically. You know, I don't know, Sonnec, when you're planning to maybe do another one of these maybe early next year. But I think for now going on Discord and looking out for these sessions is probably the best thing to do. And these sessions are recorded. So, you know, if you want to use this internally, you know, all this is public, you can use this session recording of this session internally for, you know, a training. So these resources are available. Yeah. And the YouTube channel that is hosting now that has all the trainings, right? All the meetups that is happening, you can just search from there for Hyperledger Bevel. For example, you'll get all the older sessions as well, which some of them were much longer because we did the whole network deployment, if starting from Kubernetes deployment. Yeah. So if that is all, I think we are good to close. Any more questions? All right. That's all then. Thanks, everyone, for joining. I hope this was helpful and insightful. Thank you for the questions as well. Definitely, you can understand that there is, you know, interest in Bevel. And I'm very happy to see all the questions. And hopefully I've answered them properly. And once again, as I kept on saying, we do need contributors. I know it can be a bit daunting to understand, you know, Ansible at first. But you can go and check. We are not using Ansible in a very high, you know, complex way. It's quite simply, simple way we are using Ansible. It's mostly as an automation tool, as you can see, running shell commands rather than writing shell scripts, I think. But yeah, if you want to automate or give an example of writing shell scripts as well to automate, say, adding a chain code or creating a new channel, I'm very happy to take that on board. We do have bi-weekly, on Mondays, we have the calls for Bevel roadmap and not roadmap, but the scrum call. And we have a roadmap discussion every three months. So please feel free to join them. Yeah, so I think Ansible, there is an Ansible, the commercial version of Ansible, which is already there. It's basically the part of the Ansible Tower. But then we'll see how, because as I said, we're moving more towards the operator model, or if not, then we'll directly just use, say, the Helm charts, use Helm commands, Helm install, to do the deployments. So that's the way that we are going forward. And yeah, if you guys are interested to help in that as well, then that's also very good. But yeah, we are also moving towards, say, directly using Helm commands, say, Helm install, CA server, et cetera. Yeah. Repo URL, I think David will send the video links and the repo URLs. And the Discord server link. Yeah. And the read the docs website as well. Sure. That's all then. Thank you so much. Hope, and yeah, we'll keep this going and we'll have more discussions. I think we'll try to do once every two months. So yeah, maybe in the new year. Yeah. Yeah, sounds good. Thanks, everyone. Thank you. Okay. Exactly.