Everything EOS EOS Node Operator Round Table, 15 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Node Operator Roundtable - March 15th, 2023

Description

This week, the EOS Node Operator Roundtable updates the community on Leap 4.0 development, Leap 4.0 features overview, and provide feedback on Leap version support from node operators, service providers, and other chains.

00:00:00 Start
00:00:03 Software Development update
00:00:51 Leap 4.0 release overview
00:09:37 Node operator support feedback
00:17:48 Service provider feedback
00:24:40 Feedback from other chains
00:39:02 Ubuntu 18.04 support
00:43:27 End

The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.

// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3

A

Hello, everybody: it is March 15th, we're back for another note operator round table and uh we'll start with an update from Stephen on uh progress with leap, 4.0.

B

Great thank you Daniel, so uh latest update as it pertains to leapv 4.0.0 is that uh we are tentatively closing in on a code freeze this week um it's likely going to either be today or tomorrow, uh which would mean a decent likelihood that we would cut an RC as soon as early next week. So that's kind of what we're closing in on, um as we've discussed in the past, I think it would be great idea to set up a future meeting to really flesh out and discuss at length. Some of these features.

A

Sounds good any questions all right and then, with that I'll turn it over to Brian, um I, think Brian. Before we get into the special node types, um some feedback on support, I believe.

C

Yep, uh even before we get to that I think it now would be the an appropriate time to kind of give the high level overview of of um for 4.0.0 the release that's coming up.

C

um You know note that we will be giving a more detailed um overview and a coming nude operator call, uh and in that discussion we would love to sort of hear your questions and answer them in details. um This is intended as just a a quick overview of of what the themes of this release uh are. So the you know.

C

The first thing is that we did focus on higher performance with multi-threading features, so um there's there's two big ones there, which is um ship, multi-threading uh and parallelized um transaction execution for read-only transactions, um yeah, and so together. Those you know, allow us to sort of offload a number of um computationally intensive things off of the main application thread so that it can Focus its efforts on things that have to be processed serially.

C

um So that's that's the first kind of big theme: um another one is around reduced, latency and faster block propagation.

C

So um the first feature here is that we we do have schedule-based Auto peering uh for node operators, particularly for Block producers. So if you're a block producer, uh you can configure. We talked about this a little bit in a previous call, but you can configure sort of the um a mapping between block producer accounts and connection details so that your node will automatically um attempt to connect to and allow connections from block producers that are in proximity to you in the block producer schedule.

C

And these don't sort of count against the um the the max connections setting if you turn this on. But it is limited in terms of how many block producers um will connect within this kind of pool right.

C

So the end result of this is that it should be a lot simpler for Block producers to ensure that they will receive the last block as as with as short of a path, basically as possible, so that they can get started without delay on their first block and they can be good citizens and uh ensure that their last block gets to uh the next block producer with with minimal delay.

C

um And you know not having to do any kind of uh manual finagling to make that happen, and then the other feature within this theme is around lighter validation for for Block relays, um so so now, before you've fully validated a block um as long as certain conditions are met around like yeah. This is signed by a um an entity that should have produced this block right.

C

um You can go ahead and immediately uh immediately relay that onwards. To um you know to the to the rest of your peers um and then there's also um I've been realizing. It's not in my notes here, but there's also a feature around.

C

um What is it called? um Oh, my gosh help me Kevin. What's the other uh faster propagation thing, we did uh that I failed to write in my notes.

D

um Yeah Philadelphia maintenance red was that the other one so that it can actually, as the law comes in, it gets validated, it does block counter. Validation, verifies the signature and then relays that that block onto its Fierce- and that can happen as long as the node is is, is in sync. That can happen without actually hitting the the main thread. It was that the other one well.

C

So that is one uh that's like details of this one.

E

F

C

Here's another thing and it's a big one um that we did and why can I not think of it right now, um holy cow just.

B

For clarity, if you're thinking about the optimization of block start and release time, that did not make it into the release so that that is not in scope. For this.

A

C

