DASH Community Weekly, 9 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SONiC DASH Workgroup Community Meeting Nov 9 2022

Description

PR274 - Replace chrissommers dockerhub with sonicdash.azurecr.io
PR278 - SAI-Challenger test framework and test cases - round 2
PR277 - Standardize DASH tests location (Anton)
PR217 - Added Overlay Test Plan
Covered github.com/opencomputeproject/SAI-Challenger/tree/multip-api-support sai_dataplane.py

A

Wednesday um today is uh November 9th. Now today's our 45th meeting so 45 times, we've gotten together to talk. So that's a lot of a lot of times so I think over a year.

B

That's the same power I think this is I think this is a real project. Let's keep her.

A

Yeah yeah 45 times so, okay and so the recording's on sharing my screen. So so last time you know we talked about PR 217 here relay test plan, um I mean I, sent these notes already. We talked about different things going on in the open, compute, GitHub repo and some of the items freshmen talked about, and then this week I think we wanted to talk about at least what I know of these uh two or three items here here: 274, 278 and anything.

A

um Anyone else wants to talk about, so maybe we could get started or if, if you have something raise your hand- and let me know- that's okay,.

A

um Chris, did you want to get started with.

B

Two seconds yeah I'll talk about the first two, the first one's uh I'll share my screen, the first one was just an oversight on my part when I um I did the PR several weeks ago to switch to publishing to um Azure container registry. There's a couple of Docker files um that we're using in dash that use base images and I forgot to edit those. So the base images are still based on my old repo and I. All I do is move which server they're coming from it's no functional change.

B

This is just a catching up like technical debt, so this is a real trivial one and uh it could be able to improve and release that there's no change in actual content. It's just where found that reviewing someone else's PR actually.

A

B

A

I need to merge that one then.

B

Unless anyone has the objections, yes ready for merge, thank.

C

B

And then the other one is, this is the bigger one.

B

um This is a re, a redo of beside Challenger PR, that I filed um the week of ocp, but that was like three weeks ago and um the number of concerns were raised primarily from Gohan and met multiple times in order and the concerns and try to address them, and we think this PR handles those concerns. Also, there was just a lot of clarification, and you know this discussion needed just to explain some things. This is the revised version of the pr I just closed the old one cleaned up. It's significantly smaller.

B

Has you know 30 less files changed. There was there's actually just some mistakes in the other one. Due to merging, uh we don't use a sub module coming from a private repo for um for the side generator it's now a Pi Pi module. That's one of the changes, so um I just wanted to present this again, and hopefully, there'll be less concern and controversy over this and we'd like to move forward with this. You know as soon as people are comfortable.

B

Gohan wants it to be smaller and, um according to the chat.

A

As well, okay, yeah, okay,.

B

I'm not sure how much we'd want to do and Stage it I mean we could I suppose what we could do is do the test cases second, so that the test cases make it smaller.

B

um You know. Sometimes big change requires a lot of changes, but Gohan. Could you give us an idea of what what two pieces you'd like to see it in? Would you like to see the framework first and then the test cases.

C

Now, in test cases, there's just few files you're not going to save much plus they're, like just sample test cases. It's like.

D

Yeah I need to take a look. I mean uh you just based on the pr right, so you know the description. There are many um many different parts right, so yeah, yeah, so I think the you know um I was wondering whether we can do a you know to based on those uh those description. Can we do a little bit this morning?

D

I I need to look at the description, but too many. uh So you know, like I, have a uh scalable Test example and OTG help module as such as some module extended existing your module new cases and CI ah too many things.

D

Maybe you know, you know scale traffic and Saturn. Are they the same or a different yeah.

C

It's only one sample that the scale is just one sample, so you can see how it's being used the framework it's the case is we are holding back for a subsequent PR, the actual bulk of the cases so.

B

This is just enough test cases to prove it works and run it in CI.

A

So bullet two is just one file or two.

C

uh Scale, it's only one, some one sample and I think then the funk was the other non-scale it's or one inbound and one outbound. It's like I, don't know three samples inside.

B

Yeah there's there's.

B

