Submind YouTube summaries
Thumbnail for Foundational Infrastructure Working Group, July 30 2026

Foundational Infrastructure Working Group, July 30 2026

Watch on YouTube

Video summary

The July 30 meeting of the Foundational Infrastructure Working Group focused primarily on a technical challenge regarding disk resizing within the Cloud Provider Interface (CPI) for Alibaba Cloud, specifically when migrating to smaller instance types like moving from C6 to C9 families. A team member presented an issue where the current in-place update method fails if the new disk is smaller than the existing one, prompting a discussion on potential fallback strategies. The proposed solutions included either returning a "not supported" error to allow manual handling by the Director or implementing a snapshot-based approach similar to those used by Google Cloud Platform and Azure. However, after weighing the complexity of supporting multiple update methods against the frequency of such edge cases involving VM type changes combined with disk resizing, the group decided to keep the implementation simple for now. The consensus was that raising an exception when CPI support is unavailable would be sufficient, reserving more complex fallback logic for future iterations if specific situations demand it. The discussion then shifted to reviewing pending pull requests and addressing breaking changes related to Terraform 5.x updates and dual-stack network implementations. Several items on the dashboard were flagged as blocked or requiring additional attention due to these structural changes in AWS configurations, which involved new API calls that currently hinder deployment teams. The team reviewed specific PRs concerning storage container configs and Ruby gem bugs found within certain Director versions, such as 2831.2, where health monitor testing was identified as a gap in the continuous integration pipeline. While some fixes were already merged or approved by reviewers like Nishant, others required further scrutiny from experts familiar with dynamic network configurations before being considered safe for merging to avoid introducing instability into the infrastructure codebase. Finally, the group addressed administrative matters regarding PR statuses and tracking mechanisms for known issues that had been lingering in their workflow. It was noted that while some bugs were resolved and fixed versions would appear in upcoming releases, others remained open for contribution or further discussion depending on whether they represented critical blockers or minor improvements. The team agreed to maintain a clear state for each item—whether pending review, waiting for changes, or ready for merge—to ensure transparency and prevent delays caused by unaddressed feedback loops. With the dashboard cleared of immediate action items aside from ongoing reviews and future enhancements planned for later dates, the meeting concluded with an acknowledgment that these foundational improvements would require continued vigilance to maintain system reliability across different cloud environments.
Read the full video transcript
Hello to the foundation infrastructure working group meeting. Today we have 13 13 of July. And this agenda is empty. Um so before going to the dashboard, do you have any topics we should discuss before the dashboard? >> I think I'll mention it. >> I have a question, but it's not really concerning everyone and just a specific thing I was implementing for the Ali Cloud CPI. Not sure if I should ask now or later. >> Do you have some PR or issue on that? >> Uh yeah, I have a PR. It was already merged and I I think it was already released as well, but it's like a follow-up. >> Mhm. >> I don't know if you opened it. So regarding the update disk CPI method, >> Yeah. >> Uh this one. So when [clears throat] the Bosch director wants to use the update disk uh in the CPI side instead of using the normal approach, uh and the case where the size of the new disk is smaller than the current one, the CPI can't do that well, the way I implemented because it uses the in-place update that Ali provides. So it just fails. And my idea was to implement a fallback. And uh one idea is to send a not supported back to the directory and let the director handle it using its old method. The one that attaches both this the old and the new one and copies over everything. So I guess that's not ideal. Because then the operator doesn't really know that the fallback has happened and he's intending to use the CPI method but it's fallback is manual rather automatic and he doesn't know about it. And then the other approach would be to use snapshot approach like in GCP and I think Azure in the future will have it as well. So I guess the the best way to be to make it is to fallback on the CPI side and just use the snapshot approach. So does that make any sense? >> What What is the snapshot approach? I'm uh >> Uh yeah, so it's it creates a snapshot of the disk and then creates a disk from the snapshot but with the new specs. And the disk the new specs can be a change in the in the category or the size or both. >> Really does the snapshot approach support a smaller disk? >> Uh can we test it out to be honest? >> I thought this using a smaller disk is is an overall issue. >> Yeah, it it is I think but the old approach where the director takes care I I think it should work. In in the case where it actually can fit everything from the old disk. So so that's why I thought it makes sense to have a fallback of some sort. But, the it wouldn't work in the case where like I'm uh giving example here from migrating from C6 to C9 instance families because the new instance families don't support the old disks. So, in that case the directory approach would fail prompting the new update disk CPI and uh idea to fall back using the snapshot method. >> And why the snapshot method is used in this update disk? >> Uh sorry, can you could you repeat that? >> And which CPI is using the snapshot method for update disk? >> I think GCP. I I I think it's used it by used it by default because it doesn't really have an in-place update. >> Yes, yeah. GCP doesn't support in-place disk modifications. Um so, we had to implement a snapshot approach for GCP. >> [clears throat] >> I think what you were uh what saying it that Ali does support in-place updates. Yeah, but for particular cases, it's actually not supported. >> I was thinking well, this will make uh uh complex CPI implementation because you will have to support two different ways of um disk update >> Um I look at this. So, in the CPI, resize disk normally we should get those not supported raised. >> Yeah, this is what the wire was was suggesting. >> Exactly, and I think that would be um um an acceptable approach to go in this direction. >> We would just not support it. >> Yeah. >> Uh wait, in that case, I think the director will fall back to the old way. >> Mhm, yes. Yeah. >> Yeah, which I I think won't work for the this case where I'm having the two change uh VM types. >> But, the question is because this CPI disk update um is behind a property, which is here director enable CPI resize disk. Um the question is if this is enabled by the operator should we automatically fall back to the director migration approach? Because the operator will be expecting to actually for the notification to happen on the CPI instead. >> But, it is documented that if CPI somehow not support for some reason, then it fall backs to the >> Uh wait. Yeah. >> creating a new disk, and this is edge case which CPI So, you need to introduce another strategy to resize to update those disks with snapshots. So, you um Is it an edge case or is this is it something which happens or can can can happen often? Uh >> I think it should be regarded an edge case. And it happened in the case where you want to update the VM type and also resize the disk, which I guess would have happened often. >> Mhm. [clears throat] I will try to keep things simpler, just uh yeah, fail uh fail uh raise the not supported exception. Then you don't need to do much in the CPI. Otherwise, you need to implement alternative resize update disk. Yeah. >> Yeah. I think for now we can keep it simple. And if we need something or if we have a situation where we need to invest more, we can continue there. >> Okay. Yeah. Thanks. >> document Submit or should I uh Okay. Do you have anything else to discuss? Okay, then uh we can go to um the dashboard. All team pending. >> [sighs] >> March Let's put forward uh um what is this? I should tell him provider from his breaking changes. There are some breaking changes. Uh I don't know whether I just merging will be fine. Doesn't look [clears throat] so. But we have to take care of Terraform 5. I will sign here soon. Careful there. Just consuming the change is fine or we need to do something more. And we need also review here. Notice this thing. So currently ships are using curl. Do you have context on this? >> Probably related to the dual stack that Sebastian is working on but no more context. >> Mhm. Okay. All right. I'll sign to reviews. Fix adjust storage container config. Now this we walked already into this. >> Um this one is related to the change we did on AWS where we implemented an API call API call. >> Mhm. >> So, yeah, this this one is good, and I think it's also blocking our um deploy team currently. >> And do we have So, um this is a Terraform template, so it will update the I am create time. >> Yeah. We decided So, >> We can merge this all this automatically. We will add to the needed role. >> Mhm. Yeah. >> Okay. >> [clears throat] >> In this one, I had some comments, review comments. So, I skipped reviewing it. >> Uh at the end of a site, uh >> [clears throat and cough] >> Nishant approved this one. Comments are not resolved yet, but So, uh he suggested some small things, um but um also approved the PR. I will ask. I will ask >> [sighs] >> last week. And um >> I'm still waiting for approval. I'll wait. Yeah, pending for which I would pending for which is the right state. How about this let you provide a review? >> Yep. This one is also related to the dual stack implementation. Feel confident in this one. Looks Looks okay to me. >> You say you say it's fine to merge? >> Yep. It's good to me. >> This is pretty dangerous stuff. >> Sebastian has tested them. I think he mentioned that in the description. I mean we could also leave it for a a second review as well. >> I will wait for another week. Maybe we get another feedback. Maria, I think it's the right person to provide additional feedback. Because I can I remember that we've been trying to get this right with this network dynamic network and it's always a little bit tricky. Okay. So, this was This is an old one. Now, it has been updated and you reviewed. >> Um yeah, so this one it's a bigger change. Um I would wait for additional reviews. >> But, they are related, right? >> Um yes, yeah. >> Sorry. Okay, we are again on the dashboard. Let's check waiting for changes. Still waiting for changes here. And label triggered backwards. Uh I still didn't have time to look into this. Most probably you are more impacted by this when you work with this project. It would be great to have your opinion here. Uh What strategy strategy is better? At least Adam provided feedback. Okay, still waiting for changes this one. Open to noble. This is hips. Same waiting for changes. They check pending review. Okay, we had this one. This is also pending for days one review from one reviewer, but we still need one review from the from an approver. Also the same. I remember we discussed this last time. And then Adam is also on vacation. This one we said uh we want another review. Here the same because of the breaking change. And here this is pending review. Okay. >> There is nothing. We have to check with the bumps. Um inbox This is only a new one replace. Yes. >> [clears throat] >> Yeah, this is sure. There is a PR code that Okay. pending KO >> And that's a long read. Um shortly um one of the Bosch director versions versions um particularly 2831.2 Um we somehow got um Ruby gem with a bug >> Mhm. >> inside. And I opened this um so we can look into why um we missed it in the CI So I I haven't spent much time on it, but it looks like we're not properly testing the health monitor on the CI before release. >> Mhm. >> [clears throat] >> Um yeah. >> Interesting. >> tracking purposes. Um the Ruby gem problem has been fixed and um we will have the fixed version in the next director. >> Mhm. >> Um this is more for tracking and to maybe potentially improve the CI tests so we can catch something like this in the future. >> Yeah, makes sense. Um sure. What state this should be waiting for? Open for contribution, pending merge, pending review, discussion. I think this is then pending review and discussion. So this for discussion or the same thing. Um >> Um this one I mentioned on the last meeting. >> Yes, I remember. I just saw that it's 3-day old and that's why I was a little bit >> Yeah, um I opened it again for tracking purposes. I will I'm looking into it and will probably open a PR with a a potential fix for it or try to address it. >> Mhm. Okay, then it's waiting for changes. Contribution or for contribution. Yeah. So, we had this one also last time and I also saw a fix about this. Um So, they changed the default to be false for BPM. Used in the workers. Is it I did this? It's not somehow Who is the person? No, no. >> Then we have everything promotions. Let's check. I don't think that we have any. No. Then we are done at least with the dashboard. >> [sighs] >> If >> [clears throat] >> anything new which popped up in the meantime. No, then we are done for today. Thanks for your time. Take care and see you next time. >> Thank you. Bye-bye. >> Bye-bye. >> Yeah. >> Bye-bye.