That's why it's not in my notes there there we go.

D

um The the other thing, though, somewhat related to that is um the block log, is now thread safe, and so, if in the net plugin, if you refer being blocked from your from your node from your net plug-in, it does not need to reach into the main thread. So you can. Actually, you can actually sync from a node. The node can serve out blocks without impacting the main thread at all.

C

Yeah, so you um you get another extra preview. There we've been working on this, which is why I was on my mind, but but I pulled the notes from our um from our GitHub, which is all public. So of course, if you want to know these things well in advance me saying these things. Of course you can just uh stalk our our GitHub um uh but yeah. We are also working on.

C

um uh Oh, my gosh. Why.

B

Is my brain optimizing the starting release, timing of uh block right.

C

Exactly um all right, moving on since since for some reason uh my uh needle can't find the groove on that one we'll keep moving into what uh sort of state state and history data blocks logs that sort of stuff. um So one thing that we've uh brought in is a snapshot, scheduling API, so that you can manage snapshot, requests in advance and and just overall have greater flexibility in creating and managing snapshots uh automatically.

C

um We've also added the Prometheus exporter, plug-in, um which you know, instruments the the various plugins and nodeeos and exposes that data to a Prometheus uh endpoint, so that you can do analysis monitoring Etc uh with Prometheus. If I.

D

Might unmap one uh you know during the RC and let's drive all this stuff? Obviously you know we'll be looking for for input there. So you know for the Prometheus. You know I think we somewhat considering that. As you know, okay, the promotion plugin is there it's it's ready to use now. What would you like to see added? That should be tracked. So what's there somewhat just kind of a minimum um amount of kind of data? So what else would you like? It's gonna, we'll be playing with it in our seat. Let us know.

C

Yep yeah, we we uh sort of purposefully, took a minimal approach to like what uh stats it exposes, because this is sort of the zero to one. You know first, release for this um and yeah, so so it has a minimal set of very useful stats. But if there's other things that are important uh to you for monitoring purposes, analysis purposes whatever um you know, let us know with a with a um you know, an issue on the uh leap Repository.

C

Okay and then finally, we've got uh sort of broadly Dynamic log splitting this is this is for both block logs and for ship logs.

C

um So, basically you can Define, um you know how how to split logs and how many splits you want to. You want to keep and and sort of automatically age out uh older logs by either deleting them or moving them to some some other form of Cold Storage.

C

So that's a preview for, um for version four and as Daniel said So speaking of versions, We wanted to seek some feedback on sort of the broader concept of version, support for leap, in particular other repositories. This is um or products I should say are.

C

This is also an important concept, but as this is a node operator called leap um and nudio, sir kind.

D

C

The critical things to talk about here- and um so you know, our goal of course, is to provide the support that critical, node operators need.

C

um You know. Critical Newt operators include not necessarily limited to like block producers, exchanges uh service providers. You know folks who are providing history apis Etc that sort of thing, um so we want to make sure that the support we're providing is what they need to be able to provide those Services effectively.

C

um Some of the things when we say support um what we're talking about is um you know ensuring that we've got working, builds for a certain version, maintaining the documentation for it. Debugging defect reports, patching security issues and.

B

C

Fixes supporting compatibility for for critical utilities and ensuring compatibility with other supported versions, and when we say compatibility, you know this could be Network compatibility like log compatibility, the state database snapshots the ability to replay all those sorts of things um and, of course, the trade-off. You know like in an Ideal, World. Well, I, don't know about ideal, but like in a dream world. We could just support every version forever and it would always be backwards, compatibility or backwards compatible.

C

um But, of course the reality is that the more versions that we support, um the more drag that makes that could mean that we can't move as fast as we uh would like to uh with future versions, and so, of course, the simplest taking this to Ideal in The, Other Extreme. The simplest thing would be that we only support the latest stable release, and so what I wanted to get feedback on from from this audience is sort of both for yourself and for uh any other entities that you have sort of good information about.

C