You know there's some tests down here. uh Let's see where is it another.

A

Side Challenger.

B

No Senator I think these.

A

Well, there was test scale, but.

B

A lot of these files are kind of trivial right. You know sometimes well that maybe not that's a good example.

B

You know and then there's there's a bunch of there's a lot of test case content here. Okay, there are a lot of files, but I don't know that anyone needs to study them. You sort of take them on faith that they're running the test as advertised yeah.

A

Those are the files that Anton, demoed or yeah yeah.

B

I mean the real content you can tell which files have impact and which ones are just. You know more more more examples of something.

B

But uh you know 30 files in a pull request. 34 doesn't seem excessive to me and plentiful requests are much larger than that. I mean at some point you have to. When you have a sea change in a platform you sort of bring in a bunch of new stuff, it forms the Baseline for future future work, and you know, there's it comes at a certain chunk.

B

So yeah um Gohan, maybe you could take a look at this. You have specific comments or suggestions.

B

You know we're welcome to feedback, but we think we addressed all your primary concerns in our you know. One-On-Ones we had.

D

B

Okay, so um thank you when people take a look at that- and you know give us review feedback if you would, if someone wants to load this Dev branch and try it out, that would be great and you can tell us it worked for them, but you know: we've been running this in CI on the staging branches. For some time you can see in in actions.

B

You know it's running right, it's running in CI in the staging branch and you can see uh whoops. That was a mistake.

B

uh That's not the one I want I want to see the CI actual CI. Give me a moment. Please sure.

B

See I gotta find the right back, and here we go. This is where we actually run the bmb2 and.

B

We run side Challenger tests.

B

Pulling the docker okay now we're you know: here's for example, some test cases that are running sending packets, Etc right. It's all working and you know, in order to make a pull request, sort of uh makes sense. You need the test cases to go with it, otherwise, you're just submitting a framework with no proof that it functions right. So I think this PR has the necessary minimum content in order to uh to um contribute this new framework, with a few exemplary test cases right. That.

A

Showed that pretty elegant yeah so.

B

um That's our that's our proposition and we hope it's accepted.

B

No, it's a it's a great start for the community, and just so you know you know um we. We have people working on follow-on test cases that will really demonstrate the value here and ultimately they'll be able to scale to run on real dpus. So this effort's, not just bmv2 based the whole point of this effort, was to have something that starts running on bmv2, but we'll also support large-scale functional tests and performance tests on on real Hardware.

B

As soon as we can get Hardware that has a sci Thrift interface, we will be able to show that this framework works and do demos on those Hardwares we're already using. Let's say elements of this PR, which would be the side configuration generator, we're already using the customized versions of that to configure vendor devices using proprietary apis, and this pull request puts in the framework to that when everyone is implementing their lib side, we'll run these same kind of and performance tests on Hardware in a universal manner.

B

So it's really awesome yeah! Thank you. So that's my um presentation and uh I'll stop sharing! Thank you. Okay,.

A

Anyone else have questions about this PR or how it works, or anything.

E

E

A

Okay and- and we did have one.

B

It it seems Anton here, yeah.

A

F

E

F

Then Christina.

A

E

F

Anton, will you share your screen.

G

uh Actually about the pr 77 .

A

And Anton you had a question we were going to follow up on this week as well after your PR.

G

Yeah so like I will start like verbally, so that's uh my idea was actually to make a PR for the second round to standard dice, test, um location and I come to some few questions there. So once okay.

A

So everyone, this is pr277 yep in a minute.

G

Yeah yeah, so that's one okay, so uh like right now we have some test cases in the dash and some test cases say in the sorry in the dash Pipeline and some test cases in the test test cases so and my idea was to move everything to the actually to the test cases to the functional one so where we can meet it say Dash unit this case and uh also I didn't want to just remove test cases, I merged distance scenarios to the single file and uh move it into the new location and also started changing workflow to run into run tests from the standard one, that's what the idea and I would like to like to discuss.

G

Actually. So what do you think about knowing everything like under the testes cases and uh having a single place, because by the way so in under the dash Pipeline and there's a test say they Thrift? We have also other folders and they need to clarify the what we are going to do with everything else there, whether we will be moving. How and Greece have some comments so, let's been discuss them.

