►
From YouTube: CNCF Cooperative Delivery WG 2021-11-24
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
A
C
Nils,
I
see
you
have
a
red
hat
hat
but
says
you're
at
microsoft.
A
Yes,
well,
that's
the
fun
of
open
source,
we're
all
partners.
Aren't
we.
C
B
Yeah,
I
I'm
I'm
I'm
considering.
Oh
just
you
just
need
a
beer
to
be
a
little
bit
more,
so
you
know
makes
up
for
the
year.
C
Yeah,
I
didn't
see
what
I
did
there
yeah.
I
kind
of
dropped
a
whole
lot
of
thoughts
about.
I
was
kind
of
hoping
we
could
go
through
well,
we
could
start
in
a
couple
minutes
if
people
want
to
join
but
talk
about
the
survey
and
I
put
in
a
bunch
of
thoughts
like
how
you
know.
C
Maybe
we
can
work
on
that,
but
I
was
hoping
you
could
lead
us
through
that
and
then
I
want
to
talk
about
patterns
for
patterns
and
then
the
last
thing
I
just
kind
of
wanted
to
keep
on
our
radar.
The
whole
infrastructure
resource
model
thing
yeah.
Oh
this
was
going
to
break
that
up
again.
B
Just
so
you
know
the
when
you
update
the
headers
and
stuff
like
that
it,
it
updates
the
what's
called
english
document
outline.
I
guess
that's
what
google
said
so
what
I
did
when
I
set
up
stuff
originally,
I
just
deleted
everything
that
wasn't
the
date
of
the
meeting,
and
now
that
actually
you
know
continues
to
work.
B
So
if,
if
you
want
to
have
this
kind
of,
you
know
outline
for
for
a
meeting,
we
we
should
still,
we
should
have
a
a
template
of
some
sort
at
the
very
end,
so
we
can
just
copy
that
we
need
to
then
delete
the
the
sub
headers
from
that
meeting
overview
thing,
or
else
it's
just
gonna
get
crazy
on
the
side
here.
So.
A
C
I'll
add
in
a
template
one
like
a
next.
A
B
I
I
you
know,
go
back
and
forth
between
office
and
not
so.
First
every
time
I
plug
in
my
laptop
somewhere
new
there's
a
totally
new
setup,
where's
where's
slack
now,
oh
there's
live.
B
Yeah,
I
think
so
there's
some
people
that
we
could
have
you
know
sent
a
ping
to.
But
at
this
point
I
I
think
we're
very
clear
when
the
meeting
was
and
scado
was
on
here,
the
last
meeting
and
helps
a
lot
he
is
offline,
so
he
is
probably
offline.
A
No
well,
people
are
missing,
that's
yeah,
so
we
have
the
notes.
B
Absolutely
all
right,
I
can
well
we
can.
I
guess,
guess
we
just
start,
then
I
so
we
are
recording
these
meetings,
but
I
don't
think
either
me
or
josh
have
any
access
to
getting
the
meetings
out
and
then
publishing
them.
So
I
think
that's
something
we
still
have
some
housekeeping
things
that
needs
to
get
done
when
it
comes
to
access
and
things
like
that.
But
we
have
a
couple
things
here.
I
have
the
the
user
survey,
I
say
same
agenda.
B
I
can
just
start
with
that.
So
the
idea
was
that
I
was
gonna,
get
and
and
set
up
some
questions
that
we
could
use
for
for
the
survey
and
then
obviously,
when
you
know
end
of
the
year,
all
of
a
sudden
there's
a
lot
of
deadlines
that
apparently
needs
to
be
kept.
So,
as
I
haven't
really
had
time
to
do
anything
in
particular,
I
just
have
a
couple
of
questions
and
I
think
we
need
to
talk
a
little
bit.
B
B
Does
your
company
utilize
cloud-native
technology,
but
I
guess
if
it's
sent
out
to
people
in
the
cloud-native
computing
foundation
sphere
and
that's
going
to
be
yes
in,
like
90
of
the
cases,
so
I
guess
that's
a
redundant
thing
to
ask,
but
but
I
what
I
want
to
get
is
what
kind
of
tools
are
people
using,
and
you
know,
deployment
patterns
and
and
things
like
that
to
see
what
people
are
doing
and
then
obviously
get
around
to
the
to
the
you
know,
more
cooperative
mindset
like
if,
if
you
are,
if
you
are
deploying
applications,
are
you
doing?
B
B
Short
list
of
questions
I
have
is
you
know,
what
kind
of
tools
are
you
using
are?
Is
it
limited
only
when
you
know
application
deployment,
or
do
you
also
use
the
same,
or
does
that
differ?
B
What
kind
of
tools
do
you
want
to
look
at
in
the
future
or
and-
and
things
like
what
I
was
thinking
of
is
do
you
say,
do
you
see
a
benefit
of
using
the
same
deployment
method
for
both
infrastructure
and
application
deployment
or
or
development?
I
guess
that's.
Even
that's
three
different
scenarios
where
these
things
come
into
play.
B
Does
anyone
have
any
thoughts
about
that
or
like
what
we
can?
Does
anyone
see
any
any
particular
goals
of
the
user
survey?
They
think
would
be
great
to
consider
actually.
D
Actually,
I
think
the
structure
in
in
the
meeting
notes,
so
that
starts
with
a
goal
and
and
and
an
action
item
trying
to
reach
the
consensus
on
the
goal.
I
think
this.
This
is
a
really
good
point
where
to
start
yeah
I
had
I
had
many
ideas.
I
hope
that
I
can
write
this
down
as
a
document,
but
failed
with
my
schedule
as
usual,
but
but
I
can
share
what
I've
had
in
mind
and
I
think
it
would
be
a
for
you
to
start
a
separate
document
where
we
could
collaborate.
B
D
I
think
this
is
this
is
the
questions,
but
but
I
think
we
need
the
wider
discussion
around
the
goals
and
the
principles
how
we
design
the
survey
so
that
we
know
how
what
we
want
to
ask
and
what
we
will
do
with
the
questions
after
we
have
this.
D
Well,
okay,
for,
for
example,
last
time
you
mentioned
that
you'd
like
to
run
a
regular
survey.
So
if
we
are
running
a
regular
survey,
there
are
two
other
two
things
that
come
to
mind:
either.
We
expect
to
monitor
a
change
in
a
community,
for
example,
to
monitor
how
our
work,
when
this
work
group
working
group
is,
is
it
having
an
impact?
Is?
Is
something
changing?
What
are
the
trends
what's
what's
happening
over
time?
D
For
that
we
need
to
have
some
kind
of
understanding
what
behavior
or
what
tools
or
what
we
are
monitoring.
So
the
that
we
could
you
we
use
the
similar
questions
in
in
recurring
service.
Then,
if
you
think
about
the
state
of
devops
report,
what
what
the
team
behind
it
is
doing,
they
are
with
each
survey.
They
are
studying
a
new
concept.
D
For
example,
what's
what's
the
impact
of
cloud
computing
to
the
organizational
performance?
Probably
we
have
ideas
that
may
be
important
in
cooperative
delivery
as
well,
and
probably
we
we
might
want
to
study
these
ideas.
We
probably
can't
put
everything
into
one
survey.
So
probably
we
want
to
get
an
understanding.
What
are
the
concepts
that
feel
interesting
or
are
common
or
present
in
in
the
target
audience
that.
D
We
want
to
study,
we
can
use
first
survey
to
map
out
some
subjects
and
and
focus
on
on
one
of
these
subjects
in
the
following
survey.
So,
but
but
these
kind
of
things
that
do
to
design
the
survey
this
way
we
we
need
a
bit
deeper
discussion
than
just
just
putting
the
questions
in
in
in
spreadsheet,
so
this.
This
is
why
I
think
it
should
be
a
separate
document
where
we
can
write
down
the
comment
and
and
maybe
have
a
have
a
I
don't
know,
discussion
slack
or
somehow.
D
I
think
the
first
survey
should
should
help
to
map
the
state
of
the
art
to
understand
what
practices
are
common.
Is
there
some
kind
of
relation
to
the
team
size?
Maybe
maybe
the
organizational
size
this?
This
kind
of,
probably
the
principles
in
in
an
organization
where
you
have
just
just
one
development
team
with
that
by
members
is,
is
pretty
different
with
from
from
something
like
microsoft
here,
so
we
don't
want
to
mix
these
results
in
into
one
result
or
one
conclusion.
D
So
so
we
need
to.
We
need
to
somehow
define
how
we
separate
their
audience
or
or
how
we
segment
audience,
and
and
what
are
the
questions
that
help
us
map
the
state
of
the
art,
and
then
we
can
add
a
bit
of
what
what
feels
interesting
for
us
or
what,
where
we
want
to
want
to
get
confirmation
that
this
is
a
problem
with
that
we
should
be
focusing
on.
B
I
yeah
I'm
I'm
I'm
with
you
on
on
that.
The
only
thing
that
I
kind
of
circle
back
into
is
how
do
we
coordinate
this
because
I
just
looked
at
the
tag,
app
delivery
repository
and
you
know
what
has
been
working
in
the
github's
working
group
has
been
having
these
I've
been
using
the
star
discussions
to
kind
of
this
discussion
on
github,
then
to
kind
of
at
least
get
some
idea
of
of
what
we're
going
to
do
in
one
of
these
projects.
B
If,
if
you
like
and
then
and
then
the
people
are
interested
in
in
in
this
particular
subject,
then
would
have
some
sort
of
meeting
where
one
would
discuss
like
where
to
go
from
here
and
and
try
to
get
some
action
items
and
have
actually
some
some
some
real
goals
to
to
to
to
move
by
and
but
but
I
see
that
we
on
the
telegraph
delivery.
There's
there's
you
know,
discussions
aren't
enabled
issues
work,
but
at
the
same
time,
issues
kind
of
just
become.
You
know
we
at
that
point.
D
One
of
my
bit
worried
is
that
the
data
is
already
fragmented
over
over
many
channels
and
looking
at
at
least
five
people
in
in
this
meeting,
I
think
I
think
we
should
should
not
add
to
too
many
complexity.
D
I
think
google
docs
document
that's
linked
in
in
the
meeting
notes
that
can
be
found
there
and
also
we
can
share
it
in
slack
once
we
have
the
initial
data
to
start
the
discussion,
we
can
go
over
the
discussion
on
on
the
next
meeting
and
once
we
feel
that
we
agree
on
what's
there,
maybe
then
it's
time
to
publish
it
to
to
github
for
a
wider
discussion
and
and
where
you
can
have
changes
pulled
in
through
merge
requests
or
these
kind
of
mechanisms.
B
Yeah,
so
does
I
I
I
you
know
well,
I
start
off
right
away,
creating
a
a
google
docs
as
an
idea
and
and
but
would
that
be
kind
of
like
sufficient.
If
we
kind
of
just
have
a
place
where
we
can
start
outlining
some
sort
of,
I
don't
even
know
what
to
call
it.
D
If
you
can
set
up
the
document-
and
I
have
the
access
access
to
this
one,
I
can
take
a
commitment
to
write
the
ideas
I
share
today
there
and
build
some
kind
of
structure
within
within
next
week
and
then
we'll
have
one
week
to
collaborate
on
it
before
we
have
a
next
call.
B
If
not,
then
let
me
know,
let's
see
there,
you
go
and
yeah
yeah
anything
I'll
help
as
much
as
possible.
But
again,
like
we
keep
on
saying
we
have.
Everyone
has
a
lot
of
things
to
do.
A
That's
fine,
that's
totally
understood.
B
Yeah,
but
you
know,
that's,
that's
that's
great
rain
and
I
I
I
really
appreciate
you.
You
know
stepping
up
a
little
there,
because
you
know
I
just
got
as
far
as
starting
to
kind
of
get
some
of
these
questions,
but
obviously,
at
the
same
time
it's
kind
of
hard
to
get
questions.
If
I
don't
know
what
we're
trying
to
figure
out,
that's
enough,
so
so
anything
there.
Getting
that
you
know
that's
set
up
a
little
bit
would
be
would
be
really
really
good
and
we'll
we
can.
B
We
can
start
drafting
in.
In
that
document.
I
have
some
offline
talk
and
obviously,
as
this
is
a
a
bi-weekly
meeting,
you
know
that
can
just
be
in
like
and
general
item
going
forward
and
and
we'll
just
discuss
what
we're
thinking
so
far
and.
D
I
think
we
should,
I
think
we
should
set
some
kind
of
goals
in
terms
of
deadlines
by
what
time
when,
where
we
want
to
be
yeah,
otherwise
you'll
never
get
there.
B
So
if
we
for
the
next
meeting,
because
that's
two
weeks,
we
should
at
least
have
some
sort
of
words
written
down
on
why
we
want
to
do
it
and
what
we
want
to
get
out
of
it,
at
least
in
like
a
broad
sense,
and
then
we
can
discuss
that
in
the
next
meeting
and
see
if
anyone
feel
that
we
need
to
go
in
a
certain
direction
or
not,
and
that
probably
will
work
out.
B
Hopefully,
if
everyone
agrees
on
that,
does
that
sound,
good,
yeah
and
and
obviously
I'll
interlink,
the
the
the
survey
question
spreadsheet
and
and
things
like
that
as
well
just
so,
we
can
work
on
both
fronts.
If
people
want,
if
people
just
you
know,
think
of
obviously
the
things
that
are
getting
into
that
the
the
survey
question
spreadsheet
is
not
set
in
stone.
It's
just
suggestions
for
questions
and
then,
after
a
while,
we
have
a
better
clear
goal
on
where
we're
going.
B
B
It's
fine,
I
I
I
can
barely
talk
at
this
point.
I've
been
I've
been
working,
you
know
since
early
morning,
so
I
I
can't
type
and
talk
at
the
same
time
and
let
alone
you
know
so.
C
That's
probably
yeah
no
taker
extraordinaire,
maybe
that's
my
ultimate
title.
I've
taken
notes
of
communities
for
a
while
anyway,
but
what
I,
what
I
kind
of
did
here
was
I
took
some
of
the
stuff
and
moved
into
that
chat.
Oh,
I
was
going
to
mention
one
thing:
maybe
we
can
open
a
github
issue
if
there's
not
a
discussion
doesn't
matter
but
just
an
issue
so
that
people
are
on
the
tag
app
delivery.
They
can
with
this
link
to
this,
so
they
can
find
it.
Those
only.
C
Probably
open
a
github
issue
with
link.
A
B
So
what
we've
usually
done
in
the
and
the
other
meetings
is
having
some
sort
of
you
know
action
item
list
you
know
so
the
result
of
our
discussion
then
become
an
action
item
which
then
someone
gets,
and
I
I
can.
I
can
open
a
get
up
discussion
on
the.
B
My
I
can
smell
the
dinner
getting
done,
so
that's
that's
very
distracting
all
right
cool.
I
think
that's
that's
all
we
need
to
talk
about
when
it
comes
to
survey,
because
obviously
we
don't
have
anything
in
particular
to
talk
about.
So
we
just
we.
You
know
it's
limited
how
far
we
can
get
to
that
and
then
next
the
next
one
is
patterns
for
patterns
which
is
yeah,
which
I
think
does
a
rap
song
right
in
the
middle.
C
Yeah
so
I'll
take
this
one.
This
is
kind
of
what
I've
been
thinking
about
the
past
few
weeks.
I
guess
a
few
days,
but
is
I
kind
of
think
like-
and
I
talked
to
thomas
about
a
little
earlier,
like
one
of
the
goals
of
the
app
delivery
group
is
to
provide
like
patterns
and
practices
that
can
gradually
you
know
people
can
adopt
and
can
become
conventions
and
standards
and
blah
blah
blah.
So
I
would
like
to
create
for
our
section
of
that
app
delivery.
Some
patterns,
you
know
some
stuff
demonstrating.
C
You
know,
infrastructure
delivery
with
app
delivery,
and
I've
already
been
doing
this,
so
this
is
really
just
kind
of
sharing
the
vision
sharing
the
idea
make
sure
everyone's
on
board.
Basically,
what
is
happening
now
is
I'm
utilizing
and
I
hope
other
people
will
come
and
party
on
this
with
me
is
we
have
potato
head
which
is
kind
of
a
little
bit?
C
It's
not
huge,
but
it's
a
little
bit
of
a
foundation
for
for
building
patterns
on
top
of,
and
I
wanna
utilize
that,
but
I
wanna
just
make
sure
everyone's
on
board
with
how
I
want
to
do
it.
So
I
want
to
start
by
dropping
an
issue
in
say
the
tag,
app
delivery,
repo
that
says
hey.
I
am
I
propose
this.
You
know
rough
idea
of
the
pattern,
a
rough
architecture
like
it's,
I
anticipate
using.
Actually,
I
have
an
example
proposal,
one
because
better
one
than
none.
C
So
let's
take
my
example
to
kind
of
walk
you
through
this.
So
the
example
I
want
to
work
on
in
the
next
few
weeks
is
deploying
a
database
to
one
of
many
providers
in
a
relatively
generic
way.
I'd
like
to
use
crossplane.
C
So
let's
say
I'm
going
to
get
a
postgres
database
in
azure
in
rds
aws
in
google.
Crunchydata
also
has
a
service
I'd
like
to
show
out
that
would
work
too
and
also
get
back
a
binding,
which
means
you
know
pretty
much,
just
the
url
and
username
and
password
that
the
app
can
use.
I
actually
literally
had
this
problem
for
my
last
place
and
it's
very
it
was
it's
much
harder
than
you
would
think
to
solve.
C
We
ended
up
with
vault
a
vault
sidecar
that
called
into
the
vault
engine,
which
dynamically
generated
a
secret
using
the
vault
secrets
engine
which
might
be
actually
that's
one
proposal
for
getting
that
that
I
could
put
in
the
proposal
for
forgetting
another
one
that
I'd
really
like
to
look
into.
Actually
is
the
service
bing
operator,
which
I
think
red
hat
has
been
pretty
involved
in,
but
that's
not
I've
been
watching
it
for
a
while.
C
So
that's
that
I
would
propose
all
this
in,
like
the
github
issue,
hey
I'd
like
to
demonstrate
the
database
provisioning
generically
getting
the
binding
a
spring
boot
app
on
top
or
something
like
that
or
a
node
app,
or
something
that
that
uses
that
binding
to
make
a
call
yeah.
So
I
put
that
in
the
github
issue,
people
could
chime
in
and
say.
Well
maybe
try
it
this
way.
I
do
it
this
way,
whatever
it's
still
relatively
early
days.
C
My
next
step
kind
of
in
line
actually
is
to
start
implementing
it
and
that,
I
think,
is
really
important,
like
we
had
like
like
code
on
the
ground
code,
talks
start
implementing
the
pattern
so
like
in
this
case,
potato
head.
I'm
envisioning
and
I've
been
talking
with
thomas
about
that.
So
I
did
a
refactor
last
week
and
one
of
the
ideas
is
to
make
it
more
is
to
make
it
more
extensible
like
I'd
like
to
it's
just
a
go
api.
C
I'd
like
to
be
able
to
add
just
a
handler
that
calls
a
database
instead
of
you
know,
returning
to
some
static
assets,
which
is
what
it
does
now.
So
I
would
start
that's
my
ideas.
I'll
add
a
handler
I'll.
Add
this
pattern
in
potato
head
as
a
branch,
a
link
to
it
from
the
github
issue
that
I
open,
and
so
that
and
that's
kind
of
like
advancing
the
proposal
you
know
like
here.
I
did
it
in
practice.
I
think
you
can
run
this
yourself.
Here's
the
instructions,
here's
a
rough!
C
You
know
it
may
not
be
perfect,
the
first
iteration,
so
that
would
be
kind
of
step,
two
implementing
it
and
then
oh
and
I
guess
yeah
step
three.
What
did
I
leverage
and
extend
shared
foundation?
So
I
guess
yeah,
that's
kind
of
part
of
the
the
implementation
is
okay,
I'm
gonna
bring
in
crossplane
and
see
if
that
can
work
here,
maybe
even
talk
to
them
about
it.
C
I'll
bring
in
you
know,
other
the
vault
agent
or
service
binding
agent,
yeah
and
they'll
keep
iterating
both
in
the
issue
and
in
the
repo
and
then
refine.
So
it's
like
it's
kind
of
do
it
do
it
and
then
do
it
better
and
then
that
do
it
better
stage
should
culminate.
I
think
the
outcome
should
be
a
complete
dock,
a
tutorial.
I
think
that
the
outcome
of
any
pattern
needs
to
be
a
dock
where
somebody
can
come
in
and
read
through
it
and
implement
it
and
run
it
themselves.
C
You
know
that's,
that's.
It
could
be
working
a
lot
as
you
go
but
like
that
will
get.
That
will
be
the
the
bow
I've
reached
1.0.
You
know
when
I
can
publish
a
doc.
That's
really
working,
maybe
a
test
two
and
to
test.
B
Yeah,
if,
if
we,
this
would
really
work
really
well,
if
we
actually
had
discussions
on
to
be
honest
because.
D
B
That
that
you
know
having
ish
working
in
issues
are
usually
like
one-way
street,
so
you
know
you
started
it
up
and
you
go
down
and
et
cetera,
but
the
way
that
discussion
works
is
kind
of
better
for
these
kind
of
things,
because
you
would
ask
for
you
would
ask,
for
you
know
alternatives,
and
then
someone
would
suggest
that
and
then
that
would
get
loaded
up.
B
So
I
don't
know
if
that's
a
a
thing
we
take
up
with
well
anyone
that
has
any
access
for
the
the
tag
app
delivery
repository,
but
that
it
should
it
should
probably
be
on.
At
this
point
I
guess.
C
B
B
This
is
exactly
the
thing
that
that
actually
is
designed
for,
while
the
issue
is
is
like
the
name
says
an
issue,
so
you
know
you,
you
should
be
iterating
downwards
and
then
close
and
so
discussion
would
probably
work
better
in
this
case,
and
I
like
the
idea
of
having
like
a,
I
guess,
problem
they
want
to
solve,
and
then
I
say
like
this
is
the
kind
of
way
that
I
think
that
you
know
this.
B
These
are
the
options
that
I
think
can
think
of
and
then
have
people
commenting
on
that
that
that
makes
for
a
better.
You
know
the
the
outcome
were
probably
better
at
that
point.
The
only
thing
that
I
I
think
would
be
good
is
for
if
you're
gonna
leverage
cross
plane,
how
does
that
actually
work
in
like?
How
is
that
the
binding
element
is?
Is
that
enough
of
a
binding
element,
or
do
we
also
want
to
then
drag
in?
You
know,
deployment
patterns
or
something
like
that
to
cut
like?
C
C
And
what
you
said
by
the
way
makes
me
think
like
we
could
have
I'm
thinking.
What
I
should
do
here
is
open
an
issue
in
the
tag:
app
delivery
about
the
patterns
for
patterns,
a
general
discussion,
here's
the
pattern
for
patterns
and
then
open
an
issue
for
my
specific
pattern
about
databases
and
credentials.
B
Yeah,
that
makes
sense.
We
should
also
just
open
an
issue
about
having
enabled
discussions.
That's
a
easy
one
to
get.
I
can
actually
do
that
enough.
Well,
wow.
C
B
I
I
just
I
just
know
that
I'm
gonna
forget
about
it,
so
I'm
I
can
do
it
and
I'm
just
opening
an
issue
not
submitting
it
just
so
I
remember
that
I
was
supposed
to
be
doing
it.
A
B
But
having
discussions
in
the
tag
app
delivery
repository
is
probably
going
to
be
helpful
for
many
of
these
things
unless
we
want
to
branch
out
and
have
our
own
thing,
which
then
again
doesn't
get
any
activity
on
the
tag,
app
delivery,
which
is
not
good.
B
There's
a
lot
of,
and
and
obviously
it's
a
different
kind
of
beast,
the
the
getups
working
group
and
the
open
githubs.
You
know
project
but
at
the
same
time
it's
like
there's
so
much
stuff
happening
there
that
doesn't
kind
of
trickle
down
to
the
tag,
because
it's
it's
separate
it's
from
it's
in
a
different
repository,
it's
different
organization.
Everything
like
that.
So
I
think
it's
just
and.
A
B
We
don't
have
to
ask
for
access
first
off
weirdly
enough,
so
so
I
kind
of
get
why
people
have
been
doing
in
that
way.
But
I
think
we
should
try
to
stick
with
the
the
one
place
to
just
get
more
activity.
B
I
can
see
that
there's.
I
think
we
need
more
of
these
like
problems.
B
I
I
I
kind
of
you
know
can't
figure
out
a
different
word
to
use
but
like
if
people
have
pain
points,
I
guess
that's
the
that's
the
fancy
way
of
saying
that
and
they
should
be
able
to
kind
of
just
even
that
you
know
don't
have
anything
I
thought
of
just
this
is
a
thing
that
I
can't
really
figure
out
what
to
do
and
then
have
that
discussion,
and
if
that
is
something
that
people
are
interested
in,
that's
kind
of
like
a
candidate
to
kind
of
to
create
a
not
a
pattern,
but
at
least
a
set
of
patterns
around
that
problem.
B
At
that
you
know,
and
that's
fine
and
that's
probably
something
that
discussions
also
will
help
with.
But
when
we
have
these
kind
of
set
and
start
creating
patterns,
are
we
then
just
creating
a
in
the
in
the
corporate
delivery
working
group
directory
or
which
I'm
just
going
to
have
a
patterns
folder
and
serialize
them
zero
one
to
whatever
or
with
a
date
or
I
I
can
see
it
gets
kind
of
like
messy,
really
quick.
You
have
like
600
markdown
documents.
C
Yeah
yeah,
I
captured
that
in
the
noses
where
should
they
be
published
and
yeah?
I
agree
they,
it
kind
of
depends
on
what
they
end
up.
Looking
like
like
the
potato
head
stuff
will
start
in
that
repo,
but
then,
like
maybe
the
tutorial,
the
document,
maybe
should
not.
I
mean
maybe
it's
a
different,
maybe
there's
just
a
basic
read
be
there
and
the
actual
tutorial
is
a
folder
in
the
app
delivery,
repo
yeah.
A
B
So
and
obviously,
if
if
it
is
in
the
corporate
delivery
working
group,
people
will
find
it
there
and
then
again
you
know
maybe
want
to
be
part
of
the
corporate
delivery
working
group
and
help
with
these
things.
So
you
know
it's
it's
better
to
to
get
it
there.
I
just
can't
really
see
where
it
should
be
like
how
that
looks,
and
and
obviously
at
the
start.
If
we
have,
we
have
a
couple
of
patterns.
B
That's
fine,
but
at
a
certain
point
we're
gonna
have
a
lot
and
you
know
the
way
that
that
get
up
structure
this
you
know
if
we
had
a
read
me
with
like
links
to
everything,
so
you
could
kind
of
go
over
that's
kind
of
cool,
but
the
problem
is:
if
the
the
pattern
is
in
the
same
directory,
then
you're
not
going
to
see
it
read
me
until
you
get
past
like
600
files
so
like.
How
do
you
want
that?
Maybe
we
can
just
add
on
the
corporate
delivery.
B
C
Yeah
yeah
that
that's
actually
kind
of
what
I
was
thinking
that
you
know
there
was
a
it
might
even
just
be
a
list
of
you
know.
If
you
were
some
of
these
big
companies
might
have
like
a
data
sheet
for
all
of
the
tutorials
that
they
offer.
That
kind
of
thing
would
end
up
in
the
main
repo,
and
maybe
there
would
be
a
home
page
that
lists
them
all
like.
Even
if
you
look
at
potato
head
today,
it's
actually
got
something
like
that.
C
On
the
first
page,
it's
it's
a
little
bit
scrolling
down
but
like
it
says,
delivery
scenarios
and
then
it's
just
a
bunch
of
links
to
readmes
for
flux,
argo,
cd
and
blah
blah.
So
you
know
that
maybe
we
take
some.
B
I'm
a
fast
typer.
I
was
already
there
but
yeah
and
again
that's
we
can
use
but
potato
head
as,
like
the
the
the
you
know,
the
service
that
we
use
for
these
examples.
B
But
at
the
same
time
the
pattern
shouldn't
should
be
in
the
tag:
app
delivery,
slash
cooperative
delivery,
working
group
structure
just
to
make
it
actually
belong
to
us,
but
I
think
we
yeah
we're
gonna
extensively
use
potato
head,
so
it's
you
know
and
they
can
aim
to
link
in
between
as
well
so
the
potato
head
can,
then
you
know,
say
all
right:
you
want
to
look
at
these
scenarios,
here's
a
description
of
that
pattern
and
then
it's
going
to
be
linking
to
the
actual
pattern
in
the
gap
delivery
repository.
B
I
I
have
an
idea
for
things,
which
is
always
a
bad
thing
and
I'll
I'll
I'll.
If
you're
still
writing,
maybe
I'll
I'll.
Take
an
action
item
on
on
organizing
a
little
bit
in
the
corporate
delivery.
B
A
A
B
C
B
We
keep
on
adding
abstractions,
you
know,
that's
our
job,
as
you
know,
we
abstract
the
abstraction
and
and
then
we'll
see
what
happens.
C
Oh
okay,
so
one
last
thing
I
just
want
to
mention:
I
don't
I
guess
it
was
somebody
that
was
on
this
call
like
a
month
ago
brought
this
up,
but
it
was
like.
Yes,
that's
actually
really
smart
and
we
should
keep
this
in
our
thing,
so
I
just
want
to
bring
it
up.
I
think
I'm
going
to
open
an
issue
just
to
keep
it
in
our
backlog
and.
A
C
It's
about
is
so
one
of
the
big.
In
my
opinion,
promises
of
cloud
is
that
you
know
you
can
automate
delivery
of
infrastructure,
but
we
still
have
so
many
inconsistencies
in
describing
that
infrastructure
and
the
apis
that
you
use
like.
Of
course,
we
know
like
aws,
azure,
google
all
have
different
apis
and
different
resource
models,
and
kubernetes
is
helping
with
that.
I
think.
That's
probably
why
it's
you
know
pretty
popular.
That
gives
like
a
standard
api
standard
resource
model,
but
it's
still
pretty
basic.
C
In
fact,
it
doesn't
really
describe
much
of
anything
you
can
you
don't
even
have
to
use
spec
and
status
if
you
don't
want
in
your
kubernetes,
that's
kind
of
become
accepted
now
that
you
do
a
spec
instead
of
so
certainly
some
of
the
older
you
know
resource
resources
in
kubernetes.
Don't
have
that
like
anyway,
so
and
then
within
the
spec,
though
there's
lots
more
like
let's
say
I
want
to
return
a
secret,
you
know.
Is
there
a
standard
way
to
do
that?
C
Let's
say
I
want
to
request
certain
attributes
from
the
cert
the
database,
I'm
provisioning.
Is
there
a
standard
way
to
do
that?
That
kind
of
you
know
the
different
clouds
everybody's
doing
things
like
that.
Like
cloud
formation
has
a
concept
of
a
resource
with
attributes
kubernetes,
you
know
you
could
just
say
well,
it's
in
the
spec
field,
but
there's
it's
too
loose
and
we're
seeing
people
like
try
to
further
describe
the
model.
That's
like
cross
plane
is
a
good
example.
C
They
they
have
something
called
xrm
which
stands
for
cross
plane,
resource
model
where
they've
added
more
definition
within
the
spec
like
you
should
use
these
fields.
We're
going
to
put
the
secrets
here
that
kind
of
thing
the
person
that
was
on
a
couple
weeks.
I
think
his
name
was
scott
brought
up
k
native
duck
types
as
as
another
kind
of
example,
k
native
has
like
it's
been
a
while,
since
they
look
but
like
they
have
the
concept
of
like
a
schedulable
or
you
know
a
a
runnable.
C
Well,
it's
the
same
idea,
but
like
a
schedulable
would
be
something
that
I
could
invoke
certain
things
on,
or
that
has
certain
properties
you
see,
I'm
kind
of,
but
that's
the
idea
like
and
if
and
and
other
ones
that
I
put
a
list
in
here.
Oh,
I
put
cloud
formation
terraform
kubernetes
itself,
but
if
a
pair
forms
another
is
a
good
example.
Actually
I
was
talking
with
robert,
not
robert
thomas,
about
this
earlier,
because
he
was
trying
to
coordinate
some
stuff
with
terraforming
some
stuff
with
the
animal
and
struggling
with
it.
C
So
that's
you
know
another
example
like
oh
peop:
how
can
we
bring
these
models
together
and
the
the
reason
why
it's
important
is
by
getting
more
consistency
for
that
spec,
it's
going
to
make
it
easier
for
app
devs
or
whoever
it
is
to
provision
that
infrastructure.
If
they,
you
know,
even
if
they're
forget
about
a
standard,
even
if
they're
at
least
loosely
similar
that
helps
and
we're
getting
their
little
kubernetes
and
certainly
as
it
you
know,
if
we
can
define
something
like
kubernetes
like
the
schedulable,
you
know
or
it's
then
I
can.
C
So
that's
my
kind
of
spiel
kind
of
my
pitch
on
why
you
know
gatherings.
I
think
it's
really
early
days
on
this,
like
I
think
people
need
to
kind
of
grasp
people
from
what
I'm
kind
of
trying
to
get
at
like
hey.
If
we
can
standardize
the
model
standardize
the
api
further,
the
more
you
know,
then
we
can
make
it
easier
to
deploy,
but
I
think
the
first
step
is
just
kind
of
gathering
that
stuff
together,
like
just
hey
this
is
you
guys
are
doing
it
this
way,
you
are
all
doing
it
this
way.
C
Every
project
red
hat,
has
a
whole
library
of
like
common
types.
You
know
common,
specs
and
common
patterns.
You
know
conditions
another
example
there's
just
so
many
can
we
start
gathering
those,
and
you
know
maybe
we
can
go
from
there
and
find
synergies
and
encourage
synergies.
B
As
something
that
can
be
valuable,
at
least
in
the
form
of
or
not
particularly
like
a
standard,
but
at
least
like
to
get
the
discussion
going
and
have
people
like
what
can
we
create
like
we
can
look
through,
we
can
look
through
the
the
kubernetes
resource
management
model
and
the
the
different
model
types
that
you
know.
The
different
solutions
have
and
and
kind
of
like
draw
parallels
and
find
like
a
common
pattern.
B
I
guess,
but
will
that
help
in
the
future,
for
when
people
are
creating,
people
are
going
to
create
more
tools,
all
the
time
and
and
new
things,
and
you
know
the
the
open
api
standard
and
stuff
like
that,
it
kind
of
came
and
then
all
sudden
people
aren't
using
it,
and
so
it's
like
what
can
we
do
to
help
in
that
ex?
B
You
know
in
that
respect.
What
can
we
do
there
can
we
are?
We
are
we
creating
some
sort
of
going
back
to
documents
and
white
papers,
but
are
we
creating
something
like
that,
or
are
we
trying
to
make
a
discussion
forum
for
the
creators
of
these
tools
and
or
you
know,.
C
To
be
honest,
I
don't
know,
I
think,
that's
exactly
where
I'm
getting
at
like.
I
know
that,
there's
a
proliferation
of
the
proliferation
of
these
models
and
that
you
know
getting
a
handle
on
them
would
would
help,
even
if,
like
we
can't
change
them
at
all
so
yeah.
What
I
what
my
next
steps
would
be.
You
know
if
I
have
time
or
what
what
I
would
think
another
person's
steps
might
be
would
be
just
gathering
together
and
demonstrating.
C
You
know
to
deploy
a
database
or
a
queue
or
an
observability
systems
whatever
it
is.
Here's
how
you
would
do
it
with
the
kubernetes
resource
model.
Here's
how
crossplane
does
it?
Here's
how
you
do
it
in
terraform,
maybe
even
instead
of
a
terraform
operator
or
something
you
know,
show
the
same
thing
in
five
different
ways
and
then
show
like
look
the
resource.
What
actual
the
yammer
manifest
looks
almost
the
exact
same
in
all
five
of
these,
but
there's
just
little
differences
and
then
and
then
go
from
there.
C
I
don't
know
like
do
we
go
then
to
the
vendor
and
say
hey
for
version
two.
Maybe
you
know
get
closer
to
what
these
folks
do
like
conditions
is,
I
think
a
good
example.
Do
you
know
about
the
conditions
and
kubernetes
resources
and
statuses,
like
that's,
become
kind
of
a
de
facto
standard,
even
though
it's
I
don't
even
know
if
it's
described
anywhere
like
that
would
be
the
kind
of
thing
that
we
might
you
know
arrive
at.
There
might
be
a
secret
under
status.
C
You
might
have
a
secrets
attribute
which
says
here's
path
to
secrets,
and
then
everybody
knows
that
kind
of
thing.
C
B
Yeah,
I
think
the
the
standardization
of
these
things
are
kind
of
important
as
well,
because
the
just
like
to
see
how
how
like
service
mesh,
you
know,
became
a
service
mess
which
someone
said
at
some
point
and
and
then
you
kind
of
get
like
the
the
a
standardization
on
how
service
message
should
net
meshes
measures
should
actually
work,
and
you
know
what
what
kind
of
end
point
should
that
have
and
how
do
you
do
traffic
handling,
how
do
you
etc,
and
that
kind
of
became
a
standard
and
all
of
a
sudden,
you
have
several
service
specialists
that
you
can
kind
of
entertain
because
they
are
speaking
the
same
language.
B
There
is
yeah,
but
there's
there's
a
lot
of
things
here
when
it
comes
to,
for
instance,
for
terraform.
You
know
it's
again:
it's
an
extraction
level
domain,
specific
language
created
on
top
of
json,
which
you
know
then,
is
something
that
just
the
terraform
binary
file
can
then
look
at
and
understand
that
this
is
how
it's
supposed
to
be
compared
to
what's
already
there.
B
How
do
we,
like
is,
is
you
know?
Is
it
there?
There
are
gonna,
be
some
differences
there,
just
like
stylistic
differences.
I
guess
this
is
what
I'm
trying
to
say.
Do
we
want
exactly
do
we
want
to
propose
a
I
I
like
the
idea
of
infrastructure
resource
model
standards.
B
I
just
don't
know
what
that
you
know.
I
don't
know
the
I
can
kind
of
imagine
what
that
would.
You
know
be,
but
but
at
the
same
time
I'm
not
really
sure
how
far
into
the
deep
end
one
would
go
with
something
like
that.
Also,
it's
a
big
undertaking
and
obviously.
D
If,
if
I
may
reflect
a
bit
that
for
me
for
me,
what
it
reminded
me
was
open
application
model,
we've
been
working
with
that
a
lot
lately
it
initially.
If
you
look
it
look
at
it,
it
feels
kind
of
basic.
D
You
have
an
application,
that's
a
list
of
components
and
you
have
components
there
you
have
traits,
but
when
you
dig
deeper,
you
can
pretty
much
describe
all
kinds
of
scenarios
with
with
this
model
and
since
this
model
is
not
specific
to
a
technology,
yes,
there
is
cubella,
but
but
it
they've
tried
to
get
keep
the
model
independent
of
the
technology.
You
can
pretty
much
map
the
same
model
onto
different
implementations,
whether
it's
communities
with
crossplane,
whether
it's
kubernetes
with
aws.
D
What's
the
name
of
the
kubernetes
controllers
at
the
moment
you
can
map
this
model
onto
onto
different
tools
and
different
implementations.
Now,
if
we,
if
we
wanted
to
add
infrastructure
description
to
this,
probably
there
is
a
hacky
way
to
do
it
with
combining
crossplane
with
kubernetes,
for
example.
But
I
I
think-
and
I
feel
that
this
is
not
the
subject
that
has
been
discussed
or
explored
deeply.
D
So
I
think,
if,
if
we
wanted
to
do
something
with
these
models,
then
trying
to
come
up
with
a
some
kind
of
simple
generalization
that
would
describe
the
essence
of
each
these
of
these
technical
implementations
and
that
could
be
translated
back
to
terraform
and
crossplane
this.
This
could
be
helpful
to
give
a
common
vocabulary
or
something
like
that
for
for
describing
infrastructure.
D
Then
again,
what's
the
practical
implementation
for
this
it
is
it
just
an
interesting
resource,
subject
or
or
how
who's
going
to
benefit
from
it,
and
I'm
not
sure
so
it
sounds
interesting,
but
then
again
the
business
case
or
the
motivation
behind
it
should
be
a
bit
more
clear.
C
C
So
there's
one
actually
and
then
another
one
is
tool
developers
like.
If
there's
a
consistent
model,
then
the
tools
can
interact
with
that
without
needing
to
be
bespoke
for
every
last
thing
that
comes
out.
B
You
know
they're
again
drawing
I'm
a
kubernetes
fan
boys.
I
kind
of
just
want
to
put
everything
in
kubernetes,
but
at
the
same
time
I
understand
when
you
know
you
shouldn't
do
that.
B
The
problem
I
have
is
that
I
I
talk
to
developers
who
are
the
other
way
who
you
know
for
some
reason
don't
want
to
put
stuff
into
kubernetes
and
can't
really,
you
know,
get
away
from
them.
No
matter
what
the
use
case
are,
they
always
say:
no,
it's
going
to
be
too
complicated,
having
like
even
helping
people
to
kind
of
like
this
is
the
scenario
this
is
the
this
is
service
that
you're
creating
this
is
the
application
that
you're
creating
that
can
run
on.
B
You
know
these
are
the
platforms
where
that
would
be.
You
know
a
better
fit,
and
you
can
you
know
and
how
you
can
then
trying
to
think.
While
talking
that's
not
going
to
help
me
and
how
can
you,
then,
you
know
benefit
from
that
platform
for
the
thing
that
you're
actually
trying
to
develop.
You
know
I'm
trying
to
get
people
to
understand
the
operator
model
at
work,
and
you
know
creating
controllers
and
stuff.
B
Like
that
which
they
never
thought
that
that's
how
it
worked
in,
you
know
in
kubernetes,
because
they
don't
know
kubernetes,
so
they
don't.
They
don't
see
that
opportunity
to
use
that
as
a
you
know
as
a
beneficial
thing,
if
that
makes
sense,
so
even
getting
things
like
again
going
back
to
patterns,
I
apparently
I
don't
have
any
other
words
but
having
some
sort
of
like
deployment
pattern
for
certain
type
of
application.
B
Development
would
also
probably
be
something
that
people
could
find
at
least
useful
at
least
get
like
a
pointer
in
the
right
direction
and
there's
probably
there
are
resources
on
that.
But
at
the
same
time
you
you
only
find
what
you're
trying
to
find.
B
I
guess
so
people
that
don't
want
to
do
something
in
a
certain
way
kind
of
keep
on
finding
like
the
evidence
for
that
they
shouldn't
do
it
so
having
some
sort
of
like
a
neutral
ground
where
or
these
things
are
explored
and
and
obviously
never
exclude
one
thing,
but
at
least
like
you
know,
you
probably
would
get
more
out
of
you
know
doing
it
in
a
certain
way.
B
That
kind
of
also
ties
into
how
you
again
yeah
infrastructure
resource
models.
How
how
do
you?
How
do
you
you
know?
How
do
you
utilize
and
deploy
certain
infrastructure
pieces
for
your
in
your
development
process?
B
So
I
think,
there's
a
lot
of
things
we
can
talk
about,
and
you
know
towards
that
again.
We're
really
good
to
have
some
sort
of
you
know
a
higher
higher
plan,
something
more.
You
know
something
more
tangent
to
that.
We
can
actually
see
okay.
This
is
what
we're
trying
to
do.
D
One
one
thing
that
I've
noticed
while
working
with
the
open
application
model
is
that
when,
when
you
are
talking
about
deploying
an
application
to
communities,
often
the
discussion
turns
into
how
do
you
do
something
on
kubernetes
or
what's
the
best
way
to
do
this
on
communities
and
not?
D
How
do
you
want
to
describe
your
application
or
what
your
application
should
look
like,
so
so
by
switching
to
the
open
application
model
and
this
being
kind
of
technology
independent?
This
has
helped
us
to
keep
the
discussion
on
the
applications
and
the
application
design
and
ad
less
about.
What's
the
technology
details
how
we
are
going
to
deploy
it
so.
B
So
what
we
want
to
do
is
taking
take
the
the
application
model
and
then
kind
of
just
get
the
infrastructure
in
there
underneath
as
well.
Is
that.
C
D
Yeah,
I
think
I
think
the
girls
shouldn't
be
to
create
the
new
standard
in
the
in
first
iteration
and
the
goal
shouldn't
be
to
add
a
new
extension
to
open
application
model.
But
I
think
if
we
want
to
explore
these
models,
try
to
try
to
figure
out
how
to
describe
an
infrastructure
without
limiting
yourself
to
one
specific
cloud
vendor
or
a
technology
stack.
B
There
and
and
obviously
I
I
I'm
gonna
talk
about
terraform
and
you
know,
because
that's
kind
of
what
I
do,
but
but
terraform
is
kind
of
doing
that.
You
know
you,
you
don't
limit
yourself,
you're,
not
even
limiting
yourself
to
to
hcl,
because
you
have
the
cdk
for
terraform.
B
So
you
know
if
I
want
to
write
terraforming
go,
I
can
do
that.
So
you
aren't.
You
aren't
limiting
yourself
in
any
way,
even
like
the
deployment
method,
the
way
that
you
want
to
define
it,
it's
still
like
the
terrible
way
of
doing
it,
but
but
you
you
don't
have
to
you,
can
you
can
you
can
write
in
c
sharp
if
you
want
to,
and
you
can
run
it
on
any
cloud
both
you
know,
you
know
public
or
private.
So
it's
it.
D
A
D
And
when
you
think
about
terrapore
resource
providers,
you
have
one
for
aws,
you
have
another
or
for
us
here
they
have.
They
are
cloud
specific
and
they
are
this
for
a
reason,
so
there's
a
reason
why
they
have
not
defined
the
unified
interface
for
for
all
clouds
to
kind
of
start
losing
the
functionality.
D
So
we
have
to
keep
this
in
mind.
Every
abstraction
that
you
create
will
lock
you
out
of
some
something.
D
C
Microsoft's
and
google's
and
amazon's
interests,
but
that
we
have,
I
mean
our:
we
represent
the
end
user
community
like
yeah.
We
they
want
the
functionality,
but
they
also
want
ease
of
use.
So
it's
offended
balance.
B
But
then
again,
obviously
you
know
they
need
to
create
their
own
system,
but
you
know
when
we
then
use
tools
like
terraform,
for
instance,
they
they
do
the
abstraction
level
again,
and
the
only
thing
that
you
have
to
think
of
is
that
one
way
of
creating
your
resources,
be
it
in
in
azure,
google
cloud
or
aws.
It's
still
the
same
way
of
doing
that,
because
you
know
the
tool
is
doing
the
translation.
C
B
Yeah
and
that
actually
could
be
a
thing
to
to
look
more
into
like
the
the
way
that
crossplane
is,
is
you
know
totally
removing
everything
that
has
to
do
with
platform
totally
you
know
more
or
less
totally
removing
you
know
vip
platform,
specific
things
while
in
terraform
you
are,
you
are
just
having
a
different
way
of
talking
to
the
apis,
and
then
you
would
have
to
you
know,
adhere
to
whatever
the
api
wants
to
have
it.
Would
it
be?
You
know
what
what
would
terraform
look
like
if
they
did
it.
B
If
you're
saying
I
want
a
database
like
is
it
would
that
work,
even
at
that
point,
probably
not
but
cool,
well,
we're
on
time
or
overtime?
I
guess
oh.
C
Yeah
wow,
we
really
are
okay.
I
think
on
this
I
will
try,
I
think,
I'll,
open
an
issue,
if
that's
all
right
with
you,
I
wanted
to
just
but
like
or
a
discussion
if
we
can
get
those
going
just
so
we
can
have
it
all
asynchronous
chat
about
it
and
let
other
people
know
too
so.
A
B
I'll
as
soon
as
I'm
out
of
the
meeting,
so
I
actually
can
you
know,
think
what
I'm
writing.
I'm
gonna
open
the
issue
on
my
own
discussion.
I
I
lost
the
window
now
there
you
go
yeah,
okay,
so.
C
B
B
Your
con
is
in
the
on
the
you
know:
liberation
day
of
norway,
so
I'm
still
thinking
of
going
I'll,
just
I'll
just
go
waving
flag,
while
I'm
there.
B
All
right
cool
thanks,
y'all,
you
know
good
discussion.
I
I
think
I
think
this
will
help
and-
and
you
know
next
meeting
is
in
two
weeks,
but
I
think
you
know
at
that
point
the
the
server
draft
document,
which
you
know
sounded
fancy
when
I
was
writing
it,
but
in
hindsight
well
at
least
have
something
in
it.
That
kind
of
hopefully,
will
help
us.
You
know
steer
in
one
direction
rather
than
all
direction.
At
the
same
time,.
B
Yeah
and
feel
free
to
just
reach
out
on
slack
or
something
if
you,
if
you
want
to
discuss
something
that
or.