um What are there any reasons why that would be insufficient? Us us supporting the the latest stable version um and if so, you know give me some background there and- and let me know a little bit about what what you do need um so that we can. You know, take that into our sort of decision making process for for determining how we will support versions in the future for leap.

C

So with that I'll open up the floor for anybody who has opinions or experience here.

G

Well, not too many comments, so I was, can I see it. Somebody else would comment before me: I guess not I guess uh you know supporting the latest version is spy as long as the latest version doesn't have regressions that uh you know are not fixed right. So if we look at like 3.2 today they are. The history doesn't work quite as well as 3.1 and there's not a active campaign to fix it quickly and address those issues.

G

So then people are still on 3.1, so it depends really how fast uh you know the the issues are repaired off of the latest stable. Otherwise people are asked to fix things on the old stable because, well you know that's actually stable is the latest one is not action stable, so uh I think we need some uh commentary in that regard about what the plans are to keep the latest stable, more stable. uh Before we can comment about, uh you know written, you know, support for Boulder, stable brain.

G

So if we look at other blockchain stats like if you're not on the latest patch, you know the like 3.2.warm, like the one part, then like your auto support all right. So you know that that's uh kind of the big stream.

B

G

uh You know you remember, there's some popular you can get in there, but.

G

That's my comments. The stable version is not stable.

D

Yeah and I would say, I wonder if that somewhat related. Like you know, the fix is in the branch we just haven't, cut a release. Well, I'd say: maybe one of the reasons we haven't covered with these is because, before we cut release, we need to cut a three two one and then, uh which has the current fixes in it, because we're supporting that and we don't like to release um a fix in a upper version.

D

It will release it in in the you know, in the previous version, and so that causes us actually to be slower about cutting, maybe since I think, because we are supporting so a broad range.

D

um But yeah I mean it's an excellent point about the fact that yeah, the reason you want support on three two one is because you can't use 32 at the moment for and so obviously you need three two one. Oh no, three, two three one I'm sorry, three one uh supported because yeah you can't use three two right now: yeah.

G

So that's why you know, like I, sent the Ping a few weeks ago. So is there a new release of three do come in and then everybody's like well, oh yeah, but we're focus on 4-0, so we're not doing okay, so sure so then you're forcing the community to stay on show one right. That's the that's! The decision and outcome of doing not having a release so other release. Other blockchains that that forced you to use the current release also have much more frequent releases than we do here.

G

You know it you, you might get three releases in a week. Okay, that's not ideal like yeah right, let's not get ourselves, but the point is you know it's faster than every I. Don't know two months or something yeah. If there's a Pax, that's reasonable. That seems like oh yeah. It's fixing people's problems. Well, then, do a release. So maybe there's some! You know: how do we speed up the release process? Do we need more automated tests or whatever? So we can push the releases up faster like this?

G

Obviously, if it's a huge task to generate a release, then you're reluctant to do release.

C

Yeah one one side note I'll mention on that: um it's not a Panacea by any means, but we have something I didn't mention in 4.0. Is that there's a performance harness uh in it? um It is. It is not comprehensive by any means at this stage, um but it will over time help us to in an automated fashion, understand if there are performance regressions um so uh anyway, yeah.

C

Perspective on this, um you know: is there anything unique to providing um you know providing services with nodes that that changes? How you think about what you need for sort of supported versions.

F

I am a little lost at what we're talking about since I just joined. Oh.

C

Sorry I didn't realize that you uh only recently joined yeah, so we're talking about um I'm trying to seek feedback on what uh node operators, such as BPS exchanges and and you know, broadly, service providers need um as far as supported versions um and, of course, I can go into like the details of what we mean by supported but I'll leave it abstract for the moment, um the trade-off being, of course, the the more supported versions that we um that we maintain you know then potentially the slower we.

B

C

On future releases, um so you know the the two extremes are, of course, like we support everything and the Other Extreme. We only support the latest stable right, um and so that's yeah. That's what we're kind of getting feedback on Matthew's provided some feedback so far on. You know, from a from a sort of block producer, node operator, perspective, um I'm curious about also sort of uh I know. I know you operate obviously as a node operator and block producer, but I'm curious too about the perspective.

