►
From YouTube: WG Platforms Project Meeting - 2022-12-13
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
C
B
Yeah
I
guess
so:
I
I
put
a
couple
items
on
the
agenda.
Does
anybody
else
want
to
add?
Does
anybody
want
to
start
or
specific
items?
Do
you
want
to
add
or
discuss.
B
Okay,
I'll
jump
in,
if
you
think
of
anything
at
the
end,
so
the
update
first,
what's
going
on
I'm
working
on
the
platforms
definition
paper,
we
had
a
couple
meetings
the
past
couple
weeks.
Thank
you
Thomas
and
raphaeli,
and
other
folks
that
have
joined
really
good
feedback.
B
I
think
we're
getting
to
at
least
the
structure,
a
kind
of
consensus
and
I
posted
in
the
in
the
in
the
issue
here
kind
of
what
we
could
do
next,
so
that's
I'm,
just
updating
you
all
like
I,
haven't,
had
a
chance
to
do
it.
B
Yet
it's
I
haven't
even
had
a
chance
to
handle
the
feedback
from
our
last
session,
but
what
I'm
kind
of
thinking
next
is
is
based
on
those
sections
create
a
directory
with
a
a
markdown
file
for
each
section,
some
sort
of
automation
that
merges
them
all
and
publishes
a
markdown
file,
a
PDF
there's
a
couple
other
papers
like
that
around
so
I
need
to
look.
B
If
anybody
else
wants
to
help
feel
free,
I'm,
just
kind
of
looking
at
the
way
they
did
those
and
the
others
and
and
kind
of
learn
from
that
I
figured
it'll,
be
one
PR
to
kind
of
put
the
framework
in
and
then
I'll
make
PRS
for
the
for
the
sections.
And
that
way
we
can,
you
know
kind
of
debate
before
they
before
they
land.
But
I'll
start.
You
know
largely
with
the
stuff
that
we've
iterated
on
in
the
Google
Doc.
B
So
I
guess
that's
one
update
from
me
yeah.
If
we
want
also
like
I,
don't
if
you
all
want
now,
we
can
keep
going
over
that
paper
or
we
can
get
feedback
in
this
session
here
now.
I'm
open
to
that.
The
other
thing
that
I
put
in
the
agenda
is
what
goes
next
kind
of
what
I
you
know.
I
was
inspired
in
the
last
tag-up
delivery
meeting
on
Wednesday
I
was
talking
with
Eloise
a
tiny
bit
and
he
said
in
terms
of
getting
feedback
like
one
of
the
things
I'm.
B
Thinking
with
this
paper
is
not
necessarily
that
it's
the
be-all
and
end-all,
but
that
it
puts
a
stake
in
the
ground,
and
then
people
can
say
we
agree.
We
don't
agree.
You
know
this.
Is
this
aspect.
This
is
not
so
that's
why
I
wanted
to
get
it.
You
know
something
out
there,
but
then
I
do
to
and
Eloise
was
emphasizing
projects
like.
B
We
should
work
with
the
projects
to
know
you
know
where
their
take
is
on
all
this
stuff,
where
they
fit
in
what
kind
of
feedback
they
need
from
their
users
and
I
I
thought
that
rang
kind
of
true,
like
I,
shouldn't
just
use
my
red
hat
customers,
or
something
like
I'm
kind
of
representing
cncf
here
and
and
trying
to
you
know,
PM
their
projects,
PM
that
you
know
make
sure
they
have
the
feedback
they
need.
So
I
thought
that
made
sense.
B
So
I
just
wanted
to
share
that
like
a
Next
Step
here
might
be
working
with
the
projects
that
that
are
related
to
platforms
are
related
to
tag
app
delivery
and
interviewing
their
customers,
or
even
just
you
know,
finding
people
on
GitHub
to
talk
to,
and
things
like
that.
C
Yeah
I
also
like
the
idea
very
good
to
to
gather
some
feedback
like
that
yeah.
B
Yeah
so
I
guess
I'll
yeah,
I'm
gonna
work
on
that
I.
Just
put
it
up
there
right
now,
I'm
just
trying
to
get
that
initial
paper
in
yeah.
In
fact,
I.
D
B
C
Is
it
for
projects
or
also
for
organizations
that
internally
are
building
a
platform,
and
then
they
can
share
their
feedback.
B
D
Yeah,
we
definitely
run
a
risk
of
being
too
much
biased
by
our
own
experience.
D
E
D
Like
I
think
the
last
one
they
just
wanted
better
documentation
for
their
microservices.
You
know
that
was
the
initial
starting
point
like
it's
I,
don't
even
know
if
we
mentioned
I
think
we
mentioned
documentation
at
some
point,
but
it's
it's
unusual.
So
hearing
more
of
these
stories
I
think
it's
very
useful
to
us.
Otherwise
we
might
run
a
little
bit
of
Ivory
Tower
risk
here.
B
B
So
yeah,
okay,
so
that's
all
I
mean
I,
don't
have
any
other
agenda
items
for
today.
I
just
was
going
to
get
a
progress
report.
If
we
want
to
work
through
the
dock,
I
guess
I
mean
I
can
open
it
up.
Does
anybody
want
to
talk
about
something
specific
there.
A
B
B
Yeah
check
out
the
notes,
also
from
we
from
the
past
couple
ad
hoc
meetings
put
some
of
the
stuff
in
there.
A
B
A
B
E
A
Too,
but
yeah
I'll
put
that
on
my
to-do
right
now,.
D
I
have
a
question
for
the
team
like
if,
if
we
are
done
with
the
document
but
yeah
last
time,
there
was
a
lady
here
in
the
team
that
brought
up
something
in
a
I
would
like
to
bring
it
up
again
and
see
what
everybody's
think
in
their
own
and
things
in
their
own.
D
You
know
day
job
about
that,
but
I
think
we
all
we're
all
coming
to
this
platform
idea
with
the
perspective
that
is
going
to
be
based
on
githubs
right,
so
very
declarative,
and
then
you
know
they
to
get
you
know.
Essentially,
your
interaction
with
this
with
the
platform
is
to
make
PR
s
and
then
from
there
the
github's
automation
takes
takes
over.
But
what
she
said
is
was
not
everything
can
be
made
declarative.
There
are
things
that
are
imperative
in
nature
and
very
hard
to
to.
D
You
know
portray
to
to
bring
the
very
good
Clarity
right,
I,
think
I
think
she
works
for
critics
or
something
like
that
right
and
they
have
a
solution
for
that,
but
in
general,
what
what
is
our
answer
to
that
right,
because,
because
I
think
she's
right
right,
there
are
things
that
are
hard
to.
There
are
things
that,
for
example,
need
to
happen
once
right
and
and
then
once
they're
up
and
when
the
once
they're
about
happen.
Maybe
they
should
not
happen
again
and
there
is
no
really
good
way
to
do
reconciling
so.
D
Okay,
do
we
want
to
have
a
sudden
in
that
space?
And
you
know
there
are.
There-
are
approaches
to
solving
this
problem,
but
there's
still
very
a
very
like
you
can
do
sync
waves
in
some
cases
and
spin
up
a
job
or
I
think
cross
plane
has
its
own
thing
to
do
this
kind
of
things,
but
still
a
very
it's
very
brittle
right,
so
I'm
curious
to
see
what
other
people
are
doing
for
this
problem,
and
if
there
is
something
we
should
mention
in
the
document.
A
I
I
don't
see
it
as
a
like
get
UPS
or
or
nothing
type
mentality
here
what
I?
What
I
think
is
important
when
we're
doing
stuff
with
this
is
to
keep
keep
everything
as
open
as
possible.
There
are
certain
things
or,
as
general
as
possible.
You
know,
there's
there's
the
interaction
part
of
this,
which
could
be
through
git
if
you're
doing
a
get
else
model
scenario
or
it
could
be
an
API
or
it
could
be
a
different
type
of
tooling.
A
On
top
of
that,
but
I,
don't
think
any
of
us
wants
to
write
something
that
has
get
UPS
as
kind
of
like
the
the
golden
standard
of
of
doing
anything.
A
Just
because
you
know
we
can't
really
have
that
there
are
just
definitely
you
know:
scenarios
where
there
are
things
that
just
need
to
happen
once
and
from
the
perspective
that
that
that
the
platform
that
I'm
building
like
everything
is
through
githubs,
mostly
unless
there's
a
team
that
has
something
that
just
needs
to
happen
once
and
do
something,
and
at
that
point,
as
long
as
they
can
have
it
in
a
container,
we
can
have
it
in
the
same
platform
and
and
make
an
end
point
for
it,
and
so
on.
A
So,
and
that's
that's
just
as
viable
as
doing
get
Ops
birthing.
Not
everything
needs
to
be
declared
in
the
states.
If
that
makes
sense,.
D
A
Don't
just
leave
it
curious
about
text.
I,
don't
I,
don't
see
anything
that
specifically
says
that
I
think
I
think
the
idea
is
that,
for
instance,
like
the
wording
like
task
Runners
and
reconcilers,
it
could
be
either
or.
A
So
I
think,
like
this
text
in
itself,
is
pretty
open
for
interpretation
when
it
comes
to.
If
you
want
to
do
something
more
declarative
like
declaring
a
state-
and
this
is
how
it's
supposed
to
look
and
then
have
a
get
us
process
where
it's
like
fetching
that
and
making
sure
that
happens
or
if
there's
like
a
single
fire
task.
That
needs
to
be
done
and
there's
so
many
ways
to
implement
that
that
yeah.
A
B
Well,
Abby
socratics.
One
of
the
ways
where
which
she
says
it
differentiates
from
cross-plane
is
that
cross-plane
doesn't
really
leave
itself
open
to
any
imperative
action,
whereas
I
believe
craftix
can
run
a
tecton
step
or
pipeline
as
part
of
its
work
and
yeah.
So
she
thinks,
like
Rafael,
is
saying
that
there
are
situations
where
that's
needed
in
cross-plane
isn't
quite
enough.
A
Yeah,
well
you,
depending
on
what
you're
going
to
do,
you're
always
going
to
have
some
sort
of
mix
of
of
tooling.
A
A
But
but,
like
I,
said,
there's
some
of
these
things
are
not
going
to
be
declared
in
the
state.
It's
going
to
be
a
single
Fire
based
on
some
sort
of
API
Gateway.
B
Well,
you
just
said
Robert
kind
of
like,
but
you
said
that
even
the
imperative
or
one-off
stuff,
you
would
check
in
that
I
kind
of
catch.
That
right.
You
would
have
that
codified
in
a
repo.
A
Maybe
well
for
me,
it's
like,
if
you
have
some
sort
of
tooling,
that
that
stands
up
something
that
does
an
imperative
thing
just
for
lack
of
a
better
word.
That
would
still
probably
be
a
kubernetes
manifest
and
if
it's
a
kubernetes
manifest
that
we
put
it
into
gear
and
use
flux
to
reconcile.
A
You
know
the
thing
that
it
does
and
stand
up
might
be
not
controlled
by
the
get
Ops
model.
A
But
the
delivery
of
the
resource
for
me
would
just
as
easily
be
done
through
githubs
than
anything
else.
For
me,
it's
more
of
the
if
we're
so
we're
having.
We
have
teams
that
are
doing
things
in
different
ways.
A
Some
might
use
Powershell
for
their
stuff
and
or
python
or
whatever,
and
what
we
just
keep
on
saying
is,
if
you
can
put
into
container
and
if
that
container
can
run
and
then
do
its
thing
and
quit
we
can
put
that
on
the
platform
and
give
it
an
end
point
to
spin
up
based
on
inputs
like
it
doesn't
have
to
be
in
good
necessarily.
B
A
Yes,
well,
you
know,
so
if,
if
you
did,
if
you,
if
you
set
this
up
the
way
that
it
works
for
us
at
least
like
you,
you
need
at
that
point
built
into
a
container
and
if
you're
going
to
do
that,
you
probably
want
it
again,
but
that
doesn't
mean
it
actually
has
any
impact
on
the
platform
itself.
That's
just
an
artifact
that
it
consumes.
So,
however,
that
happens.
You
know
we
don't
really
care.
A
However,
what
we
would
do
is
there
will
be
something
deployed
through
through
git,
an
application,
an
API
Gateway
that
has
an
endpoint
that
at
some
point
just
spins
up
that
container
as
a
one-time
thing
and
and
in
kubernetes.
Basically,
so
at
that
point
it's
it's
a
static
one
time
thing
that
happens
it
there
it
does
it.
Doesn't
it's
not
declared
anywhere
that
this
is
supposed
to
run
or
is
supposed
to
be
reconciled
at
all,
but
everything
around
it.
A
B
A
A
D
Think
that
is
really
the
point
right
in
theory,
if
I
lose
the
cluster,
but
I
don't
necessarily
lose
the
state
yeah
do
I
do
I
have
a
way
to
know
if
I
have
to
rerun
that,
once
only
thing
I
mean
that's,
that's
really
the
hard
part
here
and
when
I'm,
when
I
try,
you
know
when
I
try
to
model
these
things
with
jobs,
they
don't
work
very
well.
To
be
honest,
you.
B
A
But
that's
that's
the
kind
of
thing
like
for
for
me,
and
this
is
gonna,
be
convert
about
a
specific
tool
that
we're
using,
but
we
are
using
the
TF
controller
to
automate
terraform,
oh
yeah,
and
we
Define
a
terraform
resource,
terraform,
our
terraform
Guru,
and
if
that's
terraform
resource
you
know
it
has
a
certain
like
you
can
set
it.
You
know
one
minute
to
whatever
for
every
time
it
needs
to
reconcile
or
just
go
over
and
check.
A
You
know
if
everything
it
says
it
should
be,
but
what
TF
controller
does
it
doesn't
like?
In
the
like
the
controller
itself,
it
doesn't
actually
run
terraform,
it
spins
up
a
TF
Runner
that
runs
terraform
on
that
particular
instance,
and
as
soon
as
that's
done,
it's
deleted
and
it's
gone
and
the
reason
why
it
can
do
that,
and
that
makes
sense
in
in
that
case
is
because
the
terraform
state
is
stored
elsewhere.
A
A
A
So
the
the
every
like
the
instance
of
running
terraform
doesn't
really
have
any
there's
no
state.
It
just
is
not
declared
in
that
sense,
but
it's
something
else
that
is
making
that
happen.
A
So
you
could
do
it
like
that,
have
something
that
is
declaratively
stated
that
takes
any
type
of
like
external
outputs
and
then
do
something
with
that.
So,
like
the
the
application-
or
you
know,
the
the
the
thing
that
you're
supposed
to
run
is
actually
declaratively
added
to
the
system
state.
A
But
then
it's
triggered
based
on
other
things,
and
if,
if
it's
not
stateless,
then
obviously
that
state
needs
to
be
stored
somewhere,
which
I
would
prefer
not
to
have
it
in
the
kubernetes
cluster,
because
at
that
point,
I
could
just
nuke
the
entire
cluster
and
set
it
up
again
and
and
point
it
towards
get,
and
everything
would
come
up
again.
D
Right,
okay,
so
as
long
basically,
okay
I
get
I'll
terraform,
it
works
as
long
as
you
have
the
TF
State
and
in
some
cases
you
can
even
rebuild
it.
Even
if
you
lose
it
right,
I
think
if
you
write
a
very
good
terraform,
you
could
even
rebuild
it,
but
okay
I
get
it.
So
could
you
do
with
that
approach?
Could
you
do
things
like
create
a
database
schema,
upgraded
with
scheme
and
populated,
maybe
with
some
users
and
roles,
and
maybe
some
initial
data
is
our
old
thing.
D
Those
things
you
could
do
with
that
approach.
Do
you
think
well.
A
Well,
if,
if
you're
using
terraform,
yes,
everything
will
be
stored
in
that
terraform
state,
so
it
will
never.
As
long
as
you
keep
that
safe,
you
will
never
lose
what
happened
and
again.
This
is
just
like
abstraction
layers
on
like,
if
you
are
writing,
terraforming
your
machine
and
you
have
several
people
working
on
the
same
set
of
terraform
configuration
and
the
state
is
somewhere
shared
that
this
is
exactly
the
same
approach.
It
just
happens
to
be
automated
through
kubernetes.
A
So
when
someone
is
running
terraform
on
that
state
file,
it
actually
it
just
locks
to
say
it
checks
it
against
Etc,
et
cetera,
and
then,
if
everything's,
okay,
then
then
everything's,
okay,.
B
Hey
Abby
and
we're
just
talking
about
something
but
I
just
wanted
to
share
something
real,
quick.
The
one
thing
we
could
look
at
this,
as
is
you
know,
there's
a
couple
different
categories
for
automation.
This
has
been
so
we
could
write
an
article,
a
paper.
You
know
it
could
be
in
cncf.
It
could
be
rough.
You
write
something
on
your
blog
that
builds
on.
Okay,
we've
talked
about
automation.
What
are
the
three
patterns
for
automation?
You
know
declarative,
get
op
style
imperative
and
then
terraform,
because
it's
got
the
TF
State.
A
It
just
happens
to
store
the
state
somewhere
that
you
can
reference,
so
it
it
is
somewhere
where
you
say,
I
want
this
type
of
resource
and
you
don't
really
care
about
what
how
it
that
happens.
So
in
that
sense
declarative,
but
but
but
but
it's
you
know,
unlike
many
other
tools,
it
actually
puts
it
into
some
sort
of
like
a
data
file,
and
then
you
can
reference
that.
E
E
A
E
A
Yes,
but
the
way
that
I
see
at
least
the
the
tooling
itself
doesn't
do
that
unless
you
actually
do
something,
but
both
hashicorp
and
many
others
have
tooling
that
runs
terraform
and
then
do
drift
detection
for
you
by
doing
that,
and
also
just
since
you
weren't
there
when
I
said
it.
The
my
use
case
is
that
I'm
using
TF
controller
from
weworks,
which
then
does
drift
detection
yeah
based
on
that.
So
it's
not
it's
the
nature
of
the
application,
but
terraform
is
a.
A
A
A
B
Actually
was
referring
to
your
comment
last
week
that
critics
includes
some
imperative
commands
and
we
were
discussing
where
imperative
versus
declarative
fits
and
get
Ops,
and
whether
we
should
get
into
that
in
this
paper.
Yeah
I.
E
C
Detail,
at
least
within
the
platform,
because
I
guess
there's
also
a
lot
of
imperative
stuff,
even
flux
and
Argo
CD,
because
we
need
imperative
and
task
Runners.
We
have
the
sink
waves
or
the
dependencies
and
any
kind
of
tricks
to
do
imperative
stuff
in
a
declarative
world.
So
it
might
open
up
a
very
wide
discussion.
I
think.
Perhaps
the
focus
of
the
document
should
be
more
of
the
external
API,
like
the
user
apis.
C
That
is
declarative
like
I
declare,
I
want
my
development,
environment
and
I,
don't
care
how
it's
created
and
then
how
things
work
internally,
if
it's
githubs,
if
it's
through
pull
requests,
direct,
merge
or
via
containers,
then
perhaps
could
be
a
different
document
where
we
analyze
different
patterns
or
implementation
strategies.
What
do
you
think
about
that?
I.
A
I
support
that
idea
of
putting
it
for
me
the
the
reason
why
it's
a
platform
is
not
because
of
the
tooling
that
it
combines,
but
the
way
that
it
gives
the
the
users,
the
capabilities
to
do
things
and
I
think
they're.
That
part
should
be
declarative.
I
don't
want
anyone
that
are
using
my
platform
to
have
to
know
how
to
get
stuff
to
work.
I
wanted
to
be
able
to
just
go
and
say
give
me
an
environment.
It
should
look
like
this
like
what
happens
in
the
back
there.
A
You
know,
that's
not
there's
none
of
them.
They're
they're!
You
know
that's
an
abstraction
layer
down.
That's
that's!
Where
that's
what
that's
what
I
do
they
don't
have
to
think
about
that?
So
for
me,
it's
like
the
I
think
that
is
the
main
thing
that
people
need
to
think
about
when
they're
doing
creating
platforms
and
doing
platform
engineering,
it's
it's
the
actual
interaction
with
the
platform
and
to
make
that
as
easily
accessible
as
possible.
B
I
hear
you
what
I'm
kind
of
like
thinking
about
as
you
all
are
talking
is
it's
almost
like
the
imperative?
Declarative
thing
is
indicative.
It's
it's
correlated.
It
signals
that
we've
separated
the
hard
part
from
the
end
developer,
like
they
just
have
to
write
a
config
in
a
repo
declarative.
If
we've
done
our
work
right
as
platform
Engineers
or
the
capability
providers,
then
the
imperative
part
is
in
the
operator
or
the
controller
or
something
and
hidden
away
yeah.
B
A
Yeah
it's
for
me.
It's
like
the
you
know
at
this
point.
As
a
person
who
can
drive
a
car
I,
don't
shouldn't
be
able,
like
I,
wouldn't
do
I
need
to
know
how
a
car
works
like
or
even
further
down
do
I
need
to
sit
there
and
move
Pistons
up
and
down
to
make
sure
the
car
goes
forward.
No
I
should
be
just
be
able
to
sit
down
and
push
a
pedal
and
everything
works.
A
For
me,
it's
kind
of
the
same
thing:
the
people
that
I
usually
work
against,
which
is
developers
that's
kind
of
the
target
audience
for
the
things
that
I
do.
Many
of
them
know
a
lot
about
like
the
the
you
know,
how
to
run
things
and
like
infrastructure
and
so
on
and
so
forth.
But
it's
just
that
that
the
the
the
the
cognitive
overload
of
having
to
think
about
everything
they
just
want
to
say
this
is
my
code.
How
do
I
get
it
onto
the
platform
all
right?
A
This
is
the
approach
cool
done
and
then
it's
up
to
me
to
make
sure
that
that
actually
is
working
as
intended
and
and
that
they
have
an
easy
time
using
that
platform.
Oh
for
me,
for
me
that
is
key
to
what
a
platform
is.
A
Because,
again
we're
talking
about
certain
abstraction
levels.
You
know
the
things
that
I
do
is
on
top
of
a
section
layer,
so
on
top
of
extraction
layers
and
so
on
and
so
forth
and
in
the
end
it's
just
binary,
but
I
don't
have
to
deal
with
that.
B
Okay,
so
I
think
we're
good
on
that,
like
I
could
see
follow
on
talking
about
the
different
patterns
of
automation.
Maybe
we
even
asked
the
get
Ops
working
group
if
they
wanted
to
dive
into
this
little
further.
It's
come
up
in
some
of
the
slack
threads
like
get
Ops.
Is
it's
impossible
to
always
be
declarative?
Some
people
come
in
and
are
like
I'm.
Not
how
do
you
do
get
Ops
I
can't
do
it
correctly,
I've
seen
people
post
in
the
selection,
all
that
way
so
might
be
something
to
pursue.
Yeah.
A
I,
even
I
I
got
quoted
on
Mastodon
for
an
article
about
get
Ops
and
there's
a
person
who
commented
that
was
very
much
like
I.
Don't
understand
why
githubs
is
a
thing.
This
is
just
cicd
and
it's
like
now.
Try
linking
to
the
principles
and
about
exercise
clinical
training
as
well.
That's
your
CI!
Okay.
This
needs
a
whole
lot
more
talking
capable.
A
That
that
is
like
what
I
usually
say
is
get
Ops.
Is
a
continuous
deliver
deployment,
not
delivery,
continuous
deployment
scenario,
you
don't
want
to
care
about
deployment.
You
want
to
just
say:
I
want
this
stuff
to
be
deployed
and
the
deployment
itself
you
shouldn't
to
have
to
care
about.
That
should
happen
automatically
continuous
integration.
That's
one
thing:
continuous
delivery.
Having
software?
That's
that's!
That's
ready
to
be
delivered.
That's
another
thing
contains
deployment
shouldn't
be
a
thing
you
should
just
be
able
to
say
this
is
what
I
want
out,
and
then
that
happens
so.
A
Yes,
so
so
for
me,
that
is,
that
is
like
the
key
to
get
UPS
right.
You
know
simplifying
deployment,
not
necessarily
you
know
integration
or
delivery,
but
deployment,
and
in
the
same
when
it's
like
we
could.
We
could
bring
some
of
this
discussion
into
the
to
the
get
Ops
working
group
or.
A
A
So
if
you,
for
instance,
say
to
someone
put
your
manifest
in
here
and
everything
else
would
solve
itself,
that
is
perfectly
fine,
but
that
is
not
like
a
be
all
handle
way
of
defining
a
platform,
which
is
why
I
keep
on
saying,
like
the
the
like
the
interaction
elements.
A
What
I
usually
say
is
you
know,
interaction,
compute
and
data
integration,
like
those
three
things
just
have
to
talk
to
the
you
know,
put
each
other
if
the
interaction
towards
the
platform
is
get
Ops
and
you
have
developers
that
are
capable
of
doing
that
and
creating
those
manifests
and
putting
it
together.
That's
perfectly
fine,
but
some
don't,
and
at
that
point
you
need
to
abstract
that
to
some
something
else:
potential
API
big
potential
in
the
UI
with
potentially
Etc.
D
But
but
it
seems
to
me
that
the
GitHub
Slayer
is
more
and
more
getting
you
know
established
and
that's
what
I
was
saying
before
I.
It
seems
to
me
that
we
it
in
some
sense
we're
all
thinking
well
convergent
over
we're.
Gonna
have
a
get
UPS
interface
between
the
users
and
the
platform
and
what's
happening
inside
the
platform,
then
that
that
interface
may
not
be
good
enough.
We
need
maybe
something
on
top
of
it,
because
not
everybody
can
write
configuration
files
and
PRS.
So
maybe
we
need
a
tool
on
top
of
it.
D
A
I,
try
not
to
say
anything
that
concrete,
because
I'm
obviously
biased
as
someone
that
is
a
maintainer
of
the
open,
Gatehouse
project
and
very
vocal
about
basically
everything
get
UPS
at
the
same
time.
It's
what
we
try
to
do,
for
instance,
is
we're
we're
building
services
that
are
built
on
top
of
githubs,
where
we're
not
like,
hiding
that
we're
saying
it
straight
out.
This
is
how
we
do
stuff
at
some
point,
there's
going
to
be
an
an
application
platform
for
a
developer
to
use.
A
We
would
prefer,
if
you
did
stuff
through
getups,
because
that
is
what
we
believe
in,
but
at
the
same
time,
there's
all
these
different
scenarios.
So
you
know
just
different
people.
We
can't
say
this
is
the
one
approach
to
do
it
all.
So
we
need
to
be
open
for
us
putting
up.
You
know
in
our
instance
a
kubernetes
cluster
which
uses
flux
to
do
all
the
system,
parts
of
it,
and
then
the
users
might
potentially
just
use
CI
CD
tools.
A
Applied
like
whatever
like
we
can't
just
deny
people
doing
that,
because
that
is
a
a
specific
team
decision
to
do
like
how
do
we?
How
does
our
workflow
look
like.
D
A
A
States,
that
doesn't
mean
we
can
just
like
say
this
is
the
one
approach
to
do
it,
even
as
a
very
open
get
UPS
advocate
and.
D
A
Yeah,
in
many
cases,
yes,
and
in
many
cases
the
people
are
afraid
of
just
leaving
this
to
automation,
for
some
reason,
thinking
that
a
a
like
a
CI
CD
situation
is
better
because
of
a
number
of
reasons
like
I
said.
A
For
me,
the
the
entire
part
of
githubs
is
not
to
have
to
think
about
deployment
like
you
should
do
everything
up
until
a
point,
and
as
soon
as
you
know,
you
are,
you
have
something
that
can
be
contained
like
deliverable,
which
is
the
CI
cd
part
like
traditionals,
that
the
continuous
deployment
board
should
just
be.
This
is
a
new
version.
D
A
A
So
even
though
I
would
like
to
say
yes
get.
Ops
is
going
to
solve
the
entire
platform
scenario,
even
though
I
can't
really
say
that.
C
I
think
that
flexibility
is
important
like
compared
to
like
platform
like
Heroku,
for
example,
where
that's
the
way
that
it
works.
You
don't
have
the
flexibility
to
change
too
many
things
Etc.
What
we're
talking
about
here
is
you
have
full
flexibility
and
capabilities.
Then,
of
course,
there
are
recommended
way
from
the
platform
team.
This
is
what
we
recommend
to
do,
but
having
that
chance,
that
possibility
to
do
something
different
I
think
it's
quite
critical
to
the
success
of
the
platform.
Yeah.
A
And
that's
actually
a
thing
that
we've
been
discussing
like
we
want
to
be
kind
of
like
a
Roku
for
platforms,
but
without
the
like
limited
factor
like.
If
you
don't
want
to
think
about
anything,
we
could
just
like
deploy
everything,
that's
needed,
and
then
you
just
go
ahead
and
do
whatever.
But
we
are
also
open
to
in
swapping
out
tools
swapping
out.
You
know
the
delivery
methods,
whatever.
E
When
you
say
that,
is
that
essentially
like
your
golden
path,
then
your
Heroku
is
saying:
do
you
want
to
use
your
golden
path?
It's
ready
for
you
just
go.
You
know
like
here
are
your
parameters
you
have
to
meet
and
everything
else
is
done
for
you,
but
you
can.
You
can
deviate
from
the
golden
path
in
these
ways
right,
you
can.
B
B
A
Yeah
for
for
us,
that
would
be
it.
So
if,
if
we
had
someone
that
wants
to
do
things,
the
way
that
we
want
it
to
be
at
some
point,
you're
just
going
to
end
up
having
a
git
repository-
and
you
put
your
manifest
there
and
that's
it-
that's
how
you
interact
with
the
platform,
but
obviously
like
I
said
like
for
for
the
deployment
part
we
need
to
be
flexible
even
for
like
monitoring
and
everything.
That's
part
of
like
this
kind
of
like
solution.
Even
there
we
need
to
be
flexible.
A
We
have
a
starting
point,
but
obviously
we
need
to
start
off
in
in
the
way
that
we
want
to
do
it
but
be
open
that
we
have
to
change
out
every
single
part
of
the
entire
platform.
At
some
point
to
you
know,
because
we're
trying
to
do
this
at
scale
we're
not
trying
to
do
this
for
an
internal
team.
We
don't
have
like
our
internal
customers.
Aren't
internal
customers,
it's
it's
the
world
if
that
makes
sense
so
so
like
we,
we
just
had.
A
We
just
have
to
like
like
make
sure
that
whatever
we
do,
we
don't
like
paint
ourselves
into
a
corner
where
it's
like.
Oh
you
need
to
use
this
tool
to
make
this
work,
which.
B
One
last
thing
is
I
paste
it
in
there
the
kpt
folks,
that's
a
cap,
they
call
it
Brian,
Grant
and
stuff
from
Google
had
public.
They
shared
this
in,
like
in
some
of
the
cncf
channels
like
six
or
nine
months
ago.
Basically,
they,
if
I,
understand
kept
correctly.
It's
allows
you
to
make
edits
to
like
configuration
files,
even
after
they've
been
checked
in
and
it
somehow
can
push
them
back
into
git.
Also
so
like
it's
not
just
a
one-way
path,
that's
what
they're!
C
B
E
D
A
If
I
put
my
GitHub
GitHub
sat
on
for
me,
this
all
of
a
sudden
doesn't
become
get
Ops
anymore.
A
B
A
A
It
was
one
of
those
things
where
the
the
like
rationale
behind
git
Ops
is
kind
of
defined
into
the
the
principles,
and,
if
you
are
following
that,
as
soon
as
the
you
know,
desired
state
is
not
actually
coming
from
the
the
storage
space
whatever.
That
is,
if
it's
good
or
anywhere
else,
that's
immutable
inversion.
If
it
doesn't
come
from
there,
it
actually
is
not
get
us.
B
A
Well,
you
can
do
it
and
that's
that's
part
of
why
the
principles
are
written
as
they
are
actually
like.
You
don't
need
gear
for
the
getups,
but
the
getups
operational
model
needs
somewhere.
That
is
immutable
and
versioned,
and
you
want
your
desired
state
to
be
there
and
from
there
that's
the
source
of
Truth
and
the
source
of
Truth
is
what's
red
and
made
sure
that
this
is
the
reality
so
syrians
to
have
like
the
pla,
the
the
place
that
are
using
the
sources
through
writing
back
to
and
changing
stuff
back
and
forward.
A
E
B
They
use
a
different
terms.
That's
true,
yeah
I'm
glad
to
read
this
more
closely
myself.
Now
too.
After
this
call
evaluate
I
I
want
to
be
conscious.
This
was
it
was.
Thank
you,
I
mean
there's
a
good
conversation
about
get
Ops
and-
and
you
know,
potential
follow-on
paper
could
be
about
the
styles
of
automation
within
a
plan
like
I
kind
of
think.
Within
each
of
these
categories
there
could
be
a
follow-on
and
going
back
to
what
we
were
saying
earlier
about
interacting
with
the
projects
that
could
be
a
part
of
it
like
we.
B
A
B
A
Yeah,
so
so
there
are
many
ways
to
do:
automation
that
is
as
right
as
the
next
one
like
there's.
No
there's!
No
one
way
to
do
anything
but
I
think
like
I,
said.
The
reason
why
something
like
get
UPS
is
now
seeing
as
kind
of
like
a
golden
standard.
For
this
is
that
you,
you
don't
have
to
think
about
the
deployment
part
you
just
need
to
put
your
stuff
somewhere
and
that
then
everything
just
happens
with
stuff.
B
E
The
you're
almost
at
arguing
that
or
or
explaining,
that
your
your
API
for
platform
interface,
you're
having
a
big
conversation
last
week,
around
platform
interfaces
versus
the
delivery
of
capabilities
and
like
our
operator,
is
an
example
of
a
platform
interface.
Or
are
they
an
example
of
a
like
ability
to
provide
resources?
E
Which
is
you
know,
you
need
everything
they're,
just
different,
you
know
capabilities
or
whatever,
and
we
kind
of
settled
on
that
like
operators
is
a
good
example
of
it's
a
way
to
deliver
a
capability,
but
like
it's,
not
an
interface
in
an
in
and
of
itself
right
and
but
what
I'm
hearing
you
say
is
that
your
interface
is
get
Ops.
Is
that
right,
like
is?
E
Is
it
am
I
hearing
you
correctly
that,
like
your
users,
when
requesting
something,
would
use
like
a
git
Repository,
because
I
the
reason,
the
reason
I'm
asking
is
because
that
was
another
question
that
came
up
last
week
is
like?
Where
would
get?
Where
would
git
go
on
this
on
this
diagram?
Possibly,
should
it
go
on
the
diagram
if
it
should?
Where
should
It
Go.
D
A
I
was
you
know,
and
it's
kind
of
hard
to
like
pinpoint
something
like
an
operator
or
even
controllers,
to
to
one
capability
or
or
the
other,
because
yes
in
in
in
in
my
case,
get
Ops
is
the
way
that
we
are
interacting
with
the
platform,
which
means
that
you're
putting
your
your
manifest
there
and
then
it's
a
controller
that
picks
up
that
and
makes
that
happen.
So
the
actual
interaction
with
the
platform
itself
is
through
you.
C
A
Automatic
software
agents
just
to
call
this
something
besides
controller
operators,
and
if
we
are,
for
instance,
a
good
example
would
be
like
cert
manager
like.
That
is
something
that
people
would
interact
with
through
yaml,
but
it
is,
it
is
an
automatic
process
around
it,
so
they
are
ordering
certificates
through
search
manager
right,
there's.
No,
it's
not.
We
haven't
extracted
that
to
a
layer
where
you
go
in
like
hook
up
like
a
thing
and
then
portal,
and
then
you
get
a
certificate.
We
can
do
that
in
the
end.
C
And
is
that
an
API
then,
or
the
implementation
of
the
API
like
if
I'm,
using
an
application,
if
it's
backed
by
rest
or
by
graphql
as
a
user
I,
don't
like
I,
don't
see
that
so
my
API
is
maybe
the
form
that
I
have
on
my
web
page
or
in
backstage
is
the
template.
I
filled
in
to
start
my
golden
path
and
perhaps
then,
in
the
back
end,
I
have
a
git
push
that
triggers
the
edops
model,
but.
A
I
would
say
not
because
the
for
me,
what
defines
an
API
is
that
it's
actually
something
that
can
easily
be
triggered
from
someone
in
a
very
specific
manner
when
you
are
doing
get
Ops
you're.
Just
you
know,
you're,
storing
your
configuration
in
in
git
and
that
triggers
the
entire
process.
That
happens.
There's
no
interaction
through
that
form
like
you,
can't
go
in
there
and
get
info
out.
You
can't
go
in
there
and
do
small
change.
A
You
have
to
have
a
new
state
declared
in
your
in
your
git
repository
I,
wouldn't
consider
git
Ops
to
be
anything
like
an
API
unless
you
are
actually
again
putting
something
in
front
of
get
Ops
that
are
doing
these
type
of
tasks.
For
you,
the
the
interaction
Department.
B
A
B
A
Well,
it
depends
on
how
you
look
at
it
like
if
you
consider
going
into
a
git
repository
and
looking
at
files
and
reading
them,
and
then
that's
how
you
get
your
information
out
and
then
you
know
it
would
be
the
same
as
you
would
with
a
with
an
API
and
if
you
have
some
sort
of
system
that
can
read
those
manifests
from
gets
on
the
other
end
and
then
extract
information
from
that,
then,
yes,
you
could
kind
of
like
say
that
this
is
sort
of
like
an
API,
but
the
the
the
the
definition
for
me
for
API
is
that
it's
it's
a
it's
it's
an
element
where
not
only
users
but
those
computers
can
go
in
and
say.
A
This
is
the
thing
that
we
want
to
do
against
your
system
and
again
that's
an
abstraction
layer.
You
don't
say
I,
you
know
put
in
kind,
this
et
cetera,
et
cetera,
that
you
know
that's
not
declaratively
enough
from
like
an
interaction
point
of
view
for
it
to
become
an
API
for
me,
if
that
makes
sense,.
C
Yeah
and
I
totally
agree
so
I
guess
we
we're
all
on
the
same
page
of
that,
like
github's,
probably,
is
one
of
the
most
popular
way
we
used
and
we
try
to
use
but
like
from
the
API
point
of
view,
and
in
this
document
we
like,
we
don't
enforce
it
or
say
that
that's
the
API
or.
E
C
A
B
A
You
you
that
you
know
you
need
to
be
able
to
get.
You
know
some
information
from
the
cluster,
but
preferably
whatever
you're,
storing
and
get
is.
What
actually
is
the
current
state,
which
is
again
like,
like
I,
said
that
that's
why,
for
instance,
I
wouldn't
call
the
cape
what
was
called
kpt
I
wouldn't
call
that
get
us
because,
as
soon
as
you
start,
having
interactions
back
and
forth
between
different
sources
back
to
get
it's
not
actually
something.
You
can
look
at
and
say
this
is
what
the
desired
state
is.
B
You
know
what
would
be
kind
of
cool
is
if
I,
you
know
we'll
talk
to
the
GitHub
PMS
but
like
if
they
relay
the
application.
State
back
like
a
status
field
in
the
repo
like
okay,
here's
the
desired
State.
Now
there's
a
status,
here's
the
actual
current
state
like
it
doesn't
come
all
the
way
back
to
git
right
now,.
E
To
a
few
organizations
D,
it
was
like
prying
from
the
cold
dead
hands
of
developers,
the
ability
to
know
that
something
worked
based
on
their
deployment
pipeline
like
if
their
deployment
paper
went,
green
and
somebody's
like
oh,
the
most
recent
commit
broke,
something
they'd
be
like
no,
it
didn't
green,
green
Pipeline
and
so
in
multiple
cases,
I've
had
to
introduce
a
validation
at
the
end
of
a
pipeline
that
just
like
checks
for
the
state
to
be
healthy
for
x,
amount
of
time,
and
then
it
times
out
and
says
it's
not
healthy,
and
it's
not
the
perfect
thing,
and
it's
really
just
trying
to
give
feedback
back
to
the
devs
of
like.
E
A
Necessarily
because,
for
instance,
if
you're
again,
a
tool
specific
but
flux
have
the
notification
controller,
so
you
can
set
that
up
to
whenever
something
happens,
the
reconstrators
happen,
it'll
actually
CPU
out
that
information
into
slack
or
you.
E
A
Teams
or
Discord,
whatever,
whatever
you
do,
your
work
and
at
the
same
time
like
giving
observability
tools,
the
developers
doesn't
necessarily
break
the
operational
model
so
giving
them
a
place
to
actually
check
that
stock
is
working,
isn't
necessarily
A
Bad
Thing
and
you
could
potentially
do
a
web
hook
interaction.
So
when
you
get
the
stuff
you
can
report
back,
for
instance,
look.
B
B
About
was
your
commit
good,
yes
and
that's,
so
they
do
kind
of
in
the
end,
get
the
check
mark
back
yeah.
This
is
an
interesting
point.
I
think
that
I
don't
know
I
just
this
came
up
on
another
thing.
That
I
was
thinking
about
internally
recently,
where
people
were
concerned
about
building
and
deploying,
but
not
observing
and
so
yeah.
Thank.
A
You,
but
you
know
our
our
goal
as
a
UI
for
this,
so
you
can
look
at
your
deployment
there.
Flux
doesn't
per
se,
but
flux
are
also
doing
a
UI
perspective
and
there's
other
tools
to
look
at
your
deployments.
A
You
know
from
from
afar
the
the
thing
is
just
a
developer
shouldn't
be
able
to
just
jump
into
a
cluster
with
admin
access
and
do
Cube
CTL
apply
like
that's
the
idea
like,
and
it
solves
so
many
things
when
it
comes
to
secret
management
to
solve
so
many
things
about
giving
access
to
certain
aspects
of
the
platform.
It's
also
anything
around
that,
but
that
doesn't
mean
that
people
aren't
supposed
to
be
able
to
look
at
the
deployment
to
see
that
it
works.
It's
not
like,
like
you're,
deploying
it
blind
and
then
all
right
cool.
A
Let's
hope
it
works
and
just
move
on
with
your
life,
but
but
the
deployment
part
of
it
should
just
be
out
of
everyone's
house.
B
Okay,
there's
something
there
about
verification:
make
sure
that
that
we're
capturing
that
at
least
in
like
a
line
or
something
verifying,
you
know
a
deployment
or
something
okay,
we're
at
11
o'clock.
I
left
this
pretty
open.
So
thanks
for
the
the
Deep
dive
into
git
Ops,
like
I,
said
at
the
beginning,
I'm
work
on
getting
the
sections
in
feel
free
to
comment
and
the
issue,
the
doc,
whatever
it
is,
and
yeah
we'll
continue.
Conversation
offline,
oh
in
two
weeks,
I
think
we
should
cancel
it.
A
D
E
B
I
put
in
the
in
the
in
the
notes
here
and
I
did
open.
I
commented
on
the
original
issue
this
morning.
The
next
things
which
is
basically
just
to
copy
here.
I'll,
send
you
this.
This
note
I'll
paste
it
in
here
basically
just
to
copy
some
of
the
existing
papers,
structures
which
basically
seem
to
break
it
down
into
like
a
few
sections
and
then
have
some
sort
of
automation
that
merges
it
together,
maybe
publishes
a
PDF,
so
I
want
to
just
figure
out
the
framework
for
that.
A
I
seem
to
remember
Thomas
talking
about
the
operator
white
paper
and
that
there's
someone
in
the
cncf
who
pulls
down
the
information
and
creates
that
PDF
Like
That
official
looking
one
not
sure
if
it's
like
a
fully
automated
thing
or
not.
But
someone.
B
E
B
C
B
Okay,
yeah
I
basically
am
looking
to
create
a
proposal
you
know
influenced
by
these
existing
papers
or
any
other.
You
know
specs
that
people
put
on
GitHub
and
auto-generate
yeah
I
I
mean
if
somebody
wants
to
you,
know
kind
of
research.
These
and
and
put
the
framework
in.
That's
a
PR,
for
you
know
section
one
section,
two
section:
three
section:
four
with
titles
and
here's
the
merge
document,
yeah
I'll,
start
a
thread
with
you.
In
the
background
we
could
talk
about
it.