►
From YouTube: 2020-02-18 Crossplane Community Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
the
recording
is
started,
and
this
is
the
February
18th
2020
cross
playing
community
meeting.
So
the
first
thing
to
talk
about
on
the
agenda
today
is
that
0.8
was
released
just
yesterday,
so
that
is
very
fresh
news.
Thank
you
to
hashed
in
sedan,
megohm
for
running
the
release
process
yesterday.
So
we
successfully
got
new
versions
of
the
cross
plain
runtime
core
cross
plain,
which
is
version
0.8,
and
the
GCP
Asher
in
AWS
stacks
were
all
released
as
well.
A
A
Along
with
that,
thank
you
in
that
gratitude
comes
a
awareness,
some
of
the
headaches
hit
along
in
the
release
process.
Right
now,
so
we
invested
in
a
lot
of
automation
to
do
the
tagging
and
publishing
and
all
sorts
of
elements
of
the
release
process
to
get
artifacts
out
there
and
available,
but
there
are
still
some
manual
parts
of
the
process
as
well
as
divergence
from
the
published
process.
A
How
can
we
streamline
the
process
further
because,
there's
you
know
whole
synchronization
and
sequencing
that
needs
to
be
done
in
the
release.
We've
captured
it
kind
of
right
here.
This
is
sort
of
the
synchronization
steps
that
need
a
sort
of
augments
the
existing
published
sky
here.
So
we
don't
need
to
say
we're
not
going
to
get
into
like
a
full
technical
discussion
of
these
right
now.
A
But
essentially,
the
issue
is
that
we
want
to
publish
both
Crossman
runtime
in
cross
plane
with
a
new
semantic
version,
and
then
once
you
pin
the
dependencies
of
all
the
stacks
and
other
downstream
repos
for
to
those
release
versions.
So
you
need
to
get
the
commit.
The
tagging
done
and
then
update
dependencies
and
then
update
the
reference,
Docs
and
examples
references
and
then
go
back
to
the
core
repo
and
then
update
things,
and
so
it's
kind
of
a
synchronization
mess
there.
That
would
be
really
nice
if
there
was
a
better
story
for
that.
A
You
know
residents
of
that
source
code.
They
belong
to
that's
one
thing
there's,
so
we
should
continue
thinking
about
ways
to
improve
this
because
to
run
a
release.
Now
it's
not
a
lot
of
work,
but
it
does
have
way
more
manual
things
than
we
would
want,
considering
the
investment
in
automation
that
we
have
so
it
ends
up,
taking
like
at
least
a
few
hours
to
run
a
release.
So
from
that
awareness
goes
back
to
a
gratitude
to
hashed
into.
C
A
The
release
and
spending
a
few
hours
on
the
best
way,
so
thank
you,
Dan
and
any
thoughts
you
have
on
the
release
process
since
you've.
You
know
done
it
a
couple
of
times
yourself,
we'll
probably
pretty
be
pretty
valuable
so
with
0.8
out
the
door.
We
it's
time
again
to
update
the
roadmap.
With
our
plans
for
0.9,
with
our
regular,
recurring
monthly
release
process,
we
will
have
one
more
release
with
0.94
before
q,
con
Amsterdam
so
Phil.
A
A
A
B
B
So
essentially
what
it
is
is
it
just
sinks,
your
local
files
into
a
pod
running
on
kubernetes,
and
we
showed
how
that
kind
of
enhances
the
developer
workflow
and
how
you
can
use
that
alongside
crossplane
to
consume,
manage
services,
and
it
does
some
things
like
allowing
you
to
inject
different
secrets
and
credentials
when
you're
in
development
versus
when
deployment
is
actually
made
in
production.
So
you
can
imagine
kind
of
using
a
development
database
or
something
like
that
and
injecting
those
credentials
and
then
going
to
prod
and
using
different
ones.
B
So
we
walk
through
a
number
of
scenarios
there
it's
a
really
cool
tool,
it's
all
open
source.
So
we
appreciate
that
as
well
as
linked
here,
there's
a
guide
to
all
kind
of
all
along
and
it's
pretty
easy
setup.
So
I
definitely
recommend
that
one
thing
that
came
up
actually
from
the
comments
on
the
YouTube
channel
from
one
of
the
viewers
that
we
kind
of
got
into
a
little
bit
during
the
show
and
Romero
expanded
on
some
is
that
using
octet
o
to
actually
develop
controllers
is
pretty
useful.
B
So
that's
kind
of
like
a
side
thing
that
wasn't
really
a
focus
of
the
show,
but
in
terms
of
doing
local
development
on
crossplane
itself,
it
can
be
useful
because
you
can
imagine
if
you
just
kind
of
can
you
know,
stop
and
start
a
controller
really
easily
actually
in
the
kubernetes
cluster
that
you're
running
it
in
instead
of
running
it
out
of
cluster.
That's
kind
of
a
cool
feature
set
there.
So
if
you
want
to
get
any
insight
on
that,
then
definitely
look
into
that
and
maybe
it'll
help
you
get
started
contributing
as
well.
A
B
So
this
will
kind
of
be
the
I
guess.
The
early
announcement
we're
still
nailing
down
the
details,
but
next
week
actually
just
got
confirmation.
This
morning
we
will
be
joining
up
with
one
of
the
maintainer
of
cluster
API,
so
the
kubernetes
gig
that's
working
on
basically
kind
of
a
similar
thing
to
crossplane
it's
very
compatible
and
that
in
that
they're,
basically
creating
CRD
is
to
create
more
granular
components
of
a
crew
nice
cluster.
B
So
you
actually
kind
of
like
bootstrap
your
own
nodes
and
that
sort
of
thing
so
instead
of
you,
know
provisioning
an
eks,
cluster,
asgk,
etc,
you're
actually
spinning
up
something
like
ec2
instances
and
then
using
cube
admin
or
some
other
provider
to
run
Coronas
on
there
and
because
of
our
very
extendable
manner
of
provisioning
to
kubernetes
clusters.
Then
you
can
imagine
you
can
get
the
credentials
from
that
point
of
kubernetes
target
at
it
and
then
we
can
immediately
start
deploying
resources
into
that
from
a
cross
point.
Control
cluster
so
should
be
a
pretty
cool.
B
A
All
right,
Alan
and
they'll
be
interesting.
If
there's
any
outcome
from
that
show
of
a
potential
integration
of
cluster
API
with
cross
playing
or
you
know,
building
on
that
proof
of
concept,
or
you
know
the
collaboration
that
you
all
be
doing
there.
So
that's
always
exciting
to
have
new
things
and
new
ideas
come
up
with
the
topics
of
the
shows
that
you
run
so
sweet.
Definitely,
my
favorite
livestream
show
thing
whatever
you
can
say,
alright,
so
quick
notes
on
ohm
on
open
and
application
model
support
and
cross
plane.
A
So
Nick
has
been
driving
this
effort
with
the
rest
of
the
maintainer
x'
and
open
application
model
community.
So
Nick's
proposal
to
update
the
spectrum
to
be
a
little
bit
more
kubernetes
friendly
in
centric
and
also
have
crossplane,
be
one
of
the
first
runtimes
to
support
the
full
functionality
of
ohm
is
going
very
well.
There
has
been
great
feedback
and
general
collaboration
and
agreement
some
of
the
own
maintainer,
so
this
is
captured
actually
now
in
this
pull
request.
A
So
if
you
want
to
follow
along
up-stream
with
the
with
the
home
spec
pull
request
number
304,
then
you
can
see
all
the
discussion
they're
a
great
work
Nick
on
continuing
to
drive
that
so
to
put
stacks
where
a
tower
in
and
we're
included
in
these
0.8
released
yesterday.
Us
with
that
super
exciting
was
some
great
work
by
Daniel,
Susskind
and
wafak
and
Marcus
as
well.
I.
Think
Marc.
You
added
this
item
to
the
agenda.
A
C
C
The
multi
CP
with
networking
networking
resources
like
connection
global
address
and
all
that
stuff,
as
well
as
resource
classes
with
minimal
hardware
requirements
that
you
can
just
spin
up
and
see,
and
the
second
engine
that
is
included
in
templates
taxes,
ham
tree
and
example,
for
that
is,
like
sample,
stack
WordPress,
it's
basically
a
ham
chart,
but
let
you
get
a
controller
like
generic
controller,
that
watches
continuously
and
applies
them
resources
and
like
both
of
these
are
like
integrated.
So
when
you
take
lot
of
time,
you
get
a
wordpress
deployed
into
a
query.
A
Now,
and
also
me,
I
love
how
the
you
know,
focus
or
the
goal
of
tablets
axes
to
reduce
the
effort.
It
takes
to
create
a
stack
for
crossplane
and
add
new
functionality
to
the
prospects
control
plane
without
having
to
write
any
code
and
I.
Also
really
like
this
there's.
You
know,
customized
approach
and
helm
is
also
supported
right
now
as
well.
So
that's
awesome
great.
C
C
A
Alright,
let's
go
ahead
and
move
on
then
so
we
had
in
the
pull
request
section
here
there
when
I
took
a
pass
through
open,
pull
request.
I
did
you
know:
we've
got
a
big
push
to
get
a
lot
in
for
the
zone
at
8
release,
so
I
didn't
see
any
outstanding
PRS
that
were,
you
know,
needed
a
discussion
right
now.
We're
needed
any
real
shepherding
to
move
them
along,
but
Dan
Mangum
I.
A
B
Absolutely
so,
we've
gotten
a
number
of
people
who
have
dropped
into
slack
and
said
they'd
like
to
get
started,
contributing
and
we've
been
kind
of
like
mentioning
these
issues,
ad
hoc
in
the
dev
channel,
and
that
sort
of
thing
so
I
just
wanted
to
bring
them
together
for
a
place
that
people
could
kind
of
see
them
lined
up
across
all
the
different
repos.
So
we're
trying
to
be
more
diligent
about
tagging
issues
of
good
first
issue.
B
B
But
if
you're,
just
looking
to
kind
of
like
get
your
feet
wet
and
you
know,
make
a
contribution
and
kind
of
see
how
the
pull
requests
flow
works
and
that
sort
of
thing
something
more
straightforward
like
that,
may
be
useful
and
then
there's
they
kind
of
range
in
complexity,
all
the
way
up
to
cross
plane,
CLI
ones
that
are
migrating
bash
scripts
to
go,
and
that
sort
of
thing.
So
one
nice
thing
about
the
cross
plane
COI,
is
that
it's
could
be.
B
You
know
highly
impactful
to
lots
of
users
of
cross
plane
and
especially
that
migration
to
go.
Then
you
could
probably
you
know,
have
like
a
pretty
big
ownership
in
that.
So
if
anyone
is
looking
to
have
a
larger
kind
of
presence
in
contributing
that
would
be
great
and
then
there's
also
things
like
better,
more
short-term
and
needed
like
to
stack,
install
fail,
he
just
had
open
there
and
the
cross
docks
functionality
once
again
kind
of
something,
that's
more
immediate
term.
B
So
if
anyone
takes
a
look
at
these
and
has
questions
or
they're,
like
none
of
these
interest,
me
I'd
like
to
work
on
something
else,
so
we
can
definitely
find
something
for
you.
So
please
feel
free
to
drop
a
message
in
slack
and
we'll
follow
up
and
happy
to
do
any
kind
of
like
onboarding
or
walkthrough
to
get
you
started
as
well.
Pretty.
B
A
Cool
cool,
so
yeah,
and
then
you
know
in
general
the
more
like
issues
that
we
can
have
tags
that
the
more
consistent
we
are
with
that
good.
First
issue:
tag
across
all
the
repos,
the
better
off
it
will
be
for
people
to
you
know,
be
a
self-help
themselves.
You
know
when
they
come
to
cuz.
It's
a
communist
tree
that
a
lot
of
projects
use.
Some
people
come
to
the
project
and
you
know
go
ahead
and
look
for
that.
A
Good
first
issue:
light
tag
on
label
of
label
on
issues
then
they're
more
likely
to
find
something
that
might
speak
to
them
and
be
able
to
contribute
more
easily
just
lowering
the
barrier
of
entry
there.
So
that's
always
good
to
if
you
think,
if
you
see
an
issue
that
you
think
might
be
you're
not
going
to
get
to
right
away,
but
might
be
good
for
someone
who's
news
of
the
project
and
doesn't
have
like
a
too
steep
of
a
learning
curve.
Then
you
know
go
ahead
and
tag
it
with
this.
A
B
A
A
All
right
cool,
so
then
we
can
adjourn
the
enclosed,
the
general
session
here
for
the
community
meeting
and
anyone
who
is
interested
in
the
release
process
in
builds
and
all
that
sort
of
stuff
is
more
than
welcome
to
stay
on.
But
if
you're
not,
then
this
will
very
likely
it
very
quickly
be
a
boring
discussion
for
you
so
feel
free
to
drop
off
at
any
time.
A
According
to
these
steps,
they're
highly
detailed
they've
got
all
the
commands
and
stuff,
but
now,
since
we
have
kind
of
a
new
approach
here,
that
has
not
been
documented,
we're
in
a
state
where
only
you
know
one
or
two
people
like
have
that
tribal
knowledge
to
run
it
correctly,
which
is
a
definitely
a
bad
state
to
be
in.
So,
at
the
very
least,
we
need
to
update
our
process
guides
such
that
we
can
get
back
to
a
state
where
anyone
can
run
a
release
again,
but
yeah
so
dude
did
you
have
some
ideas.
A
B
Absolutely
so
I
mean
the
first
thing,
that's
kind
of
like
the
clear
I
think.
Most
tedious
part
is
updating
references
and
Docs
so
that
both
involves
regenerating
the
API
Docs
before
we
cut
the
branch,
which
is
the
first
step
there
and
then
also
doing
the
the
branch
prep
which
is
like
six
through
there
or
something
so
basically
going
through
and
updating
pointing
to
specific
versions
of
different
stacks
and
crossplane,
and
that
sort
of
thing
and
I
think
those
are
probably
like.
B
The
API
Doc's
are
regenerated,
but
as
you'll
see,
I
bethey
are
open
this
morning
because
we
regenerated
I,
read
your
narrated,
the
API
Docs
and
it
didn't
update
the
table
to
link
to
one
of
them.
So
there's
just
all
kinds
of
like
small
things
like
that,
so
part
of
that
is
getting
cross
Doc's,
either
into
the
cross
plain
COI
or
into
cross
plain
tools.
So
I
have
that
issue
open
for
getting
into
Crossland
COI.
Maybe
cross
line
tools
make
more
sense
as
generation
kind
of
thing.
B
However,
that
brings
up
the
question
of
how
those
basically
get
published
to
the
the
github
repo
that
has
the
website
on
it.
So
there's
like
a
automatic
sync
that
happens
right
now
for
the
docs
in
the
main
crossplane
repo.
So
we
could
set
up
something
like
that.
Another
idea
I
had
is
if
we
had
kind
of
just
like
a
CR,
DS,
doc
kind
of
thing
or
a
cross
plain
CR,
DS
doc
website
that
essentially
just
parsed
them
for
you.
In
that
way,
we
wouldn't
be.
B
You
know,
as
we
have
more
infrastructure
stacks
and
that
sort
of
thing,
then
it
wouldn't
be
that
each
you
know
Rico
had
to
be
running
its
own
doc
generation
and
make
sure
up-to-date
and
then
getting
implemented.
You
know
the
build
sub
module
to
sink
that
and
that
sort
of
thing
you'd
be
more
like
sort
of
like
go
docks
if
you're
familiar
and
because
we
could
basically
dynamically
parse
the
CRTs
and
that
sort
of
thing
and
generate
them
on
the
fly.
That
could
also
be
a
nice
dogfooding
application
and
last
thing
on
that.
B
B
So
we
do
both
the
first
bullet
point
in
the
update
process.
There
is
actually
updating
the
API
Docs,
so
yeah,
if
you
like,
if
you
go
to
crossplane,
do
and
then
go
to
documentation
and
then
API
API
reference,
that's
what
we're
doing
the
generation
with
cross
talks
for
so
that's
just
like.
We
have
to
run
that
regularly.
B
One
of
the
issues
with
that
is
that
you
know,
like
you.
Let's
say
something
gets
updated
instead,
GCP
the
the
next
step
to
get
that
into
the
docks
is
doing
an
update
on
the
cross,
plane,
docks
which
isn't
really
a
straightforward
workflow
and
it's
definitely
very
manual
and
then,
like
you
said,
the
other
part
is
what
Jerry
has
up
here,
where
we're
basically
changing
like
master
to
different
versions
and
that's
more
related
to
walkthroughs
and
examples
and
stuff,
which
is
a
little
more
tricky
and
I'm
a
little
more
comfortable
updating,
manually,
I
think
what.
A
I
was
just
thinking
about
that
one
there.
So
if
you
had
all
the
examples
as
well
as
the
user
guides
in
like
residing
in
each
one
of
the
stack
repos,
then
it
seems
like
it
would
a
logical
step.
There
could
be
each
one
of
these
here.
It
could
be
like
a
placeholder
and
then
during
the
build
process.
You
know
the
occurred
of
the
value
of
the
current
version,
that's
being
built.
We
could
be
injected
into
those
files
there.
A
So,
when
you're
building
from
like
this,
you
know
stack
GCP,
0.6,
release
branch,
then
you
know
as
a
build
environment
variable
or
whatever
it
could
flow
in
there,
and
you
know
populate
the
docks
with
that
particular
version
and
have
the
published
with
the
whatever
the
version
is,
that's
currently
being
built.
So
it
would
be
a
completely
you
know
automated
process
that
way.
A
It's
kind
of
difficult
right
now
well
started
to
call
right
now,
because
all
the
stacks
docks
and
stuff
live
within
the
single
cross,
plane,
repo
so
and
they
all
had
their
independently
versioned
as
well,
so
core
cross
plate
doesn't
really
know
it
doesn't
have
internal
knowledge
or
innate
knowledge
about
what
version
each
stack
is.
First,
is
if
you're
building
the
docks
for
each
stack
out
of
the
stack
repos,
they
do
have
an
innate
knowledge
of
what
version
they
are,
because
that
is
the
are.
A
C
B
Think
that's
less
important,
definitely
like
it
would
be.
It
depends
on
what
kind
of
docks,
if
it's
like,
actually
the
example.
So
examples
get
updated
as
well
on
the
on
the
release.
Branch
like
those
I
feel
more
like
we'd
like
to
have
those
have
the
right
library
that
sort
of
thing,
but
I
mean
most
people
who
come
to
the
repo
or
like
so
on
on
master.
B
You
know
we
could
have
master
there
and
then
I
guess
on
any
branches
on
master
like
we
could
build
this
conditional
logic
basically
into
the
generation,
then
like
replace
master
essentially
so
I
think
it
would
be
more
important
on
master
I.
Don't
think
that
many
people
are
going
to
like
there
at
least
0.6
branch
and
like
let
me
look
at
the
docs
on
that,
but
could
be
wrong.
There
yeah.
A
That's
a
very
good
point:
Susskind
one
that
I
entirely
overlooked
when
I
was
chairing.
That
idea
is
that
yeah,
like
you
know,
there's
just
kind
of
two
forms
of
the
docks.
One
is
the
markdown
that's
committed
to
the
repository
repository
itself
and
one
is
the
first
published
you
know:
generated
HTML
Docs
that
go
on
to
cross
lane,
dot,
IO
the
documents
tight,
so
yeah,
so
having
a
placeholder
version,
that's
in
the
committed
source
code
repo
would
make
for
a
broken
experience
if
you're
browsing
the
docs
from
within
the
source
code.
A
C
A
Yes,
okay,
we
could
do
something
I'm
sure
there,
but
that
deaths.
That's
a
good,
a
good
point
to
bring
up
what
it
was
like,
so
that
your
that
that's
one
aspect,
the
doctor.
You
know
dachshund
examples
having
their
versions
updated,
which
is
a
manual
tedious
process
right
now,
but
is
there
you
know
I
with
go
mod
in
dependency
management
within
go?
Is
there
a
better
solution
or
is
there
automation
that
can
be
improved?
A
The
experience
we
have
around,
like
these
items
here,
like
pinning
cross-play
into
the
new
crossplane
runtime
release,
are
pinning
the
stacks
to
the
new
cross
main
once
I'm
pinning
the
stacks
to
the
cross.
New
new
cross.
Plane
like
that
is,
is
that
always
gonna
move
an
you
already
have
to
do.
Go
update
that
go
dot
mod
with
the
you
know,
text
editor
and
then
run
go
mod,
tidy
or
whatever,
like
reserve,
better
process.
There.
B
So
I
think
that
I
mean
we
generally
are
gonna
have
to
actually
like
do
the
pinning
and
go
mod.
But
we
could
you
know
generalize
that
with
a
script
or
something
like
that
or
maybe
something
more
sophisticated
so
but
I,
don't
think
that
you
can
like
handsome,
like
conditional
logic,
mod
it's
going
to
like
automatically
update
itself
or
anything.
B
Anders-
and
it's
not
clear,
you
know
what
kind
of
like
where
you
want
to,
pin
it
to
so,
just
because
we're
like
releasing
a
new
version
of
stat
GCP,
it's
not
clear
that
we
want
the
latest
tag
on
cross.
Flane
runtime
I
mean
like
generally,
we
do,
but
not
I
mean
that
that
wouldn't
be
something
that
I
would
want
like
hard
try
to
like
always
use
the
most
reason.
It
could
be
the
default
or
well.
C
C
B
I'd,
never
edit
the
file,
I
mean
you
know
mod
and
then
or
go
get,
and
you
just
do
like,
for
instance,
for
all
of
these
yesterday
I
ran
the
exact
same
commands:
go
get
github.com,
slash
cross
by
node,
slash
across
playing
at
latest,
so
I
just
ran
that
on
all
of
them,
and
you
can
also
run
it
at.
You
know:
V
0.7
dot
o,
so
it's
similar
to
like
node
like
that,
but
you
still
have
that
manual
stuff.
Okay,.
B
A
Yeah
I
mean
the
general.
The
general
problem
here
still
remains
about,
like
the
scalability
of
all
these,
because,
like
one
of
the
pains
here
is,
have
been
to
open
pull
requests
and
you
know
waiting
for
ci
to
pass
and
then
you
know
improving
and
merging
the
PO
requests,
so
that
general,
you
know,
process
of
the
more
stacks
I
mean
that
consider
a
conversation
about
what
stacks.
A
Do
we,
as
a
you
know
upstream,
community
want
to
maintain
and
be
responsible
for,
or
does
that
get
you
know
completely
independently
managed
by
different
teams
and
vendors
etc,
so
that
that
burden
is
is
more
of
a
dissemination
scalability,
as
opposed
to
trying
to
you
know,
scale,
a
single,
a
single.
You
know
person
and
nervous
individuals,
responsibilities
to
across
all
those
tacks.
Yeah.
B
One
thing
I
thought
of
like
you're,
mentioning
I
was
running
the
release
yesterday,
but
I
don't
have
like
permissions
to
cut
a
branch
or
C
tag
or
that
sort
of
thing
which
is
like
fine,
because
we
obviously
need
like
it's
not
like
we're.
Just
gonna
give
someone
like
permissions
to
cut
all
like
do
all
the
PRS
without
review.
So
if
even
if
Jared
is
running
it
like
he'd
sought
to
get
a
sign-off
on
there
until
you,
the
cutting
and
RC
tags
are
different
in
that
regard.
B
But,
like
one
thing,
I
thought
of
is
if
we
had
kind
of
like
a
third
party,
committing
those
kind
of
changes
like
the
RC
tag
and
cutting
a
new
branch.
So
right
there
pretty
I
mean
like
a
bot
or
some
sort
of
automated
process.
Then
we
could
do
kind
of
like
scoped
permissions
to
whoever
is
running
the
release.
So,
like
you
could
say
all
right,
you
know,
Marcus
is
running
the
release
today.
Give
him
permissions
to
like
execute
this
thing
that
tells
the
bot
to
cut
a
new
release.
B
Branch
I've
seen
that
pretty
commonly
across
different
projects,
especially
really
large
ones
where
lots
of
different
people
may
run
the
release,
and
they
only
want
to
give
people
at
temporary
permissions,
and
they
don't
want
to.
You
know,
update
the
github
permissions
to
do
that.
So
they
have
a
bot
that
has
the
permissions
and
then
they
give
them
permission
to
invoke
the
bots
sort
of.
A
It
yeah,
so
actually
you
know
that's
the
intent
of
the
goal
is
that
tagging
and
you're
cutting
release,
branches
and
stuff
that
actually
should
be.
You
know
part
of
our
build
automation,
pipelines
and
they
were
until
we
started
doing
an
RSC
tag.
So
the
RC
tag
there
is
like
we
have.
You
know
we
run
the
tag
pipeline
already.
A
You
know
to
do
like
a
0.8
tag,
and
so
that's
completely
automated
and
you
had
permissions
to
run
that
you
know
because
the
the
entity
that
is
performing
the
tag
and
pushing
the
tag
is
actually
the
buildbot,
and
you
know
you
have
permissions
as
an
operator
of
Jenkins
to
execute
that
pipeline
and
it
does
the
get
operations
using
its
credentials.
So
that's
where
we
should
be
back
to
again
soon.
A
If
somebody
were
to
follow
up
on
that
I'm
not
going
to
point
it
name,
any
names,
but
I
might
point
fingers
is
that
you
know
that
tied
pipeline
would
work
out
for
doing
the
RC
tags
as
well,
and
so
when
it's
time
to
tag
master
with
an
RC
tag,
you
just
run
that
pipeline,
and
so
you
wouldn't
need
credentials
or
permissions
to
push
tags
directly
to
master,
which
is
not
a
good
practice
in
the
first
place
anyways.
So
that
should
be.
That
should
be
adjusted.
A
And
then,
if
you
look
also
at
the
tagging
pipeline,
it's
it
has
the
ability
to
cut
a
release
branch
as
well.
It
just
doesn't
work
in
our
current
flow,
where
we
want
to
do
release
branches
after
tagging
so
like
that
could
be
cleaned
up
as
well,
so
that
nobody
would
need
tag
permissions
necessarily
to
do
pushing
the
tags
manually
or
creating
release
branches
manually
either.
So
that
could
be
completely
offloaded
to
our
build
automation.
So
there
should
be
a
solution
for
that.
Can.
A
A
Expression,
that's
like,
oh,
that,
if
you
this
this
tag
here,
you're
putting
here
just
not
is
not
conforming
to
you
know.
My
my
perspective
is
my
opinion
of
what
Cimber
should
look
like,
so
that
that's
the
issue
that
needs
to
be
fixed.
Okay,.
A
A
X,
oh
yeah,
so
that's
those
are
some
of
the
ideas
there.
So
from
this
conversation
it
sounds
like
you
know
the
permissions
aspect
for
tagging
and
push
and
trading
release
branches.
We
can
do
that
through
build
automation.
You
should
be
able
to
do
that.
So
that
should
be
easier.
The
dependency
management's
could
be
addressed.
Maybe
with
some
bit
of
tooling,
with
you
know,
go
get
you
know,
go
mod
and
stuff
like
that.
We
could
probably
add
some
automation
to
make
that
easier.
The
scalability
of
having
to
do
PRS
across
Multan
for
multiple
stacks.
A
You
know
I,
don't
think,
has
an
upstream
community
that
we
want
to
continue.
You
know
maintaining
too
many
more
stacks.
Oh
I,
don't
think
we're
gonna
continue
to
scale
there.
That
should
be
like
an
independence,
a
thing
that
particular
vendors
or
you
know,
authors
own
and
can
do
on
their
own
with
their
own
permissions
and
such
and
then
the
docks
you
know
thinking
through
that
and
moving
to
a
a
approach
or
design
where
each
repo
owns
its
own
docks,
and
maybe
you
can
have
you
know,
automation
there.
B
So
but,
like
I,
said
that
would
take
like
a
little
bit
of
work
and
like
building
something
that
parses
them
and
like
dynamically
presents
them.
And
then
we
have
to
you
know,
run
it.
That
sort
of
thing
could
be
a
cool
dog
food
thing.
But
how
do
we
feel
about
that
versus?
Just
being
like?
You
know,
if
you're
building
a
stack
like
you
document
it?
However,
you
want
then
we'll.
A
Be
that
yeah
that
kind
of
gets
into
the
whole
conversation
about
like
what
the
scaffolding
right
like
when
you
do
across
the
NCL
I
like
in
stacking
it?
What
do
you
get?
You
know
you
get
likes
to
build
automation,
you
get
some
substructure,
you
know
to
do
documentation,
generation
stuff,
like
that's,
entirely
reasonable
to
be
part
of
the
scaffolding
that
you
get
is
well.
You
know
sure
Susskind
has
some
good
opinions
on
that
yeah.
C
A
C
A
A
C
A
B
C
B
Do
a
patch
or
something
you
have
the
main
blocker
on
that
is
just
that,
because
the
crossplane
Doc's
are
dependent
on
the
stack.
So
like
Jared's
saying
like
you
release
a
new
PCP,
you
have
to
go
and
update
the
docs
on
crossplane
and
then
back
for
that
to
the
release
branch
and
that
sort
of
thing,
so
just
all
in
one
so.