C

If there's anything unique with using nodes to provide services, all.

G

C

um As it relates to inversion, support.

F

I, don't know that I have anything immediately. Offhand I mean I I, don't think we're a group that typically cares about. What's supported, um we will run what we need to run and we will hack together what we need to hack together, um like I again I. Don't have a lot of context, but um like the dropping of Ubuntu 18 support like cool, we don't really care about that. We'll continue to run 18, and if we have problems we probably will solve them ourselves.

F

um We do uh I, guess it'll, very limited team size, um the if we were forced to migrate like we are during a hard fork for whatever reason you know that was not a hard Fork because of some sort of support issue, or whatever I mean. That is a burden when you're running I, don't know 100 nodeeos instances or something, um but in terms of supported versions, I mean I. Get that it's just it's not going to be getting security updates or performance fixes, or anything like that.

F

I, just I guess: I, don't really I'm kind of rambling here, but I don't have anything concrete as to how it would impact a service provider over uh any of the other types of operations. And then you have just weird situations like us where we're like we're gonna push through it anyways we don't need a whole lot of support.

F

I mean changes, are awesome and once there's a change, we need we're going to be upgrading, but right.

F

I, don't know I, don't know if that was useful or if I'm.

C

No, it was, it was helpful, it's sort of a but.

G

You need personal name go ahead. The other consideration here is like when support for things is removed from a new version that creates resistance to upgrade or, for example, when apis are not exactly compatible, even though they all say, B1 slash whatever you know, then you know people well, I can't upgrade, because it removes something- and somebody depends on that. So, if you're thinking about from a service provided perspective right you're, not in control of everybody, who's using your API.

G

So if you, if you want to allow node operators to be able to upgrade easily, we need to make sure that there's no indifferences in the supported apis uh in order to to let those threes up right.

C

Unless it's a conscious decision to to remove something and where you know um we're willing to take the resistance that that creates right well,.

G

Yeah so and that removal has been communicated well in advance and everybody knows about it and then, when the service provider then can do a rollout and say well, it was already communicated. So therefore we could not remove it. Yeah yep yeah when we've had situations in the past, where the API has changed, and you know there was there's no control over keeping the old one versus a.

F

Good, the new good block stuff might be a good example of that like when do we? When do we flip that on and how many old clients are going to be broken like I, guess, from our point of view, we don't provide paid Services, it's all free to clients that use it. So we don't necessarily have to consult with anybody.

F

When that change happens, um we can do it at will, but it's likely we'll break some clients that are trying to use it um that are compatible with how to serialize the new approach or whatever you know old, AP or old sdks won't know what they're receiving that's, not necessarily our problem. We have no slas or anything like that, um but yeah, it's like.

F

When do you pull that trigger and that's kind of that burden and I know we're kind of wandering off over what's supported, but that is kind of what is supported at the API level. It's like. How long do we support the version will get Block as we roll out the version two essentially.

C

Yeah too yeah I think this also brings me into um perhaps it's strange space for this call, but uh the you know I'm working on getting feedback from sort of exchange. Node operators as well I know that none of them were I assume that nobody on this call is, is an exchange or or related to an exchange in any way.

C

um But that said, I I predict that they've got some sort of unique behaviors as it relates to upgrades um compared to uh very engaged. um You know Antelope and EOS- focused group like this, so.

C

C

Uh Kevin or Steven before we move off of this topic, do you have any um any other sort of probing questions on this line of questioning or Zach 2 and is acting? Probably even uh just here so.

D

I mean maybe, if someone wouldn't mind, commentating more about other changes and their experience there. So a little bit of indication that some change, apparently you know, there's a new patch, no support of anything in the past. It sounds like maybe a new patch every week, as you know, like oh crap, we think you know we broke something when we fixed something, and so we we just keep building upon that and releasing and releasing that sounded like that was one extreme I'm sure there's there's some sort of eel um variance there.

