►
From YouTube: ClusterAPI AWS Kickoff
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Uncle
next
hi,
my
name
is
Ashish
I
work
at
Nordstrom
in
the
platform
engineering
team,
where
we
run
a
multi-tenant
platform
for
all
of
Nordstrom
engineering
on
Google,
using
communities
using
AWS
as
our
cloud
provider.
We
use
terraform
driven
by
make
to
provision
clusters
to
provision
our
our
multi
cluster
multiplet
form.
B
I
am
here
to
participate
by
myself
kind
of
to
interact
with
the
community
and
see
where
I
can
contribute
so
I've
been
working
on
communities
for
about
a
year
and
a
half
now
worked
with
a
couple
of
projects
in
the
community
work
with
a
few
folks
from
hep
tio
on
arc.
I've
worked
on
tariffs
on
providers
like
the
Google
providers
for
terraform
yeah.
That's
my
background.
C
Okay:
okay:
what's
up
everybody,
I'm
Chris,
Nova
I'm,
one
of
the
founding
members
of
the
cluster
API
project
I
work
at
hefty
ow
I
wrote
a
book
on
this
stuff
I'm
just
here
to
kind
of
be
a
fly
on
the
wall
and
observe
and
make
sure
folks
have
what
they
need
to
to
be
productive,
so
nice
to
meet
everyone
or
see
you
again.
D
C
G
H
Hey
guys,
this
is
Josh
I
work
with
Vulcan,
helped
out
on
the
cross
cloud
project
and
just
interested
in
the
cluster
API
project
and
see
where
it
can
go
playing
around
with
working
on
a
provider
and
just
trying
to
soak
in
everything
that
I
can
pack
in
here
so
I'm
just
here
to
help
out.
If
I
can
swell.
I
J
J
So,
there's
a
bunch
of
folks
kind
of
all
doing
similar
type
of
things
in
the
community.
I
think
the
purpose
of
the
kickoff
meeting
was
to
kind
of
rally
those
efforts
towards
a
common
set
of
solutions
that
we
can
agree
upon,
because
it
makes
no
sense
for
everyone
to
maintain
their
own
independent
thing.
When
you
know
we'd
be
solving
a
common
set
of
problems,
yeah
open
source,
that's
one,
it's
really
good.
J
For
typically
in
the
past,
we
usually
find
the
best
way
to
go
about
doing
some
of
this
stuff
is
to
rally
in
a
spec,
but
right
now
that
might
be
a
little
premature,
I'm
sure
there
are
things
we
could
do
almost
immediately
to
kind
of
get
make
a
little
bit
of
progress
and
then
make
the
spec
kind
of
evolve,
as
as
we
get
enough
people
to
take
a
look
at
it.
So
our
folks
aware
that
there
are
already
exists
in
AWS
repo
there.
There
is
one
it's
very
sparse
at
this
point.
J
C
C
J
So
there
exists
a
repo
just
so
like
a
PSA
right
now
there
exists
a
repo
there.
It's
in
the
notes
right
now.
It's
also
pasted
in
the
chat
window,
which
I
did
for
folks
to
kind
of
rally
on
what
I
think
makes
a
lot
of
sense.
Right
now
is
almost
every
single
provider
has
some
common
themes
for
the
very
beginning
of
what
they
create
and
we
can
probably
step
out
a
good
portion
of
that
and
then
rally
on
a
spec
and
I
do
believe.
J
The
one
pull
request
that
is,
there,
provides
some
level
of
specification,
so
I
think
a
common
way
for
folks
to
kind
of
move
forwards
is
to
work
on
a
doc.
There
exists
a
doc
that
we
started
on
our
side.
A
Jason
worked
on
it,
but
he's
kind
of
currently
sick
kind
of
starting
to
lay
down
some
of
the
details
there
and
it's
totally
open
for
folks
to
me
see
if
I
can
share
his
document
now,
I'll
have
to
copy
it.
J
Maybe
I
can
copy
the
document
to
the
end
of
this
current
one
every
one
second
here,
and
that
anybody
can
comment
or
look
at
it.
I.
Don't
expect
to
have
the
conversation
today
on
the
details,
but
just
to
rally
on
the
notion
of
rallying
on
specs
right
and
usually
that's
a
good
conversation
piece
for
us
to
start
to
go
through
in
depth
some
of
the
details
that
we
can
agree
upon,
disagree
upon
and
find
some
common
core
behavior
that
we
we
think
we
should
drive
towards.
J
So
now
we
kind
of
have
an
overview
of
what
some
people
are
interested
in.
We
kind
of
have
some
deets
down
below
in
the
document.
One
of
the
things
I
was
kind
of
looking
and
hoping
for
from
this
larger
group.
As
we
kind
of
start
to
talk
about
this
is
to
list
out
some.
You
know
requirements
that
people
have
like
Illya
explicitly
specified.
One
is
that
for
any
provider
it
be
nice
to
be
able
to
have
both.
You
know
a
customized
version,
as
well
as
an
EPS
version.
J
K
L
J
That's
a
good
meta
topic
to
start
to
have
the
discussion
on
you
know,
and
then
we
can
start
to
refine
requirements
from
there,
because
this
I
do
think.
If
you
were
to
have
multiple
invitations
of
PKS,
it
would
kind
of
what
I'm
trying
to
avoid
is
fragmentation
too
much
fragmentation
for
a
given
cloud
provider
right
and
for
a
lot
of
the
parameters
that
you'd
specify
for
a
given
provider,
some
of
which
would
be
common
for
it?
I
guess
across
both
eks
stands.
You
know
a
custom,
ATS
implementation
and
some
would
be
orthogonal
to
right.
J
B
B
J
Entirely
have
folks
are
folks
aware
of
how
sort
of
the
internal
controller
manager
inside
of
kubernetes
operates
thanks
kind
of
sarkoff,
so
it's
totally
possible
I.
Think
one
thing
we
want
to
make
sure
too
is
that,
instead
of
the
controller
manager
for
kubernetes,
there
are
many
controllers
and
there
they
are
based
upon
independent
resources,
and
there
is
nothing
that
prevents
us
from
having
sort
of
this
Venn
diagram
of
resources
and
having
multiple
controllers
that
we
kind
of
Co
maintain
within
this
repository.
J
So
that
model
exists
in
upstream,
where
you
have
different
flavors
and
you
use
use
a
different
sort
of
incantation
that
you
pass
to
things
on
startup,
but
the
back
end
code.
Has
you
know
a
different
set
of
control,
loops,
a
rectification
for
those
independent
resources
or
objects
that
may
have
overlap.
Does.
C
B
Be
I
don't
know
if
it's
the
machine
set
controller
and
the
machine
controller,
but
but
yes,
I
Tim.
To
answer
to
your
point,
yes,
I
I
agree
that
we
can
have
multiple
controllers
monitoring
the
same
resource.
Maybe
filtering
on
some
tag
that
some
one
example:
that
kind
of
pops
up
to
mind
is
some
sort
of
a
controller
for
Secrets,
which
says:
there's
a
controller
that
is
just
sanity,
checking
the
secrets
or
making
sure
the
secrets
are
strong
enough
and
the
other
is
responsible
for
propagating
secrets
to
different
name
stencils.
B
Only
if
you
have
a
tag
say
propagate
true
with
the
propagate
controller
propagate
any
secret.
But
there
is
this
other
control
controller,
which
is
monitoring
all
secrets
right,
so
I
that
that
was
one
example.
That
kind
of
came
to
mind
as
you
were
speaking
so,
are
you
saying
that,
based
on
the
providers
was
some
control?
One
controller
logic
will
reconcile
that
and
the
other
controller
will
just
kind
of
do
perform
when
the
walk.
Yes,.
J
J
So
it's
up
to
us
or
we
could
even
fragment
and
somehow
figure
out
a
way
to
like
have
a
hierarchy
of
resources,
but
there's
nothing
that
prevents
us
from
from
splitting
out
the
configuration,
but
still
having
a
sort
of
generic
umbrella.
That
kind
of
ties
it
all
together
on
startup
right
think
think,
oh
for
lack
of
it.
This
is
a
terrible
analogy,
but
just
bear
with
me
discriminated
unions
inside
of
C
or
an
example
of
you
have
the
single
blob,
which
could
be
a
or
b
and
you
could
pass
it
on
through
and
based
upon.
L
One
I
see:
we've
talked
in
the
past
about
what
would
happen
if
there
were
two
legitimate
or
two
providers
for
the
same
cloud
and
that
we
wanted
to
support
and
how
we
might
share
a
repo
for
them.
I,
don't
think
we've
thought,
through
the
details
of
that
so
positive,
for
sharing
the
GAE
and
native
us
repose
of
the
enforce
us
sort
of
thinking
about
how
multiple
controllers
feature
the
same.
You
go
now
and
then
the
negative
is
that
we'd
have
to
start
thinking
about
it.
Now.
J
Yeah
yeah,
we
can
always
choose
to
do
a
and
then
stub
for
B.
You
know
as
a
as
a
group.
It
depends
upon
who's
going
to
put
in
the
work
right.
Ultimately,
open-source
is
all
about.
You
know.
People
stepping
up
to
the
plate
and
saying
like
I'm,
gonna
I
would
love
to
help
working
on
this
and
then
the
the
collective
kind
of
trying
to
help
Shepherd
it
in
in
that
is
amenable
to
all
parties
involved
right.
J
J
So
my
kind
of
goal
here
in
this
first
part
for
this
first
kind
of
kickoff
meeting
is
to
kind
of
gather,
really
big
requirements
right
and
that's
sort
of
flipping
the
eks
to
being
able
to
support
those
two
different
flavors
which
I
like
I,
don't
know
we
should
we
should
name
the
flavors,
be
more
fun
and
then
the
ability
to
support
those
two
different
flavors
is
like
a
good
example
of
a
requirement
right
and
I.
Think
dude.
The
folks
have
other
examples
of
like
larger
requirements
that
they
can
think
of.
J
K
A
K
So
we
try
and
talk
into
phi
if
there
is
any
other
play
where
you
can
think
of.
That's
probably
discussion
like
I
mean
I,
wonder
if
there
could
be
some
like
you
know
some
said
now:
the
flavors
were
people
actually
run
control
plane
as
pods
in
the
managing
in
a
management,
cluster
and
nose
around
separately,
or
you
know,
versus
control,
plane,
running
completely
external
place
like
I,
think,
maybe
that's
that's
another
kind
of
flavor.
We
can
think
about
yeah.
A
K
E
E
K
Yeah,
that
could
be
a
thing,
but
I
don't
think
it's
like
a
flavor
right,
that's
more
like
a
parameter,
but
the
kind
of
very
specific
flavor
type
thing
that
I
had
in
mind
was
one
where
you
would
manage
nodes
yourself,
somehow
versus
let
an
auto
scaling,
group
and
ponemos.
So
I
think
that
that
could
be
a
separate.
B
K
Well,
that's
yeah,
that's
that's!
Not
a
scalar
part.
I
think
that's
a
separate
part,
but
the
actual
and
like
it's.
It's
not
exactly
that
level
right!
It's
like
how
do
we
create
you
know.
Do
we
for
each
note
that
we
want
to
create,
we
call
the
ASG
API,
or
do
we
call
the
other
one
and
the
other
one
involve
us
doing
a
lot
more
work
there
right?
Yes,.
M
B
K
Okay,
but
I
don't
know
if
it's
if
it's
a
flavor
of
versus
the
parameter
right
but
I
mean
also
yeah.
Does
the
actually
does
well
with
everything
he
asks
versus
eks
versus
a
fully
managed
like
syrup,
sorry,
fully
user
own
cluster?
Let's
say
that
it's
a
it's
a
yeah
there's,
probably
significant
difference
there,
although
we
could
argue
that
some
node
management
could
be
obstructed
away
in
a
very
similar
fashion.
J
C
Yeah
totally
so
I
sleep
with
with
Ilias
comment
on
you
know,
is
next
year
and
ec2
is
that
that
logical
boundary
at
the
flavor
level
or
at
the
parameter
level
I,
definitely
think
it's
at
the
flavor
level.
The
nitty
gritty
of
getting
into
actually
creating
the
user
data
and
deploying
a
machine
is
pretty
complex.
Where
do
you
go
from
the
launch?
Configuration
ASG
approached
versus
the
ec2
approach
and
there's
just
a
lot
of
subtleties
there?
How
those
resources
relate
together,
you're
going
to
get
you
to
get
data
from
other?
It's
of
the
deployments
well,.
C
C
Maybe
there
is
some
parameterization
around
destroyed
it
and
creative
as
well
that
we
need
to
figure
so
as
we
started
looking
at
this
I
think
it's
going
to
make
sense
to
figure
out
what
these
flavors
are,
and
maybe
we
have
one
that's
like
focus
on
closest
point
on
compliance
and
we
have
another
one
that
sort
of
like
the
the
simple
implementation.
That's
just
good
on
ec2,
and
then
we
have
like
one
that's
a
little
more
like
resilient.
C
J
Think
what
might
make
sense
from
this
point
like
once
we
start
to
get
capturing
more
and
more
requirements,
is
eventually
pick
like
a
single
MVP
right
that
we
can
rally
on
yeah
and
then
expand
on
the
MVP
over
time
to
encompass
other
use
cases
in
scenarios,
because
one
thing
that's
pretty
common
in
these
types
of
problems-
is
that
you
can
get
analysis,
paralysis
and
there's
a
big
group
of
people
here,
and
we
don't
want
that
to
happen.
We
much
rather
have
a
focused
deliverable
effort
and
we
can.
C
What
do
we
think
about
for
that
MVP
as
we
go
through
the
process
of
defining
what
our
first
flavor
is
gonna
look
like?
Would
it
be
meaningful
that
sort
of
template
eyes
that
and
say
for
flavor?
We
need
to
define
these,
you
know
and
number
of
factors
and
provide
owners
to
these
flavors
that
can
sort
of
like
Shepherd
them
through
and
for
the
mess
from
reading
that
analysis,
paralysis,
yeah,.
J
J
That
basically
says
here
here:
the
the
known
knowns
based
upon
trial
and
error
and
experience
that
we've
had
here
is
what
we
see
today,
and
this
is
the
path
that
we're
gonna
try
to
go
down
seems
like
a
logical
approach
and
then-
and
then
after
that
you
know
we
can.
We
can
iterate,
but
I
know
different
parties
are
gonna,
have
different
vested
interests.
N
So
I
joined
the
call
and
I
thought
introduced
because
I
couldn't
talk,
but
anyway
it's
always
a.
Secondly,
the
idea
of
actually
collecting,
some
so
to
say
historical
data
or
other
tools,
they've
been
around
there
I
mean
we
can
ask,
maybe
with
a
male
to
stick
it
up
us
or
directly
to
stick
it
up
us
which
I
think
in
the
meeting
is
this
Friday
I,
don't
know
which
time
any
would
be
II
would
be
a
good
idea.
N
N
You
kill
an
old
stuff
like
that
that,
of
course,
we
don't
have
to
focus
on
right
now,
but
I
think
it
will
be
nice
to
focus
on
an
MVP
and
start
collecting
all
those
thoughts
together
such
that
we
can,
you
know,
get
the
best
out
of
it,
because
I'm
pretty
sure
that
there
are
a
lot
of
learnings
with
a
lot
of
tools
like
cop
cgw.
Sorry
cops.
Keep
it
up
your
ass
Cuba
corn,
happy
Oh,
quick
starter,
which
also
did
a
great
job,
a
lot
of
things
and
I.
J
C
So
like
here
would
be
a
great
example
for
thinking
about
a
flavor
would
be
eks
versus
a
raw
Amazon
implementation
and
a
parameter
would
be
spot
pricing
that
says,
regardless
of
if
you're,
using
eks
or
if
you're,
using
Amazon
ec2.
We
want
to
try
to
go
the
affordable
route
and
you
spot
instances
where
you
can
so
anyway.
Some
other
requirements,
I
had
was
I
just
wanted
folks
to
start
thinking
about
guarantees
as
we
go
through.
This
process
guarantees
around
our
infrastructure,
particularly
around
things
like
idempotency,
and
what
we
do
when
things
fail.
C
We
all
know
the
infrastructure
is
going
to
fail.
Nodes
are
not
going
to
come
up
to
go
wrong,
we're
going
to
be
blindsided
and,
as
we
start
to
build
out
the
software
being
able
to
mentally
say.
Oh
I
know
that
the
dysfunction
color
this
API
transaction
guarantees
it's
either
going
to
do
exactly
what
I
wanted
to
do,
or
it's
going
to
fail
and
then
do
its
work.
It's
going
to
be
handy
for
us
as
engineers
as
we
start
crafting
the
software,
so
I
don't
know
if
that's
probably
gonna
be
a
lifetime.
C
I
J
J
It
can
be
very
interesting
of
how
you
want
to
approach
it.
There
can
be
different
ways.
You
can
do
it.
Some
people
want
a
mutable
infrastructure
where,
like
you,
never
mutate
the
nodes
at
all
ever
and
some
other
people
might
want
to
be
able
to
mutate
the
existing
environment.
So
decisions
like
that
we
should
try
to
make
in
the
beginning,
for
an
MVP
at
least,
because
that'll
have
pretty
lasting
consequences.
C
What
general
like
generalized
behavior,
do
we
want
the
AWS
until
me,
implementations
is
sort
of
like
favor,
and
then
you
know
which
particular
flavors
is
our
first
one
that
we're
gonna
work
on,
but
I
think
the
upgrade
story
is
is
going
to
be
huge.
We
really
can't
afford
to
get
that
wrong,
because
you
know
in
my
mind,
that's
really
one
of
the
big
wins
that
we're
getting
by
lobbying
together
as
community
is
we
were
friendly,
going
to
get
a
good
upgrade
story
so
with
the
proposals?
C
How
how
do
you
think
we
should
go
about
starting
to
draft
either?
Look
at
these
well.
J
I
think,
like
step
one
getting
some
a
history
lesson
makes
a
ton
of
sense
so
like
if
we
can
reach
out.
If
someone
like
you
wants
to
reach
out
to
Justin
and
kind
of
draft
down
like
these
are.
These
are
the
things
we
learned,
and
these
are
the
things
we
want
to
avoid.
I,
think
that
makes
a
ton
of
sense
and
then
maybe
another
independent
group
can
be
working
down
like
here's.
J
How
we
kind
of
see
breaking
down
the
different
flavors
and
potential
parameters
across
a
larger
group
I
would
almost
the
way
we
approach
it
in
steering
is
we
have
like.
We
have
little
mini
groups
that
kind
of
federated
out
and
kind
of
come
back
to
this
larger
group
in
the
next
time
or
the
next
meeting.
So
that
way
we
can.
We
can
still
make
progress
on
these
independent
things
over
time.
Does
that
seem
like
a
reasonable
approach.
J
J
Can
help
solicit
and
get
folks
to
rally
on
putting
down
things
on
paper
for
generalized
requirements
and
they're
like
a
kept
style,
if
folks
want
to
join
in
just
put
your
name
next
to
it
in
the
back
and
they'll
try
and
I'll
try
and
get
another
doc
going.
You
know,
I'll
talk
with
Jason
and
Chuck
I'm
gonna,
basically
be
facilitating
more
so
than
actually
they're
doing.
O
J
F
J
Think,
like
enumerate
the
different
possible
incantations
in
in
sort
of
like
specification
forms
or
maybe
even
like
enumerate
the
different
options
that
we
can
think
of.
It's
probably
like
the
first
part
of
a
spec
right,
so
I
I
think
that's
almost
even
better
than
trying
to
come
to
the
next
meeting
with
a
spec
would
be
come
to
a
listing.
A
J
Iii
think
before
we
start
merging
some
of
those
PRS,
we
should
just
rally
on
what
we
want
to
do.
First,
because
I
don't
want
to
give
any
precedent
for
things
until
we've
kind
of
agreed
and
then
once
we
agreed
we're
just
going
to
move
fast,
so
I
think
there's.
There
are
some
pieces
that,
outside
of
the
scope
of
the
individual,
spec
and
requirements
analysis,
there
are
logistics
that
need
to
be
handled.
J
J
B
J
Think
we
can
even
do
like
a
whole
section
on
lessons
learned
like
if
we
just
came
armed
to
the
next
meeting
on
like
here
are
the
incantations
that
we
had
here
the
good
aspects
here:
the
bad
aspects
and
then
kind
of
distill
those
down
from
different
people
or
different
providers.
I
think
that
alone
is
a
very
fruitful
effort
and
would
feed
into
the
next
steps.
I
think
in
the
enumeration
of
some
of
the
different
flavors
of
parameters
can
can
occur
independently,
but
I
think
the
I
think
by
next
meeting.
C
K
And
I
also
wonder
I
guess
there
are
kind
of
like
very
bold
questions
that
that
one
could
ask
why
this
isn't
a
you
know
a
feature
in
cops
that
we
are
working
on.
Why
are
we
working
on
a
new
project?
Twice,
it's
not
a
feature
in
unicorn
or
some
other
project
right.
Why
is
it
like
a
whole
separate
project
and
that's
sort
of
related
to
that?
Isn't
it.
C
C
J
N
J
Is
I
guess
that's
probably
another
topic
you'd
be
like
what
time,
because
it
seems
like
there's
a
lot
of
interested
parties
here.
Twenty-Eight
people,
that's
pretty
big.
What
should
we
send
out?
A
doodle
I
tried
to
coordinate
a
time
that
works
for
folks
to
figure
out.
Should
we
have
regular
reoccurring,
meetings
and
figure
at
a
time
a
frequency
and.
C
Time,
yeah,
yes,
I
would
I
would
suggest
once
a
week
starting
and
then
also
on
that
email
thinking,
an
email,
distinct
close
to
lifecycle,
an
email.
This
evaded
us
with
the
same
doodle
in
both
and
then
it
might
even
make
sense
to
just
start
a
whole
new
dock
where
we
can
start
to
highlight
lessons
learned
in
requirements.
So
folks
can
start
pre
flushing
that
out
before
this
next
meeting,
because
I
have
a
feeling,
once
we
get
together,
be
less
involved
as
well.
28
people
is
going
to
be
a
low
number
for
us.
J
So
it
sucks,
it
sounds
to
me
like
who
wants
to
take
point
on
the
administrivia
with
doodles
and
docks
all
right,
appreciate
it
Chris
and
do
folks
who
are
interested
in
sort
of
capturing
history
want
to
coordinate
with
Chris
and
folks
who
want
it
captured
or
just
enumerate
potential
options.
I
can
help
facilitate,
but
I'm,
probably
not
gonna,
be
on
point.
I'm
gonna,
probably
throw
Jason
under
the
bus
and
maybe
put
him
on
point
or
some
of
this
stuff
he's
not
here
so
I
can
do
it.
C
J
That
I'm
gonna
I'm
gonna
enumerate
the
state
space
or
at
least
rally
the
folks
to
enumerate
the
state
space
to
be
a
facilitator,
and
then,
if
you
can
help
facilitate
the
history
and
oh
my
gosh,
we
should
never
do
this
again
or
we
should
do
these
things.
Okay,
I
mean
what
do
you
mean
by
state
space,
listing
of
options
of
different
different
ways,
people
good
at
least
to
start
to
enumerate
the
ways
that
we
could
construct,
flavors
or
sort
of
even
help
to
sort
of
like
lay
down
texts.
Out
of
me,
if
that's
possible,
okay,.
C
C
J
B
J
B
C
C
J
C
It's
a
big
one
for
me
and
then
this
might
be
a
requirement.
This
might
be
an
implementation
detail,
but
at
some
point
it
might
make
sense
for
us
to
start
considering
how
we're
going
to
manage
things
like
authorization
and
I
am
profiling
and
how
we're
going
to
handle
the
security
element.
This
whole
thing
I
feel
like
that's.
Whenever
we're
studying
new
projects,
especially
kubernetes,
is
sometimes
easy
to
overlook
security
out
of
the
gates,
but
if
we
can
get
that
income
of
the
gate
that
would
be
rad.
B
C
Across
the
stack
security,
everything
from
how
do
we
authenticate
to
the
kubernetes
api,
all
the
way
up
to
which
I
am
user?
Are
we
using
all
the
way
to
argue
storing
on
AWS,
API
credentials
and
secrets
or
not
or
where
those
going
so
anywhere
across
the
whole
process?
Just
wanted
to
have
a
security
minded
posture,
as
we
start
bringing
shape
to
things.
O
There
has
been
some
discussion
happening
in
the
guise
of
yes
around.
What
we're
going
today.
Canonically
for
I
am
identity
for
pops
that
he
proposals,
ones
from
you
switch
which
has
taken
the
history
of
the
previous
implementations,
including
cube.
So
I
am,
and
a
SS
was
a
longer-term
proposal
which
requires,
as
the
guy
changes
nothing's
been
decided.
Yet,
oh.
B
Okay
I
know
Azure.
It
has
like
a
pod
identity,
implementation
I,
just
looked
at
it,
I'd
not
spend
too
much
time
on
it,
but
I'm
just
aware
that
there
is
something
like
that:
I
don't
know
if
you
want
to
implement
some
something
similar
here
or
if
that
effort
is
like
how
to
scope
of
what
we
are
trying
to
do.
F
Netflix
did
something
interesting
with
Nick
per
pod,
so
that
I
as
level
security
groups
could
be
applied
to
pods,
which
I
think
is
a
pretty
interesting
thing.
I
know
it's
a
it's
a
challenge
to
have
to
deal
with
the
overlay
network,
security
policies
and
the
and
the
underlay,
and
you
know
what
manages
poking
all
the
right
holes
at
the
right
times
dynamically
through
both
layers.
So
I
think
that
was
kind
of
interesting
thing.
Maybe
something
to
think
about
here
as
well.
K
Well,
it's
interesting
that
we
we
get
to
discuss
these
things
already
in
the
first
meeting,
but
now
I
was
kind
of
wondering
that
you
know
what
is
really
yeah.
Maybe
we
need
to
mostly
define
what
are
we
going
to
address
and
not
going
to
address
and
I
thought?
Why
understanding
so
far
what
this
was
mostly
about:
defining
the
API
and
and
an
implementation
that
proves
that
API
works,
and
then
we
could
move
on
and
see
how
that
API
extends
beyond
such
a
basic
implementation
and
it's
not
for
30
parts
of
it.
K
O
Think
we
need
to
represent
these
options,
at
least
in
it
in
some
sort
model
and
whether
that
cut
might
be
yes,
just
eks
them.
These
are
things
we're
not
going
to
take
care
of
right
now
that
that
might
be
fine,
but
we
should
represent
I
think
we
should
have
some
representation
of
the
maximal
set
of
requirements
and
concerns.
J
Yeah
I
totally
agree
with
that
approach,
because
that's
kind.
What
I'm
trying
to
do
in
rallying
around
the
history
plus
and
numerating
the
state
space
of
requirements,
not
necessarily
picking
a
path,
because
different
parties
in
this
group,
as
well
as
different
parties
outside
in
the
broader
community,
will
want
different
things
and
be
able
to
commit
to
certain
things.
J
What
I
was
saying
is
I
agree
with
Miss,
the
name
sorry
I
did
my
dear.
What
would
nadir
said
is
that,
because
there
is
a
large
group
of
folks
here
with
you
know,
working
for
different
companies,
they
will
have
different
interests
right
and
they
may
not.
I
don't
want
to
be
prescriptive.
Never
is
a
sig
leader.
C
J
I
think
right,
a
minute,
so
I
think
the
action
items
just
reiterate
we
have
Chris
is
gonna
work
on
doodles
and
docks,
which
we
should
totally
make
some
type
of
pun
out
of
I'll,
try
to
enumerate
some
taxonomy
and
how
to
sort
of
frame
and
talk
about
this
stuff
and
get
all
the
pieces
in
place
and
I'm
I'm
not
going
to
actually
do
probably
all
of
the
work.
I'm
gonna
help
to
facilitate
it.
J
A
Fine,
so
the
the
result
of
these
these
two
efforts
that
were
kicking
off
today
are
they
going
to
be
in
documents
that
are
linked,
I.
J
E
C
Way
I
was
thinking
about
my
new
building.
Doc's
through
email
was
to
to
give
a
summary
and
what
we
went
over
today
linked
back
to
this
email
offer
new
Doc's
that
are
shared
with
the
corresponding
states
as
needed
and
offer
a
doodle
with
a
proposal
of
a
weekly
meeting
for
people
to
fill
out.
So
we
can
try
to
get
something
on
the
calendar.