 So welcome everybody to today's virtual Hyperledger Meetup. We are speaking about the Hyperledger Bevel 1.0 release in the road ahead. We have two of the Bevel maintainers with us today, Sonak Roy and Suvajit Sarkar. So I will hand it off to them and they will share with you about the release. Thanks, David. So yeah, welcome everyone to the virtual meetup. As David just said, and we all know here, we are very much excited that we have kind of come up with a very important milestone and a pivotal moment in our whole open source journey. We are coming up with the Hyperledger Bevel release 1.0. Before we go into the topic, let's just introduce these speakers. Let Sonak first introduce himself. Hello. Hi, everyone. Yes, so that's me, Sonak Roy. If you have interacted with me on Discord, yeah, I'm available there at Sonak of 17, 18 years of experience in engineering, currently for the past seven, eight years, mainly focusing on this distributor systems and blockchain and also the product owner and one of the original creators of Hyperledger Bevel. Yeah, that's my experience currently working for Accenture and more also like in the open source domain. And yeah, and Shubhajit. Yep, thanks, Sonak. Well, myself, Shubhajit Sarkar, I have around 10 years of experience in technology management areas. Currently working at Accenture, I'm a maintainer of Hyperledger Bevel, particularly in the areas of development and architecture. Yep, you can find me on LinkedIn as well as Twitter. My IDs are given here. Now with further ado, let me move to the agenda. So what we will cover in this session is for one hour. We'll try to kind of divide each into 15 minutes quickly and then finally maybe we'll keep it open for any questions. I mean, you can feel free to ask questions on the chat or maybe you can just pause and pause us and then ask questions as well. So we'll just kind of do a quick introduction of what Hyperledger Bevel is and then we'll directly jump to the release 1.0 features and then we'll talk about the future features, releases, and other activities that are going to come up. And with that, let me move to the first slide, which is the first topic, which is introduction to Hyperledger Bevel. I know most of you must have seen this, I mean, whoever is kind of being with us on different calls have seen this slide before, but it becomes very important for us because it kind of keeps us aligned with our basic principles and our vision basically. So I mean, just to kind of give an overview of what Hyperledger Bevel is for people who are joining for the first time. So Hyperledger Bevel is an automation tool that allows you to rapidly and consistently deploy production-ready DLT platforms. So these production-ready DLT platforms that currently bevel supports are basically seven of them. We support Hyperledger Fabric, Hyperledger Bezu, Hyperledger Indy, Quorum, Substrate, R3 Corda Open Source, and R3 Corda Enterprise. Now, the idea of a bevel is basically a tool, as I said, that would allow any operator or developer to quickly set up a secure and a scalable blockchain or a DLT network. And then basically, it kind of, as I said, it's very much done in a very kind of rapid way. So it kind of cuts your development time from matter of weeks to matter of hours, thus letting you focus on your basic use cases and application design, whatever you want to build on top of your blockchain network. Now, whenever I have any questions about bevel, as in whenever I try to add new features or whenever I have some idea that can kind of be part of bevel, I always refer to our guiding principles because that kind of becomes a key and important area that helps us or lets us keep Hyperledger Bevel in a way that allows, as I said, it's a kind of production ready DLT solution. So some of these basic principles that help us to achieve that is the reference architecture. Basically, this is the whole Hyperledger Bevel conforms to the reference architecture or DLT architecture 2.0 that is kind of was open source by Accenture, I think almost a couple of year back, and then it keeps upgrading, but basically it consists of various principles, patterns, components which in turn has various runtime architecture and development architecture that kind of takes care of your security, your DevOps services and various integration services layers. The other guiding principles are we design or we kind of have our architecture created in such a way that it is infrastructure independent. So if you have used bevel, know that it kind of supports any cloud platform that you wanna use, maybe any common cloud providers that you have given that it kind of supports Kubernetes. So any cloud provider on-prem or cloud, whether if it supports Kubernetes, you can use bevel to deploy your DLT network of choice. Modular design, all of our components are kind of modular to plug ready to be plugged and played and you can kind of use one without the need of other. When we talk about our future releases or the current release, you'll get an idea of how we are kind of trying to create the design into a more modular way. This is only possible because from the beginning itself, we had designed bevel in such a way that every component is basically modular in principle. Design for security. So bevel till now, I mean, in a production set up, we never keep our credentials saved in or stored in your local system or environment or your deployment machine. Everything is kind of put in securely into HashiCorp world, which is our present key world that we support in future as I said, everything is modular in design. These key vaults can be replaced with any other, let's say cloud managed vaults as such. Finally, that we use in our tools are open sourced and the product itself is Apache 2 licensed with Hyperledger. Moving on, likely jumping to the key highlights of release 1.0. So before I do that, do we have any questions on the chat or do we move ahead? No, can't go ahead. Okay. So key highlights of the release, I will also share a link to our release, release changing. It's in draft position right now, but yeah, I mean, you'll get a more detailed idea of what are the new things or new changes that you'd see with the release 1.0.0. But yeah, some of the key features which you see in the screen are support for Hyperledger Fabric 2.5. So the 1.0 brings up the support or it allows you to deploy 2.5 along with the older 2.2.X version and also along with 2.5 we are currently, we have almost completed all the operations that are there as in the common ones. The, for example, addition of peers, addition of orderers and addition of order organizations, those kind of operations are also supported with two version 2.5. This also comes with the option of deploying chain code as an external service, also upgrading chain code versions. The other important thing that we have been working on is the ability to deploy your DLT networks using GitHub actions work. So when we talk to different people on the Discord channel and most of the issues that we see people are facing are related to some of the prerequisites or let's say the versions of the Ansible or components which are required in the, basically the developer machine from which you're gonna run the bevel scripts. So with the ability or with this GitHub actions workflow, it kind of solves that problem. You no longer need to kind of create your own environment to run the scripts. You can use the GitHub actions directly and trigger any deployment or any deployment, network deployment of your choice. The other important thing which would be a much focused item for the future releases is the standalone Helm chart. So for this, we have started with Hyperledger Basu. So now with this, you can deploy Hyperledger Basu without using Ansible at all. You can just use Helm commands to deploy Basu network. And also we have seen that many people just want to deploy our DLT network for a quick test without kind of taking, without caring about the various proxies or indices or let's say the Key Vault which is how she got for now. So for Basu, we have also added the ability to deploy network without proxy or without vault. The other important thing, key thing is the documentation change. So we have completely restructured and redesigned our documentation which would increase readability. It has new look and feel altogether. It also focuses on having the documentation designed around user perspective or user persona or it basically whenever some users come, they have that one set of mindset. For example, they want to let's say deploy a particular network and they need a particular flow from where they can get the proper things that are required for the deployment. So I mean, it's structured in such a way that it becomes much easier for anyone to follow or guide and follow through all the steps from configuration to deployment to initial testing. So we'll keep continuing to improve our documentation but yeah, it's majorly being redesigned with that new look and feel. I will also share a link to or you can just do or read the docs bevel search. It's been updated so you can have a look at the reason to redesign documentation. The final important key release aspect is the Hyperledger cacti connectors. So now I think couple of our platforms which are I think Pesu, Corum and Fabrik as well have been, I mean, we have added a feature that would allow these platforms to also deploy the cacti connector along with the node which would kind of allow you to use cacti connectors for these networks allowing interoperable communication between the various DLT ledgers. Right, we'll move to the next slide which is talks about future lease features. Shauna, off to you for this. So before that, I would like to, you know, Subhijit, if you can just walk us through the documentation, the new documentation link, yeah. Okay, so let me first share the link and then. Yeah, I have shared the link. So if you just screen, share the browser and then just brief on the main changes. Of course, we have used the theme that was designed under the Hyperledger mentorship product project for the redesigning of the documentation. Hopefully all Hyperledger projects will be using the same theme. So which is very good, we've used to do to MK docs and the flow of the documentation in the sense the content is also from how it was suggested by that mentorship. Yep, so let me quickly open that. Yeah, it's your third. Yep, third tab, yeah. Oh, it's already there. Yeah, so if you scroll flow through, so we have added the introduction, it is the same thing, but the major changes are if you go to concepts, Subhijit, the, we have introduced, we have added the sequence diagram, because it seems people were a little bit confused on how it actually works. So hopefully this diagram will allow you to understand how the sequence works. And of course, if one of the things in the sequence doesn't work, then rest of the following things will not work. Then we have all the concepts that the major concepts that we use Ansible, GitOps, Helm, Kubernetes and Vault, these are the major concepts that we use, that we use. So if someone is using Bevel, if they already know these things, it is helpful. If they, I mean, some basic understanding of each of these things are necessary. Otherwise, of course, you will have much more problem in using Bevel or deploying the network. Then if we go to getting started, so that's where I have now with this theme, and it allows us to add this kind of tips and then warnings and important messages in a very colorful way. So you can see all the important parts highlighted. There is the tutorials. I think it's next, which we have, I think there is like a still ongoing thing that we have to do that we'll have to sort some of the guides into tutorials, because now we have less tutorials and a lot of guides. So we'll maybe do some kind of filtering. Yeah, so if you go to guide, so this is where basically all the operational guides are there, like what for each of the separate different platforms like Corda and Fabric and mainly Corda and Fabric, because they are the most common used, and then we have Bevel and all as well. Yep, and then going to the references, if you go to the references, so we do have the architecture, sorry, some of the commands, how to troubleshoot, what is the roadmap, which is the important part? And yeah, so that kind of brings us to the roadmap. I see there is a question, what is the difference between Bevel and Firefly, or there is overlap between both projects? Okay, Bevel and Firefly are really totally different. Firefly is kind of, I think similar, I'd rather say it's similar to CACTI, because it's works on the interoperability, so on. Bevel is a deployment accelerator tool, it's a deployment framework. So you'll most likely use Bevel to deploy Firefly for your production systems. So that's the difference. Yep, so going back to the PowerPoint for our future things, the road ahead, basically the second part of this discussion, we will mainly, as kind of alluded to in this one, that of course we'll keep on continuing and improving our documentation. That is how, I mean, any open source product works. There is no end to documentation because with every new things, there will be new updates needed for the documentation part. So yeah, so we go to the next slide, Suvijit, yeah. Suvijit, are you, maybe? Okay, I think we are stuck, Suvijit, maybe. I think I did drop, sorry, I'm back. Oh, it's fine, I've shared now. So this is, yeah, so basically for future releases, we of course planning to start supporting Corda 5, that will be a new platform because there is a major difference between Corda 4 and Corda 5, so it will be a separate platform. That, so with this release, we have changed all the, like all our Helm charts is available under as Helm repo. So you can just go do like Helm repo, add hyperledger.github.com slash bevel, and then you'll get all the Helm charts that is published under our Helm repo, bevel Helm repo. So the next kind of future release, future change would be to use those directly as the GitHub source or all our update our documentations to directly use those Helm charts when you're doing Helm install from the Helm repo directly. Then of course, Grafana Prometheus integrations, I think they have been partly done for Beysu, but we'll try to put it or extend it for the other platforms. Deployments with only Helm making Ansible optional, so that's more or less the more major target that we want to achieve for that using only Helm or without using Ansible. So out the theory or kind of the principle, I would say that we try to follow, we'll be trying to follow is that if you want to a short and simple, like if you want a dev network or if you want a test network, a small test network to quickly do things to test your application or deploy your smart contract, then use Helm using Helm install, say four or five commands, it will run deploy your network, which will be more or less production, but not exactly a production or this solution. But then when if you want to use more complex network, more production or better production or these solutions which includes a vault, which will include Github so that you have automated updates in your cluster. So that's when you will use Ansible. And also when you want, for example, like you have multiple, you have to create say 10 organizations or five organizations or 50 organizations, then just using Helm install will not work because you have to run this Helm installs, say 50 times for each organization, which is not ideal. That's when you'll use Ansible. So, but yeah, we're making it more towards that with this release, Hyperledger Basu is like that. So we have a very simple five, six step deployment or even less, I think deployment for Hyperledger Basu, which is actually taken from the Quorum Kubernetes charts that is published or maintained by consensus, but we have integrated vault with it and Github with it via Ansible. Main change is vault. So you can use the ashykov vault and your secrets are always stored, even if your Kubernetes cluster is, say, destroyed. The additional on the similar lines, what we'll be doing there is introduce with Basu, starting with Basu itself, you can now deploy without vault. So you don't need vault and also without using Githubs. So you don't have to use Githubs. That's, you just deploy using Helm install. And so that means you will not have to wait for, we have so many questions saying this, my job is not working, that job is not working and I cannot see, it cannot, does in progress. So that things will be minimized. The other, so that's there already done for Basu. We'll of course do the rest in the next few months. And we also have the option, like there is a key called cloud native services now in one of the value files. So that means that it is false for now, we've not used any cloud native services, but if here we have more AWS or Azure experts, they can, you can add the code for yourself in which way you will be able to use the cloud native services, reading the secrets from the AWS Key Vault, for example, or Azure Key Vault, rather than vault, HashiCov Vault that we provide of the users. So those, yeah, making it incoming, going back to Subhijit's comment or about our guiding principles on modularity, that's where we are going ahead. And we have seen a lot of interest between in our, with our clients as well. And with the users, which I think many of you are here in this call to use the native Kubernetes services, sorry, native secret services, cloud native services. So you can use them. And then the last of course is deployment using Kubernetes operator. So part of it is there via, for fabric it is there because you can deploy, you can use operator, the Bevel operator fabric, which is like a sub project, I would say for Bevel, but you can use the Bevel automation with that. So again, you don't have to run the Helm, sorry, Cube CTL configure function multiple times. If you have, if you are, for example, deploying, you know, 10 node network. So gradually the same operator would be, or that pattern would extend to say, say, Bezu and go Corum on our Corda as well. So that's, these are the main things that will be working from now on, depending of course on your contributions, I think it will depend, that will drive the how soon we get it or how late we get it. But that's, these are our prioritized versions. Yeah, that's from my side on this one. Any questions, I'm sure there are questions. Okay, there aren't any that I can see. There are a couple of questions on the YouTube channel. I don't know if y'all have been looking on the chat there. I can copy those over here. Let me do that. And maybe you've already covered this, but I'll just make sure. Okay. So the first question was, compare is in compare Helm usage against Bevel operator. Not totally sure of this question. I mean, I'm not sure I understand, but I think it kind of tries to make that what is the difference between Helm and Bevel operator, but there isn't, in that sense, I think the Bevel operator itself internally uses the Helm charts. So we are also going to be doing the same. So the Helm charts that we are creating right now and we have introduced with Beisu, for example, have introduced like the task, like dependent Helm charts. So in that sense, if you install, if you just help install chart A, the other dependent charts, for example, which creates the vault authentication or which adds, creates the network parameters, for example, in Korda, that will always automatically be called within that. So you don't have to call like five charts to reach at the end state. So you'll most probably call two of them or most of the more important ones. That's how we are going to do with, when we do deployments only will help. That's the principle. Not sure if I answered that correctly. Is Grafana Prometheus is used for infrastructure monitoring? I think there is a question. So that is dependent on you. So we are going to add Grafana and Prometheus integrations that will, but it will be only for the DLT network that you are deploying. If you want to add your infrastructure monitoring, the Kubernetes other monitoring as well, that depends on you because we are not, as we've tried to be infrastructure independent, that's another second most important, or second not most important, the second principle that we go stand by, if we start adding infrastructure monitoring, then we'll have to do it separately for AWS and Azure and Google and whatever new cloud provider is coming up in the market. So it just defeats the purpose of what we will use about. So our Grafana and Prometheus monitoring or integrations will be for the DLT platform themselves, like for Corda or for Fabric or for Beesu, for Beesu, for example, it's already there. Will other appellate projects in migrate to operator as well interested for Dev setups? Yes, so that's the point that I'm, I think whoever has that question on YouTube is a very good question. And that's something that we want to encourage between the community and the community, that yeah, there are other hyperledger projects should also have their operator setup. And they, because they are deploying on Kubernetes when you use operators, it means Kubernetes operators. Then yeah, they should be ideally be under bevel and should ideally be using the existing health charts because otherwise you will end up re-creating the same health charts. So that's, so hopefully I've answered the question from Ravi who is asked here directly, I think. There's one more question by Sushin. All right, yeah. So the main issue is facing is native bevel is supported for till 2.2 and bevel operator is supported 2.5. So yeah, should we give you one to answer that? Yeah, so if by native bevel you mean the bevel project, so then yeah, I mean this release, we have come up with 2.5 along with the various operations that we already supported for 2.2. So you have it. Yeah, so with the current release that is 1.0 or even if you get the developer branch, you can run till use native bevel for fabric 2.5 as well which is more or less the latest one. I think 3.0 is still in kind of beta testing for fabric. Yeah, so yeah, that's our team here. We do need more maintainers and just contributors, not just maintainers, but we'll keep actively working to make these features available to you. We have, so these are the like more or less the long-term goals, so enhanced or interoperative with other hyperlager projects. So in that sense, in any, as you have said to other, someone asked in, I think on YouTube, right, what happens with other hyperlager projects when they use operator? So yeah, ideally all the operators should be under bevel and there should not be someone who is writing new Helm charts to deploy on Kubernetes. Ideally they should be using our Helm charts and that's where the interoperability is. Otherwise again, if someone is writing it, they're doing it again, I mean, like reinventing the wheel in that sense. Introduce advanced customization options. So yeah, like I discussed, we are adding, we will be, I mean, our team, my team personally, which is like four people, like five people. We will not, that may, I mean, prioritizing on the AWS or the Azure Key Vault or Google secrets, that wouldn't be our priority, but this is, we'll make the code or the Helm charts easily customizable for adding those features. Of course, performance optimization, and that is where the, we are also introducing more, better memory and resource utilization, those limits that we have under Kubernetes also with Prometheus and Grafana, Prometheus, you will be able to use those metrics and see if something is going wrong and if your Kubernetes cluster is needed, needs more, you know, juice basically, that will be there and that will drive the performance optimization. Okay, there is a question. Yeah, this is just again for the YouTube recording. Is it possible to avoid using GitHub actions workflows or is it manually requirement? So it is not, it is not a mandatory requirement. The actions workflows which is there for deployment is just for example, it's a sample. So you can integrate with it in your GitHub repository or you don't have to manually created it or manually run. And the idea behind that is it's provided to it, it will be used for our own advantage because we test it, test the deployment like almost every day, three, four times, most likely. So that will advantage is that we can schedule them to be deployed, say when we are not away from our desks, for example. So and also it will offer as a template for someone who wants to integrate with the Azure DevOps or any other DevOps, they have similar tools. So, Subhajit, you want to take the next call for action? Yeah, for some reason I hear things in a lag and broken. Do you still hear my voice clear? Yeah, I can, I'm able to hear you. I mean, it was a bit broken towards the end of your last session, but now it's fine. Okay. Right, so yeah, now comes the most important part for any open source thing is basically invitation. So invitation for everyone who wants to be involved with the project and basically what we want is we want you to be involved with this project. We want you to contribute in all means that you can. It may be from testing our testing hyperledger bevel, creating bugs, creating issues, whatever you find, asking questions on Discord. And most welcome if you can do a code contribution that would be the best thing, but everything from documentation to issue creation, everything is kind of gladly welcomed. So how you can kind of get involved through us is by basically joining the various calls that we have so that you understand how the project is moving. And some of these calls that you see are done in regular basis. We have the bi-weekly sprint planning calls where we have open calls to discuss how the sprint is kind of different issues that are picked for the sprint, basically sprint in a, we do in a scrum way. So we have the scrum calls as well. And then we have the planning for that whole scrum, basically. We have a roadmap grooming call where this calls we do once every PI, which is around three months timeframe where we kind of look into our product backlog. We discuss, we see how the community wants to kind of have different suggestions or not. And then we create issues and we create roadmap on the call itself. And then we have the regular release and PI demos. So you can join all of them. And we also have the workshops that we do. We'll soon be planning one. For the roadmap grooming call, we have one coming on the ninth Fab. And then we also have one demo coming up on first Fab, where we'll be doing a demo on various features that we have been working for past release, which is basically release 1.0. We'll be talking about, we'll be doing hands-on and then showing some of the features that we have worked and developed on. Yeah, and to add to that, I think the workshop, there are a bevel, the operator fabric workshop that has already been planned for February. So we'll do the whole, as we discussed, as the release 1.0 towards the end of February, in that case for bevel, I'll be showing, or I'm me, or Subhijit and Subhijit, we'll be showing how to deploy using just the help commands as we discussed in this, as it is a major feature. And without using Flux and without using Vault, for example, for Bezu, specifically, because the other ones are yet to be done, yeah. Yeah, and to, like, you can, it's, I know there are a lot of questions here like this, and there have been a lot of questions on the Discord as well, but yeah, it is with the direction of this project, it's an open source project. The direction of the project will be in your hands, actually, that where you want the project to be going. I mean, we are a small team and we can provide some direction, but we cannot control the whole thing totally, right? So that's where it is that you, if you get more involved, it will fit, or it will be updated to be fit your purpose. Right. I mean, from the day one, since we open sourced, we have been kind of very flexible and adaptive to different things that are required by the community. So yep. And with that, time for questions, just feel free to ask us anything that you want. Yeah, any other questions, or if I have not answered the questions, we have not answered the questions that has already been asked. Is it, that's, you can say that, you know, any other clarifications also is fine. No more questions on YouTube as well. Yeah, I don't see any other questions there. Right. I think in that case, it's all right. This was supposed to be a short call because it's more like a project update. Of course, the workshops are longer and we'll have the workshops planned soon enough. I'll talk to you, David, on that. And yeah, thanks everyone for attending and thanks for your, I think most of you use, already use Bevel. So thanks for your usage and yeah, continuous questions as well on Discord. Yeah, thanks to you too. And I'm glad to hear you're thinking of a workshop. Yeah, happy to play on that with you whenever you want to talk more. Yep. That's all. Thank you and have a good evening, morning, you know, wherever you are. All right, thanks everyone. Thanks everyone.