D

You know: where are we on that Spectrum? Where would ideally you'd like us to be.

G

I think the the other thing is. Other chains have multiple different clients. You call clients, it's like node EOS go node us rust, no dos, C, plus plus you.

B

H

G

Of thing right, so in other chains, you know, if you don't like the policy, the release policy of one client, you might use a different one. uh Obviously we don't have that here. You.

C

G

Have one um so.

H

As as a Telus BP, uh I can say that I typically run like the stable version previous to and current release, uh and sometimes two stable versions behind, uh just to avoid any sort of bugs popping up. Anything like that and.

H

H

That that has that's, probably that hasn't really been any so many API issues, but um just having that, um like consistency of uh stable releases, uh is probably what we're looking for most of all, just so that we know that um if we need to upgrade there's uh because we tell us we sort of, we have to roll out our own custom contracts and everything like that, if there's any changes to uh system contracts or um any base level, node or node OS changes.

H

um So it's just it's good today. That, like changes, don't happen too frequently in that regard. uh Personally, I'd like to see it if there was at least sort of um two previous stable versions um to uh the main, the current one being supported, but I realized that might not be feasible for a reason to um bad battery constraints or like um Team constraints or whatever.

C

So say that say that last thing again, you gave kind of a specific request and I want to make sure it captured it. Correct.

C

H

I'd like to say uh two um previous stable versions released um from whatever the current stable version is so I mean it say.

H

The like 4.0 was released as stable, um I'd like to see sort of like 3.2, stable and 3.1, stable, also supported, but not necessarily like 3.0 or anything prior to that, and then, if it was like four point, you know two was released, then you know roll that up another one so that it's 4.2 4.0 3.2, that wow I think that would probably be sufficient kind of um you know like long-term support, so to speak.

D

I I'm curious would that include like if we do, if we roll out a new feature, that is a consensus upgrade, so you know typically I think we're shooting for that um in September or October, or you know time frame once a year for the bang, so it let's say, let's say in that scenario: September we we roll out a new feature that it's a consensus level uh um protocol feature I mean you know you can't enable by the chain. It's already the dog um the.

D

Would we then would we then encourage um it, ensures on all the change, the weight or, let's say, um the the next okay April March, that is the next 10 or release ugly Rachel. Then you tell them they need it remember the view always cheap.

G

Well, let's just stop Greg should use the latest all right. Sorry.

H

Sorry was that that an open question for the.

D

Floor yeah did open questions to the floor. I mean you'd mentioned two all into having two just wondering you know. Does that include like when we do a consensus of capital level upgrade because Gurley our thought is that you know when that happened. You know what once you enable a protocol feature, uh that's included in a release. You can no longer, you know the old executables.

D

The old relations no longer work with that chain, and so, if we were to all in Tad two available uh stable releases that you can use, then we would have to encourage people to not enable a protocol feature as soon as it's available, but he did wait. For you know a release or two before um before it was enabled.

D

Does that make sense.

H

Yeah do um consensus, upgrade features normally align with major version upgrades so like, like version two version, three vision, four, that kind of thing.

B

But not entirely, we may be using major versions for other conditions, but it will always be that fall timeline that we're targeting for consensus upgrades that would risk forking you from the network, but there may be uh things that may be considered breaking changes that take place inside of a March April release, for example, we're going from 3.2 to 4.0, like as we speak right like we're, targeting a 4.0 released and it's not September October.

D

Yeah and we've done that at you know a number of reasons, but you know filling 4.0 release we're removing API up that have been deprecated for a long time. So, since you know those apis are going away, you know considering it a major release uh so that you know and like what we're just talking about a few moments ago, we're trying to get better about that for a thing where we're not changing apis on on. You know my relation, but we're doing it.

D

You know thoughtful and, and within you know, a a major release time frame, so that's uh yeah that in this case, that's that's what an indication there.

B

And on that topic, we are um actively exploring some slightly modified taxonomy to help communicate some of the difficulties in adhering to Simba.

