►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 17 March 2022
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Sidhartha Mani (Minio)
A
Blaine
and
grant
hey
good
morning,
everyone,
I'm
gonna,
say
I'm
gonna,
give
the
prelude
the
introduction
again
for
the
sake
of
the
recording.
So
I
was
I
was
just
talking
to
blaine
and
grant
about
this
just
a
few
seconds
ago.
I
think
I
think
the
cap
is
very
close
to
being
merged
with
the
last
round
of
reviews.
There
really
wasn't
any
new
comments.
A
It
was,
you
know
it
was
just
a
one
note
saying:
please
address
the
ones
that
you
know
we
haven't
yet
so
so
after
last
week's
meeting
I
updated
the
cap
based
on
everything
we
talked
about,
and
I
think
we
left
the
discussion
kind
of
halfway
last
week.
So
I
just
want
to
continue
that
so
we'll
do
another
round
of
care
preview
today
and
and
and
make
a
decision
together
about
how
we
want
to
move.
A
You
know
design
this,
and
I
also
found
out
another
thing
that
that
might
be
useful
for
authentication,
which
is
what
was
that
again,
so
so,
there's
a
way
to
project
service
account
tokens
into
pods
with
an
expiry
on
them.
It's
it's.
It's
apparently
the
mechanism
that
kubernetes
provides
to
do
credential
rotation.
A
B
A
B
We
did
talk
about
that
yeah
kubernetes
service
account,
tokens
can
basically
say
like
after
after
date
x,
you
know
reload
this
file
and
get
a
new
token
and
the
clients
kubernetes
clients
at
least
know
how
to
how
to
do
that.
C
A
Yeah
yeah,
so
so
you
know
we
could
so
there
was
always
this
question
of
how
I
don't
want
to
get
distracted
too
much.
But
there's
always
this
question
of
what,
if
you
have
multiple
buckets
that
you
that
you
want
to
provide
access
to
currently
the
current
mechanism
just
says
the
map,
all
of
the
service
accounts
for
map
all
of
the
cloud
accounts
for
these
buckets
into
the
same
kubernetes
sales
account
and
then.
B
Yeah,
we
could
hear
you
the
whole
time,
but
you
couldn't
hear
us
how
I.
A
See
all
right,
I'm
sorry
if
I
spoke
over
any
of
you
but
anyway,
so
so
we
can.
We
can
get
to
that.
In
the
end,
the
the
thing
with
service
accounts.
How
about
we
proceed
with
the
cap
right
now,
go
for
it
all
right.
So
so
so
there's
been.
There's
been
this
question
of.
Why
don't
we
create
type
structures
for
protocols
and
we
responded
last
week
saying
we
can't
do
it
at
the
protocol
level,
because
every
vendor
needs
some
vendor
specific
things.
A
So
so
there
is
a
need
for
a
parameters,
map
on
opaque
map
and-
and
michelle
came
up
with
another
suggestion-
saying
basically
just
also
put
the
kind
and-
and
that
way
you
know
you
can
you
can
make
it
a
typed
object.
You
can
refer
your
type
to
object.
We've
thought
about
this
before
I
don't
know
if
it's
really
needed
for
alpha
I,
but
I
think
it's
a
good
suggestion.
A
I
don't
know
if,
like
how
important
do
you
all
think
it
is
that
to
have
a
type
parameters
rather
than
opaque
in
in
the
bucket
object
on
the
bucket
class
object.
A
A
So
so
when
you
say
you
need
both,
do
you
mean
stuff,
that's
purely
s3
and
not
vendor
specific,
would
be
type
and,
and
everything
else
would
be
opaque.
Is
that
what
you
think.
B
That's
common
across
multiple
implementations,
those
become
type
parameters
on
the
bucket
class,
not
parameters
but
typed
fields.
On
the
bucket
class.
You
can
have
an
arbitrary
number
of
those
they
can
increase
over
time,
and
so
the
idea
is
for
the
proprietary
ones
you
need
opaque
and
for
the
ones
that
are
common
to
all.
You
use
typed
and
initially
the
list
of
both
is
very
small,
but
they
grow
over
time.
A
That's
a
good
way
to
put
it
yeah.
So
so
I
guess
we
don't
really
need
this,
then
we
don't
need
whatever
I'm
showing
on
the
screen
a
reference
to
a
type
c
id.
E
A
We
cannot
pass
in
proprietary
parameter
fields.
I.
E
E
Said
I
think
we
gave
we
gave
her
the
example,
but
she
was
saying
that
example
is
not
enough,
because
you
can
actually
just
using
this.
This
thing
she
was
printing
here
would
be
enough.
Is
that
enough?
If
not,
you
probably
need
to
give
a
more
concrete
example.
Why
that's
not
enough,
I
think.
B
Yeah,
I
I
see
what
michelle
is
saying
too
and
boy
I
wish
she
could
just
be
in
this
meeting.
We
could
just
talk
and
talk
to
her
but
yeah.
There
is
an
argument
that,
like
opaque
parameters,
kind
of
suck
in
terms
of
you
know
the
ability
to
get
things
subtly
wrong
and
not
know
it,
and
so,
if,
if
like
a
vendor
wants
to
provide
a
vendor
specific
typed
object.
B
A
I
kind
of
like
this
actually,
like
you
said
it's
a
step
forward,
but
even
with
that,
you
know
evolving.
The
vendor
specific
type
is
much
harder
than
simply
just
providing
a
parameters
map,
especially.
B
C
B
B
A
Yeah
yeah
just
to
answer
that
serialization
question
you
could
still
just
do
json
or
something
and
regardless
of
whether
it's
a
pivx
or
its
type,
the
driver
has
to
interpret
on
the
other
side,
at
least
now,
with
with
the
type
field
with
the
type
crd,
the
driver
gets
to
work
with,
you
know
a
type
structure
rather
than
just
an
unvalidated
map
string,
string.
B
B
C
A
I
wouldn't
go
yeah.
I
think
you
raised
two
good
points.
One
is
yeah
it.
It
does
require
the
grpc
api
to
to
somehow
serialize
an
unknown
structure.
That's
one
and,
and
the
other
is
it's
harder
to
evolve.
This
type
you'll
still
need
a
map
string
string.
You
know
in
order
to
quickly
innovate
in
order
to
quickly
just
add
new
features.
A
B
A
D
B
A
That
sort
of
I
think
that
will
end
up
happening
in
practice
where,
where
you'll
end
up
with
a
lot
of
you
know,
they'll
probably
create
a
type
and
then
just
end
up
putting
all
the
new
features
into
annotations,
like
like,
like
the
initial
versions
of
ingress
controllers,
pretty
much
everything
was
determined
through
annotations.
There
yeah
could
be.
A
Yeah,
okay,
okay,
so
so
two
things
one
is
serializing
for
I'm
just
writing
down
quick
points
for
me
and
I'll
update
it.
You
know
write
it
better
later.
Serializing
for
grpc
is
more
complex.
A
B
Right
in
the
beginning,
at
the
beginning,
I
I
was
just
pointing
out
that
you
know
you,
you
need
both
well,
I
guess
you
need.
This
is
kind
of
a
third
thing
right.
You
need
a
way
for
opaque
parameters
which
can
either
be
a
literal,
opaque
string
map,
or
it
can
be
some
arbitrary
object.
Kubernetes
object
that
just
gets
jsonified
and
then
you
all
and
then
for
stuff.
That
really
is
cross
driver
like
those
should
be
typed
things
that
are
part
of
the
cozy
spec,
but
I
realize.
A
B
A
Or
why
do
you
think
like
shing
was
saying
earlier?
I
I
still
wonder
why
why
michelle
thinks
this
is.
This
is
better
than
would
be
well.
B
E
As
much
sense,
more
than
just
like
one
thing,
we
want
to
pass
in
right.
If
you
need
like
five
of
those
config
refs,
then
that
will
be
a
problem,
then
probably
won't
be
better.
No.
B
E
B
A
Yeah,
I
don't
think
it'll
even
gain
that
much
attention
by
doing
it,
because
its
focus
is
elsewhere.
E
A
E
Maybe
that's
a
new
development
we
haven't,
we
were
not
giving
that
feedback
before.
E
E
Okay,
it's
just,
I
still
don't
know
why
that's
what's
the
problem,
what
we
I
I
have
not
heard,
like
particular
complaints
about
you
know,
since
we
are
using
that
in
forwarding
and
snapshots.
I
haven't
heard
any
particular
concerns.
A
I
think
I
think
we
can
verify
mr,
why
why
you
know
we
can
ask
why
why
the
current
like
like
like
ben,
is
saying.
I
think
the
the
benefit
that
this
provides
is
not
that
much
it's
not
it's
not
orders
of
magnitude
higher
it's
it's
marginally
better.
The
main
benefit
I
see
is
is
for
the
admin
the
you
know.
They
won't
make
any.
A
E
D
E
A
A
Yeah,
I
think
I
think
I
don't
think
we
have
to
resolve
this
or
take
this
and
and
make
it
a
part
of
the
api
spec.
A
I
think
we
can
just
leave
a
question
here
saying
the
current
approach
works
and
here
are
here-
are
the
I
mean
it's
a
trade
of
both
kind
of
work.
The
current
approach
works.
What
she's
saying
also
works.
We
can
talk
about
the
disadvantages
of
the
approach
she
suggested
and
asked
you
know.
Do
we
still
need
to
go
forward
with
this,
or
can
we
just
move
on
without
this?
I
think
I
think
it
will
be
fair
to
say
that.
C
A
Yeah,
I
think
I
think,
last
week
we
were
having
a
discussion
about
protocol
field.
This
needs
to
update
okay,
we
were
having
a
discussion
about
the
protocol
field
and
and
why
I
think
michelle
was
suggesting
that
the
protocol
field
like
why
do
we
have
it
in
the
bucket
class
object?
Is
it
meant
to
restrict
what
protocols
are
exposed
and
and-
and
we
had
a
good
explanation
for
this-
I
I
can't
fully
remember
so.
A
I
didn't
I
didn't
respond
to
this
yet,
but
the
discussion
kind
of
went
in
the
direction
of
should
we
have
the
protocol
feel
in
the
bucket
access,
because
the
idea
is
only
the
application.
Writer
really
knows
what
protocol
they
want
their.
You
know
their
application
supports.
Does
anyone
grumbler.
B
B
You
know
at
a
glance
whether
a
certain
request
is
likely
to
succeed
or
not
right,
because
if,
if
you
know
that
your
workload
requires
gcs
and
you
go
look
at
the
bucket
class
and
see
that
it's
not
there,
you
might
not,
you
know
you
might
even
bother
creating
your
bucket
request,
because
you
know
it's
going
to
fail
and
then
you
can
just
go
either,
find
a
different
workload
or
find
a
different
cluster
or
talk
to
the
admin
to
try
to
resolve
the
problem.
So
it
gives
you
earlier
feedback
on
supported
protocols.
A
Well,
not
really
right,
because
I
could
argue
the
other
way
and
say:
users
will
not
have
access
to
the
bucket
class,
so
they
create
the
bucket
request,
point
it
to
either
the
default
bucket
class
or
someone
they
know
and
and
they'd
be
wondering
why
the
part
doesn't
start
up
or
why
the
market
isn't.
Oh.
B
Yeah,
a
lot
of
users
would
never
notice
this
or
they
would
ignore
it,
and
it
would
just
go
on
and
hit
the
wall
anyways.
But
the
point
is,
it
creates
an
opportunity.
If
somebody
did
want
to
create
like
an
introspective
workload
generator,
it
could
go.
Look
at
a
particular
kubernetes
cluster
and
look
at
the
bucket
classes
and
then
decide
what
to
do.
B
It
creates
a
possibility
where
otherwise,
there
would
be
none
you're
right.
Most
people
will
not
look
and
they'll
just
they'll
still
get
the
error,
but
that
that
would
be.
Those
are
the
two
benefits
I
can
think
of
for
having
it
here,
because
in
real
you
know,
the
the
real
driver
has
a
real
list
of
what
it
can
support
and
it
can
notify
the
sidecar
through
grpc,
like
I
support,
s3
and
gcs,
and
so
the
sidecar
will
know
what
is
really
supported
and
the
bucket
request
with
the
bucket
claim.
B
Well,
we'll
know
what
the
what
the
workload
really
needs
and
they
can
work
it
out
between
them,
whether
that's,
okay
or
not.
This
is
just
sort
of
a
way
to
perhaps
administratively
disable
one
that
otherwise
would
work
and
to
communicate
to
external
controllers.
You
know
what
what
what
can
work
in
advance.
A
Yeah,
and
is
this
passed
into
the
grpc
spec
into
the
grpc
call
for
bucket
creation.
B
Probably
not
I
mean
I
would
expect
the
sidecar
would
consult
the
list
when
it
was
trying
to
bind
a
bucket
claim
to
a
to
a
bucket
class,
and
if,
if
the
protocol
and
the
bucket
claim
didn't
match
one
of
the
bucket
class,
the
sidecar
would
just
never
even
make
an
rpc
call.
And
just
say
this
is
an
error.
A
Right
right
so
yeah,
so
so
so.
A
B
A
B
Not
for
correctness
for
correctness,
you
could
just
say
either
you
get
what
you
asked
for,
you
don't
get
you
asked
for
and
in
the
sidecar,
and
the
driver
can
figure
that
out
between
them
between
the
two
of
them,
the
benefits
to
adding
it.
Also
in
the
bucket
class.
Are
you
know
if
you
want
to
override
what
the
driver
says
and
say
and,
and
you
know
have
fewer
protocols
than
driver
can
really
support,
or
if
you
want
to
just
make
it
discoverable
by
external
applications,.
A
Right
right
right
through
the
specification
itself
yeah,
so
so,
even
if
I
get
if
I
get
a
list
of
protocols
here,
if
I
set
a
list
of
protocols
here
in
the
class,
it's
possible
that
the
driver
may
not
support
all
of
them.
B
B
A
A
B
A
Yeah,
I
think
that's
better
anyone
else.
Any
thoughts
on
that.
A
I
I
like
this
actually
so
in
the
sense
that
it's
hard
to
justify
for
me.
What
protocol
really
does
here
other
than
specifying,
but
but
just
as
we
discussed,
you
could
specify
a
list
here
that
doesn't
really
match
what
the
driver
supports.
So
even
that
benefit
isn't
isn't
really
there.
A
Itself,
for
example,
yeah
yeah
yeah.
That
makes
sense
so
so
what
if
we
remove
protocols
from
a
bucket
class
and
just
had
one
protocol
in
the
bucket
claim-
and
you
know
bucket
creation-
either
succeeds
that
fails
based
on
the.
B
A
Yeah
my
into
now:
okay,
let's,
let's
do
that.
You
need
to
write
yourself
an
ai.
A
A
I
think
the
reason
we
started
doing
passwords
was
so
that
it
wouldn't
join
wretching.
A
The
good
thing
is:
git
stores
this
cache
in
in
s
cookies.
So
even
if
I
leave
the
space
and
reload
it's
going
to
be
there.
A
Yeah
I'll
I'll
just
make
a
note
here
and
I'll
update
it.
Based
on
that
note,
I
don't
think
this
is
good
enough
as
a
response,
but
it's
good
enough
for
me
to
follow
up
later,
all
right.
So
here's
another
question
that
michelle
had
resource
accounting
bucket
access
class,
okay,
so
bucket
access
class.
Her
question
is:
should
we
have
driver
name
in
the
bucket
access
class.
A
I
think
I
think
the
reason
she's
she's
saying
is
one
is
discoverability
because
it's
you
know,
you'll
know
what
driver
is
gonna
end
up
talking
to,
but
but
you
don't
want
there
to
be
a
misconfiguration
right
between
what
the
bucket
itself
was
provisioned
with
and
and
the
driver
with
which
you're
asking
for
credentials.
F
Could
would
it
be
beneficial
to
like
add
the
supported
drivers
as
a
status
item
on
the
bac?
F
F
I
don't
know
if
that
then
could
make
its
way
to
a
status
on
the
bac
to
give
users
the
the
benefit
of
discovering
what's
available
to
them,
while
at
the
same
time
making
making
the
system
not
prone
to
misconfiguration.
A
E
E
C
B
A
A
Yes,
well,
there's
a
problem
with
that,
though.
The
problem
I
see
with
having
a
driver
feel
here
is,
you
might
end
up
mismatching
a
bucket
access
class
for
a
given
bucket.
So
say
you
have
two
drivers
running
in
one
cluster
and
you
have
bucket
one
provision
by
driver
one
by
specifying
the
bucket
access
class
you're.
Now
restricting
if
you
specify
the
wrong
driver
name
in
the
bucket
access
class,
then
then
you're
trying
to
gain
access
to
a
bucket
that
was
provisioned
by
a
different
driver.
B
A
That's
fair:
now
we
do
remove
the
ambiguity
of
of
what
driver
it
needs
to
talk
to,
because
now
you
specify
bucket
class
or
bucket
access
class-
and
you
don't
have
you
know
by
not
specifying
the
driver
name,
it's
the
driver
is
actually
implied
from
the
bucket
itself.
B
So
if
you
put
the,
if
you
explicitly
put
the
driver
name
in
the
bac,
then
the
sidecar
that
is
responsible
for
calling
the
driver
could
just
reject
the
acs
that
don't
match
immediately
and
say:
oh
okay,
this
is
this
is
a
bac
for
some
of
the
driver.
We're
not
you
know
we're
just
generating
air
and
return.
B
B
A
A
Well,
not
really.
I
was
going
to
say
for
a
given
protocol.
The
way
you
specify
access
is
going
to
be
the
same,
but
that's
not
entirely
true.
I
think
I
think
the
way
you
specify
or
where
you
specify
access
control
for
aws
is
is
different
from
what
csf
expects
so
yeah.
I.
A
A
A
So,
on
the
first,
no,
it's
only
returned
right.
A
A
No
it's
from
the
ba.
Yes,
it's
well
it's
from
the
bar.
So
no
not.
Where
does
it
come
from,
but
the
first
time
when
you're
calling
grant
access,
so
you
don't
have
an
account
number
that's
returned
by
the
driver
yet,
but
the
reason
we
decided
to
have
an
account
name
that
that
gets
passed
in
is
for
item
potency,
because
if
you
don't
have
this,
two
calls
to
the
same
grant.
Access
will
end
up
providing
two
different
credentials.
B
Well,
yeah,
you
need,
you
do
need
an
item
potency
key,
but
I
don't
know
if
the
I
didn't
think
that
that's
what
the
account
name
was.
I
think
I
thought
the
account
name
was
specifically
for
the
for
the.
I
am
based
authentication,
where
you
were
meant
to
grant
access
to
a
specific
cloud
account
rather
than
like
generating
an
s3
someone.
You
know
an
s3
secret.
A
Maybe
we
need
a
better
name
here,
but
but
it
the
only
purpose
it
has
right
now
is
to
service
the
item.
Potency
key.
A
B
Dash
hold
on
okay,
I'm
confused
again,
because
I
thought
we
collapsed
bas
and
bars
down
into
one
object.
Oh,
that
it
hasn't
been
updated.
Then
yeah
there
is
no
bar,
it's
just
a
ba
yep.
I
mean
I
was
happy
in
the
in
the
dual
object
model
where
bars
and
bass
were
separate.
But
if
you
want
to
collapse
it
down,
then
yeah
you,
you
need
something.
B
Okay,
but
but
the
account
name
is
still
necessary,
for
I
am
style
authentication,
it's
just
not
it's
just
it
will
be
ignored
for.
A
A
The
the
pod
simply
uses
so
so
the
part
simply
specifies
the
service
account
name
and
the
service
account
is
mapped
to
a
particular
cloud
account.
A
kubernetes
service
account
is
mapped
to
a
cloud
account.
A
Not
really
you
just
need
some
account
that
grants
access
to
a
particular
service
account
to
access
the
bucket.
B
All
right,
I
guess
I
want
to
see
that
in
action,
yeah
yeah,
so
I'm
not
I'm
not
an
expert
on
how
well
this
cloud
stuff
works.
A
So,
let's
see
so
so
you
create
a
google
service
account.
So
this
is.
This
is
different
from
a
kubernetes
service
account
and
yeah.
Add
im
policy
binding
that
binds
the
google
service
of
gsa's
gold
service
account
to
the
kubernetes
service,
account.
A
A
B
A
Okay,
yeah,
I
was
just
trying
to
explain
but
yeah.
It
needs
a
longer
explanation.
It
needs
more
time,
but
for
now
all
this
account
name
does.
Is
it
it
acts
as
an
item
for
c
key?
That's
all,
and
I
think
that's
all
we
should
say.
B
B
A
D
B
A
B
A
A
So
access
id
or
access
identify,
I
don't
know
some
identify
any
thoughts,
any
any
ideas.
Anyone.
B
B
A
B
No,
the
sidecar
just
looks
at
the
kubernetes
object
and
passes
down
the
necessary
fields
to
the
driver,
including
the
uuid
of
the
bucket
access
object
as
the
as
the
item
potency
key
and
that
just
becomes
an
implementation
detail,
that's
not
visible
to
kubernetes
layer.
Oh,
we
can
just
call
it
bucket
access
id.
No,
no!
You
just
delete
the
field
and-
and
we
just
say
for
item
potency,
we
use
the
uuid
of
the
object
itself
and
you're
done.
A
B
A
Yeah
because
because
then
there's
no
ambiguity,
you
know
you
know
exactly
what
needs
to
be
filled
in
there's
no
question
of
where
you
get
that
id
from
and
and
you
know
we
can
write
in
the
docs
saying
that
bucket
access
id
can
be
used
for
it
importantly
by
the
driver,
if
it
wants
to
prevent
multiple
access
to
be
cleared
for
the
same
request.
A
No,
no
totally
fine.
You
know
it's
important
that
everyone's
on
the
same
page.
So
should
we
also
consider
other
important
features
like
quota
restrictions?
C
A
What
I
mean
by
that
is
yeah
I'll
I'll,
add
a
bunch
of
stuff
like
that
quotas,
restrictions
and-
and
you
know,
better
access
control
on
how
buckets
share
and
stuff
like
that
here.
I
think
that's
an
easy
one.
I
think
in
this
bucket
and
there's
no
okay,
so
I'll
update
yeah,
that's
about
it.
A
I
think
we're
almost
done
so
I
mean
with
the
cap
and
and
the
meeting.
We
have
a
few
minutes
and
I
have
a
few
other
things
to
discuss,
but
I
think
that's
all
with
the
cap.
A
Sweet,
okay,
all
right,
so
I'm
just
going
to
assume
silence
means
no
questions
and
everything's.
Okay,.
B
So
so
sid
I
I
do
want
to
recommend
that
if
michelle
chronically
can't
attend
this
meeting
and
if
we
need
to
have
her
present
for
one
of
these
review
meetings,
we
really
should
consider
like
a
one-off,
scheduled
meeting
between
this
team
and
michelle
to
go
over
any
details
that
were
that
require
real-time
discussion.
A
B
B
C
E
I
actually
recommended
last
time,
but
last
time
she
was
like
she
just
need
to
set
aside
some
time
to
review
it
herself.
So
yeah.
A
Okay,
yeah:
let's:
let's
how
about
this?
Let's
update
the
cab
and
then
and
then
we'll
reach
out
to
michelle,
saying
that
hey
would
be
good
if,
if
we
all
could
get
together
and
kind
of
do
a
live
review.
B
B
A
A
But
given
that
we
are
so
close
to
resolving
everything
I
mean
assuming
I'm
assuming
the
cap
gets
merged.
There's
a
tiny
possibility
that
that
can
happen
that
it
can
happen.
We
could
potentially
skip
next
week's
meeting.
A
I'm
going
to
be
there
for
a
while,
but
but
next
week
I
definitely
can't
attend
I'm
going
to
be
there
for
two
weeks
after
that,
I'll
be
able
to,
I
mean
I'll,
be
able
to
make
it
each
time
every
time
it's
just
next
week
and
the
week
after
that
is
still
tentative
yeah.
This
time
slot
is
it's
just
before
midnight
in
india,
so
you'd
be
a
pretty
late.
A
I
think
I
can.
I
can
make
that
work,
but
next
week
I'm
going
to
be
busy
yeah.
B
A
A
I
think,
given
my
next
week's
schedule,
I
would
prefer
to
skip
it
unless
someone
wants
to
you
know
take
over
for.
E
C
E
If
you
know,
if
you
want.
E
Something
yeah.
A
Definitely
yes,
yeah
I'll
anyways
we're
doing
that
yeah!
This
was
just
about
the
meeting.
Okay,
so
then
that's
resolved.
We
will
skip
next
week's
meeting
and
yeah
the
cap.
I
think
we're
all
in
agreement
on
what
to
do
about
this.
B
A
B
I
was
gonna
say,
have
a
safe
trip
man.
I
understand
that
flights
to
india
are
relatively
challenging
with
the
certain
airspaces
being
closed
right.
It's
already.
A
Yeah
yeah
yeah,
actually
it
actually
flies
through
dubai
and
the
path
to
dubai
is
directly
over
ukraine.
So
they
can't
take
that
right
now,
so
so
they're
actually
going
around
through
russia
and
then
getting
back
to
dubai.
A
No
russian
s
place
is
not
close,
so
so
so
russia
is
very
wide
from
east
to
west
and
and
yeah
yeah.
Because
of
that
you
know
ukraine's
just
in
one
corner.
So
this
this
flies
all
the
way
through
the
middle
of
russia
and
comes
back
circles
around
to
dubai
and
then
and
then
to
india
from
there.
A
Yeah
yeah
yeah.
Hopefully
hopefully
you
know
it's
all
fine.
I
think
it
should
be
fine
because
I
have
I
have
other.
I
know
I
know
other
people
that
are
doing
the
same
trip:
yeah
yeah.
It
should
be
okay,
but
but
thanks
for
the
wishes
yeah
yeah,
so
I'll
update
the
cap-
and
you
know
I
think,
I'll-
think
michelle
and
and
we'll
skip
next
week's
meeting
and
and
depending
on
michelle's
response,
we
can.
We
can
set
up
a
call
with
them.
B
A
All
right,
I
think,
I
think
we're
at
the
top
of
the
hour.
Unless
anyone
has
any
questions,
I
think
we
can.
You
know
we
can
end
a
little
early.
You
can
have
two
and
a
half
minutes
back.