A

Well, I assume this would affect the people mostly running tests now, and so that would be. You know, whoever, whoever on the call, can raise your hand if you're running tests now but for sure you know Marian's running tests. um I know merch is running tests. um So what do you guys think.

C

It's okay from my side, I mean it's good to have everything in one place and structure nicely, and this helps.

B

Yeah I think the original originally I just started adding tests under dash pipeline, because that was the only place we had tests for the bnb2 and it seemed convenient. But you know people have pointed out: we got tests in lots of locations and we should consolidate so I think the the basic idea to move them and sort of promote them up to the main test directory I'm in favor of that, after that's just a matter of details, you know we can.

B

We can talk about the details of which folder or how to name them I'm totally. Fine with that.

A

I didn't mean to cut you off Chris sorry.

C

No, no! That's! Fine! It's fine.

A

Marion does that work for you since I know, you're running tests.

C

Oh sorry, yeah.

A

That's okay, okay,.

G

um Included hanif here because yeah.

A

I was just gonna, say: honey from broadcom. Does it but.

C

He's not an office also yeah.

A

He's out of office for two weeks guys, so we can. We can just let him know.

B

Yeah. Thank you. This is just a little really just a kind of a refactoring. Our directories a little bit. Okay,.

A

So it doesn't sound like there's any opposition uh Gohan. How about you good.

D

Good, can we go to the you know, PR descriptions. uh You know.

D

All tests under test test cases um in.

A

The dash replay, which yeah I mean for now we're all working under dash.

D

A

D

No I get that, but I think the um so there there were some scale tests, and uh you know some: some tests can run the BMV too, so how to differentiate them or.

G

uh Okay, so at this moment we have uh two locations under this cases. This is like functional and scale so and right now, I'm playing only with functional one. So here I just uh updated readme file.

G

Split root, readme file and move a appropriate description to which folder with the content of the each folder what it will contain, contain and so on. So previously.

D

So this should test the size shift. Waynet is that be removed or what no.

G

No, no, no! No! It's still here, just a div, so it's not I haven't changed anything in that file. So right now here we have only one file because I merged to previous one so test size shift. We need to win at V6, I merged them in the single file here.

G

So the name is like uh up to you because, like it's work in progress, It's still draft I wanted to have some comments, uh but right now it's here, I uh also configured Docker to run it about the docker based way. I will have at the end. One question uh verify that it's running passing on BMV 2 original end, updated to all readme files that point to the proper location.

D

Yeah sure I didn't get it I shot the this test size shift winner, the V6 being removed right, so where, where is it? Where does it go? He.

A

G

It oh yeah, so in the same file, so right now that file contains two classes like UDP pocket test and uh UDP V6. So that's one file.

D

So why why does it call experimental why the name is called as.

G

Big experiment, because it's draft so like.

D

Because uh yeah, no, no, no! No! Okay! No! The pr is a drop down understand, but why this test is, though the name is.

G

Called experimental, okay, so that's the first question so first name that come to my mind, because we already have side Dash vinets there and they need to have a different name. So another suggestion, maybe uh net bmv2, because right now it's uh it's not using uh size, simplified! Sorry! So, okay! So it's not using full uh here one to do! It's all bmv2!

G

Only this case it will be run only on two, so we are going to fix it eventually, but not in this PR, so that's I might I can rename it to the this is a prefix PM video or something like that. So if you have any.

D

Oh then, maybe you can make like a side side Dash you win at the basics right so.

G

D

Problem yeah but I think experiment. What sounds like? uh uh Not uh not the official test right so but it is. It is a value test, so you know, but it's a it's basic functionality right. So um but but I guess you know you moved here they.

D

How does people you know, know? Okay, so in this functional test um you know some are running uh can be run in the BMV too. Some cannot.

G

So that's uh yeah, so that's all all discussion, so we uh bmv2 doesn't have all functionality. It's in progress, I'm right now, testing by the way one.

D

So can you can you add some tag.

D

In this uh in unit and the.

