►
From YouTube: CNCF SIG App Delivery 2021-02-17
Description
CNCF SIG App Delivery 2021-02-17
A
A
A
C
B
Could
be
I'm
not?
Let
me
just
check
like.
C
Okay,
then,
if
I
turn
up
my
volume,
then
everything
is
my
story.
C
D
C
C
E
C
C
Okay,
let's
kick
it
off
with
the
operator
working
group.
I
assume
it's
going
to
be
a
quick
update
from
your
side
because
you're
in
between
a
lot
of
work
but
I'll
pass
it
over
to
either
thomas
or
omar,
to
give
us
an
update.
E
Yes,
currently,
there's
not
much
nothing,
nothing,
really
new
in
the
operator
working
group.
Currently,
we
are
trying
we
are
making
progress.
We
are
writing
some,
some
sections
chapters
and
so
on
getting
feedback.
E
C
So
how
successful
was
the
last
call
for
contributions?
I
followed
some
of
it
on
slack
and
twitter
and
almost
felt
that
people
said.
I
don't
want
to
contribute
to
like
that
amount
of
work
that
you're
already
doing,
but
I
have
this
other
tool
which
I'd
like
you
to
mention
as
well,
so
like
like.
Overall,
how
well
did
this
go
and
I
guess
there
are
other
specific
areas
where
you're
looking
for
feedback.
I
think
that's,
usually
the
other
confusion
and
confusion
that
I
notice
from
people
saying:
okay,
yeah
contributing.
E
It
would
be
especially
it
would
be
cool
if
someone
could
provide
best
practices
and
so
on
for
operators,
because
I
think
the
whole
world
talks
about
best
practices
of
operators,
but
no,
but
nobody
writes
about
it
and
exactly
this
in
this
area,
it
would
be
cool
and
also
if
someone
would
like
to
add
some
some
products
frameworks
for
operators.
It
would
also
be
cool
if
they
would
be
mentioned,
especially
for
what
are
they
meant
for
and
how
they
can
help
customers.
A
A
E
No,
it's
also,
it
also
broke
out
for
me.
C
E
We
did
not
screen
changed
something
since
the
last
meeting,
but
there
are
a
lot
of
issues
regarding
of
tasks.
We
we
need
contributors
for,
and
what
I
also
want
to
mention
is
we
got
some
new
contributions
for
us
from
some
frameworks.
This
cube
builder
or
I
think
cop,
and
they
were
also
very,
very
helpful
at
the
moment.
A
Yeah
my
internet
got,
I
continued
to
talk
and
then
I
realized
everything
is
stuck.
So
I
just
wanted
to
say
that
if
someone
wanted
to
contribute
in
the
past
and
the
google
doc
was
a
hard
place
to
do
that,
we
now
we
feel
that
the
new
github
issues
way
is
better
and
we
think
it's
much
easier
to
contribute.
We
find
ourselves
easier.
So
if
someone
thought
about
it
in
the
past,
please
come
forward
and
think
about
it
in
the
present.
Also.
C
Yeah,
I
think,
the
more
concrete
you
make
the
request
for
input.
I
think
the
easier
it
is
to
to
get
it.
I
mean
just
jumping
ahead
a
bit
of
the
the
contributions
we
had
on
the
on
on
the
potato
head
project
I
just
put
in
an
issue
there
that
literally
reads
update
the
flux
example
to
flux
to,
and
actually
somebody
really
jumped
in
here
and
and
did
it.
C
So
I
think
that,
they're
being
like
very
specific
on
on
what
you
want
so
ellison
jumped
in
she
updated
the
example.
I
think
that
being
more
specific,
the
more
it
helps
and
like
I
thought
I
was
really
write
it
for
customize
or
do
it
for
this
and
that
so
that's
kind
of
my
learning
there,
it's
the
more
specific
you
are,
the
more
people
are
likely
taking
it
on,
of
course,
yeah.
I
think
that's
what
that's
why
I
was
asking.
Where
exactly
do
you
need
help,
because
I
think
that's
where
you
most
likely
will.
D
A
Yeah
have
issues
open
for
every
section
in
the
dock
that
still
need
content
in
it.
It
might
be
that
issue
I'll,
we'll
pass
another
run
on
the
issues
to
verify
that
it's
state
exactly
what
the
content
we
exactly.
A
We
expect
to
be
there,
but
we
have
project
and
we
have
issues
so
people
just
can't
say
I'm
working
on
that
issue.
We
basically
need
content
and
that's
hard
to
to
ask
for
people.
C
E
Yes,
we
could
try
to
provide
more
more
specific
issues,
so
not
only
write,
write
some
sections
about
frameworks,
but
for
the
specific
framework
and
so
on,
because
I
think
then
the
and
the
communities
also
feel
mentioned.
C
You
usually
they
they,
they
quickly
jump
in
so
also
from
from
what
we
had
on
around
potato
head.
When
I
was
asking
for
a
helmet
example,
people
from
help
jumping
in
or
cloud
native
application,
bundles
the
same
thing
happen.
So
the
more
specifically
you
ask
the
more
likely
it
is.
You
get
people
to
jump
in
and
they're,
usually
very
open
to
help,
and
that's
just.
C
Yep?
Okay,
okay,
next
topic
before
we
jump
to
giblet
and
a
one
chart
potato
head
update,
so
the
potato
head
project?
That's
a
small,
tiny
project
that
we
started
for
initially
the
last
kubecon
session,
which
we're
doing
again
newer
contributions.
It
now
supports
prometheus.
We
know
the
thermistor
support
in
there.
The
goal
is
also
have
open,
telemetry
support
in
there
and
we
now
have
flux
to
support
as
well.
So
we
see
that
people
are
continuously
contributing
to
to
the
project.
C
Right
now,
I
think
the
biggest
challenge
is
that,
as
this
was
never
planned
to
be
a
project,
it's
really
about
finding
people
who
also
test
and
validate
examples.
So,
the
last
time
we
had
this
discussion,
what
what
kind
of
support
would
be
needed
like
if
somebody
has
a
new
example,
just
trying
out
different
examples
with
different
tools
is
definitely
helpful.
C
I
usually
trust
people
who
build
tools,
but
their
examples
are
going
to
work.
But
for
me
it's
like
okay,
I'm
taking
the
example
right
now
and
then
playing
around
with
it
and
well.
It
starts
to
get
easier,
and
it
motivates
me
even
more
that
all
the
examples
keep
around
being
running
on
like
a
local
kubernetes
environment.
C
C
Maybe
I
come
up
with
an
idea
on
how
to
solve
this
problem
and
the
other
outstanding
topic
there,
where
I
again
are
not
planning
to
make
progress,
is
to
split
it
up
into
multiple
services.
C
I
think
that's
where
the
fund
really
starts
and
where
we
can
add
more
more
in
there
as
well.
I
just,
I
think
I
just
need
to
put
it
into
an
issue
and
get
get
get
the
first
version
done.
The
good
thing
is
that
now
everything
builds
automatically
anyways.
All
the
images
are
created
automatically.
That
makes
a
lot
of
the
updating,
simpler
and
again
for
the
actual
web
service
that
we
will
eventually
need.
C
D
C
Where
we
can,
then
dynamically
assemble
the
potato
heads
and
just
getting
it
done.
Media
gambling
and
the
other
services
can
be
done
by
somebody
who
has
not
that
much.
You
are
my
knowledge,
but
they
do
have
itself
my
video
yeah
and
it
actually
also
as
soon
as
we
have
a
more
stable,
maintainer
structures.
So
if
we
find
people
who
really
have
interest
in
getting
this
demo
application
or
developing
the
demo
application
further
the
ideas
and
also
to
potentially
just
submit
it
as
a
cncf
sandbox
project,
so
they
just
make
it.
C
It
has
a
quite
a
number
of
contribut
contributors.
But
from
the
maintainer
perspective,
I
think
that's
where
it
would
be
great
to
have
eventually
other
people
stepping
up
or
finding
enough
interest
there
that
it's
not
yet
submitted.
C
But
I
think
it
would
be
a
good
candidate
for
this
type
of
like
sandbox
project,
yes
and
with
this
I'd
actually
like
to
pass
over
and
because
this
is
actually
the
perfect
transition
to
last,
because
that's
how
we
got
to
know
each
other
because
he
contributed
actually
to
potato
head
and
put
a
gimlet
and
example
in
there,
and
that's
actually
great
what
he's
doing
so.
Please
join
us
here
and
yeah
present
what
you're
doing
there,
because
I
think
it's
like
super
interesting
for
people.
C
B
Sure,
thanks
for
the
invite
really
so
yeah,
I
just
found
the
the
potato
head
app
and
I
used
it
in
one
of
my
blog
posts
and
then
I
made
a
contribution
and
I
think
that's
that's
how
we
met,
and
I
don't
know
how
much
time
I
have.
I
try
to
keep
it
short
and
maybe
I
started
one
chart
because
it's
a
simpler
concept
and
then
just
get
into
the
basics
of
what
gimlet
is
yeah.
I
think,
if
you
keep
it
to
like
20
minutes.
B
Absolutely
so
I'm
I'm
going
to
finish
in
10,
hopefully,
and
then
we
just
can
talk
all
right,
I'm
going
to
share
my
screen.
I
hope
you
will
see
it
and
yeah,
so
I'm
laszlo
vogers.
I
am
running
my
solo,
consulting
firm
cloud
native
stuff
and
in
besides
that
I'm
also
putting
a
lot
of
time
and
effort
into
product
development.
So
right
now
it's
a
consulting
firm
with
some
product
work.
I
like
to
flip
that
around.
B
If
everything
works
out
as
I
as
I'd
like
it
to
so,
there
is
this
thing
called
one
chart
which
is
a
helm
chart.
Basically
the
title
says
it
all
or
tries
to
to
sell
it
like
a
one
chart
to
rule
them
all.
Basically,
it's
a
hum
chart
for
your
application
deployment
because
you
can
find
a
chart
for
all
the
infrastructure
components
out
there,
but
when
you
start
developing
your
own
projects,
you
know
it's,
it's
not
easy
to
just
copy
and
paste
your
yaml
snippets
together.
B
So
over
time
I
I
started
this
chart
and
whenever
I
came
across
when
you
come
across
a
new
use
case
like
I
need
to
set
an
image,
that's
a
basic
use
case
or,
but
when
I
need
to
set
an
ingress,
I
just
extend
this
chart,
and
hopefully
with
like
20
or
30
use
cases
I
can
cover
the
typical
application.
Deployment
needs
just
just
a
quick
intro.
So
by
default
it,
if
you
use
one
chart
one
chart
and
you
set
the
image
and
the
version
it
spits
out.
B
You
know
a
deployment
and
the
service.
So
it's
it's
almost
like
the
the
helm
starter
chart
and
later
on,
if
you
add
more
stuff
in
it
like
environment
variables,
it's
one
step
more
convenient
way
to
write
this
this
this
values
file
than
writing
the
kubernetes
manifest.
B
You
have
a
config
map
created
out
of
this
values,
file
right
here,
the
values
I
just
provided
and
this
config
map
is
referenced
and
everything
from
in
it
is
pulled
in,
and
you
know,
if
you
want
to
specify
in
an
ingress
here,
is
a
quick
way
to
do
that,
I'm
always
in
trouble
finding
the
identitation
for
the
for
the
ingress
snippets.
So
I'm
like
making
like
five
mistakes
before
I
get
it
right.
So
I
just
put
this
into
this.
B
This
chart
basic
things
like
or
not
basic
things,
but
for
high
availability.
If
replicas
is
greater
than
two
I
just
by
default,
put
data.
There
are
pod
distribution
budgets
and
some
anti-affinity
rules.
So
it's
basically,
if
you
get
started,
you
have
an
image
you
want
to
deploy
it
quickly.
B
That's
a
very
convenient
way
to
do
that,
and
I
found
myself
being
very
happy
when,
when
I'm
at
this
stage-
and
I
want
to
deploy
something-
it's
speeded
up-
my
workflow
quite
a
few
times
also
there
is
there-
is
like
a
chrome
job
version
of
it
like
if
you
want
to
just
run
a
cron
job,
finding
that
email
on
the
kubernetes,
docs,
page
and
assembling
that
snippet
is
yeah
more
time
than
I
would
I
would
like
to
use
for
it
and,
as
as
things
progress,
I
will
just
add
more
use
cases
here
and
it's
on
github,
so
you
can
also
add
feature
requests
or
pull
requests.
B
So
this
is
a
very
simple
idea.
Maybe
you
have
questions
to
it
already?
Maybe
not.
I
can
proceed
on
how
I
I
use
this
little
component
in
furthering
my
work.
C
I
actually
have
to
have
a
question
because,
okay,
what
really
piqued
my
interest
is
because
I
started
to
see
a
lot
of
people
doing
this
right
now,
like
they
don't
keep
writing
all
of
their
helm,
charts.
They
invest
a
lot
in
templating,
actually
a
a
company
who
who
I'm
working
closely
with
they
said
well.
Also,
they
don't
want
to
teach
everybody
how
to
do
kubernetes
so
their
their
chart
contained.
They
also
have
like
a
reference
template,
charts
and
people
just
put
put
in
the
container
and
they
kept
extending
it.
C
They
kept
adding
like
service
mesh
configurations.
They
kept
adding
opa
rules
and
building
more
and
more
and
more
so
eventually,
they
know
when
somebody
deploys
something
and
they
know
exactly
what
they're
getting.
So.
I
think
the
first
question
is
how
extensive
what
modular
is
this
so
that
I
could
add,
like
my
open
configuration,
my
networking
configuration
in
there
and
it
might
start
with
the
first
question
because
then
the
second
one
would
be
okay.
How
much
can
I
also
create
my
templates,
because
I
was
just
saying
that
they
have
like
an
api
template.
B
Okay,
well,
so
that's
the
other
side
of
the
story.
I
so
I
had
this
template
in
every
projects
I
had
and
whenever
they
have
a
new
need,
whether
they
want
to
mount
an
azure
storage
bucket,
or
they
want
to
just
exclude
the
service
from
from
link
rd
service
mesh.
I
just
have
these
simple
flags
given
to
developers
so
instead
of
passing
wiki
items
around
and
ymo
snippets,
I
just
tell
them
that
hey
in
the
latest
version,
there
is
this
support,
so
you
can
use
that.
B
So,
yes,
I
think
this
chart
could
be
used,
as
maybe
a
starting
point
for
an
internal
chart.
So
obviously
this
chart
will
not
cover
all
the
use
cases
of
everybody,
because
then
it
will
be
an
unmaintainable
spaghetti
like
helm,
charts,
get
often
this
criticism,
so
I
think
I
will
just
stop
adding.
Let's
say
after
when
I
reach
30
use
cases
and
that
should
cover
like
a
basic
opa
rules.
B
What's
that
open
policy,
agent
and
and
so
on,
so
so
I'd
like
to
cover
the
basics
and
from
then
on,
I
think
I
have
two
recommendations
for
people.
One
is
to
to
fork
it,
which
I
have
a
private
fork
of
this
one
in
a
project
I
started
recently
and
the
second
one.
If,
if
home
becomes
too
annoying
for
you,
you
can
always
run
helm,
template
on
your
latest
chart
and
you
can
just
have
the
yaml
and
you
can
take
it
wherever
you
like
it
to
your
own
templating
solution.
A
B
A
But
yeah
it's
a
great
starting
point
to
tell
people
best
use
cases
around
things
around
charts
around
how
to
do
it
and
I
think
yeah.
It's
it's
great.
B
F
F
F
I
think
this
is
probably
like,
philosophically
this
is
probably
the
same
thing:
what
you're
doing,
plus
the
whole
build
image
step
and
since
you're
both
working
on
it,
I'm
probably
going
to
do
some
self-criticism
on
it,
because
I
would
precise
the
same
thing
that
we
are
doing
also
on
it,
which
is
while
it's
a
great
thing
that
we
provide
these
knobs.
I
think
the
challenge
which
I
always
face-
and
you
may
also
face
which
I'd
like
to
share
with,
is
that.
F
Sometimes
we
try
to
override
the
different
workload
spec
items
on
top
of
hem
chart
and
it
becomes
a
challenge
about
where
to
stop
that,
like,
for
example,
like
replicas,
it's
there
inside
the
deployment
spec,
but
it's
also
there
in
the
hem
chart
values
yammer.
I
think
the
challenge
is
to
figure
out
what
is
that
good
subset
that
we
need
to
expose
and
what
not
to,
and
I
went
through
the
docs.
I
think
you've
done
a
pretty
good
job
with
it.
B
Thank
you,
yeah.
It's
going
to
be
a
balancing
exercise
and
I
think,
even
at
one
company
like
a
a
common
shared
chart
will
be
good
for
95
percent
of
all
the
teams,
but
there
will
be
always
a
unique
team
who
just
want
to
do
their
own
thing
and
that's
fine.
They
should
just
then
maintain
their
fork.
I
guess
right
right.
I
agree.
B
All
right
so
so
this
is
actually
a
building
block
where
people
who
are
new
to
kubernetes
or
just
want
to
move
fast
can
can
use-
and
I
I
built
some
other
tooling,
which
is
building
on
this
building
on
helm
charts
in
general.
But
I
try
to
promote
this.
This
one
chart
approach
which
is
gimlet,
which
is
like
a
command
line
tool
at
the
moment,
and
it
is
it's
basically
github,
stooling
and
tooling
around
kubernetes
to
get
started.
B
B
I
I
think
it's
a
good
ring
to
it.
It's
a
bit
arcane.
I
know
it's
the
drink,
it's
not
about
the
drink,
so
I
am
gimlet
is
also
like
a
little
carpentry
tool
like
a
little
drill
like
a
hand,
drill
and
that's
what
I
found
like
a
great
analogy
like
I'm
building
a
tool
and
that's
a
nice
little
handy
tool.
B
So
that's
sort
of
the
analogy
I
would
like
to
to
get
across,
but
I
think
everybody
thinks
about
the
drink
and
I
just
accepted
it
by
now,
and
I
like
it
for
the
the
ring
to
it
like
gimlet.
I
I
just
like
how
it
sounds.
B
All
right,
then,
I
I
just
get
into
kimlat
just
very
shortly,
because
I
think
it's
larger
thing
or
it
eventually
it
will
be
larger
than
just
a
10
minute
demo,
but
I
just
get
started.
B
So
so
helm
charts,
so
I
I
got
a
little
bit
bit
overboard
with
with
helm,
charts
and
helm.
Charts
has
a
values,
json
schema
file
and
and
based
on
that,
I
made
a
little
tool
inside
the
gimbal.cli.
B
You
may
have
seen
this
already,
but
so,
if
I
type
gimlet
chart
configure
one
chart
one
chart,
it
actually
opens
the
ui,
and
I
generate
this
ui
based
on
the
values.
Schema
file,
values,
json
schema.
So
if
people
are
again
new
to
kubernetes,
they
can
just
come
here
and
have
a
ui
on
their
laptops
set.
Some
readiness
probes
change
the
path
to
healthy
z.
B
Maybe
if
they
are
savvy
enough,
they
can
delay
the
health
checks
and
basically,
if
they
close
the
browser,
then
they
should
have
the
values
file
printed
on
their
screen.
So
that's
that's.
Basically
the
values
five
for
one
chart
and
if
I
just
go
one
step
further,
if
I
pipe
this
into
helm,
template
one
chart
one
chart
and
then
give
it
as
a
standard
input
again.
If
I
just
do
some
changes
this
time,
it's
going
to
be
my
war.
B
My
value
and
again,
if
I
close
this
screen,
then
you
know
the
values
file
was
piped
into
the
the
one
chart
and
the
config
map
has
this
value,
so
myvar
myvalue,
so
sort
of
there
is
like
a
little
workflow.
If
people
want
to
just
work
with
the
helm
values
files
they
can,
they
can
use
this.
I
think
it's
even
able
to
get
a
saved
values
file.
So
if
I
would
have
saved
this
values
file,
I
could
have
feed
into
this
workflow
again
and
I
can
generate
manifests
like
this
and
with
gimlet.
B
I
am
a
huge
fan
of
git
ups.
I
think
everybody
is
these
days,
but
if
you
have
a
helm
template,
I
also
wrote
another
little
tool,
which
is
gimlet
github's
right
and
then
it
basically
writes
into
a
local
copy
of
a
github's
repository
following
some
conventions.
B
So
if
you,
if
I
maybe
I
I've
just
run
this
example
shortly
just
let
me
just
look
in
into
this
git
ups
repo.
I
have
here
with
the
folder
structure,
so
how
about
the
environment
should
be
maybe
production
the
app.
B
B
I
I
don't
some
something
got
misinterpreted
here,
so
so
let
me
just
break
this
up.
Okay,
so
let
me
just
write
the
manifest
to
to
manifest.yml,
so
this
configuration
with
replicas
10.
B
Close,
oh
maybe
I
have
some
state
issues
here,
one
more
time:
10
close
it
good.
So
now
I
have
the
manifests
file
with
replicas
for
and
if
I
gimlet
keydops
write
the
manifest
file
to.
B
B
So
that's
basically
game.github's
right.
It's
a
little
handy
tool
that
you
can
use
from
ci,
so
that's
sort
of
the
the
workflow
idea
behind
it
that
some
people
likes
to
write
their
github's
repo
by
hand
not
having,
for
example,
flux
how
to
update
the
image.
So
in
this
case
you
know,
code
change
comes
in.
There
is
a
ci
testing
process,
artifact
so
on,
and
then
you
write
stuff
to
the
github
repo
from
where
the
githubs
controller
is
pulling
down
stuff.
B
So
this
little
cli
gimlet
cli,
is
able
to
give
you
a
set
of
conventions
and
a
few
tools,
like
writing,
manifest
to
this
structure
deleting
and
also
bootstrapping
the
the
githubs
cycle.
B
Also
it
it
has
like
a
gimlet
seal
command
to
because
one
chart
has
support
for
sealed
secrets,
and
you
know,
ceiling.
Sealed
secrets
is
kind
of
a
pain
in
the.
D
B
Meaning
that
you
have
to
like
ceiling
keys
one
by
one
and
so
on
so
there's
a
little
convenience
feature,
and
just
the
last
thing,
I'd
like
to
add
that
all
this
playing
with
values
files
is
nice
with
gimlet.
I
also
introduced
a
manifest
file
structure,
which
is
very
similar
to
all
the
helm,
release.
Crds,
you
have
seen
that
are
out
there.
Flux,
argo
cd
everywhere.
B
I
also
have
my
own,
which
is
the
only
difference,
is
that
you
should
keep
this
in
with
your
application
source
code,
so
this
is
for
developers.
This
is
like
a
split
workflow,
so
developers
will
be
able
to
store
their
whole
configuration
in
their
source
code
repo.
This
is
the
values
file
file
part.
This
is
the
chart
reference,
and
this
is
some
additional
meta.
Information
and
gimlet
has
some
tools
to
process
these
files
render
the
manifests,
write
them
them
into
the
right
place.
B
So
that's
where
gimlet
is
today:
that's
a
cli
and
mostly
helping
people
who
do
stuff
from
their
ci
or
from
their
laptop
just
to
play
around
with
git
ups
and
right
now,
I'm
extending
it
with
the
server
side
component,
which
is
basically
detaching
everything
from
ci.
So
it's
not
ci
from
where
you
write
stuff
anymore
to
the
github's
repository.
B
Instead,
I
introduce
a
server-side
component
which
will
able
to
support
like
policy-based,
deploys
like
everything
from
master
should
go
to
production
or
some
on-demand
stuff,
rollbacks
and
so
on,
without
replaying
the
the
ci
procedure
and
perhaps
introducing
more
access
control
as
well.
So
that's
just
the
future
stuff.
I
just
put
the
concept
down
there
in
the
blog
post,
so
that
was
that
it
was
quite
a
lot
of
things.
I
think
I
think
for
now.
B
What
I
wanted
to
convey
is
that
one
chart
is
a
very
nice
foundational,
building
block
or
charts
in
that
sense,
which
I
I
built
more
stuff
on
top
how
to
generate,
manifests
out
of
it,
how
to
store
them
effectively,
and
then
I
also
try
to
give
people
more
workflows.
So
that's
is
going
to
be
gimlet.
B
So,
that's
that,
thanks
for
listening.
C
I
think
what
was
confusing
me
a
bit
because
you
called
it
a
githubs
tool,
so
I
was
assuming
that
there
is
a
component
that
actually
does
the
deployment
like
you
would
have
like
in
influx
or
see
in
the
in
the
argo
cd
type
of
environment.
I
mean
don't
get
me
wrong.
I
guess
already
a
lot
of
components
out
there
that
can
do
exactly
this
and
wine
west
is
something
that
that
that
already
exists.
C
I
think
that's
just
maybe
a
a
comment
here.
So
when
you
told
me
if
the
github's
tool,
I
was
expecting
something
different
than
what
it
actually
is,
and
so
I
don't
know
how
the
other
people
think
about
it,
but
it
was
just.
I
think
that
the
naming
might
be
might
be
a
bit
bit
misleading
here,
but
what
the
tool
is
doing.
I
think
is
great
like
helping
to
manage
those
components
and
so
forth.
I
think
it's.
It's
super
helpful
and
useful,
and
I
think
I
thought
we
had
other
people
here
as
well.
C
They
can
see
the
values
so
I'd
like
to
get
other
people's
touch
on
this.
We
used
to
work
a
lot
and
google
need
this
deployment
and
also
have
to
make
them
available
for
other
people.
I
know
that
thomas
does,
because
we're
probably
working
closely
together
so
I'll
make
it
up
and
other
people
now
for
questions.
B
Yeah,
maybe
I
just
just
a
quick
reaction,
I
think
it's
a
fair,
fair,
fair
point.
I
should
really
find
what
am
I
really
building?
Is
it
a
release
manager?
Is
it
some
other
thing?
Maybe
you
guys
have
some
ideas?
How
should
I
name
it?
But
true,
I
don't
have
the
actual
git
ops
control
loop,
that
synchronizes
stuff
between
kit
and
the
cluster.
I
use
flux
for
that
because
it
just
does
a
great
job.
D
Yeah,
I
I
don't
know
how
you
would
describe
it
if
you
really
don't
want
to
use
the
word
get
ops,
but
if
you
I,
I
can't
imagine
other
than
a
git
ops,
repo
editor,
which
is
really
what
you're
doing,
which
is
the
left-hand
side
of
a
full,
get
up.
Cicd
workflow,
so
you
know
I.
I
always
find
it
tricky
when
people
say
it's
not
git
ops
unless
there's
a
deploy
step.
Okay!
Well,
that's
probably
true.
If
you
don't
deploy
something
you're,
not
really
doing
it
up,
you're
just
editing
static
files
somewhere.
D
So
I
think
the
the
interesting
question
to
me
is
when
you
see
this
kind
of
stuff,
what
is
the
actual
workflow
for
validating
the
changes
before
they
actually
get
deployed
now,
you're
slamming
into
your
git
repo,
you
better
be
able
to
undo
your
changes
and
do
all
sorts
of
other
things,
because
right
now,
it's
all
the
tool
looks
like
it's
just
helping
you
edit
quickly.
D
So
if
I
had
infinite
speed
fingers,
I
could
do
that
manually
and
I'd
still
have
problems.
When
I
pushed
to
my
repo
with
continuous
deployment,
because
I
didn't
validate
anything
so
the
whole
I'm
interested
in
these
tools
because
they
help
you
do
things
and
not
make
errors,
but
then
you
still
have
to
you
still
have
to
do
them.
D
I
would
say
in
flight
actively,
so
you
have
to
see
what
happens
when
they
fail
deploy.
Will
these
tools
be
used
to
undo
your
things
undo,
your
good
deeds
in
your
repos?
Those
kinds
of
things
are
interesting
to
me
because
unless
you
actually
have
the
edit
part,
the
validation
part
and
then
the
application
which
could
fail
and
then
you
know
you
have
to
roll
back
and
do
all
sorts
of
other
stuff,
you're
you're
solving
one
one
piece
of
the
problem.
I
guess
give
me
my
comments.
B
D
When,
once
once
you
do
that,
you
then
start
to
grow.
If
you
were
growing
this
kind
of
capability,
you
would
say
edit,
then
you
need
a
validate
step,
which
is
the
shift
left
of
the
the
linter
that
you
would
run
on
your
manifest
before
you.
Let
flux
or
argo
cd
take
it
and
deploy
it,
because
if
you
make
a
you
know,.
F
D
You
make
another
if
you're
doing
this
by
hand,
you
make
a
typo
your
replicas
to
4
million
right
when
they
arrive
at
your
cluster
perfectly
good
integer
arrive
at
your
cluster.
They
won't
there's
not
enough
resources
to
do
that.
Many
so
it'll
just
sit
there
in
pending
state.
Those
kinds
of
things
should
be
caught
long
before
you
actually
push
to
the
repo.
D
So
if
you
have
tools
to
edit,
you
should
also
have
tools
that
validate,
which
is
part
of
your
ci,
for
forget
repos,
for
get
ops,
repos
and
then
and
then
potentially
even
dynamic
validation.
So
if
you
know
where
it's
going,
then
you'd
have
to
talk
to
your
deployment
facility
to
to
pull
the
rules
like
admissions
control
rules
or
policy
rules
that
you
may
or
may
not
be
violating
so
so
you're
at
the
beginning
of
a
of
a
pretty
big
piece
of
work.
D
Where
you
can
you
know
you
you
just
don't
want
you
want
edit
the
added
capabilities
to
ensure
that
the
structure?
Doesn't
you
know
you?
Don't
you
don't
mess
up
your
structure
because
you're
not
going
to
do
it
manually
you
just
don't
let
someone
go
in
and
hammer
the
yaml
you
if
you
go
through
tools,
that's
how
you
can
sort
of
simplify
that
and
and
then
you
can
even
have
logging
capabilities,
so
you
could
keep
track
of.
Who
did
it
and
what
did
it
like?
You
know
you
could
grow
this
to
be
infinitely
capable.
D
So
I
don't
know
where
you
want
to
take
it,
but
that's
sort
of
it's
an
interesting.
You
know
a
lot
of
these
and
and
yes
who
I
don't
know
who
said
it
earlier,
there's
a
lot
of
these
tools
as
well.
So
people
write
they
start,
they
get
excited.
D
C
Yeah,
I
think
it's
a
good
point.
I
think
calling
it
an
editor
might
be
good
as
well.
I
would
like
the
validation
part,
because
that
very
often
hits
you
like
at
least
having
the
ability
to
do
a
dry
run
and
things
and
there's
like
other
nice
things
that
I
I'd
see
that
that
were
what
were
we
usually
struggling
is
okay.
C
I
want
to
have
this
for
another
environment
like
I
want
to
clone
an
environment
just
build
it,
but
I
want
to
modify
just
a
couple
of
things
like
on
a
base
reaper
and
maybe
something
else,
depending
on
how
close
you
want
to
get
to
get
when
you
at
least
commit
something
to
get
almost
like.
Having
I
mean
get
per
se
is
version
management.
C
C
You'd
like
go
back
from
version,
one
two
to
version
two:
it's
it's
built
for
source
code
and
if
you
look
at
all
of
the
the
the
the
providers
out
there,
you
have
like
what
is
it.
They're
called
merge,
requests
for
pull
requests,
and
then
you
have
like
bigger
change
sets.
C
D
C
Yeah
at
some
point,
so
we
keep.
We
see
a
lot
of
people
that
keep
death
open
more,
that's
so
that
people
can
push
and
push
in
there
and
it's
it's
okay,
but
the
bigger
repo,
you
might
say:
well,
I'm
taking
like
the
updates
on
this
service
and
I'm
not
taking
the
updates
on
the
other
servers.
Obviously,.
D
D
So
you
have
no
hope
but
to
share
through
that
push
common
push
right.
Okay,
that
that's!
That's!
That's
your
problem,
because
the
normal
way
you
would
do
this
if
you
had
the
resources,
you'd
fork,
your
get
ops,
repo!
You
pointed
at
your
own
environment.
You
push
as
many
dev
configurations
as
you
like,
and
then
you
submit
a
pull
request
with
the
final
one
up
to
your
to
your
to
your
dev
environment.
D
That's
the
shared
one
as
opposed
to
your
personal
one,
but
if
you're
forced
to
share
a
ci
integration,
environment
and
everyone's
slapping
their
changes
on,
but
you
just
want
to
cherry
pick.
Some
you'd
have
to
check
them
all
out
into
a
branch
and
then
send
a
pull
request
from
that
branch
into
your
stage
environment,
where
you're
just
integrating
those
three
and
I
suspect,
cherry
picking.
Those
is
going
to
be
tricky
if
you
have
hundreds.
C
I
mean
it
can
be
done,
but
it's
we
just
see
people
that
sit
in
if
they
go
to
the
like,
really
extreme
approach,
and
they
can't
replicate
environments
for
each
individual
developer
also
for
response
constraints
and
they
also
kind
of
want
to
get
them
to
a
point
where
they
say.
Well,
you
usually
should
not.
Your
deployment
should
not
break
other
people's
deployments
yeah
but
yeah.
I
agree
it's.
I
think
it's
a
matter
of
taste.
I
think
what
we're
all
trying
to
say
here.
I
think
it's
a
great
tool.
C
Yeah,
I
think
it's
also
good,
for
I
think
it's
part
of
the
work
eventually
for
the
github's
working
group,
and
I
really
wanted
to
get
this
here,
because
I
think
it
can
help
a
lot
of
people
do
a
lot
of
things
well,
for
me,
the
number
one
thing
it
does:
it
helps
people
to
easily
get
started
with
bonitas
and
getting
something
deployed
like
this
whole
idea,
which
we
have
of
making
things
simpler.
C
I
think
one
chart
can
be
of
a
great
help
and
also
inlet
can
be
of
a
great
help,
but
you
have
an
either
repo
and
then
take
now
a
tool,
and
that
is
going
there
and
I
also
like
it
one
thing:
that's
you
have
the
small
tools
to
do
one
thing.
Well,
I
can
remember
this
from
this
whole
from
the
whole
web
community.
It's
me,
I
think
our
industry
is
always
evolving
around.
We
build
a
lot
of
small
tools,
so
we
can
plug
together.
C
Then
we
decide.
No,
that's,
not
a
good
idea.
Then
we
built
one
big
tool
and
to
end
it
got
does
it
all,
then
we
realize
no,
that's
not
a
big
idea
reader
and
then
we
go
back
and
forth
right
now
more
in
favor
of
let's,
let's
build
a
couple
of
smaller
tools
and
let
people
pick
and
choose
what
what
they
want,
because
we're
all
in
this
early
learning
phase
and
things
are
revolving
quickly.
C
Okay,
we
have
more
or
less
used
up
the
time
today
and
I
had
already
left.
I
think
we
have
people
still
here
from
also
from
from
argos
video,
if
you
haven't
interacted
with
the
argo
people,
yet
I
would
encourage
you
to
so
reach
out
to
them.
I
mean
it
should
work
with
our
pretty
much
out
of
the
box
and
it
could
even
be
a
way
to
do
it
easier
because
you
have
a
predefined,
git
repo
structure,
which
I
think
is
great
and
yeah.
C
B
Thank
you
thank
you
guys
and
for
the
opportunity,
and
also
for
the
great
feedback.
I
I
had
a
few
so
thank.