►
From YouTube: Service APIs Meeting (APAC Friendly Time) 20200312
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).
A
All
right
we
are
recording
this
is
the
service
api's
meeting
for
Thursday
March
12
and
to
get
started
we're
going
to
talk
about
security
models,
so
this
is
something
like
that.
Nick
and
I
had
volunteered
to
take
on
and
look
further
into
last
week,
and
this
is
very
much
a
rough
draft
a
starting
point.
This
is
not
a
final
point
and
I.
A
This
is
really
just
a
rough
proposal
right
now
of
where
we
could
go,
but
basically
we
we
already
have
this
concept
of
roles
as
part
of
service
api's.
We
have
the
idea
that
okay,
there's
an
infrastructure
provider
that
provides
infrastructure
for
your
organization,
maybe
a
cloud
provider,
maybe
a
pass
provider
whatever
it
happens
to
be.
A
You
have
a
cluster
operator
who
would
fill
the
ops
role
and
you
have
an
application
developer,
and
we
want
to
make
sure
that
we
have
thought
of
everything
that
will
make
sure
that
we
can
at
least
provide
this
level
of
granularity
when
we're
talking
about
authorization
for
service
api's
and
beyond
that
we
have
a
few
resources.
This
does
not
include
this.
A
Could
all
change,
depending
on
additional
resources
we
get,
but
I
think
the
general
principles
that
we're
talking
about,
even
if
it's
not
specifically
gateway,
class
class
gateway
and
routes,
can
apply
in
a
lot
of
different
cases
here,
but
in
general
we
have
these
three
primary
API
resources.
Now
we
also
identified
two
places
that
are
very
common
requests
that
are
also
security.
A
Related
one
is
the
ability
to
configure
TLS
on
routes,
there's
potential
for
configuring
more
than
just
TLS
on
routes,
but
for
now
just
configuring
TLS
on
routes
and
then
allowing
gateways
to
target
routes
in
multiple
namespaces,
so
the
security
model
we
identified
and
to
understand
this
process.
We
just
wrote
out
some
very
brief
initial
thoughts
on
what
we
could
do
and
what
the
what
the
scope
of
things
were
and
then
from
there
we
actually
realized.
A
We
need
some
help
with
this,
so
we
had
a
quick
call
with
Bowie
Mik
myself
and
Jordan
Liggett,
and
he
provided
some
Jordan,
provided
some
great
insight
on
what
we
should
be
doing
here.
What
makes
sense
and
what
doesn't,
and
so,
of
course
our
back
is
how
you
do
authorization
in
kubernetes
right.
So
that's
a
reasonable
starting
point,
and
so
at
a
minimum
you
can
fill
the
basics
of
these
roles.
We
it
we
identified
an
infrastructure
provider,
you
can
read
and
write
gateway
classes
and
then
there's
some
very
basic
are
back.
A
That
would
be
a
role
for
this
permission,
and
then
you
have
a
cluster
operator
and
in
this
in
this
use
case,
they
want
to
read
gateway
classes.
They
want
to
read
and
write
routes
and
gateways,
and
again
our
back
makes
that
possible
so
fairly
straightforward.
So
far,
then
you
have
an
application
developer
and
they
can
regain
weight,
classes,
read
gateways
and
read
and
write
routes,
and
again
this
is
all
possible
with
our
back.
A
This
is
something
we're
probably
all
fairly
familiar
with,
but
this
is
just
an
example
of
what
a
cluster
role
or
role
would
look
like
that
accomplishes
this
now,
where
it
gets
a
little
bit
more
complicated,
is
namespace
restrictions
and
generally
B's
other
special
use
cases,
because
not
everyone
is
going
to
want
to
have
gateways
that
can
target
routes
in
any
namespace
as
an
example.
That
may
not
even
be
a
reasonable
default,
but
the
proposal
as
it
exists
right
now,
is
to
have
some
attribute.
A
A
So
we
may
want
to
rethink
that,
but
right
now,
empty
selector
indicates
anything
which
is
I,
think
the
standard
in
kubernetes,
but
we
may
want
to
think
otherwise
there
and
then,
as
another
potential
idea
here,
TLS
config
on
routes
would
be
just
some
kind
of
boolean
field.
That
indicates
if
routes
for
this
kind
of
gateway
class
can
include
TLS
configuration
and
again
the
default
value
of
this
field
would
be
false.
A
The
big
problem
here
is:
there's
no
way
to
do
any
kind
of
authorization
with
our
back
for
these
kind
of
more
specific
things.
So
the
proposal
is
that
these
restrictions
would
be
enforced
by
the
controller
implementing
the
gateway
class.
So
this
puts
a
lot
of
work
on
the
controller
itself.
The
controller
would
be
required
to
populate
status
fields
for
gateways
and
resources
to
indicate
if
they
are
compatible
with
the
corresponding
gateway
class
and,
of
course,
not
implement
invalid
configuration,
because
there's
no
way
that
we
could
prevent
invalid
configuration
from
getting
in.
A
We
just
have
to
have
a
status
indicating
this
is
invalid
and
then
just
rely
on
the
controller's
not
to
implement
that.
So
if
a
route
in
the
Gateway
is
referenced
in
an
invalid
namespace
for
the
Gateway
class,
it
should
be
ignored
or
if
a
route
has
TLS
configuration
and
the
Gateway
class
doesn't
allow
it,
it
should
be
ignored
and
then
respond
to
changes
in
gateway
class
configuration
that
may
change
which
gateways
or
routes
are
valid.
A
So
that's
that's
a
high-level
of
a
very
rough
proposal
for
security
model
and
authorization
very
interested
in
feedback
on
that
I
made
it
a
Google
Doc,
because
I
think
there's
going.
This
would
be
a
massive
PR
and
I
didn't
think
it
could
handle
all
the
conversation
that
could
surround
this.
So
for
now
it's
just
a
Google
Doc
feel
free
to
comment.
I
add
whatever
makes
sense
and
I
also
added
a
little
note
below
about
some
alternative
approaches.
We
considered
one
being
adding
new
API
resources.
A
This
is
a
really
rough
idea,
but
would
allow
us
to
model
things
better
with
our
back.
There
were
sufficient
downsides
and
after
our
conversation
with
Jordan,
he
decided
this
was
not
the
best
forward
and
then
a
validating
webhook,
but
that
comes
with
its
own
limitations
when
you're
doing
any
kind
of
cross,
valid
cross,
resource
validation
and
so
I
covered
that
there
as
well
but
I,
think.
C
A
C
B
Yeah
yeah,
so
I
think
an
important
part.
An
important
part
to
mention
here
that
the
conformance
testing
that
we're
talking
about
is
is
not
just
a
general.
Yes,
this
is
component.
It
would
be
conforming
to
a
specific
profile
which
again
is
a
move.
It's
a
direction
in
which
the
general
performance,
arts,
they're
seekers,
work,
is
moving
towards
further
communities
anyway,
and
so
yeah
like
the
idea
here,
will
be
that
you'd
be
conforming
to
a
profile
that
includes
you,
know,
TLS,
conflict
on
routes
or
something
like
that,
and
so
they're.
B
The
the
real
I
think
one
of
the
big,
the
big
affects
this
decision
sort
of
has
some
upwards
flowing
effects.
The
thing
that
it
solidifies
in
my
mind
is
that
it
does
mean
that
the
behavior
of
the
Gateway
is
dependent
on
the
gateway
class
that
it
is
associated
with.
You
know
that
they
gate
with
the
Gateway
in
the
Gateway
class
together
determine
the
behavior
of
the
Gateway
I
think
we
are.
B
We
should
be
able
to
ensure
that
most
of
the
Gateway
behavior
is
the
same,
but
if,
but
it
doesn't
mean
that,
in
order
to
understand
how
a
particular
gamer
will
work,
you
need
to
look
at
the
gateway
class
at
the
specular
gateway
class
and
the
status
of
the
gateway
class.
To
ensure
that
you
understand
what
features
the
gateway
class
has
available.
I
think
that's
I
think
that's
actually
a
big
improvement
on
where
we're
at
now,
because
we're
right
now
with
ingress
you,
you
have
no
way
of
knowing
what
features
your
controller
implements
or
not.
A
B
And
I
think
the
other
thing
I
wanted
to
call
out
here
was
that
that
it's
kind
of
like
for
some
things,
you
know
we
had.
We
anticipated
that
for
some
things,
they'll
be
controller,
specific
configuration
that
you
pass.
That
would
be
passed
in
the
there's
like
an
extension
field
where
you
can
supply
it
or
a
config
map
or
or
a
specific
type
for
your
controller,
and
so
you
know,
then
it's
up
to
the
controller,
how
they
do
that.
B
But
the
idea
of
you
here
is
to
promote
the
fields
that
are
required
for
conformance
to
to
spec
fields
on
the
gateway
class,
so
that
then
you
know,
then
there's
no
sort
of
optionality
about
them.
You
either
do
them
or
you
don't,
and
everyone
needs
to,
and
everyone
can
agree
for
conformance.
You
know
it
for
you
for
a
reverse
proxy.
You
must
do.
You
must
allow
you
telescoping
all
that
so
I.
Don't
think
that
that
would
be
the
thing,
but
you
know
it
for
a
particular
performance
profile.
B
A
What
what
about
it
just
is
an.
A
C
A
B
A
A
A
C
B
So
the
conformance
there
and
decide
defines
the
behavior
that
a
specific
controller
must
implement
to
be
conform
it
to
that
profile.
Yeah
yeah,
so
you
might
say,
like
a
reverse
proxy
you're
averse,
proxy
gateway
controller,
must
must
have
master
support.
Conform
must
conform
to
this
set
of
things.
When
these
things
happen,
when
you
have
these
things
set
on
the
gateway
class,
this
is
this
is
how
the
controller
must
behave.
B
It
just
gives
us
the
opportunity
to
do
that
and
yeah
I
would
hope
that
we
should
be
able
to
keep
the
number
of
gateway
class
spec
fields
reasonably
low,
because
the
more
we
have
there
the
more
of
a
sort
of
dimensionality
problem
in
conformance
we
have.
But
but
you
know
it
may
make
sense
to
have
some
things
that
yeah.
C
A
D
A
D
D
B
B
C
B
A
E
B
Yeah,
so
that's
the
idea
and
again
this
this
was
a
this
was
an
example.
I,
don't
think
it's
you
know.
Yes,
it's
fine
it
just
it.
The
idea
here
is
just
that
to
indicate
the
sort
of
the
class
of
thing
that
we
might
want
to
do
by
specifying
something
on
our
class
like
that
is
exactly
the
sort
of
option
flipy
behavior
that
we're
talking
about.
B
C
C
E
D
Is
there
reference
with
these
two
kind
of
documents?
Is
there
references
to
which
user
stories
it
addresses
not.
D
E
F
E
E
Like
oh
well,
I
did
before
we
got
on
yesterday's
colleges.
Saying
hey
I'd
like
to
talk
about
this.
So
I'm.
Sorry
did
you
say
mailing
list
yeah,
no
I
didn't
put
it
on
the
mailing
list.
Oh
let
me
take
that
as
an
action
item
I'm
actually
off
today
and
tomorrow,
but
I
did
want
to
jump
on
this
call
just
to
at
least
try
to
discuss
this
topic
or
answer
any
questions
more,
but
I'll
definitely
add
throw
that
on
the
mailing
list.
E
C
B
If
oh,
yes,
I
when
you're
talking
about
on
binding
collisions,
you're
talking
about
sort
of
imply
that
there
would
be
like
a
first
first
rider,
wins
semantics.
That's
the
thing
that
I
have
learned
to
my
great
pain
in
doing
contour
stuff.
Is
that
yeah?
It's
really
difficult
to
do
that
in
communities
at
a
machine
at
Machine
timescales,
because
because
it's
a
set
of
things,
not
a
list,
so
there's
no
watering,
so
it's
very
to
figure
out
which
one
actually
was
first.
So
that
would
be
something
I
know.
B
C
D
D
B
Yeah
so
first
first
runner
wins
semantics
inside
kubernetes
imply
that
you
have
to
write
something
back
to
the
object
to
say
it
was
the
first
like
it's
like
yo
attaining
a
distributed
lock
over
that
portion
of
which
one
relation.
Unfortunately,
so
the
thing
that
yeah,
the
thing
that
I
would
recommend
is
just
we
need
to
be
careful
about
that
I
contour.
The
way
we
currently
do
it,
which
is
the
wrong
way,
is
that
if
there
is
a
config
anywhere
in
the
tree,
the
whole
thing
is
invalid.
That's
really
bad!
B
It
sucks
it
sucks
with
us
sort
of
the
more
social
service
use
cases
where,
if
user
a
create
something
and
then
use
a
be
create
something
that
happens
to
match,
then
they're
both
good,
but
there's
not
really
much.
We
can
do
aside
from
coordinating
distributed,
locking
so
that
that
was
sort
of
that
I
wanted
to
sort
of
surface
that
as
a
possible
problem
on
that.
It's
important
to
keep
an
eye
on,
because
your.
E
Point
is
like
you,
get
almost
yeah
good
current
model
and
you
get
almost
denial
of
service
yourself
right,
so
you've
got
a
gateway.
Virtual
host.
Everything
is
working,
just
fine,
you
go
to
add
another
virtual
host
and
oh
gosh
I
got
a
conflicting
host
name
and
what
you're
saying
is
basically
treat
that
entire
config
as
well.
B
Yeah,
so
that's
what
that's,
what
HTTP
proxy
and
contour
currently
does
and
that
that
has
exactly
that
problem
that
that
it's
really
easy
for
people
to
accidentally
in
all
of
those
like
a
large
blast
radius,
and
so
the
important
part
about
reducing
the
blast
radius
here
is
to
try
and
keep
that
make
this.
The
specific
part
that
that
that
is
is
in
conflict
to
be
the
part.
That's
invalid
and
I
will
light
up
through
status
somehow
online,
but
but
it
is
yeah
it's
a
least.
B
G
And
it's
important
to
have
that
some
determinism
in
that
right,
so
that
users
can
or
the
operators
right
at
least
the
cluster
operator,
can
figure
out
okay,
what
takes
priority
and
instruct
their
users
or
if
somebody
something
does
go
wrong,
they
can
figure
out.
Okay,
it
went
wrong
because
of
this,
this
resource
was
created
because
otherwise,
looking
it's
like
in
large
clusters
becomes
super
annoying.
It.
D
I
agree
with
Harry
the
the
process,
for
this
needs
to
be
specs
and
conformance
and
needs
to
be
part
of
conformance,
because
when
you
get
these
conflicts,
you
know
they
can
have
serious
consequences
like
oh,
there
was
a
conflict,
and
now
we
have
a
security
issue
in
our
deployment
right.
So
we
need
to
specify
how
controllers
kind
of
deal
with
those
so
that
the
product
behavior
is
predictable.
Yeah.
B
And
so
that
the
last
point
that
I
wanted
to
make
there
is
that
there
are
use
cases.
People
want
some
people
want
use
cases
where
you
and
for
some
types
of
config
to
be
merged
rather
than
the
vehicle.
That's
like
the
current
ingress
behavior
people,
like
some
people,
actually
want
that.
Whether
or
not
we
want
to
support
that.
As
part
of
this
is
a
decision
we
need
to
make,
but
we
need
to
be
aware
that
people
actually
do
some
people
actually
do
want
that
behavior.
So.
E
B
B
And
that
is,
that
is
a
that
is
not
SPECT
in
the
ingress
spec.
However,
it
is
how
some
stuff,
a
lot
of
ingress
controllers,
have
ended
up
implementing,
so
it's
kind
of
the
unexpected
behavior,
whether
or
not
it's
the
correct
expect
but
hey
yeah.
This
is
that
this
is
a
case
of
well.
This
is
what
this
is,
how
it
ends
up
being
right,
like
so,
and
some
people
in
typical
fashion.
Some
people
now
rely
on
that
workflow.
Oh
really,.
G
And
finalize
that,
so
all
traffic
goes
to
either
of
the
one
services
and,
most
of
the
time
we
advise
users
to
use
different
paths
right.
So,
in
addition
to
hosts
so
that's
another
comment
that
I
had
with
the
current
virtual
host
thing
is
like
you
cannot,
you
do
want
to
use
users
do
want
to
split
out
based
on
just
path
based
routing,
especially
for
you
know.
Different
teams
wants
to
want
to
control
different
paths,
so
a
subdomain
or
a
virtual
host
I
think.
C
That's
something
that
we
may
be
able
to
address
with
the
recursive
resource
chaining,
which
I
think
it
doesn't
appear
here.
So
you
were
the
inclusion
for
the
contouring
folks.
One
aspect
of
the
API
I
thought
that
was
very
interesting.
Damian
was
this
sort
of
promotion
of
the
TLS
to
almost
like
an
entire
workflow
and
of
itself?
B
I
guess
that
was
one
of
the
questions
that
I
wrote
down
as
well,
that
you,
given
that
right
now
communities
kind
of
expects,
a
lot
of
tear
less
things
to
be
stored
as
a
secret.
There's
a
there's,
a
clean
boundary
there,
where
you
can
automate
the
crap
out
of
that
secret.
If
that's
what
you
want
or
you
can
specify
it
manually
and
it's
kind
of
up
to
the
cup
to
the
people
who
are
doing
things
I,
understand,
I,
understand
the
use
case.
B
You're
talking
about
anywhere
you
we've
got
like
you
want
people
to
be
able
to
say.
I
would
like
to
be
able
to
serve
to
serve
my
stuff
out
of
this
website,
and
here
is
a
certificate
for
something
like
that
or
I
want
to
pass
through.
I
want
you
to
pass
through
this
config
to
my
web
server,
and
he
is
that
he's.
The
you
know
here
is
the
certificates
that
I
am
using.
B
C
C
So,
let's
say
that
we're
in
a
situation
where
you
have
different
are
about
permissions
for
the
Gateway
itself
and
then
the
app
developer,
we're
expecting
to
write
routes
right
in
that
case,
you're
saying
how
the
app
developer
is
going
to
say:
hey
use
such
a
such
certificate.
I
can't
edit
the
Gateway
directly
in
your
model,
you're
saying
that
hey
that
app
developer
is
going
to
be
able
to
produce
one
of
these
requests
and
then
there's
going
to
be
some
state
transition
when
it
makes
it
through.
C
On
the
admin
side,
my
question
is
and
then
and
then
presumably
there's
some
automation,
which
we
in
your
case
you
built
into
q
cuddle,
but
imagine
there's
some
automation
where
it
facilitates
that
relationship.
Is
it
possible
to
build
the
same
kind
of
automation
but
just
basically
editing
gateway
in
some
sense.
C
C
E
I
mean
my
thinking
behind
the
whole
kind
of
gillis.
Config
separate
object
is
just
providing
that
maximum
flexibility
for
these
different
use.
Cases
right
where
it's
like,
hey,
you
know
we're
a
small
I've
got
a
small
cloth
clothes
for
a
small
mom-and-pop
shop.
You
know
we
want
one
person
to
do
it
all.
Well,
you
know
we
can.
We
can
do
that,
I
think
as
soon
as
we
kind
of
tie
it
into
a
specific
resource.
E
That's
we're!
You
know
we
kind
of
have
to
ride
that
one
horse
in
say.
Ok,
this
is
the
role
that's
responsible
for
managing
TLS.
So
to
your
point,
like
okay,
do,
could
we
potentially
you
know,
have
this
chile's
config
object,
but
automated
basically
applying
the
TLS
config
to
the
gateways?
Spec
I
mean
I.
Guess
it's
possible,
I
might
I,
guess
I
always
thought
like
you
know
doing
anything
to
spec
is
it
should
be
done?
I.
E
C
In
my
mind,
was
that
so
that
block
it
has
both
the
certificates
and
then
some
kiosk
configuration
and
whether
or
not
that
would
be
permission
differently
than
say
the
Gateway
and
its
listeners.
Because
there
is
some
implicit
sort
of
notion
that
you
have
that.
That
gateway
in
of
itself
would
be
sort
of
managed
by
a
completely
different
set
of
people
than
the
certificate
and
acceptance
right,
because
even
if
you're
you're
going
to
be
Auto,
accepting
that's
sort
of
like
almost
like
your
editing
of
sub
piece
of
the
Gateway
automatically
through
automation.
C
E
Well,
you
know,
I
think
the
flexibility
with
a
Tilles,
config
object
or
Achilles
complete
request
object
is
that
you
know
the
are
back
associated
with
it
is
going
to
be
depending
on
who
consumes
it
right
for
maybe
by
default.
We
say:
okay
has
the
same,
are
back
permissions
as
a
gateway
all
right,
but
for
those
that
say
well,
no,
you
know
I
want
my
developers
to
be
able
to
create,
and
then
you
know
we
would
adjust
the
permissions
accordingly
or
for
large
enterprises
that
say
no
security
operations
is
responsible
for
TLS
config.
So,
okay!
E
Well,
let's
you
know,
update
the
are
back
permissions
for
the
you
know,
for
the
TLS
config
request
to
make
sure
that
you
know
they
could
only
be
read
by
the
cluster
ops
and
the
development
and
the
developers,
but
it's
a
sec
ops
group
that
we've
created
that
can
create
the
chillest
config
request.
Yeah.
C
I'm
curious
about
this
layering
because,
like
it,
would
be
good
to
kind
of
explore
what
because
you're
gonna
have
to
as
part
of
your
sort
of
proposal,
like
you
have
a
piece
of
automation.
That
kind
of
needs
to
be
there
and
it's
like.
Could
you
build
automation
such
that
it
edits
the
Gateway
like?
Let's
say
you
have
a
TRD
for
the
TLS
config,
but
it's
now
actually
doesn't
exist
in
this
level
of
the
API.
C
That
way,
we
don't
have
like
additional
resources
that
dependence
right
now
and
then
the
other
question
would
be
if
you're
going
to
split
gateway
and
the
TLS
portion
of
gateway
into
two
resources.
It
would
be
good
to
write
out
like
what
scenarios
you
think
it
makes
sense
to
have
someone
have
permission
to
basically
automatically
manage
all
their
TLS
certificates,
but
yet
they
can't
sort.
C
E
Yeah
I
mean
if
we
had
hyper
our
back,
where
it's
like
a
you
know,
you
could
only
you
know,
do
certain
things
to
a
field,
and
that
would
be
great
I'm
sure
to
have
it's
its
downfalls
as
well,
but
that's
essentially,
what
we're
trying
to
do.
It
would
be
great
if
TLS
can
just
live
in
a
gateway
and
then
use
our
back
based
on
you
know,
corporate
policies
to
to
adjust
who
can
do
what
to
that
field
right.
C
Yes,
it
would
be
good.
I'll
drop
some
comments.
Those
comments
on
your
presentation,
if
you
could
did
like
figure
those
things
out.
The
other
thing
was
a
comment
was
about
the
virtual
host.
It
was
an
interesting
ideas
that
you
have
TLS
and
that
the
the
protocol
that
in
the
TLS
overlay,
so
you
have
like
pls.
D
C
E
C
G
B
D
E
With
the
extensions
because
it's
I
kind
of
made
a
comment
in
the
slide
deck
on
this
topic
is
like
okay.
So
if
it's
a
new
protocol
under
the
virtual
host
model,
which
okay
we'll
add
it,
isn't
it
as
an
extension
and
then
as
it
matures
and
becomes
more
widespread
in
its
usage
and
graduated
to
an
actually
an
actual
typed
type
field.
C
C
It
feels
way
more
tractable
than
trying
to
force
people
to
use
an
extension
mechanism
to
describe
it
initially
inside
the
virtual
host
and
then
sort
of
later
graduate
that
entire
blog,
at
least
that
seems
like
kind
of
hard
to
deal
with
you'd
have
to
write
a
whole
library
to
kind
of
deal
with
schema,
izing
it,
and
so
that
was
sort
of
the
thought
of
why
we're
going
to
keep
the
protocols
all
in
their
independent
resources.
So
they
can
kind
of
evolved
independently
and
the.
E
F
C
B
So
that
was
my
thought,
and
that
was
where
some
I
think
maybe,
where
Rob
and
I
talked
about
something
with
the
previous
thing,
where
we
were
thinking
a
similar
thing
where,
where,
if
there
was
a
shared
struct,
that
was
the
tailer
struct,
that
you
could
use
that
you
could
use
either
on
the
gateway.
Or
if
you
have
that
bit
flipped
on
the
wrap
on
the
routes,
then
then
it's
the
same
struct.
So
the
code
that
actually
deals
with
the
mechanisms
of
that
struct
will
will
be
the
same.
B
But,
like
you
know,
just
you'll,
be
calling
that
code
out
from
the
different
from
different
spots.
I,
don't
know
if
that's
any
better
or
not
need
to
think
more
I
mean
personally
I.
Think
the
best.
The
best
thing
that
that
you,
that
you
pulled
that
you
pulled
with
all
of
the
virtual
hosts
off
is
that
I
think
it's
actually
really
important
to
treat
domains
as
a
special
thing,
because
they
are
a
special
thing
like
that.
H
C
I
had
a
note
about
that,
and
that
was
what
would
be
great
to
follow
up
on
is
to
figure
out
what
specifically
a
domain
is
going
to
be
intended
for
and
what
we
can
like.
What
would
we
go
to
the
doc
string
on
that
domain?
Feel,
like
you
see
one
example
would
be
dish
will
be
used
by
systems
like
external
DNS
to
create
the
MS
entries
for
each
of
the
virtual
hosts
or
something
like
what
is
I
understand.
There
is
some
relationship
there
that's
being
enforced,
but
beyond
that
enforcement.
C
What
does
that
be
and
what
kind
of
guarantees
would
we
want?
Other
people
to
consume
that
API
to
be
using,
if
that
makes
sense
like
part
of
the
API,
is
to
build
for
our
controllers.
But
part
of
the
API
also
is
to
interoperate,
with,
let's
say,
an
external
controller
like
external
DFS
or
let's
encrypt
right
like
how
does
those
interact,
because
I
think
that
that
domains
is
actually
one
of
the
latter,
where
it's
sort
of
outward
basing
from
the
ecosystem?
C
And
we
just
had
a
bunch
of
people
I
think
even
it's
in
one
of
the
use
cases.
But
one
of
the
comments
somewhere
was
like
ok.
But
how
does
this
interact
with
some
of
these
like
ecosystem
aspects,
such
as
ice
and
crepes,
I?
Think
for
sure,
if
you're
gonna
use
domain
to
get
the
certificate
and
then
probably
also
some
external
DNS
kind
of
mechanism.
E
C
B
C
E
Yeah,
let's
collect
some
comments,
feedback,
and
maybe
we
can
you
know
based
on
you
know
what
everyone
thinks
is
you
know
if
we
feel
like?
Oh
gosh,
you
know
like
let's
dig
in
a
domain
a
little
bit
more,
which
it
sounds
like
that's.
Definitely
a
work
stream
taken
from
here,
maybe
I
think
a
little
bit
more
about
the
chillest
config.
E
C
So
I
think
right
next
week,
let's
get
everything
out
on
the
mailing
list,
so
we
get
as
broad
coverage
as
possible
I
think
next
week
we
can
kind
of
let's
see
how
people
feel
and
sort
of
at
that
point:
I'm,
okay,
with
just
moving
ahead
with
some
PRS
to
kind
of
get
these
things
in
how's.
That
sound
note.
C
B
B
E
C
C
A
Okay,
so
if
you
look
at
the
the
calendar
on
the
community
page,
we
have
an
update,
up-to-date
calendar
invitation
there,
but
unfortunately,
when
we
change
things,
if
you
use
an
old
calendar
invitation,
it's
probably
useless.
Now
you
can
add
the
entire
calendar
and
then
you'll
get
updates
to
it
and
then
also
one
note
while
I'm
thinking
about
it,
we
are
doing
auto
upload
now,
so
what
I've
been
told
is
around
24
hours
after
a
meeting
this
would
go
on
the
kubernetes
channel
on
YouTube.