B

Like a PDF group.

D

I, remember you know the is this using the pi test.

B

No, this is PTF.

G

Right here, but.

D

In terms of, is he using, but the test framework is that Pi tester.

G

No, no PDF is based on the unit test, it's unit test, so it doesn't have marks. So we can have group. We.

B

Can have a group.

G

Yeah so that we can Mark ad group, for example, B yeah. So that's one that's for bmv2, because it's also.

D

But for the for the side Dash we have been attached is that uh uh is that the pi test, or is that the unit test unit.

G

Test unit tested no.

D

No, the other one, no, no, no, not this one, but the other one.

G

uh Not in this PR, my outside so.

D

No, no okay, but it's in a tree right. So oh.

G

No, no so in that, in the functional directory we have only PDF test cases should.

B

We should we anticipate other types of test cases and maybe have a directory for PTF versus Pi, test or side Challenger Etc, because this is going to grow and um I. Think it's a valid point and that's one thing: I tried to do in the old Dash pipeline directories, articulate which framework was running them.

D

B

Think we better anticipate three Frameworks we have now and they all have their place right.

C

D

What what what is of extreme Frameworks yeah.

B

Well, two at least we'll have PTF and Pi test and yeah I guess you could say: there's going to be I will probably won't have vanilla pie test framework, we have site Challengers and potentially Pi test.

B

So you know two broad categories, PTF and Pi test, and we should articulate them. So you can run a test on the whole directory right.

B

D

That's yeah I mean yeah. If they are in different framework, I guess you know we shouldn't put them into the same folder, because uh otherwise uh you know uh people will be confused to run them, because the running measure will be different right. Yeah.

G

In that case, like okay, so that's I might I can recreate the same like folder structure. Let's, let's look.

B

You can just move it, you could just move it right.

F

That's the first step.

G

Yeah, this is this as well: I.

D

G

Just to merge to these cases, because it then um there's like less it uses less space because they anyway have a copy past in the more than 50 percent. Okay. So right now we have in under the tests, we have a PDF and Pie test. So, like you, you suggest to have the same like PTF and pay tests uh uh well, yeah.

B

Anton think about think about in the future. If we have tests that are not just SCI Thrift right, what if we have gnmi tests or some other kind, so it's almost like we want to take that whole site Thrift directory and put it under test cases.

B

C

Another possibility I have a comment: I actually strongly disagreeing to have any framework name in the folder structure for test cases. Test case should be feature oriented for the product. In my opinion, and when I click run I, don't care what Frameworks running behind the scene I want to see. My blah blah blah feature test case is running.

C

Why do I care two cases I run with one framework and three with other framework I want to see my five cases passing or not and no functionality of my brother, but in that my strong opinion on this matter.

G

By the way we can work around this uh by that script, so we we have script run So currently I have run functional test in this. So here we have currently a single command front, PTF test cases. Maybe if we Let's, uh let's extend it. If and when we have other test cases there. So once we have right now, a single one. So that's okay, so we can even like list them everything what we want. So if we will have some.

D

I think from the user point of view right so I think what you said just makes sense, but I think you know from the developer point of view and maybe confusing right. So if you mix different test cases in the in the same folder, so usually when the developer trying to develop a test case, you know where that that's where we want to uh you know, encourage you right. So then, basically those developers will look for the uh for the examples of existing test case and see. Okay.

D

How can I, you know, see those examples and start writing my own right. So, but if you mix different framework into the same folder, then you know it can cause some confusing sounds of the variable okay, which one should I follow uh in this folder.

F

I I have a comments here. Voldemort is speaking So currently I a little bit agree with mircha. To be honest, so it should be like um you know that, as as it is in the pull request here, so we have this cases folder. We have functional folder, which means functional test cases, and uh here we are trying to put the functional test cases which should be covered actually by the PDF. So, as I understand, we don't plan to cover functional by the pi test, so.

B

Most of the I think I wouldn't make that assumption. I, don't I, don't think we should make that arbitrary assumption.

B

What you're saying is, if they're all functional, then we we know implicitly they're all PTF I would I would rather not make that assumption, because.