B

You know like patch minor major well that doesn't really speak to that consensus upgrade so um we've not officially adopted anything yet, but we're kind of playing with this idea of like a cardinal versus a marginal release and how that intersplices with Simba to communicate when there will be a consensus upgrade as well just so that we're equipping the community with as much visibility in advance as possible about the impacts of these upgrades.

H

uh What I can say for the last Telus upgrade that we did? That was a consensus level upgrade, uh uh which I think was to 3.1 uh that took us quite a long time um just to for all the BTS to get their ducks in a row um for everyone to be comfortable. Having tested the changes to included all the upstreams into the Telus contracts, um it did take us like quite a long time um from when the software was initially available. uh It would probably be close to like eight months or something like that.

H

B

And just out of curiosity, um I heard you mentioned specifically three one: um are there any bits of that like longer tail that you can attribute to the complexity of us switching over to effectively like a new GitHub, org and all of that sort of stuff? Or was it really just like the material differences in the release of the software, because, of course, this was when we had our whole uh switch over to enf, oh and Repose and stuff like that.

H

uh It was mostly due to the uh the extra protocol features that needed to be upgraded. That would Fork out the other um uh BPS that were on the same uh software and also the fact that we needed to uh upgrade the system contracts as well, at the same time, just making sure that all the system contracts were compatible with the the new base version of node EOS.

H

um We were a little bit behind in that respect, so we like we kind of, did a lot of work all at once uh um with that consensus upgrade uh but yeah. If there was, um if there was going to be kind of like consensus, upgrades like every six months or something like that, as as part of the release schedule, then we probably wouldn't be able to keep with that kind of pace.

H

I suppose, like we'd, be looking at, maybe like every like second version, where there was a consensus, change or something like that, um we would prefer kind of like less consensus, upgrades I suppose, um like uh as a as opposed to sort of like more frequent ones.

B

100 and I think that that's why we're targeting that same date range at an annual level um just because we definitely have some sensitivity to the level of pain that that introduces but feedback as we move along will be critical on that front. But I will say uh public on behalf of the enf that there are no present plans at this time to make it in every six months sort of deal.

B

And if anything like that ever were to occur, we would communicate abundantly to to make sure that we weren't introducing a lot of headache for people um again like we're. We're pretty set as a policy for the enf that moving forward it'll, be that September October time frame that any consensus upgrade does occur and that doesn't even necessarily suggest that it will require a consensus upgrade. That's just when we would plan to have those be enacted.

B

Moving forward and um just kind of the natural process of us wrapping more uh ringer and process around the enf as an entity. Moving forward.

F

I will say from a multi-network perspective.

F

um It is good that the networks stagger out uh when they do consensus upgrades as well, because for those of us that are active on all networks or many networks um trying to juggle all the networks. Upgrading to the same feature at the same time is a lot um and you also have the benefit of like Network a does this upgrade first and gains experience gains knowledge shares knowledge, B benefits from that.

F

Maybe some fixes come along c then benefits from all of that and like like right now we're seeing wax adopting 3-1 we're going through that process right now, um it's how many ever months later, but there's all that institutionalized knowledge. Now that's being passed in and it's probably going to be the smoothest rollout of those consensus changes. So reducing the time span in which consensus changes get deployed will compress that that thing, that's kind of happening naturally right now and um providing that benefit.

G

Yeah so one thing to consider when you're thinking about version support rather than a strict it's, this version, plus dot version for stop.

A

G

Maybe it's this version plus x amount of time on a previous version.

B

Right and I think that that really comes into play, especially flipping into these upgrades right. There needs to be a stability period before we say: okay, but like this. This is good to go before we kind of Rush another one off to the side, um so I think they'll absolutely be considered in like the upgrade process. I, don't think, we've thought as much about like as time moves on whether any of those other things sort of fall off, um but that is a good thought.

G

Right because, like you, could probably gather consensus from the community as to where people are at and it's like, oh well, all the chains are now on 3.2. So well we don't end this. What's 2.1 upgrade right so.

