►
From YouTube: WG-KMS Bi-Weekly Meeting for 20221004
Description
WG-KMS Bi-Weekly Meeting for 20221004
A
A
C
A
Yeah,
so
I
I
have
not
looked
at
it,
which
is
my
fault,
however
I
would
assume
it
is
still
valid
because
we
haven't
changed
any
of
the
API.
All
we're
all
we're
sort
of
desperately
trying
to
do
is
get
kubernetes
kubernetes
in
a
place
that,
like
we,
have
all
of
our
squats
so
like
it
took
like
a
niche
a
month
to
get
like
a
a
folder
effectively
created
for
us
to
put
the
KMS
stuff
in
which
is
absurd.
A
So
I
was
focusing
on
those
because
I,
basically
don't
control
the
approval
of
those,
whereas
for
like
the
reference,
implementation
and
stuff
I
have
more
time
because
I
just
have
to
review
it
and
I
can
just
approve
it
and
it's
fine.
It
doesn't
I,
don't
have
to
like
drag
in
like
Jordan
and
everybody
else
to
review
it
with
me.
A
If
you
wanted
to
move
it
to
kubernetes
kubernetes,
it's
fine
with
me
like,
if
you
want
to
just
open
the
pr
there,
instead
like
to
migrate
the
code
into
the
new
KMS
staging
repo,
because
that's
where
it's
gonna
live
like
where
it's
supposed
to
go.
So
if
you
wanted
to
do
that
just
so,
it
would
run
on
CI
and
stuff
like
if
you
have
tests,
and
you
want
them
to
run
in
CI
and
see
it
Go
Green.
That's
that's
totally
fine,
but
you
haven't
done
anything
wrong.
C
A
A
Which
I
expect
the
reference
implementation
is
probably
already
doing
like
like?
Otherwise,
it
probably
wouldn't
work,
but
so
yeah
I,
so
I
I
think
like
I
want
to
get
at
least
some
of
it
in,
if
not
necessarily
like
the
final
version
of
it
in
in
126,
mostly
because
I
I
want
some
of
our
tests
to
use
like
a
real
like
an
actual
implementation,
not
a
base64
implementation
and
be
able
to
sort
of.
A
A
Right,
so
what
I
was
well?
What
I
was
going
with
that
is
like
I,
don't
feel
the
need
for
the
reference
implementation
to
be
perfect
and
complete
for
pieces
of
it
to
get
merged
is
sort
of
the
the
bit
I'm
getting
at
so
like,
for
example,
I.
Don't
necessarily
assume
it
has
perfect
metrics
or
something
like
metrics.
A
Yet
it's
fine,
like
I
I,
think
we
we
should
get
a
good
enough
thing
in,
so
that
other
people
can
work
on
it
with
you,
instead
of
like
it
being
all
elsewhere,
like
the
sooner
there
is
code
available
within
that
repo
I,
think
the
better
and
and
I
do
want
to
be
able
to
have
it
used
and
test.
So
that
way,
like
you
know,
once
we
start
like
adding
metrics
and
stuff
to
it,
you
know
we
could
have
an
integration
test
for
canvas
V2.
A
That's
using
the
reference
implementation
performing
some
operations
and
then
making
real
assertions.
Saying
yeah
I
know
the
metrics
actually
work,
because
you
can
see
them
like
they're
being
put
somewhere
and
so
forth,
and
so
on.
Right,
like
I,
want
I
want
to
test
the
pieces
together
and
we
we
probably
can't
do
like
Real
Performance
tests,
because
you
know
you
won't
be
reaching
out
to
a
real
key
Vault,
but
even
that
might
not
be
out
of
the
question.
A
A
So
that
I
think
is
sort
of
the
next
step
on
that
one
and
then
oh
I
will
work
on
key.
It
will
improve
it
as
time
goes
on,
so
we
have
about
a
month
from
now
is
code
freeze,
so
we
have
that
time
to
keep
merging
stuff
into
kubernetes,
kubernetes
and
then
I
think
like
a
week
after
that
is
Test
free.
So
we
can
keep
writing
tests
for
a
week
after
that
and
afterwards
we
can
still
keep
writing
code.
A
But
for
example,
but
one
of
the
things
we
have
to
do
to
go
beta
in
127
is
will
write
out
all
the
requirements
for
beta,
but
one
of
them
is
the
reference
implementation
yeah.
We
we
do
want
to
probably
have,
like
you,
know,
bits
and
pieces
a
little
bit
ready,
so
that
way
we're
a
little
bit
ahead
of
that
curve,
because
there's
there's
generally
like
because
of
Christmas
and
all
that
stuff,
like
there's
a
actually
surprisingly
little
time
in
between
those
releases.
Just
because
people
are
out.
A
C
B
I
was
also
going
to
say
the
same
thing
like
because,
even
if
a
review
on
March
there,
then
like
you,
would
still
need
to
make
certain
changes
to
bring
it
again
into
stating
directory.
So
like
it's
twice,
the
work
for
you
like
in
making
changes
so
like
yeah,
just
making
one
change
to
make
it
land
in
the
stating
directory
would
be
like
the
beautiful.
So
I
was
going
to
say
the
same
thing
today
on
the
car.
C
C
A
B
Yeah,
so
I
could
stop
the
expiring
cash
stuff
I'm.
Just
seeing
what
better
way
do
you
want
to
test
it
like
I?
Have
the
basic
unit
test
by
removing
the
clock?
Skew
and
I
can
check
that
it
works
so
I'm
just
seeing
if
I
can
add
more
tests,
but
other
than
that
I
think
it's
complete,
so
I'll
open
a
PR
later
today
and
then
once
I
finish
that
there's
one
other
PR
that
I
I'll
issue
that
I
assigned
to
myself
the
disa
love
multiple
KMS
plugins,
with
the
same
name.
B
Those
are
the
two
things
in
the
KK
repo
and
then,
apart
from
that
I've
been
reading
the
two
gaps
that
we
have
to
look
at,
which
are
required
for
rotation.
So
one
is
the
API
server,
Cube
API
server
identity
and
then
the
second
one
is
a
storage
version,
API
and
then
I
think.
The
plan
is
me
and
more
planning
to
sync
on
it
later
today
and
then
add
it
to
the
agenda
for
seek
API
Machinery
tomorrow
to
see
what
we
can
do
to
take.
B
It
from
alpha
to
Beta
to
GA
and
I
think
more
and
mentioned
before
that.
One
thing
we
can
do
is
if
there
are
no
blockers
and
all
that,
then
we
could
follow
the
same
graduation
so
like
when
we
graduate
KMS
to
Beta.
We
can
see
if
we
can
graduate
others
to
Beta
as
well
like,
depending
on
how
the
call
goes
tomorrow,.
A
You
know
so
there's
the
API
server
identity,
Alpha
cap
and
the
storage
version
Alpha
account
owned
by
API
Machinery,
which
basically
block
us
from
doing
rotation.
If
those
things
don't
for
automated
rotation,
those
don't
exist
because
they
basically
try
to
solve
the
same
problems
that
we
have
to
solve
so
yeah.
That
was
the
gist
of
my
idea.
There
is
that,
if
we
can,
if
we
can
try
to
work
on
it,
try
to
polish
those
things
within
this
release
and
then
crisp
up
their
beta
requirements.
A
A
B
Yeah
so
so
far,
I've
looked
at
the
API
server
identity.
One
like
there
was
no
major
blocker
for
Alpha
to
Beta
I.
Think
like
Tess
was
one
thing
and
then
metrics
around
it.
So
tomorrow,
based
on
what
city
API
missionaries
says
like
they're
like,
oh,
maybe
they
need
bigger
changes
and
all
that
I
think
we
have
to
make
a
decision
that
if
we
can
actually
graduate
it
to
Beta
with
KMS,
because
there's
no
one
working
on
those
two
right
now
like
it's,
it
was
implemented
in
120
and
that's
it.
A
C
There
is
one
more
feature
that
assigned
to
me
was
encrypting
everything,
so
hopefully
I
will
start
working
on
that
as
well
later.
Today,
there
is
one
probable
thing:
I
think
Rita
you're
working
on
the
CID
encryption
right,
so
I'll
probably
will
wait
on
that
as
well,
but
it's
not
a
blocker
for
me.
I
can
still
get
started
on
the
other
resource
types
and
have
like
a
draft
PR
brain
just
to
get
some
like
an
hourly
reviews
or
something
but
yeah.
A
C
A
Yeah
I
I
I
I,
do
really
want
an
answer
on
some
of
these
things
too,
because
like
for
example
like
I
like
I
added
this
stuff
here
for
dynamic
Transformers,
that
basically
I
think
would
make
it
pretty
easy
to
add
the
hot
reload
stuff
that
you're
working
on,
but
also
it
it
gives
you
a
pretty
easy
spot
to
be
like
I,
want
to
enter
to
everything
or
some
variation
of
everything,
so
yeah
I'm,
just
I'm,
hoping
that
this
gets
unlocked
soon.
So
that
way,
the
other
stuff
is
kind
of
in
place.
A
A
C
A
A
A
A
I
was
gonna.
Try
to
distill
the
response
from
the
other
leads
into
like
a
answer
to
those
issues
and
close
them
out
from
that
last
time
we
discussed
it,
but
the
the
gist
I
got
from
like
David
and
Mike
and
I
guess
to
some
degree.
Jordan
was
that
if
something
is
possible
within
KMS
V1,
then
we
should.
We
should
try
real
hard
to
make
sure
it's
still
possible
in
V2,
but
the.
A
Right,
like
you,
should
not
be
able
to
invalidate
a
database
backup,
because
your
like
KMS
is
down
or
something
and
that's
kind
of
the
architecture
they
were
going
for
so
yeah
the
gist
was
I
was
going
to
close
it
out.
I
was
like
no,
we
will
not
implement
this.
It
would
significantly
complicate
any
implementation
on
our
side
and
we
just
don't
believe
it
to
be
a
good
idea
or
here's
the
reasons
why
we
don't
think
it's
a
good
idea.
A
Let
me
think,
but
yeah
I
did
look
at
their
code
when
they
say
they
support
multiple
KMS
providers,
what
they,
what
they
mean
is
when
you
do
encryption,
they
ask
many
different
kms's
at
the
same
time
to
do
encryption
and
then
like
they
collect
all
the
responses.
So
on
reads:
any
single
KMS
can
decode,
but
on
rights,
multiples
rights
have
to
succeed
like
multiple
calls
out.
The
KMS
have
to
succeed.
A
So
like
it's
an
interesting
trade-off,
not
necessarily
the
trade-off
I
would
make,
but
it's
an
interesting
one
so
but
I
mean
so
yeah
that
that's
the
kind
of
the
gist
of
it
is
I.
Don't
think
that
we
would
complicate
our
design
like,
for
example,
the
I
I
would
see
like
the
reference
implementation,
just
kind
of
explode
in
complexity.
A
If
you
wanted
to
try
to
build
it,
so
just
yeah,
I
I,
don't
think
there's
enough
of
a
use
case
to
like
just
warrant
the
additional
complexity,
I
guess
at
the
end
of
the
day,
if
it
ends
up
being
important
in
the
future,
you
could
always
do
a
KMS
V3
to
address
it.
If
you
insist,
no
I
mean
I'm
serious
right
like
if
we,
if
we,
if
we
do
a
good
job
with
V2
building,
a
V3
should
actually
not
be
nearly
as
hard
right,
like
part
of
the
reason
we're
having
to
do
so.
A
Much
work
is
because,
basically,
all
of
this
is
a
work
that
B1
should
have
done
from
the
get-go
and
we're
just
doing
it
now
right,
but
like
things
like
metrics,
a
reference
implementation,
good,
API,
review,
good
test
coverage,
all
that
stuff
should
already
exist
and
and
but
that's
basically
the
reason
like
you
know,
good
performance
characteristics
like
that's
why
we
won
didn't
graduate
right
for
their
V2
graduates
and
has
all
those
like.
If
theory
is
just
saying,
Hey
I
want
a
more
expressive
API.
Well,
then,
all
the
other
stuff
is
still
the
same.
B
A
A
What
that
means,
because
the
V1
beta
one
only
has
a
beta
API
that
it
supports,
but
I
guess
we
don't
really
have
a
problem
going
from
alpha
to
Beta,
because
we
could
just
drop
the
alpha
and
immediately
just
go
to
Beta.
It
doesn't
have
to
be
any
migration
from
alpha
to
Beta.
It
Alpha
doesn't
have
any
support,
guarantees
so
like
we
can
just
go
to
Beta
and
it's
fine.
We
just
change
everything,
but
we
do
have
to
have
some
something
that
tells
you
what
beta
to
V1
looks
or
V2
looks
like
right.
A
Jordan
was
kind
of
like.
Maybe
it
won't
matter
because,
like
we
won't
change
any
of
the
fields
anyway
and
I
was
like
that
sounds
like
a
recipe
for
disaster,
because,
like
the
point
of
having
Alpha
and
beta
to
GA,
is
that
you
get
to
change
your
mind
at
each
one
of
the
steps,
though
I
mean
you
could
argue
that
if
the
reference
implementation
works
well-
and
you
know
all
the
things
they're
working
with,
we
might
we're
unlikely
to
discover
some
new
magical
constraint.
That
makes
us
actually
need
to
change
the
API
right.
A
I
I
think
for
the
operative
beta
proto-graduation
I
think
we
should
just
like
we'll,
we'll.
Probably
we
should
ask
like
you
know,
for
an
API
review
or
we'll
probably
get
one
anyway
from
my
Jordan
and
stuff
I
I
think
we
ourselves
should
very
carefully
look
again
at
that
point
at
all
the
fields
and
like
make
sure
they
all
make
sense,
make
sure
they
all
have
good
names
that
you
know
where
we
can
be
descriptive.
We
are
just
those
types
of
things.
B
A
A
I
think
that's
all
I
have
I
think
so,
like
you
know,
I'm
a
little
bit
blocked
on
some
reviews
from
Jordan.
Oh
I
I
didn't
talk
about
this.
One
I
could
work
on
this
one
right
now
it
which
is
like
making
it
so.
The
API
server
has
a
single
concept
of
key
ID
for
a
particular
canvas
plugin
I
could
I
could
build
that
in
now
for
Stillness
checks,
and
it
would
mostly
be
functionally
correct.
A
The
the
part
that
would
be
kind
of
off
about
it
is
it
wouldn't
be
like
formally
correct
until
my
other
PR
goes
in
kind
of
deal
like
the
gist
is
my
my
other
PR
makes
it
so
that
for
a
single
for
every
canvas
plug-in,
we
only
make
one
grpc
connection,
meaning
we
only
ever
have
one
understanding
of
the
status
of
that
plugin
right
and
the
key
ID
that's
returned
in
status
is
what
the
plugin
is
saying.
Is
this
current
right
key
effectively?
A
A
So
that's
part
of
the
reason
I
didn't
I
didn't
spend
much
time
on
it,
yet
just
because
it
didn't
feel
good
to
like
build
a
thing
that,
like
technically
passes
all
tests,
but
there's
actually
semantically
still
wrong.
Because
of
this
other
thing,
that's
out
of
whack
I.
Think
I
had
one
open
question
and
maybe
I
can
ask
you
all.
Is.
A
In
the
way,
I
wrote
my
initial
version
of
the
pr
if
in
the
process
like
so
after
I've,
read
data
off
of
disk,
so
either
using
a
cached
data,
encryption
key
or
by
fetching
a
new
one
with
the
help
of
the
KMS
after
I've,
read
that
data
and
I
parse
it
out
and
I.
Look
at
the
key,
ID
and
I
want
to
compare
it.
If,
during
that,
comparison,
I
get
an
error
in
the
sense
of
I
tried
to
call
status
and
Status
fails.
A
Or
more
specifically,
the
cached
status
response
as
a
failed
one.
I
wasn't
exactly
sure
what
to
do.
I
had
like
two
thoughts,
I
was
like
well,
maybe
I
would
just
do
a
live
check
like
I
would
do
another
status
request,
but
somehow
indicate
that
you
cannot
use
the
cache.
You
need
to
update
to
try
to
get
a
new
valid
response
from
the
plugin.
A
That
was
like
one
thought,
or
the
other
kind
of
strange
approach
was
to
just
say
that
no
it's
stale
like
like,
because
I
can't
tell
if
it's
still
I'm
just
going
to
assume
it's
stale
right.
So
where
you
would
effectively
be
saying,
is
hey
if
you
know
you're
running
a
storage
migration
and
you
get
to
this
check
and
I
can't
figure
out
how
to
answer
you
I'm
just
going
to
tell
you
to
stale.
A
That's
watching
any
of
those
resources
that's
currently
encrypted.
It's
not
just
immediately
start
getting
a.
What
like
a
wall
of
watch
events,
because
you
know
things
are
changing,
but
not
really
they're,
just
like
not
changing
kind
of
deal,
but
I
didn't
really
know
what
the
correct
answer
for
such
a
thing
was
like
the
the
part
that
concerned
me
with
any
approach
that
failed,
the
right
or
or
or
failed
to
read,
was
that.
A
Well
now
you
have
even
more
dependencies
on
the
canvas
plug-in
like
like
the
the
cash
might
of
the
data.
Encryption
key
isn't
doing
exactly
what
you
expect,
which
is
buffering
you
from
any
flaking
this
on
your
plugin,
because
now
you're
saying
that
hey,
even
though
I
have
a
cache
data,
encryption
key
I
might
still
fail
on
a
read,
because
I
can't
figure
out
what
my
current
key
ID
is.
A
That
so
that
is
a
choice.
So
the
the
way
it's
written
right
now
is
it's
just
reusing
the
same
code
that
we
use
in
the
health
checks,
which
has
a
cache
right,
the
caches
for
a
certain
amount.
So
imagine
that
you
were
trying
to
hit
the
plug-in
and
the
at
that
instance
of
doing
the
health
checks.
You
cache
the
failing
response
right
and
then,
during
that
same
time,
interval
someone
is
trying
to
do
like
a
storage,
migration
or
or
just
really
reading
and
writing
data
to
an
encrypted
resource.
A
If
you
had
a
cached
data
encryption
key,
the
read
would
just
succeed
because
you
would
just
like
normally
it
would
succeed
just
because
you
were
able
to
read
it
using
the
daily
version
key
right,
but
now
you
have
an
in
that
same
spot.
You
have
to
check
hey
I,
read
the
data
from
Storage,
whether
it
was
cash
or
not,
using
or
using
a
cache
data.
Encryption
key
or
not,
but
I
have
to
like
assert.
A
Is
that
data
considered
a
stale
read
or
a
non-salory,
because
that's
how
storage
migration
understands
to
do
the
right
or
not
like
if
it
was
an
In-Place
update
or
an
In-Place,
no
op
update,
and
so
you
have
to
always
be
able
to
answer
that
question
now,
whereas
previously
you
just
returned
false,
you
literally
always
said
No.
It's
it's
perfectly
fine
right.
B
B
Yeah
I
think
like
I,
was
getting
confused
when
you
said
cash,
but
now
I
understand,
because
whenever
we
do
a
startup
check,
we
have
we
cache
it
in
memory.
What
was
the
last
day
that
we
got
and
that's
what
we're
going
to
use
to
do
the
stale
check.
So
when
we
do
a
read
and
then
we
compare
the
key
IDs
there
if
they
don't
match
we're
like?
Oh
it's
a
statement
right.
A
The
possibility
of
causing
just
like
random
errors
too,
like
because
you
know,
when
you
get
an
area
at
this
state,
you
just
get
a
500
all
the
way
out
to
the
client
with
this
horrible,
like
I,
don't
know
what
to
do
with
this
path
and
the
client's
like
well
I
sure
the
hell
don't
know
what
to
do
with
that
path.
Api
server,
maybe
you
should
figure
it
out.
Foreign.
C
A
A
A
C
A
Right
but
the
reason
we
have
the
data
encryption
key
cash
is
to
paper
over
the
plug-in
being
down
for
some
small
window.
Okay,
so
that
that's
like
the
the
part
that
kind
of
is
bad
about
this
right.
Like
you
built
this
fancy
cache
in
memory
which
Anisha
is
not
rewriting
to
be
an
expiring
cache,
but
you
know
whatever
it's
still
a
fancy
cache
to
prevent
complete,
catastrophic
failure
for
like
tiny
transient
outages
on
the
plug-in.
C
A
Well,
no
right
because
this
check
would
come
after
the
cash
has
been
used
and
it
could
still
fail
right
so,
like
you
could
have
a
perfectly
valid
cash
data.
Encryption
key
that
is
consumed
is
used
to
decode
the
data,
but
then
because
you
can't
tell
if
the
data
is
still,
you
fail
the
request
and
the
you
and
it's
like.
A
Maybe
the
user
didn't
give
a
about
your
sales
check
right.
They
just
wanted
their
data
to
work,
I,
I
guess
this
is
only
in
the
update
path,
so
the
user
is
trying
to
update
something.
You
just
don't
know
if
they're
trying
to
update
it
as
a
no-hop,
as
in
this
historic
migration
or
they're,
just
trying
to
update
it
because
they're
trying
to
update
it.
A
A
A
The
the
other
aspect
of
like
returning
true
in
that
code
path
is
I,
so
I
I
think.
What
will
happen
then
is
you
will
definitely
get
a
right
to
STD,
which
does
would
then
hit
the
canvas
plugin
so
that
in
that
sense,
I
was
I,
think
I'd
also
reasoned
in
my
head,
like
hey.
If
the
canvas
plugin
is
actually
not
working
at
this
instance,
then
we're
gonna,
we're
gonna.
The
right
will
fail
and
that's
okay,
because
we
can't
make
the
KMS
plugging
order.
B
A
A
Yeah
you're
right
it
isn't
indeed
another
regression.
I
guess
an
alternative
to
all
the
things
I've
said
so
far
is
we
could
have
an
implementation
that
always
returns
the
last
successful
key
ID
yeah.
That's
all
so,
even
if
status
is
failing
whatever
the
last
successful
response
was,
that
did
have
a
non
failing
value.
I
could
return
that
one.
A
I
I'm
saying
that
we
we
would
have
we
would
in
the
process
of
doing
those
two
tips
build
the
mechanism
for
getting
the
last
cash
response
anyway,
but
we
would
have
to
because
that's
sort
of
what
the
API
would
entail
right
like
what
was
the
last
key
ID
that
this
API
server
saw.
That's,
basically
what
that's
the
status
of
that
resources
show.
Among
the
other
thing
that's
already
showing,
so
it
might
actually
end
up
being
that
might
end
up
being.
The
sort
of
the
simplest
thing
is
like
cache.
A
The
key
ID
separately
from
the
rest
of
the
health
check
response
as
a
different
thing,
so
that
one
only
changes
when
you
get
a
successful
one,
and
even
if
technically,
if
you've,
never
gotten
a
successful
one,
meaning
you
just
have
empty
strings
stored
in
that
variable.
That
will
always
never
compare
to
key
ID,
because
we
just
don't
let
the
KMS
plugin
send
an
empty
string
as
a
key
ID.
So
you
can
never
not
send
that
field.
A
So
I
think
that
might
end
up
being
the
simplest
thing.
It's
just
like
hey.
We
just
compared
to
the
last
value
that
we
understood
you
to
have
and
if
it's
out
of
date,
that's
fine,
because
the
whenever
we
build
the
full
automatic
storage
migration
has
to
be
based
off
of
the
last
understanding
we
had
anyway,
so
like
the
mechanism,
for
that
has
to
wait
for
convergence
anyway.
C
A
A
C
A
Well,
because
I've
done
some
of
the
refactors
and
stuff
already
that
PR
now
should
be
pretty
small.
It
shouldn't
be
the
the
one
with
the
key
ID
status
checks.
It
should
actually
be
pretty
small
I've
actually
done
most
of
the
in
the
niche
had
to
review
it.
Where
I
was
like
here's
a
diff,
that's
useless,
just
look
at
the
old
file
and
read
it
and
then
read
the
new
file
and
tell
me
if
I
still
does
the
same
thing.