E

B

We may have functional tests written in PSI Challenger.

C

We can have scaled with it on mpts, maybe yeah.

F

Yeah, we will have scale like performance, so we can have separate folder for this.

E

Is saying that if a test case is written, if one doesn't know whether it will run on all types of Frameworks that they have, then it's very confusing right.

B

I mean this we're talking about software project here, not the user experience, the user experiences press the button and it runs, and the user doesn't care what folder it's in, but the developer does so.

C

Why developer cannot have a good experience as well.

B

But but that's a that's in the eye of the beholder.

B

Maybe we should uh maybe we should.

A

Where do we go from here, yeah.

B

Why don't we take this? Maybe have a debate, an extended debate offline. We can do that in a smaller group. I think it's good that we got all these different opinions out on the table and it just brings it out and then maybe we can save people's time while we haggle.

E

A

B

A

Yeah really good guys: okay,.

B

G

So maybe the goal is by.

B

Next week,.

G

It's result and.

B

Yeah to bring it up again, yeah and I. Think the the big takeaway, though, is when we start putting them under this main test directory, eventually, it'll be also more ready to put into the Sonic management framework right, because we're consolidating and curating this in the right way and.

C

In Sonic management they are grouped by feature ACL, Feature, bgp, Feature and so on.

B

Are there different Frameworks in those groupings.

C

It's Sonic management framework, but this is why I'm saying Sonic management can be like the all-encompassing thing. Underneath maybe it starts like you have different topologies under you have even a keysight topologies there with keysight harder you have t0, T2 and so on. T2 lag, which assume a different VM container configuration and connections. Let's do a different tests, but so it could be a bmv2 topology. It could be a dash switch topology, a dash dpu one I mean those could be controlled. From that perspective from the um test topology that is being required.

C

You require two VMS with a bmv2 or you require a dpu with two ports. 100 Gig or you require I, know 400 gig, Smart, Switch or something.

E

C

Well, we'll take.

G

It offline yeah, okay, yeah, let's discuss because see that from other on other hand, we right now have in that folder only one type of test cases and like we are trying to moment where you can dissipate everything what's possible to be placed here so also like. We don't really know what will happen Okay, let's, let's discuss it separately and have a continuation next week.

A

I'm sorry I was just gonna say: that's why we have the best and the brightest here, I guess to think about it.

G

Yeah so like everybody who has some opinions, so please.

E

G

Comment on that PR, so yeah that would be good, yeah, okay,.

A

Anton I'm sorry I didn't mean to cut you off. What were you saying.

G

Yeah, so that's uh I wanted also to add that uh I changed Docker files and uh after maybe make epr so I, see that my verification is fading because, like I cannot rebuild and push anything to the work results also to the docker repository. So that's also a question how we can submit PR when, from from us different repository, so right now see the time from Rush mantel cushion and checks failing because Dockers are not updated.

B

Yeah, you can't, you can't publish it from a fork.

G

That's yeah yeah, so that's and the way the commission is um how to verify or what will be a procedure in that case, whether I need to put the command here. So that's um trust me so like at my PC yeah.

B

Did you did you look at the um the um Docker workflows document that I wrote.

G

uh I'm, probably not so good so yeah take.

A

A look: can you put a link in the chat Chris? Yes,.

B

I will do that, okay, and it also answers some questions that Gohan had on this topic.

B

um You know about security, holes and Publishing to ACR, but once again you um you can't you can't publish to Doc race car unless you're a maintainer put it. That way. That's kind of the bottom line you have to you have to have the proper right access to even do that and that's it's sort of a bit of a let's say, a firewall.

G

But Gracie Wilson.

B

I'm looking for it right now,.

A

And Anton you, you had a question last week too about um updates on Sonic management overlay test plan to look at and Prince had mentioned. Appear might be ready this week, so I wanted to check in on that.

G

No yay, if it's already ready, because I'm like last week, I checked on Friday. It was nothing lessons.

A

G

So if any updates hey.

A

Prince, did you have an update.

H

This is the Sonic management PR right. We are yeah.

A

Some overlay test plan to look at or something yeah.

