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.