From 6da857fd0b479c9f25e698b87da69655394c7e3e Mon Sep 17 00:00:00 2001 From: George Appiah <48031636+iamGeorgePro@users.noreply.github.com> Date: Sun, 26 May 2024 17:21:35 +0000 Subject: [PATCH 1/3] Create meeting notes for sig providers #16 Signed-off-by: George Appiah <48031636+iamGeorgePro@users.noreply.github.com> --- sig-providers/meetings/016-2024-04-24.md | 81 ++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 sig-providers/meetings/016-2024-04-24.md diff --git a/sig-providers/meetings/016-2024-04-24.md b/sig-providers/meetings/016-2024-04-24.md new file mode 100644 index 00000000..26416a2b --- /dev/null +++ b/sig-providers/meetings/016-2024-04-24.md @@ -0,0 +1,81 @@ +# Akash Network - Providers Special Interest Group (SIG) - Meeting #16 + +## Agenda +- Update from Praetor on all of the work that they have been doing. +- Open Discussion on all things related to Akash Providers. +- Provider Build Process and Stability +- Bid Engine Updates + +## Meeting Details +- Date: Wednesday, April 24, 2024 +- Time: 08:00 AM PT (Pacific Time) +- Recording: Coming Soon +- [Transcript](#transcript) + +## Participants +- Andrew Hare +- Andrey Arapov +- Damir Simpovic +- Deval Patel +- Jigar Patel +- Lukas Meilhammer +- Nathan Ward +- Scott Carruthers +- Tyler Wright +## Meeting notes +#### Tyler Wright: +- Welcomed everyone to the providers monthly meeting. +- Emphasized the importance of the community repo for provider audits. Providers should follow the template available for audits. +- Acknowledged Andrey Arapov's efforts in keeping the provider announcements updated on Discord. +- Praetor’s role in facilitating upgrades for those who prefer an easier path than direct documentation. +- Mentioned efforts to ensure providers stay updated, noting some providers had outdated versions and incorrect contact information. +- Encouraged checking the provider announcements channel regularly for updates on versions and upgrade instructions. +- Weekly SIG meetings are led by Scott Carruthers with support from Andrew Hare and Andrey Arapov. +- They discuss support issues related to the Akash codebase. +- Providers are encouraged to track issues labeled "provider" in the support repo of the Akash Network organization. +- Tyler urged providers to participate in the weekly SIG meetings or leave comments on relevant issues. + +**Praetor Team Updates:** +- Tyler Wright announced the successful acquisition of the Praetor team by Overclock Labs. Praetor will soon be open-sourced, enabling community contributions and collaborative improvements. +- Jigar Patel highlighted the Praetor team's journey and expressed gratitude for the community's support. He outlined the steps being taken to open-source Praetor's three microservices. +- **Key Updates from Jigar Patel:** + - Praetor tooling will be open-sourced, with three microservices to be available for community contributions. + - Recently provided a one-click update for version 5.13 for providers. + - Active development on open-sourcing Praetor's microservices is ongoing. + +**Roadmap and Project Tracking:** +- Tyler Wright emphasized the importance of the public-facing roadmap available on GitHub in the project section. It will show ongoing and upcoming tasks, including contributions from the Praetor team. +- Providers and community members are encouraged to track progress and participate by leaving comments and suggestions. + +**Network Upgrade Information:** + - A network upgrade is scheduled for next Thursday, pending validator votes. + - Validators are encouraged to vote on the upgrade, which aims to enhance usability and unlock new functionalities such as private repositories. + - Post-upgrade, validators will test for stability on Mainnet before notifying providers to upgrade their nodes. + +**Provider Build Process and Stability:** +- Tyler Wright discussed efforts to improve provider stability and build processes. +- Scott Carruthers introduced a new automated Akash provider build process, currently in beta: + - Automated build process using K3s for Kubernetes clusters. + - Significant reduction in build time to 10-15 minutes. + - Current status: In beta, suitable for lab builds and testnet builds. + - Community and core team are invited to test and provide feedback. + - Documentation available at [Akashengineers.xyz](http://akashengineers.xyz). + +**Bid Engine Updates:** +- Scott Carruthers updated on the progress of converting the bid engine script from Bash to Go: + - Reverse engineering of the Bash script to Go is largely complete. + - Testing ongoing to ensure identical pricing outputs between Bash and Go versions. + - Discussion on supporting customization of the bid script for providers with specific needs. + - Andrey Arapov suggested maintaining support for both Bash and Go scripts temporarily. + - Consideration for an approach where providers can specify the script path to a custom binary or script. + +**Closing Remarks:** +- Tyler Wright invited additional provider-related discussions. +- Emphasis on staying engaged in discussions on Discord and GitHub. +- Reminded attendees about the upcoming SIG client call and the rescheduled steering committee meeting on May 2nd. +## Action Items +- Praetor to continue the process of open-sourcing Praetor’s microservices. +- Praetor to keep the community updated on progress and any issues via GitHub. +- Core Engineering Team to focus on improving provider stability and refining the build process. +- Core Engineering Team to Continue testing and developing the automated build process. +## Transcript From 14c4c86728846f7466b4912145839f33dd77dd8e Mon Sep 17 00:00:00 2001 From: Drinkwater Date: Sun, 26 May 2024 14:51:21 -0400 Subject: [PATCH 2/3] Update 016-2024-04-24.md add transcript chore: add video recording link Signed-off-by: Drinkwater --- sig-providers/meetings/016-2024-04-24.md | 206 ++++++++++++++++++++++- 1 file changed, 205 insertions(+), 1 deletion(-) diff --git a/sig-providers/meetings/016-2024-04-24.md b/sig-providers/meetings/016-2024-04-24.md index 26416a2b..9bbc78bd 100644 --- a/sig-providers/meetings/016-2024-04-24.md +++ b/sig-providers/meetings/016-2024-04-24.md @@ -78,4 +78,208 @@ - Praetor to keep the community updated on progress and any issues via GitHub. - Core Engineering Team to focus on improving provider stability and refining the build process. - Core Engineering Team to Continue testing and developing the automated build process. -## Transcript + +# **Transcript** + +_This editable transcript was computer generated and might contain errors. People can also change the text after it was created._ + +Tyler Wright: All right, welcome everybody to the providers monthly meeting for April It's April 24th, 2024 this special interest group for providers meets monthly to discuss all things related to the Akash provider. Usually have conversations have been around issues to the cost provider upgrades. There's been discussions on Those updates from the play tour team, which is a preferred and easy way to build a provider on Akash for those that are slightly less Technical and don't want to use the documentation. We've gone over the documentation in previous meetings related to the cost provider. + +Tyler Wright: There'll be a couple of announcements that I will go through before we might talk about a couple of things and then I open it up to any questions. couple things again as we talk about every month if anybody is looking to have to provide our audited please use the community repo. There is a template for those that are looking to have their provider audited Andrey Andy on Discord does a great job of keeping the announcements in the provider announcements tab updated for folks so that they can know again upgrades versions how to upgrade Etc. I know that pretor has historically followed behind with allowing those that use their path to upgrade. So again, please look out for those announcements. + +Tyler Wright: We are trying to keep people informed obviously. There's some folks that don't always check Discord as often as they are. So there are some workarounds that are being discussed to make sure that again providers upgrading because there were a group of providers that were previously audited that were running very very old versions didn't have proper contact information. So again, Andy is made announcements multiple times in the provider announcements Channel keeping people up to date and all things related to Providers and provider upgrades. + +Tyler Wright: Continuing on since our last meeting there has been a fair amount of work that's been going on related to the provider. There is a six weekly meeting that happens where usually led by Scott Arthur and with support from Andrew and Andre we go over any support issues that are in relation to the court code base in the support repo and the cash Network organization. Any issues that are related to the provider or tagged provider. And again, we have discussions about those issues during that time. So if anybody has any questions or comments about anything related to the provider any issues that they brought forth whether it be in the community or again Made issues directly, please. + +Tyler Wright: please track this repo and you can look by a track this issue the issues and the support repo and you can look by the label of report provider. And again, if you have any comments questions concerns, feel free to join that weekly meeting or feel free to drop a comment inside this relevant issue + +Tyler Wright: continuing to move on one of the big items that has happened on chain. I think it was beginning to talk about it was the community funding for prey tour to make it open source and to bring the pray to our team who was on the call today under overclock. Again, there's been some items that have been added to the roadmap. That will indicate some of the work that the Prater team will be doing on their roadmap. There will be some issues that will be created that can be tracked by folks. But again, I think the first thing is obviously there's got a lot of hard work that the prior team has done over. + +Tyler Wright: maybe two years at this point even longer to again allow another path for folks to easily build the provider. I know that when there's been issues with the prey tour app. The prior team has been very responsive and made changes as quickly as possible. They've worked very very closely with the core team on upgrades on again changing their structure to accommodate Helm charts. And again now is acquisition is now complete pray for will be open source in the near future so that it can be Community contributions. I know there's a whole plan that's pertains that provided microservices and just like a good improving the provider experience in general. + +00:05:00 + +Tyler Wright: It's going to be great to be working even more closely together on what that looks like. I do want to give Jigger and dabal a little bit of time if they want to talk because usually again during these providers they give an update on all things pray to our but again, it's a new day new age. So they'll continue to get updates on all the work that they're doing during these meetings, and it will continue to grow into more of a collaborative effort, especially as again provider microservices are broken out and The pretor cooling becomes more open source, and we get more contributions from the community. So again much. Congratulations to all the hard work and pray to our team. Go ahead. Jigar. + +Jigar Patel: Yeah, thanks Yeah, and thanks to everybody who supported us throughout our journey. we are very excited to continue work on Twitter with the work lab teams and all the family faces God Andrew and everybody actually right who supported us in our journey. And our past excellent. Now all the formalities are done. We started working on making Twitter an open source right now. And then in the meantime, we also gave one click update for 5.13 that recently updated in a provider. So that's on this road out and it's available for providers to update and + +Jigar Patel: yes, we are working currently on open sourcing all over three microservices. So our Predator is based on three microservices. So it'll be open source soon. And then obviously we will add more issues into all those data papers and we'll track and continue our work on working on those issues. + +Tyler Wright: excellent Again, the public facing roadmap for product and Engineering is in GitHub in the project section. We talked about it during the steering committee, which will happen next Thursday, May 2nd. But this is available to anybody anybody can leave comments at any time again Against this board as jigar just mentioned as they continue open source, and they have those three specific microservices that have become reposed. They will create issues inside of those repos that will then again get shown up on this board. So you can track all the work that they'll be doing amongst many other things. + +Tyler Wright: there's a number of items that kind of touch the provider. Some are More ux facing in terms of pricing and provider availability and inventory. So again, we' can always look inside this project roadmap for the product and engineering and again if you have any questions comments we can go from there. + +Tyler Wright: Besides the work that's going to be added from the parade tour team and again you'll see a reflected over the next couple of weeks on this roadmap. There are some other items that will be added to the roadmap soon. But two items that I want to call out today as many have seen on chain. There's a network upgrade that is planned for next Thursday pending boats that is open for voting right now. So if you're validator one of voting in general, please vote, on that Network upgrade functionality and I'll be unlocked. It's just like again more usability for all C. So as I can main reason for the upgrade, but there will be some other things related to again private repos that will be unlocked after the upgrade. + +00:10:00 + +Tyler Wright: As always the validator will go through the network upgrade process first. It'll be tested and make sure that it's stable. It's already been going through testing and sandbox and just a number of members of the core team have done testing. But again, once and made that upgrade happens next Thursday, and there will be a period of just making sure it's stable on Main net after that period has ended there will be a message that will be sent out to Providers to upgrade their nodes. So again, please wait for that announcement before Or doing anything next week. + +Tyler Wright: Outside of that there is one other thing that I think we kind of have touched on previously, but I want to give Scott the opportunity to talk a little bit more about this today. You can see it in testing on the product and Engineering roadmap, but one of the big task S of the core engineering team over the last three weeks has been around build product process updates as well as providers stability in general obviously with the provider incentives and the Akash Network continuing to grow. We're at the point where it's + +Tyler Wright: We've seen growing pains with the provider and stability and working through those growing pains. And we appreciate all the providers that have been helping to again do quick upgrades notice problems. But one of the things that the core team is trying to do at the highest level is just decrease the number of General problems, whether it be through testing which is continued to prove improve, month over month as well as just Figuring out at the highest level, because so much has changed with the provider so much ashamed of the network over the last few years just like going back over and spending a couple of times dedicated a couple of Cycles rather dedicated to really looking at build process really looking at the provider providers stability and fine-tuning any, technical debt. + +Tyler Wright: So again one thing that you see Andre Scott and others working on is around that provider stability. As well as provider Bill process Scott has been working with members of the community to test a new provider build process. And I know that the pretor team is also in line as to what's going on. But Scott, did you want to talk at all about provider Bill processing where it is? Just so this group on this call and those that are listening in later can get update on everything you're working on. + +Scott Carruthers: Sure, so, I guess I'm trying to remember if I have covered this in providers before I may have actually been since our last session that I started to work on this so. Sure my screen here for a second. + +Scott Carruthers: Maybe for some reason + +Tyler Wright: Not yet. + +Tyler Wright: it's popping up. Now we could hit you up now just went away. + +Scott Carruthers: Yeah, okay. Okay. + +Tyler Wright: At least for me. + +Scott Carruthers: I don't know what's going on with me. I mean, I'll try one more time. + +Scott Carruthers: about now + +Andrey Arapov: granted + +Scott Carruthers: are you able to see? + +Tyler Wright: meaning and now it's popular now it's coming up right now. Okay. Yes. + +Scott Carruthers: Yeah, mate seems to be very. unresponsive that okay,… + +Andrey Arapov: Yeah, it works. + +Scott Carruthers: so I'm not sure if there's Okay, I'm not sure if there's a little bit of a delay as I'm going through this but it should be fine either way. so as Tyler said so basically we've created a process that + +Scott Carruthers: allows a lot less friction and they provide a bill process and I would say that this is still in beta. right now and I think this can be heavily used today for lab builds or testnet builds and things of that nature and then we'll announce and also populate and the production documentation when this is ready for Primetime use so this is a engineering site that I Maintain, so this is ta.network. This is very developer focused and probably most in the audience are familiar with this from when I've This site before for different topics. But specifically for what we're talking about today. If you go to Engineers a costume Engineers that XYZ and you go to a cost provider automated build. + +00:15:00 + +Scott Carruthers: you can just read through this document yourself, but there's basically a series of install scripts that will and I describe this in the very Beginning portion or actually, it might be in the provider build section of everything that These scripts will conduct so essentially this is using 3s as the kubernetes cluster and essentially through pre scripts. We can install the characteries cluster along with and then on the worker nodes, we can install the case raise and join it to the cluster and then install persistent storage and GPU drivers and things of that nature and then finally the final build script actually builds the Akash provider, so + +Scott Carruthers: I build a large number of providers as I'm doing code testing. And so using this heavily myself. We've not been able to take the Akash provider Bill process down to a 10 or 15 minute install process. So for any of those that go through the traditional Cube spray. + +Scott Carruthers: methodology you can appreciate being a bill of cluster and 10 or 15 minutes is very powerful. And again, we look forward to being able to use this in production as well to take some of the friction away. So obviously the Prater team is very much focused on this as well and going through a Prater build. It removes a lot of the complexity and s tower mentioned earlier the Prater team and what I'm doing here in the scripts were very much in lockstep in the prettier team is looking at these scripts and are going to implement the same procedures and if they find a cause in their procedures to edit any of these processes then again, we'll be unlocked up and I can + +Scott Carruthers: Modify any of the build processes or the prayer team can modify their bill processes, but we'll ensure that we're in lockstep, but from a very high level we would love for people in the community to experiment with this. I've announced this to a caution ciders and hoping and know that I've got a response from a couple providers that have gone through this without any issues. So yeah, feel free to explore this documentation yourself, but from a very high level, this is a Automated a cost provider Bill process that with the execution of three scripts you can. build the Renaissance cluster you can install GPU persistent storage and any of those ancillary features and then build the actual cost provider itself and it Really extracts away a lot of the complex today. So no for example for GPU providers instead of having to go through. + +Scott Carruthers: And video driver installs and the runtime tool kits and things of that nature that's all abstracted and included within the build script processes. So again, we'll be testing this. Much more thoroughly over the coming. Days and weeks and then eventually release it into production. So yeah, that's basically the intent of this project and this current status. The guy heard a Pam go up. + +Andrey Arapov: Yeah, Scott. + +Scott Carruthers: I'm not looking at the meeting. + +Andrey Arapov: Thank you very much for presentation. It can hear me. + +Scott Carruthers: Yes. Yeah, I can hear you. + +Andrey Arapov: Operation looks very nice this is something that I've been like and we're beginning to join the capture something. I didn't also advocating for the beginning but there are a couple of things we need to focus really on if we want to get it to the production is the upgradeability that we can keep upgrading the cluster result impacts and the availability of such as the etcd database. That is the main ingredient of the kubernetes cluster. You need to check how it's done there in k3s so that in the event if one note is down or their moment laid down the etcd the database where all this information is stored about all config Maps secrets and so on so that there are ways to either restore it so we need to make it up somewhere. + +00:20:00 + +Andrey Arapov: Or that it has, What base of it running somewhere on different notes as well? + +Scott Carruthers: Yeah, and so to that point, I initially built this again to be able to do a code review and as we're writing new go code and the core code base. the other tests are very easily. So that's initially where we're building in and then we'll start to build on top of it as we move this to a production build. Strategy, so as we're going through that I'm adding more and more functionality to this one of the most recent updates that I just announced over the last few days is I've also now added a script to do cluster upgrades. So to be at an upgrade the k3's control plane nodes and worker nodes. This scripts will go through and basically does a analysis of the current version. + +Scott Carruthers: Running in a cost provider and then we'll look at the latest stable version and the k3's GitHub repository. And then if there's a diff between current version and latest stable the script will execute the upgrade. So I've started going through that and that works. Very well as well. So again, this is taking the kubernetes Procedure down to a 10 or 15 second procedure per node. But yeah to Andy's playing obviously that's the whole reason that we want both internal to the core team and within the community why we want this to be more thoroughly tested. We're not going to release this for production use until we've gone through all those Possible concerns so I think we're rapidly approaching that but I'm still some things that we want the community and the core team to test before we recommend this for production use. + +Tyler Wright: Go ahead Deval. + +Scott Carruthers: I'm gonna + +Deval Patel: Yeah, without wanted to add one point here there is a focus on skill ability on our side as well. Right? So when we Use the k3s are focus is on the scalability of the So basically they should be able to go from one node to I mean single note to multiple nodes are easily. + +Scott Carruthers: Yeah, absolutely. And I know that jigar in the fall and I have talked about this sum as well. So that's again something that I'm interested in The Predator team and others within the community testing as well. I think. we're probably all where k3's use over the last couple years as really started to Gain, an adoption and not just for our single node deployments but there's a lot of large Enterprise organizations that are now using k3s and multiple control plane nodes and multiple worker nodes whenever I'm using this is certainly in a multi-node environment, at least with isolated control plane and dedicated worker nodes. So any of the tests I'm doing and this is multi-node. I know the prayer team that shared possible issues that they faced in the past with k3's when it goes beyond a all-in-one node provider. So yeah, I'm + +Scott Carruthers: definitely interested in seeing the prater's teams testing of this over time and hopefully, with some of the advents and You continue to work in the k3's project As I said, I think a lot of those concerns have gone away just based on the amount that I'm seeing K3 is used in Enterprise use, but for a cost provider use specifically obviously very interested in seeing this used in large multinode clusters as well. So yeah, that's definitely one more element that we'll want to more thoroughly test before releasing to production and maybe I could even be a staged approach I think for a long time even going back A couple years ago Andy and I remember a conversation a year and a half ago where we've talked about using k3's for all-in-one node. a cost provider use so this could even be a phased rollout or possibly we + +Scott Carruthers: Recommend, the skirt build process for all-in-one providers, which is somewhat prevalent within our community. So possibly we'll roll this out and recommend this initially for small cluster use and then recommend it for larger. Cluster use as we've tested more thoroughly. + +00:25:00 + +Scott Carruthers: I'm gonna stop sharing now just so that can go back to the meet screen. But again, this will be part of production documentation initially. But if there's anyone on the call or listen to this recording that would like to play around and build a cost provider and 10 minutes and try to put this service Paces. You can currently get to this in a caution Engineers that XYZ and A automated build Tab and go from there. + +Tyler Wright: Thank you very much, Scott. That is actually a great segue to just quickly talk about. + +Tyler Wright: Docs We had a Sig documentation meeting last week or excuse me, a couple days ago during that same documentation meeting. I just want to let everybody that's here. Make sure that they're aware the documentation and this is not the documentation. It's got just reference. That's just an alpha that you all have for a cash cord engineering documentation before it makes it into again the official Doc sites for super experimental stuff with your class that Network slash docs is now + +Tyler Wright: Again under the website repo if anybody had sees any provider related documentation issues or any inconsistencies or anything that the one improve please go to the website repo you can make an issue inside the website repo and tag it documentation and again folks contributors from the community is also from the core team actively look at those issues and look to solve them. I know that recently. And I'll give you an example right now share my screen real real fast. + +Tyler Wright: So again, if you go inside the website repo you can see how to contribute to docs how to change shocks how to add new files. inside of the issues you can see issues that are tagged documentation. Here's an issue as an example that Andre saw where the documentation or Prater build was old and somebody from the community updated this yesterday and this will be merged very soon. So again, if anybody sees any provider related documentation issues where there be related or otherwise, feel free to Get involved inside that website repo again create an issue. You can create a PR if you want or just drop something in sick documentation or providers that references the issue and we'll look to get that in address as soon as possible. + +Tyler Wright: cool Real quick. One other thing. I know that Scott's been working on that touches. A provider is around bid engine scripts. I believe that now going to go as opposed to where it was historically and that's something that again Scott has shared a little bit of alpha in Akash insiders and it is currently on the projects road map. I'm trying to find it real + +Tyler Wright: But Scott, while I'm looking to find this? Is there anything that you want to give an update on as it pertains to the bid engine work? + +Tyler Wright: There we go. + +Scott Carruthers: I'm sure just briefly so as Tyler described this is a providers in the community are very familiar with the current Bachelor script that we use for dedicated or customized bit engine. So basically we're taking the current best shell script and converted to go so + +Scott Carruthers: Largely been complete for several weeks and I just needed a test environment to be able to test it against them. So just some current internal. Dev environment work that needed to be completed so that's now complete and so basically over the last couple of weeks I've had a development environment the new go logic running in parallel with the current Bachelor script and just doing an analysis to ensure that the price derived is identical. So basically just represent engineering the current best health script and along with one minor hiccup with GPU interfaces and the pricing around those which isn't really a go issue but something that currently the scripts DP on + +00:30:00 + +Scott Carruthers: for some technical reasons, but other than that anything that I throw at the new go Logic equates the exact same pricing as the current best shell script. So there's still some things that we need to work through. I'm very confident and they price derived out of the go logic so that reverse engineering is essentially done. There's still some things that we need to answer on. How people would customize that script and also I've done some testing of white listing and the ability for providers to get dedicated pricing based on the deployment address all that's working. But I think there's the core pieces of actually driving the price. I think we're perfectly in our now all converted to go and could go into production in the very near future and there's just some ancillary cases that we need to software or maybe look for their into so that's basically the effort is taking. + +Scott Carruthers: The logic that previously existed in best shell scripts and converting into go which I think is far easier to reason about especially for anyone. Familiar would go personally. I think the logic of it just and this is anything against the current bash Health script. I think it's work written excellently for what it is. But I just think they logic within the go code is a lot cleaner to look at. So yeah, that's the effort coning. They best sell script in the bid price Go logic. So yeah, hopefully we'll be able to introduce that in the very near future. + +Tyler Wright: Go ahead Andrew. + +Andrey Arapov: Yeah. do you guys want to remove a bit Script support entirely or still there will be this option kept for whoever still wants to customize with engine script because I know there are some providers that they use their own with scripts for instance. I know one provider who sets it so that it doesn't beat on really low CPU or the requests. Let's say minimum 1,000 recourse units and something like that. + +Scott Carruthers: Yeah, so that's what I was referring to and some of those. Cases that I'm very confident that the price derived out of the new go logic is identical to the pricing derived out of the previous shell script. But for those that want to actually customize the scripts we're going to have to solve for that. This hasn't really been discussed. these gray haven't happened yet, but personally I wouldn't see a future where we're going to support both the shell script and they go code. I think alternatively we need to come up with a strategy that would allow for the same type of customization. However, we do that I think it would probably involve them. + +Scott Carruthers: some variable entries are something like that that would so I understand the need and I'm very familiar with the fact that there's some providers that are customizing the bid price script and not bid on a very low resource like point one Bid, so yeah, that's something that we're definitely going to need to solve for but I believe the future would be that this would all be supported in go and then we need to solve for those educes instead of simultaneously about the bachelor script and the code logic, but yes, I'm not really something that has been solve for yet, but I obviously will be sell for before we convert to the go logic. + +Andrey Arapov: Yeah, thanks. I think the easiest to be to just keep the support for the whatever bit script people want to run just in case if they have Corner cases. I don't think it's expensive to just keep this option for the Provider Services that bit script path usually timeout options. It's just my wish and of course it can be discussed. But this is how I view things because there's a lot another point. maybe it's deserves for the engineering discussion of the providers, but the insurance is the apis because they can change but I believe the provider service will be supporting this environment variables anyway, so I guess we are good. Thank you. + +00:35:00 + +Scott Carruthers: yeah, I mean we can definitely have discussions about continuing to support both the shell script and the go logic so yeah. let's have those discussions that my personal preference would be to be able to solve for any of those needs within the go code. However, we need to do that. So for that customization where a user doesn't want to bid on. A sdl that only has 0.1. CPU to be able to solve for that and they Go logic, but yeah, we can have that discussion and maybe we will arrive at the decision that it makes sense to support both. Yeah, we'll have to say + +Andrey Arapov: Yeah, in the beginning at least here's one month. We support both and then we can cut it off something like that. It's in the worst case and if you don't gather enough information from the providers because some kind of keep running their providers and forget about or just not painted enough intention on these things being changed and then when suddenly they realized that something changed, so All right. + +Scott Carruthers: Yeah, yeah, that might be an idea as well to support both for just an intern basis. Yeah, I make sense. + +Andrey Arapov: Open that it's sort of the expensive just to let the provider run a simple script give all the data and script. I understand that it's a bash script not everyone is familiar with bash. But if it's about the structure how things look like there. It's quite easy to shape it into a better look as well, but nevertheless. + +Andrey Arapov: Yes, I don't have any specific point to that except for that. I just like love that, some things that you can really use basically I use the script is a kind of plug-in extension. So, there are a lot of software that you can use different plugins in different languages could be not necessarily a shell script. I think it actually even supports the python or whatever you specify there environment shell as well. So maybe actually if I'm not mistaken, I think it even supports you can just hide the past and you can put the binary in go link compiled and it's plugging and I think it will work because all it does it executes today or script or the binary? It's the standard input and it makes the calculations and just it's out the rate in your kitty per block and I think + +Andrey Arapov: Actually Scott, so I just hit right now this idea so that I don't miss it. Sorry if I take much time, but I think it was checking this out because maybe you can even like your go logic you can create the extension itself that would basically compile it and specify it is a bit script path to a binary and see if it works. I think or maybe a mistaken but just an idea + +Scott Carruthers: That's very much. I'm the see so to summarize just make sure that I understand you correctly the ability to update the go Logic on the same as we would be able to update the bachelor script because it's calling an external go file that… + +Andrey Arapov: Yeah. + +Scott Carruthers: what you mean? Yeah, yeah, so yeah. No, I think I did definitely that's feasible. I literally have not looked into that at all. But yeah, I think that probably would be one path is a continuing to allow. The customization of the script but it's now just in go and set of a bachelor script. So yeah, definitely think that's feasible. + +Andrey Arapov: Yeah, because I think is that then you can just here is a goal Inc version or people don't even need to care about looking into it because then I think we nearly haven't received any Community commits to the big pricing script but what I'm saying, my point is that hey you can either use that or you can use goal link implementation and you will not see any difference except which language you prefer. All you need to set is the proper bus to this binary or JavaScript. Basically, that's it. + +Scott Carruthers: Yeah, that makes sense. + +Tyler Wright: Excellent love that discussion. And did bring up another thing that I just want to touch on and I think damir has done a great job of this in the past. He will start conversations in Discord about specific features and then he will push some of those features over to discussions to get more input from the general Community. If anybody sees I would ask anybody on this call and I asked us with everybody across all calls make your voice is heard on some of these conversations. + +00:40:00 + +Tyler Wright: Whether it be for new features again related to provider just experiences. I know that we were talking I think damir had previously put feature requests around multiple bids on the same single order. I know this is something that Scott's been working on in terms of for the new go bit engine logic. But again, there was also an issue created around this as being tracked. So for those that Again have any thoughts ideas. Please get involved in some of these discussions and this will help drive, + +Tyler Wright: Priority on some of these things, along with just constant conversation in these meetings, because I know that Scott the pre-tor team other members of community often in time attendees meetings here feedback from data center providers smaller community-based providers and then take those insights back into their work. So again, feel free to get involved or stay involved in somebody's discussions and s***, but thank you very much. For the work that you do to start some of these discussions. + +Tyler Wright: All right. We talked about a number of things today doing the providers call. I wanted to see if there's anything else that anybody wants to discuss provide a related. + +Tyler Wright: again, look out for some announcements related to the main net upgrade and how it affects providers. Again. If you have the ability to vote, please vote on the main upgrade. It is planned for next Thursday. If you are looking for a provider audits, please go the community repo and said they cost that work organization and follow the template there. There will be a provider audits working group call. I know that Piper Dev and the team have been working on an automated tool and there will be a call next week Wednesday, I believe. So again, please add that to your calendar. + +Tyler Wright: And yeah, we'll just continue to work together between meetings again if anybody wants to test upgraded way that Scott has built for again building provider, please go to Akash engineering that XYZ and follow documentation. There are reach out in providers for more details. + +Tyler Wright: Both much appreciate everyone's time and about 14 minutes. We will have the Sig client calls where again folks that are building clients on top of Akash Cloud most there are a number of other teams that sometimes join that meeting. But again, feel free to get involved in the state clients call which is happening in again a little under 14 minutes and then steering committee, which is usually the last Thursday the month has been moved to again next Thursday May 2nd following the network upgrade just for timing Much appreciate everyone's time. Let's stay connected in Discord and on GitHub again. Look at the roadmap. If you have any questions about anything we talked about today, but we'll just continue to work together online much appreciate y'all. Talk soon. + +Andrey Arapov: Thank you all. Have a good one. Bye. + +Tyler Wright: Bye. + +Scott Carruthers: Thanks, everyone. + +lukas meilhammer: Dubai + +Jigar Patel: nice guys + +Meeting ended after 00:44:12 👋 + From 5ee2a521ec8dfbd7e0767353284963c1bef6bc76 Mon Sep 17 00:00:00 2001 From: Drinkwater Date: Tue, 28 May 2024 00:11:20 -0400 Subject: [PATCH 3/3] Update 016-2024-04-24.md Signed-off-by: Drinkwater --- sig-providers/meetings/016-2024-04-24.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sig-providers/meetings/016-2024-04-24.md b/sig-providers/meetings/016-2024-04-24.md index 9bbc78bd..45a48e3f 100644 --- a/sig-providers/meetings/016-2024-04-24.md +++ b/sig-providers/meetings/016-2024-04-24.md @@ -22,6 +22,7 @@ - Nathan Ward - Scott Carruthers - Tyler Wright + ## Meeting notes #### Tyler Wright: - Welcomed everyone to the providers monthly meeting.