Submind YouTube summaries
Thumbnail for Foundational Infrastructure Working Group, September 17 2026

Foundational Infrastructure Working Group, September 17 2026

Watch on YouTube

Video summary

The Foundational Infrastructure Working Group convened to review several pending pull requests, beginning with updates to logging mechanisms and Go dependency management. One key discussion involved cleaning up error message formats for JSON parsing errors to ensure compatibility between different versions of the Go compiler, specifically addressing changes in error strings introduced in newer releases. Another significant topic was a fix regarding stem cell deletion issues during VM deployments; previously, the system would set the current stem cell to an empty string upon failure, triggering unnecessary cleanup that prevented redeployment. The proposed solution modifies this behavior to preserve the active stem cell unless explicitly required for removal, though this change requires careful review due to its impact on CI/CD pipelines and potential side effects in environments like AWS where heavy stem cells are used. Further into the meeting, attention turned to log forwarding behaviors following an upgrade from Ubuntu Jammy to Noble, which resulted in a sixfold increase in log volume being sent to external systems. The team identified that signed URLs containing sensitive tokens were inadvertently included in plain text logs forwarded via journalctl, posing a security risk. While some members suggested implementing redaction flags or separating debug logs into local files rather than forwarding them externally, others noted that the increased logging might be acceptable given the low cost of storage. Additionally, there was discussion about migrating away from Canonical's infrastructure due to perceived inconsistencies in their recent decisions, particularly regarding the shift toward Rust-based components, although no immediate action was taken to change the base operating system or tooling stack. The group also addressed security vulnerabilities flagged by Dependabot within the Bosch bootloader and resolved pipeline failures caused by missing private YAML files that prevented blob store synchronization. These issues were approved for merging after confirming they did not introduce new risks and aligned with existing security practices. A notable point of contention arose regarding the handling of heavy stem cells in cloud environments, where the team acknowledged long-standing challenges but agreed to proceed cautiously until further testing could validate the stability of the proposed fixes. Throughout the session, participants emphasized the importance of tagging relevant experts, such as Azure specialists and UAA maintainers, to ensure thorough reviews before final approvals. By the end of the meeting, most items were either approved for merging or deferred pending additional input from specific team members who required more context on complex behavioral changes. The group recognized that while some fixes addressed critical gaps in logging security and deployment reliability, others represented nuanced trade-offs between operational simplicity and robustness. With several issues now linked to open pull requests and assigned reviewers, the working group concluded by noting upcoming commitments, including participation in an EU summit next week. Overall, the session reinforced the team's commitment to maintaining infrastructure stability while adapting to evolving technical landscapes, balancing immediate fixes with strategic considerations for future architectural shifts.
Read the full video transcript
Hello. Hello. Happy Thursday, folks. Give it another two minutes and then we'll start the meeting. Seems like we might have a very light crew today. Yeah. All righty. I guess we'll start. Welcome to the Foundation Infrastructure working group. Um, looks like kind of a skeleton crew here today, but we'll try to get through what we've got. Um, can folks see my screen? Okay. Can you >> see it? >> Yes, we can see it. >> Okay. Right. Um, let's see here. Start with this one. We don't have any reviewers. Um, let me know if either of you have context on any of these. Welcome, Amed. >> Yeah. So on this one, Ned uh is working on cleaning up some logging uh stuff on the agent side. So this is just a prerequisite, I guess, that he'll use the features here in a different PR. Not sure if they're up or out of draft yet, but uh they should be coming soon, I guess. >> That seems good. Um, this was me. Um, there were some changes. I think the root of this is that there are uh there's some changes in the way that the JSON parsing error format uh sorry the JSON parsing error error message string comes back and we were testing very specifically um for that. So, and even though uh the go c the bos cpi go it has a go mod file that points to golang 126 in CI it tests against 127 now that's been released and the new version of go has some slightly different error messages and um I believe also now fails compile if there are any govet errors Um, so this uh I don't know if there were vet errors here, but this this basically fixes the ways that the error messages uh were set and matches so that it works in either um in either 126 or 127 or in in this case uses a slightly smaller um substring of the error rather than the full the full text. And the rest of this is all uh vendor updates. I think I may have one review on this. There's one approval. If anybody has any thoughts, let me know. Give approval as well. Looks looks good to me. Cool. Thank you. Welcome everyone. Hm. >> All right. Uh, dynamic IPs. I'm guessing maybe this has to is related to IPv6 or no. Does anybody have any context on this Azure? Oh, sorry. This is Bosch directly. Never mind. I don't know nothing about this. Okay. >> The only one >> there are two people who played with IPv6 I think and those are not in the call. >> Okay. Right. We have a code rabbit approval but nobody else. Um so I'm going to leave this as is. pending review. Oh, this is uh this is a response to uh a comment on the issue that I had opened previously. So a commenter found that it the fix pre that I previously pushed uh doesn't fix the exact error. So this is a response to uh change it up a bit. So it's a bit complicated. So that would be best if someone can take a look. Okay. What is he trying to do? >> Um, do you have you tagged the original commenter? >> Uh, yeah. On the issue, I tagged him. Okay. >> Not on the PR. >> Might be worth tagging them on the PR. Um, >> yeah, that makes sense. Um, and then I'll Yeah, we can pick this up. I'll I don't know that I'll have time this week and I'm out on vacation, but if if Yeah, please just keep keep pinging folks and make sure they're both tagged. >> All right, thank you. The fix it just just mono the fix itself is not that complex but the train of thought leading to the fix is a bit of a >> Mhm. >> thing that needs some taken care of. >> So yeah. Yeah, that makes sense. Over there. Just looked at it. It seems okay. Mhm. documentation even. That's amazing. Yeah, this seems to be highly Azure specific >> for their new API endpoint. >> Yeah. Inclined to approve. Does anybody have any other anybody anybody else have contact on Azure that >> Yeah. >> reason? >> Uh the other guy who norm signed for height or something. >> Mhm. Good. He's in the reviewers list, I think. So, >> yeah, >> this one. >> Exactly. >> I mean, yeah, >> they are on the same team, so maybe he already took a look. >> Yeah, it would be kind of nice to get another >> Azure expert on there. This is all just documentation. It looks like that's fine. Let's see. Um, this I think we uh I looked a little bit at this but don't have haven't had a chance to give it a deep dive. Um, >> wasn't Ruben creating something for this? >> Uh, Reuben >> was all in one stem cell stuff. >> Yeah, I think it was more of an all-in-one thing. I'm going to ask Reuben to take a look. This is um I think specifically using the new um Rosetta compatible stem cell for Mac OS and being able to run run a Bosch director in in a in a Rosetta comp in a Rosetta compatible container. >> Oh, okay. >> For local development. Um yeah, I'm going to leave put Reuben on there and look at that pending discussion. Yeah, this one is pending review as well. It has to do with a create end of deploy on the director and apparently a colleague found that uh in some cases stem cells get deleted and then you can't redeploy because the stem cell has gone. you have to manually upload it. >> And this happens in specific cases when uh on a second run when the stems is already present. uh when on second run the create M >> uh the VM deployment create M fails >> it goes partially through uh the run and deletes the or rather it doesn't delete but it sets the current stem cell as an empty string >> and on the next run >> there's this cleanup that goes through and deletes all the unused stem cells. >> Mhm. So what the fix does is it does not set the current stem cell to the false to the empty string. It's a bit of a behavior change because uh this way we won't uh when create runs it tears down the VM it won't uh remove the current stem cell but it shouldn't be shouldn't change the outcome because in the happy path uh the when the VM comes up again it will set it M >> but it's a bit of a complex thing and I' be happy to have a someone take a look give a review. >> Yeah, >> that makes sense. I think I guess I might be worried about use cases in CI where where we end up tearing down the direct we end up tearing down a create VM but then the stem cell is left over in the IAS. It sounds like that might be a consequence here. Yeah, that can be a thing. And I I also think was why are we if you're so afraid of cleaning up when in the next run, shouldn't there be like like a maybe a flag or something? Uh I'm not sure because uh what this change does is doesn't clean up but rather uh just uh so the it just removes the flag the thing that actually sets the current stem cell that's being used to nil which will trigger the cleanup to delete everything. >> Okay. Yeah, maybe I'm understanding the issue. >> Yeah, I'm not explaining it very well. So, >> it it sounds it sounds complicated and and interesting. So, I put a note for our team to take a look and Reuben maybe or Ramon be be good. >> Yeah, I need to deep dive more into it before it's needing to >> Yeah, this seems seems cool. I mean, I'm it seems like a thing we should be addressing. Um. >> Mhm. >> I'm not sure. >> I joined a bit late. I'm sorry. Um, there should be an issue linked to it. Uh, it was opened a while ago, [clears throat] but it might have >> might not have linked it to the PR. >> No, no, it's there in the description. Uh, but yeah, it might have more context >> in the beginning. Yeah. >> Uh, here. Okay. >> A while ago. So I don't really remember the details. >> Okay, cool. Yeah, it be it would be good to get some eyes on it. I think a lot of the stuff has moved into like ready to merge because code rabbit has approved, but >> yeah, so have to >> code rabbit should stop approving. He is not an approver. >> I agree. Um, okay. Yeah, I flagged this for folks to take a look at there. Thank you. >> Thank you. This is cool. Um, it's interesting to see the dusty corners of things. Um, is this ready? Let's see. I want to that. Yeah, heavy stem cells in AWS is uh is a long longstanding issue. >> Yeah, I'm excited to see this change happen because it will um it will help with being able to put the Bosch CPI or the AWS CPI into BPM. Um because right now the heavy stem cells have to use device drivers and um >> and such >> maybe we can also if heavy stem cells is a thing we can also maybe like the light stem cells uh turn that down a little bit maybe. >> Yeah. >> Yeah. Exactly. Um, and I will I guess re-trigger trigger coil review. >> Okay. >> Joseph, that was a tried it a long long time ago. heavy stem cell stuff. Um, I don't know. >> I don't remember. Let's see here. Being a not Azure expert, I'm kind of inclined to trust Toby and Shade or Sebastian on this one. Um, >> yeah, I I think so, too. We'll do that and then maybe we'll come back in a bit. Um >> yeah, co-pilot cannot do a lot, but this is way too much for him too. >> Yeah. Let's see. I think this one is in the wrong column. This is Yeah, this should be ending. Oh, no wait. That's is waiting for changes from code rabbit. Zoom that and request that. All right. Head secret acting. Yeah. I think there was one comment on co that was addressed but yeah the the backstory here um we noticed that after migrating from jammy to noble the bush agent logs jumped six times um so after some >> um yeah this one is actually not about it the previous one was um so it seems we started forward ing all the debug bush agent logs >> which is not happening on um I will open separate PRs for it but need to add some stuff to the bush utils. Um this one in particular I accidentally noticed that we are forwarding in plain text uh the signed URL which contains tokens and other information that maybe should not be Yeah. Visible. >> Yeah, those are the the the blob store ones, >> I think. So, yes. Yeah. Okay. >> Um, yeah. So, I'll be using this one later in the I think the push agent. This is >> Didn't we already have one where we can just put like the redact flag on it like or are you now just redacting only the tokens from that URL? I think the idea is to reduct the entire thing. Um, and there there's also a I think review uh method that's going to be used in the code. >> Well, I thought the Bush director already did already had this. You just need to say which uh you just need to say just make this uh make this a secret deck. is in >> I don't know where it was anymore. It was a long time ago when I >> when I did this. >> I think this is for the agent though. The dire this is the director's all Ruby code. >> Oh yeah. Okay. So the agent does not Yeah. But you mean in the agent logs? Is that >> Yeah. >> Yeah. So yeah. So but then you always need to go the the agent logs can only be viewed when you have root access. You cannot do like B logs >> those access right >> I think you were working on something related to Ramon. Um >> it was a long time ago. I I for sure. >> Yeah. Um so the way Jami was forwarding logs I guess it's different in Noble and once we migrated um like the the amount of logs um increased six times and I noticed we're now forwarding all the the actual Bosch agent debug logs uh to our logging system. Um, okay. Um, but this thing with the signed URL I think has been there for like for a while. Um, >> yeah. So if the if there is too much logging now going on which is not wanted then we we just need to reduce this a little because I think it's it's from journal C uh we are including the we are just forwarding the journal uh CTL from the journal from watch director to the logs now I know there's some PRs like in the past months when someone tried to change several things But >> yeah, if if this was if this is solving uh something from the agent. Yeah, fine. That's good. >> Yeah, the was both I think >> I'll review the comments. Um >> okay, >> for the push agent, uh someone did make a change and forward the the logs to a file. And the idea I think is to have them locally and not forward them to external uh systems >> which was okay with Jamie but yeah noble works a bit differently but that's going to be a separate PR in the agent. >> Yeah I mean it can be worth having those or anyway yeah we should talk about that when that that comes up. >> Um thank you for digging in. Um, I need to put some people in here. >> Yeah, the the funny thing is the Bosch DNS stopped sending logs, but the B agent >> Yeah. increased the amount with no >> That's strange. Well, possibly DNS is less involved like it it is doing less because it's not the primary resolver anymore. >> Yeah. Yeah. It's a a lot less loss now. Yeah. Um, I think I'm just going to go ahead and scan and see if I will leave these for them to take a look at. Um, all right. That one we talked about. That one we talked about waiting for things. That one we're talking about. Um, >> another cleanup script. Yeah. >> Yeah. It's all we need. Uh, okay. I am to leave that there. And then then a few Bosch boot loader. Um actually it's good that you're here, Ramon. Um Bosch bootloader has a couple of um security bumps from dependabot and I've been leaving those cuz it seems like it should be something that the pipeline takes care of. But I also didn't want to commit without somebody with more context. >> Not those kind of things. It does almost everything except for uh for these ones. Um so yeah, just merge them. >> Okay. >> Merge them and if it fails, it fails. We will see it in the pipeline. That's >> cool. >> Are these um is it because they're not in they're in test packages? Well, that one's not. Neither of these look like they're safe to >> Oh, yeah. I'll tag you and feel free to do what whatever makes sense. Um, >> yes. Uh, as as a as a general comment, I I added a flag to the Golang bump script in the Go release that will allow it to um bump test dependencies as well as non-est dependencies. So that maybe that flag will be useful. I don't know. >> Okay. Well, if I need some more context, I'll Yeah, I'll text you. Um, okay. Um, this I think uh so this blob was added as part of a PR, but it didn't it because the person who PR the changes didn't have uh the private YAML. It wasn't synchronized to the um to the blob store. So we're seeing failures in the pipeline trying to generate the release. So I I think that the bump jobs will pick up excuse me will pick up the newest version once this has been deleted but right now it's skipping. >> Yeah, I would I [clears throat] think so too. Uh normally would override it but because it's not even able to access it, it will fail. >> Yeah. So yeah um I will quickly add my approval then we can um so this is something that the what's called iuntu advantage or abuntu pro um that uh will wake up and try to see if canonical is present in the uh I think this is maybe the I guess it's in jammy anyway I guess it's a new new change for this >> okay I approved it and merged it >> oh thank you appreciate Great. Um, I'm inclined to merge this unless folks have concerns. >> No, I have no concerns. Okay. >> Buntu, can Ono really like to push stuff he can't remotely? We need to we need to rethink if we want to stay with Canonicle at this point because they are making really bad choices lately. >> Oh, I'm not excited about the idea of switching base OSS. >> Yeah, but now they're putting Rust everywhere and like they they changing >> everything is going to be in Rust. We're rewriting the the Bos directory in Rust. >> Oh, nice. Yeah, it's going to be great. >> It's memory safe. >> Exactly. Um, all right. This was the thing you mentioned, Ned. It sounds like >> Yeah. Yeah. about the lo forwarding. >> Yeah. H I wonder if there might be value in breaking up the Bosch agent into like a a standard log and a and a a debug log potentially. >> Yeah, we Yes. So, we can do that. Um because I if yeah I haven't looked at this. I'm just thinking out loud but sometimes the debug level stuff is very valuable on disk but um probably not valuable to be sending all the time. Although it might be very nice for folks who are debugging agent problems to have the disc to have the the logs get off the VM. But um >> yeah, but it should be a flag then turning it on and off. >> Yeah, >> we we weren't really getting anything with jummy. >> Mhm. >> Because we we need to look I I think it's systemd uh because we that's the whole R unit, right, of RS log that we use. >> Mhm. Yeah. RS lo and journal are both doing things together and then we are we are sending it to the log directory and then and then create a sim link to the B old B wash log directory. >> Yeah, >> I think that might have already been done but I'm I'm not sure. >> Okay. Anyway, this seems Yeah, seems valuable and seems cool. I'm not sure what the I don't have a thought yet about what the right move is, but um maybe on Resolute it it makes sense for us to move the Bosch law the agent logs into the standard RVCAP logs RV gaps logs location. Um cool. Thank you for tracking this down and figuring out a way forward. Oh, people made me check it. Yeah, I didn't want to, but they sell six times more logs and there were questions about >> Yeah, tell them to upgrade their log server, maybe. >> Data's cheap. >> Yeah, exactly. All right. Okay. And I think we're in a good spot with all this stuff. I'm going to move over to issues. GitHub is a little slow. Um, is this a Bosch thing or a UAA thing? Looks like a Um, this might be worth tagging UAA folks. um because they're probably better able to tell us if our the configs were sending are sufficient or not. And I I think they may actually be the the UAA release itself may be in control of these values or at least have control the defaults. Yeah, I'm assuming we're not printing error any error because we're not getting any. I'm sure we have some placeholder for the returned error. It seems to be empty, I guess. Let's see. Marcus, I think, is My network is very slow today. Anyway, while that gets looking looking up, I was going to tag Marcus, who's one of the UAA contributors. Um, seems like this is already in light. There's a PR open. seems like this maybe interesting. Okay, Sebastian is looking into it. Leave that open. Okay. It's good. Okay. seeing anybody from UA. I'm I'll tag one of the UAA maintainers in here. Um, I think that might be the end of current things. Um, I don't know that we have any promotions. This is new. This was opened last week, so I think we usually give two weeks for those. Um, I don't know if I can approve this or if it will matter. It looks like we're good base and merge. Welcome. This seems good. And it looks like we have this was the person I was looking for before merch. All right. And merges there. Excellent. I think that might be the end. I think that's all folks. Unless there's anything last minute agenda items. >> No, I've been out of the game too long. So, >> well, as always, you're always welcome back, Ramon. >> Yeah. >> Well, next week is the EU summit, the summit again, so we'll be there. >> Awesome. I wish I was going to make it, but I will not. Um, all right, folks. Thank you for coming. Uh that was the foundational infrastructure working group meeting and I hope you have a lovely Thursday. Bye all. >> See you. See you next week. See you next week. See you in two weeks. Bye.