H

Yeah, so um the configuration part is, is ready, um there's a draft peer, but the implementation is still a work in progress, so um I'm I'm thinking it will be ready by this week.

H

So so, maybe once the pr is ready, I will post it on to this thread.

G

Okay, thank you. Thank you, yeah. Thank you. So Greece here is your link just.

B

In the chat yeah exactly yeah, that's the link, hey it's best, just to read through it and try to understand it, but you you always need the cooperation of a um of a maintainer to get a new image into ACR, forks, forks, can't, publish and so probably read through this- and um you know get back to me and we can talk about it.

B

I don't want to re, want to reiterate to the community that we should probably have more than one person who um is comfortable with helping to manage this process, and that's why I documented it- and there may be even a better version of this. There may be a better way to do this, that I hadn't thought of, but I came up with three ways to do this and um there's a better way. I'd love to know about it.

A

Okay, well, I'm always willing to help.

D

um So so Chris I didn't quite understand this part. The logic right you mentioned on the pr you cannot push to the ACR I think yes you're right, because they shouldn't have the permission to do that, um but it shouldn't prevent the pr testing right. So what what is a? What is the reason that the you know in the pr testing we we have to download from the ACR.

B

No, if you, if you go down well PR testing, it's sort of there's a pre-testing phase. Let's say: if you, if you go down, let's say: there's one was developed from a fork: you a developer, can test a new Docker file in their personal in their local repo yeah. You can do that yeah. It shows that in Step, uh I think step four. In that little picture there yeah you can develop the docker file locally, but ultimately, in the final stages it needs to be uploaded to ACR, and so you have to go through.

D

A branch no no before before the pr being checked in right, so they shouldn't be able to. They should not be able to upload to the ACI right. So because, uh because uh you know it's their private Branch hasn't been revealed right. So um but.

B

D

Question is why uh you know why why prevent from us doing the pr testing I mean uploading to the SAR. You know. Official build uploading to Sr makes sense, but why why you know failed to upload to HR will prevent them from uh you know doing the pr testing. That's a question. That's.

B

I, don't have an answer to that: how to refer to an image that doesn't exist in the repo yet so you can test.

D

It so that's part I I, guess you know this. um It's uh you know in in in the pr test right, so they they put their changes. They put the docker files right so using that we can build that. uh You know the new Docker with that change, Docker file and then just use that locally to do the test right. So we don't really.

G

D

Upload to the ACR and then you know, have another process to download the formation and doing the test right. So because it's just uh yeah.

C

D

You think about it. You know it's providing an environment where it's just uh like a develops environment, there's some kind of VM or workers that build that private Docker and then using that Docker to do the test right so that that should be that should be able to doable. You don't have to really upload to the ECR right. So.

B

No, no, let me let me explain, I understand your question better, you can. You could pull the pr Branch into your workspace and manually do a make of that Docker image and it'll be stored locally.

B

Okay, you can do that.

D

You you can or you cannot you.

B

D

Yes, oh yeah, yeah yeah. Of course they can manually. You know yeah yeah, of course, but uh with the CI system can also do that right.

B

um Yes- and this is this- is maybe a uh I understand so I I attempted many months ago to streamline the CI process so that it's not rebuilding Docker images every time and it pulls them, and it's sped it up from hours to minutes right.

B

So in order to do that, then the normal CI process tries to pull the image, not make it every time.

D

I I see I, see I, see so, okay, but uh okay. No in that case, you actually need the.

B

You gave me an idea, I'll work on this. The idea is because right now, I'm running some GitHub action files. Only in the main branch like the publish yeah, what I what I can do is I can- and this is just like one line of code in each- maybe one line a couple lines of code in the CI file when we run CI on a fork, I can have it build the docker image now that'll be a penalty, but it's only in the CI right. No one cares um and then so for a fork.

B

Build I can build the docker image and we'll test it without publishing and then in a brand Branch or the main repo I can have it pull the image. That's another possibility.

G

B

At a time, that's.

G

Probably not all images need to rebuild, but only some of them if we can somehow.

C

D

G

D