B

Yeah and I think that that's something that um I think we can absolutely partner with folks Like You on um you've received a few messages from me just now, of course about uh getting a little bit better visibility into the pain people are putting up with, and the versions that they're on, because uh that's very material implications for us right. Ideally, we want people upgrading from a version of three two to four.

B

Oh and um you know making that a more painful process, because we've not gotten that patch in for you guys is- is very material. So um maybe I'll take a moment on this call to say in case you haven't noticed a lot of us product. People have some very thick skulls and we don't always get uh the feedback that we need so feel free to Advocate. If you're facing that pain routinely and it's keeping you on a previous version.

B

um Matthew you've been a really great Advocate um and I promise. I, don't ignore you or anything, but if a few people also uh try and bonk me on the head a few times, we can definitely attempt to be a bit more proactive and there's also some dashboards. I think we should set up to monitor the versions everyone's on, so we can in sure that there's not any lurking things really holding people back.

G

I will add more exclamation points love it.

B

Well, thank you.

E

I have a question for Aaron, so Aaron or anyone else this applies to, but Aaron earlier I heard you say that your team is going to stay on Ubuntu 1804 and if we drop support, you're going to do whatever it takes to continue supporting it, because that's what you want to do, I, don't know if you were using that as an example to elucidate your point or, if you're actually going to stay on Ubuntu 1804, but I'm, just curious for you or anyone else who plans to do that.

E

Canonicals, ending support for security updates on April 28th. So my question to you and anyone else is: are you planning to pay for the security updates? Or are you do you have it? Are you planning to like switch to a newer version of Ubuntu, or are you just staying on it for now and why I guess out of curiosity.

F

The why is largely due to a lack of time um or resources.

F

um And it's not it's more of uh where it falls at a priority tree I mean if we had unlimited resources, sure we could upgrade and replace those resources.

F

um So it's not out of, like stubbornness, to want to be on a specific version. We're not married to anything specifically it's just where do we dedicate our time with as much as we do?

F

um As far as like security upgrades, I think the nodes that you're gonna see like in our situation, where that happens, we don't really care about security upgrades, because those nodes are just locked down like nobody can access them unless they're accessing it through some sort of tunnel into a data center.

F

um So it that kind of stuff is a lesser concern, uh compatibility or and or like critical issues that, like crash it for some reason, would be a lot more critical of an issue.

F

um But we run a lot of infrastructure that just like none of you would ever be able to access, and we don't upgrade those servers as regularly just because it doesn't need it. So it in the again in that full priority scale, just Falls really low.

E

Does anyone else have comments on that yeah thanks for sharing that with me, because that was uh there's a lot of internal discussion on 1804 and, frankly still is so I appreciate you sharing your perspective and your use case. Yeah.

F

Not a problem, the struggles of running so much with so little.

C

Awesome so, as always, I appreciate everybody chiming in with their feedback. If, if anything else occurs to you uh after the call of course, don't hesitate to to reach out um on telegram um in most of the uh channels where this stuff would be discussed. So you can just mention me in one of those or or direct message me find me in the sort of members list there.

C

um It is 9 47 we could at least where I am. We could um switch over into talking to node types, but I do worry that uh we would potentially uh not get very far before needing to stop so I will sort of take the the vote on whether we should um you know hand, hand the mic over to Daniel now or if we should try to get a little bit done on the mood types discussion.

C

All right, in absence of feedback, I'm gonna make the recommendation that we uh by hand it over to.

B

C

Stop now so that we don't kind of just uh scratch a surface and not get any depth. So.

A

Daniel I'll, second, that thank you Brian um another good discussion, yeah, we didn't get into the special note types, but that's okay, we'll save that for next week. um Sorry, thank you! Everybody have a good day and- uh and maybe not you right catch a buffalo figure out what's happening with you next week.

A

See you guys thanks. Everyone thanks.

G

Everyone, videos, okay, everyone.

A

H