Long, how long does it build that uh Docker right? So, if there's a change, how long does it it.

B

Depends which one there's like there's, probably seven or eight Docker files. If you're building grpc from scratch it takes, it could take hours on a machine, local machine, it could take 50 minutes, maybe in the cloud it's extremely slow, so I extracted and built grpc all by itself as a library. That's an example of something never changes.

B

Some of the other images like site, Thrift server it takes I, don't know seven or eight minutes.

B

But if you, if you do like a push, you want to see it happen pretty fast and get your CI feedback and what we don't want is waiting an hour to see if it passed. Yeah I don't want to wait an hour, um but I think we can probably use some fine tuning here. Gohan.

D

um Because I think the you know the re, the the dog her eyes, so um so maybe what what we can do is that uh you know we. We can split the docker into a few files right. So therefore, you know just have a base layer. Then it has. You know some additional layer right. So then we can put you know those mostly frequent changes in the in the top layer, so that uh normally right, so you can just uh pull those base layer.

D

You know I think you know like, for example, you you mentioned like the grpc right. So probably nobody is going to change. That I mean if it's a re original the grpc right so in the public doesn't really works to build it every time. So, but you know for the bmv2, you know the side, libraries, those kind of things you know. Maybe people will constantly changing that and then we can put the top layer so that um you know we can pull and uh get get them right.

D

So you know basically I think the you know every time right. So you know what what we did um in the Sonic is is way too mt5 checksum uh for that Docker file, and we we get that checksum and when they, when we upload the the docker file, we upload the we tag that Docker file with that checksum and upload it.

D

So uh then the uh in the in the build process right, so we always try to pull from the ECR on that particular checksum, and if it's successful it means that has been built and uploaded. You know officially right uploaded to the to the docker registry so that you can pull you don't have to rebuild it right. However, if you try to pull that particular, uh you know tag you know, which is the md5 checksum, but you cannot find it. Then you know, okay, you know, I.

D

This Docker file has been changed, I, don't really having the reporteries have to build myself. So that's one way we we use to address this. uh You know um achieve the balance between you know.

H

D

Two pool- and uh you know what what to pull and also save the time for the.

B

Yeah, that's another optimization too, but just so you know it already is broken into um smaller images. I'll just quickly take the screen over and show you this old PR that uh you know way back in um what was this July nah? It's it's I've already, trimmed it down quite a bit, I! Think it's just the fine tuning of the difference between a PR versus a developer versus there's some fine tuning that can go on there.

D

B

So it's already optimized as much as I can make it for now. I think it's just the images. The images are optimized just I think some of this nuances of publishing versus building can be improved, so I'll think about that.

E

A

So that's all I had for today. um Unless I don't know, if we have time for a reshma to go into the whole open compute project, Psy changes that kind of thing do you want to save it for next time, reshma.

E

uh Sure sounds good Christina, okay, we just uh upstreamed the code, changes that we have done so far. The auto generated test framework and the test cases as well yeah.

B

Yeah, oh, can we use the um Main Branch from PSI now.

E

Yes, if needed is.

B

Someone going to do a proud.

F

Chris, we already discovered this probably last time, I think you can. We use the Upstream version so to do some notification there before moving the main okay. We can talk about this.

B

Okay, so it's still work in progress.

B

Right, it's the PTF. That's.

F

The that issue- yes, yes, yes, PDF changes.

B

We still have 11 minutes if uh rational wants to talk like is.

A

Sure, before it reshma.

E

There is- maybe we can discuss next time but uh voldemortnik. What is the part that you were saying? Can you please elaborate a little bit more or do you want to talk next time.

F

uh We we can talk about about this next time. I'm, not sure we have time still to talk about this, but we have some changes on the PDF itself, a PDF framework. There is some fix which needs to be first merged into the PDF. Then we should post changes into the site or we will need to change the submodel PDF submodel in the dash.

F

So I can provide probably next time the the changes and show to error.

A

A

So I'll go ahead and send notes like I. Usually do um I always learn something from this group. So thank you. Everyone, I'm gonna, stop. The recording now looks like some of you are going to be in Seattle next week for on E.