►
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
Hello,
everyone
welcome
to
cloud
native
live
where
we
dive
deep
into
the
code
behind
cloud
native,
I'm
annie
and
I'm
a
cncf
ambassador
as
well
as
a
senior
product
marketing
manager
at
camunda,
and
I
will
be
your
host
tonight.
So
every
week
we
bring
a
new
set
of
presenters
to
showcase
how
to
work
with
cloud
native
technologies.
They
will
build
things,
they
will
break
things
and
they
will
answer
all
of
your
burning
questions,
so
you
can
join
us
every
wednesday
to
watch
live.
A
Another
thing
that's
happening
in
the
cncf
universe
is
the
cncf
survey,
so
the
time
to
answer
is
right
now,
so
that
is
really
nice
and
thank
you
for
all
the
replies
so
far
and
in
the
future.
So
this
week
we
have
amazing
speakers
here
to
talk
about
to
talk
with
us
about
the
vs
code
and
flux
testing.
The
new
unreleased
oci
representative
feature
so
and
as
always,
this
is
an
official
live
stream
of
the
cncf
and
as
such
it
is
subject
to
the
cncf
code
of
panda.
A
B
A
B
C
B
Sure
no
problem,
and
so
this
is
me,
I'm
an
open
source
support
engineer
at
weaveworks
on
the
developer.
Experience
team-
and
this
is
the
cloud
native
live
web
stream.
I've
been
working
and
supporting
and
developing
flux,
as
well
as
this
new
vs
code
extension
for
flux
that
we're
going
to
see
as
part
of
the
demonstration
of
the
new
flux
oci
feature.
C
But
if
you
feel
like
this
is
so
new
and
kind
of
a
lot
to
take
in,
please
let
us
know
in
the
chat
or
happy
to
back
up
and
explain
a
few
things.
But
one
thing
that
will
it
reiterate
several
times
is
that
there's
so
many
benefits
that
people
already
today
have
been
getting
from
flux
by
getting
get
ups
there's
many
many
more
than
we
listed,
but
some
of
the
things
that
will
be
even
better
with
this
oci
support
is
scalability
and
security.
C
We'll
also
reiterate
that
if
you're
an
existing
flux
user,
you
can
continue
to
do
things
the
way
that
you're
doing
but
hopefully
you'll
be
excited
about.
You
know
some
of
the
companies
that
really
have
pushed
the
limits
and
made
these
made
it
necessary
to
have
these
added
benefits
and
that's
why
flux
has
been
developed
to
to
add
these
new
capabilities
that
we're
excited
to
share
and
then
at
the
end.
C
I
think
what
we'll
do
is
we'll
do
a
run
through
and
we'll
answer
questions
at
the
end,
both
like
beginning
questions
as
well
as
for
existing
flux,
users
we'll
go
a
little
bit
deeper
and
then
we've
got
pinky
in
who's
in
the
flux
community
online
as
well,
we'll
be
monitoring.
So
if
you
have
anything
specific
along
the
way,
pinky
will
be
monitoring
the
chats.
C
So
please
chat
away
and
hopefully
pinky
will
fall
as
well
and
by
the
way
you
might
notice
that
kingdom
is
demoing
this
all
in
vs
code,
which
is
a
whole
another
exciting
topic,
but
kingdom's
been
working
on
this
fantastic
extension
so
that
you
can
do
get
offs
from
within
vs
code.
So
if
there's
any
extra
time,
then
we're
happy
to
chat
about
that,
but
we'll
see
how
it
goes.
B
B
We've
also
added
support
in
the
vs
code
extension
for
the
new
oci
repository
sources,
so
you'll
see
as
we
go
through
the
demo
that
is
in
use,
and
it's
part
of
the
demo
and
oci
manifests-
are
a
new
option.
That's
available
in
this
release.
There
are
many
implications.
It's
it's
going
to
be
very
helpful.
I
think
for
a
lot
of
our
users,
especially
those
of
you
who
might
have
taken
advantage
of
the
automation,
features
it's
going
to
make
things
a
lot
simpler,
but
all
of
the
old
paradigm
is
stable.
B
B
Only
they
can
use
fewer
boilerplate
manifests
and
oci
will
permit
flux
to
reverse
some
guidance,
also
that
we
weren't
happy
about
and
I'll
get
into
that
a
little
bit
more
later,
but
by
reversing
that
guidance,
we're
doing
this
without
losing
any
functionality,
so
you
should
be
able
to
go
on
using
flux.
The
way
you've
been
using
it
or
adopt
flux
more
easily.
B
Ci
jobs
are
going
to
run,
things
are
going
to
get
pushed
to
container
registries
and
then
flux
will
take
over
from
there
to
deploy
to
staging
or
production
whichever
environment.
The
change
is
destined
for
or
both
as
this
time
as
that
goes
on,
but
what
is
get
ops
exactly
so
these
are
the
principles
of
get
ops
broadly
together
they
say:
use
git
as
a
single
source
of
truth
and
there's
some
elaboration
here
about
how
that
should
be
done.
B
So
like
kubernetes,
the
system
is
all
built
on
declarative,
behaviors
and
declarative
artifacts,
but
with
the
additional
requirement
for
git
ops
that
you
must
use
a
version
store
and
if
you
know
about
kubernetes
you'll
recognize
number
four,
which
also
applies
there,
as
kubernetes
is
continuously
reconciling
based
on
events
in
the
system
and
fluxes.
Similarly,
reconciling
on
intervals
or
events,
if
you
have
access
to
them,
that's
all
according
to
an
alignment
with
the
github's
principles.
B
Immutable
artifacts
are
also
an
important
part
of
this.
We
need
immutable
artifacts
that
cannot
be
changed
once
they're
cast
only
by
ginning
up
a
new
version
and
releasing
it
out
the
door.
That's
how
we
maintain
our
capability
to
audit
and
describe
the
exact
state
of
the
system
at
any
given
time
by
ensuring
that
it's
precisely
described
in
a
declarative
way,
and
the
remaining
features
here
are
a
bit
opinionated
about
how
you
should
do
your
change
management
and
with
good
reason.
B
B
So
what's
a
cluster
repository
well,
this
is
just
the
git
repository
that
you
bootstrapped
into
applications
may
have
their
own
git
repository
and
and
that's
an
extremely
common
pattern.
Although
it's
not
the
only
pattern,
we
we
can
sort
of
trust
that
the
application
repository
when
we
say
install
pod
info
at
version
6.2.0
that
the
application
response
that
the
app
repo
is
a
responsible,
trustworthy
source
for
what
does
that
mean
exactly
for
pod
info
the
app?
B
B
So
the
example
that
we're
going
to
work
through
today
is
from
the
docs
at
least
partially,
and
you
can
find
it
here
if
you
search
for
oci
cheat
sheet.
This
is
where
about
where
we're,
starting,
if
you're
a
docs
person,
if
you
like
to
read
what
we're
doing,
you
can
go
ahead
and
check
that
out,
and
here
is
the
application
that
we're
going
to
be
deploying.
B
I
made
a
few
adjustments
to
that.
According
to
these
docs,
mostly
and
a
few
other
adjustments
in
order
to
make
things
fit,
you
can
fork
my
fork
and
check
them
out
or
just
go
ahead
and
look
at
them,
but
they're
meant
to
be
sort
of
hands-on,
shovel
ready
so
to
follow
along
at
home.
If
you
want.
This
is
what
you
need.
B
Please
take
note
that
you
will
need
to
enable
the
github
actions
there,
since
it's
a
fork,
so
forks
don't
run
github
actions
by
default,
but
we're
going
to
need
those
because
we're
publishing
a
release
and
we're
going
to
let
flux,
deploy
the
release.
So
here's
what
I've
done
to
make
this
a
little
bit
simpler
for
presentation.
B
I
think
I
said
that
you
don't
need
to
copy
from
one
repo
to
another
in
general,
but
in
this
case
I'm
going
to
do
that
because
it
makes
simpler.
So
this
is
the
place
that
I'm
copying
my
manifests
from,
and
this
is
where
I
copy
them
to
and
you
can
see
how
to
adapt.
These
examples
from
the
source
code
and
we'll
see
right
now.
B
That
application
info
is
running,
I
said,
there's
a
kubernetes
cluster,
that's
running,
let's
see,
pull
up
a
monitor,
so
we
can
see
that
that
cluster
is
running
we
have
so
this
is
the
we've
get
out
and
I'm
sorry.
This
is
the
flux
extension
and
here's
our
cluster
demo
cluster
and
I'm
just
going
to
pull
up
canines
because
it's
it's
got
a
little
bit
nicer
responsiveness.
We
can
see
things
happening
as
they
happen
there,
so
I'm
going
to
pull
that
up
as
well,
but
so
what
we're
going
to
do?
B
A
B
Yeah,
I'm
sorry
about
that.
All
of
these
repos
are
public,
at
least
so,
if
there's
anything
that
you
want
to
read,
please
check
out
the
repos.
I
will
ch.
I
will
show
this
again.
You
can
see
I've
got
a
lot
of
commits
so
past
the
original
version,
so
we
have
made
some
changes
here.
So
this
is
where
to
look
for
those
changes
and
all
right.
So
what
we're
going
to
do?
Here's.
B
A
B
The
main
reason
why
I
want
this
canines
ui
here
is
because
some
of
the
things
take
a
little
while
and
I
want
to
make
sure
that
they're
actually
happening
before
I
say
we
should
wait
and
see
what
happens.
So
we
really
only
need
to
see
that
it's
you
know
all
blue
or
that
it
turns
red,
but
I
I
didn't
realize
that
was
the
thing
that
was
too
small
now.
So
thanks
for
that.
C
B
B
To
a
different
logo
and
we're
going
to
change
one
more
thing:
we've
got
some
scaffolding
to
help
us
change,
so
this
version
number
here
is
going
to
have
to
increment,
along
with
everywhere
else
that
that
version
number
occurs
in
the
repo.
So
that's
a
number
of
places
and
we've
got
a
little
helper
here.
B
B
B
B
So
from
the
oci
cheat
sheet,
this
is
the
document
I
mentioned
earlier
here
in
the
workflow
examples.
Here's
that
diagram
that
I
showed-
and
these
are
the
github
actions.
This
is
the
example
github
actions
that
facilitate
this.
So
all
these
are
really
doing
are
they're,
taking
a
clone
of
the
repo
and
they're
running
flush.
Push
artifact
flux,
push
artifact
against
a
path.
A
And
there's
a
request
from
the
audience
yet
to
make
the
text
a
bit
bigger
and
I
think
the
documentation
link
was
provided
by
pinky
earlier
to
the
chat,
but
maybe
he
can
post
it
again.
If
someone
missed
it
and
also
there
was
a
question
from
the
audience,
would
this
be
a
good
time
to
take
it
or
are
we
leaving
the
christians
to
the
end
fully.
C
B
All
right,
so
we
can
see
that
our
deflection,
our
deploy,
is
rolling
out
to
pre-production
as
promised,
and
what
we
should
find
now
is
in
our
pod
info
repo,
and
if
you
want
this
to
work
too
you're
going
to
have
to
enable
issues
on
your
fork
as
well,
there
is
a
manual
approval
workflow.
This
is
not
something
specifically
part
of
flux.
B
B
B
B
B
And
then
do
the
same
thing:
make
release,
forget
tag
and
get
push
and
we'll
see
that
the
same
thing
happens,
but
in
reverse
this
time
and
it
should
proceed
very
quickly,
just
as
we
saw
before
as
soon
as
the
docker
build
is
done.
So
we'll
pull
that
watcher
up
again.
So
we
can
see
that,
as
it
happens,.
C
Yeah,
I'm
sorry.
I
was
chatting
with
pinky
on
these
various
ones.
We
wanted
to
kind
of
focus
first
on
maybe
more
beginner
questions
and
then
we'll
go
to
some
deeper
ones.
In
the
end,
pinkie
was
still
working
on
the
github
questions,
so
we'll
see
if
we
can
pass
on
that
until
there's
something
else
and
then
is
the
oci
repository
exactly
the
same
as
any
container
image
repo.
Could
we
push
to
aw,
aws,
ecr.
B
That
is
a
great
question.
So
aws
ecr
is
an
oci
compliant
repo.
It
is
a
spec.
Not
every
docker
registry
is
necessarily
oci
compliant.
There's
a
media
type
that
makes
an
oci
image
a
little
bit
different,
so
the
media
type
in
a
normal
docker
container
image
is
a
root
fs
and
it's
a
different
media
type
than
we
use
here,
which
is
I'm
not
exactly
sure
what
it
is.
But
it's
something
that
contains
different
type
of
content
and
flux
will
flux
will
push
whatever
you
decide
to
push
whatever
is
in
that
directory.
B
When
you
run
flux,
push
with
few
exceptions,
there
are
a
few
things
that
shouldn't
be
pushed
like
a
dot
get
directory.
I
think
that's
actually
a
bug
right
now,
but
flux
will
push
whatever
you
tell
it
to
push
and
the
oci
artifact
will
hold
whatever
type
of
content
you
want
it
to
hold.
So
if
there's
something
else
that
you
wanted
to
do
with
this,
besides
flex
customized
controller,
applying
your
manifests,
those
things
are
possible
too.
B
What
the
oci
repository
resource
does
like
every
flux,
source
kind
it
reaches
out
to
the
remote
source
and
it
creates
a
tarball
locally.
That
it
serves
up
as
a
local
cached
copy
of
the
remote
resource,
so
each
oci
repository
represents
one
deployment
stream,
so
we
have
multiple
ones
here
we
have
one.
That's
pointed
at
the
tag
production.
B
B
So
it's
already
been
released
at
this
point
here
we
did
the
release
flex
push
artifact
with
git
tag
from
the
actual
tag.
So
this
is
our
tag
version
and
we
see
that
the
release
has
gone
out.
Maybe
you
saw
maybe
let's
see
if
we
can
see
our
new
release
here,
6.2.13
it's
done
out
to
pre-production,
so
we'd
like
to
approve
it
now.
So,
let's
go
back
to
our
issues,
find
the
approval.
B
So
if
we
really
pick
this
apart,
we're
going
to
find
some
problems
in
this
workflow,
this
is
a
ci
workflow,
but
it's
it's
pretty
good.
This
is
pretty
much
exactly
what
I
would
have
wanted
if
I
had
been
in
an
application
developer
role
where
I
need
something
like
flux
to
help
me
deploy
and
the
reason
for
that.
B
B
Yeah
sure
so
the
principles
that
we
highlighted
before
declarative
version,
immutable
pulled
automatically
and
continuously
reconciled
what's
happening
is
our
declarative.
Artifacts
are
getting
placed
in
our
version
store.
Now
it's
an
oci
repository,
that's
a
derivative
of
our
git
repository.
So
it's
not
really
not
git
ops.
It's
still
get
ops.
That
artifact
is
traceable
back
to
git,
even
if
git
ops
required
git,
which
it
doesn't
the
definition
doesn't
specifically
say,
git
all
right.
So
we've
got
our
versioned
artifacts
and
we
have
a
process,
that's
pulling
them.
B
B
It's
a
mutable
tag,
a
not
an
immutable
tag,
but
a
mutable
tag,
and
I
want
to
highlight
this
as
something:
that's,
not
inconsistent,
because
git
itself
also
has
mutable
tags.
Tags
are
all
mutable
and
git
and
branches
are
also
immutable.
Unless
you
have
a
branch
protection
policy
configured
which
you
should
do,
because
the
definition
of
git
ops
requires
immutable
artifacts
and
the
only
immutable
artifacts
that
you're
getting
from
git
are
sha
based
so
each
time
there's
a
a
new
commit
hash.
B
B
So
if
we
want
we
can
use,
we
can
pull
in
a
particular
tag
by
version
you
can
use
an
oci
semver
reference
here
and
senver
range
will
allow
you
to
select.
So
I
can
put
in
a
range
here.
I
can
say
any
6.2.x,
or
I
can
say
any
six
point
x
is
what
that
would
say.
It's
the
same
as
this
expression,
and
this
is
all
according
to
december.
B
So
if
you
go
to
semivery.org,
you
can
read
all
about
the
senver
spec
or
you
can
just
put
in
a
wild
card
and
then
you'll
accept
any
release
and
that's
what
I
would
probably
do
in
my
staging
environment.
That
way,
I
would
accept.
Even
probably,
I
want
pre-releases
too,
I'm
not
sure
if
star
would
get
your
pre-releases
or
not,
but
that
would
definitely
capture
pre-releases,
something
like
that
awesome.
C
So
especially
companies
like
you,
know,
microsoft
and
amazon
that
just
felt
very
validating
that
all
the
work
that
the
maintainers
and
the
contributors
and
everybody
who's
done
together
has
really
created
a
well-designed
piece
of
software
that
provides
that
scalability
and
security
automation,
et
cetera,
et
cetera.
All
these
benefits
that
github
springs,
and
so
I
was
really
validating
because
we
are
this
close
to
graduating
in
the
cncf.
C
The
question
is
specifically:
do
you
have
a
pattern
for
when
you
have
a
monorepo,
and
you
do
not
want
to
expose
all
of
your
code
to
the
cluster
for
the
deployment
operator
to
access?
We
have
separate
environments
for
different
customers,
and
so
exposing
the
monorepo
to
fluxie
is
a
no-go.
Well,
certainly,
people
aren't
doing
that.
So
what
are
your
thoughts
generally
on
repo
and
what
this
new
oci
work
helps
to
do.
B
So
what
I'm
doing
here
when
I
do
flex
push
artifact,
I'm
pointing
it
at
this
deploy
directory,
and
if
we
go
here,
we
see
that's
in
the
pod
info
repo,
and
this
is
where
all
of
my
manifests
are
kept.
So
all
of
my
code
is
outside
of
there
and
flux
will
not
be
exposed
to
any
of
my
code.
It
will
only
be
exposed
to
what's
in
the
deploy
directory.
B
Its
own
manifests.
You
can
do
that
as
well,
not
in
this
particular
layout.
Because
of
the
way
we
have
this
laid
out.
We
have
bases
above
overlays.
So
if
I
wanted
to
just
select
this
overlay
well,
you
can
see
actually
this
one
would
be
okay.
I
can
grab
this
one
because
it
doesn't
have
any
outside
references
and
it
doesn't
actually
reference
a
base.
But
if
I
wanted
to
select
like
the
dev
environment
here,
we've
got
a
lot
of
these
resources.
B
Captured
in
bases
because
we
don't
want
to
duplicate
them
in
our
code
base,
so
in
our
dev
overlay,
this
is
the
a
directory
that
you're
meant
to
apply
from
it's
an
overlay.
You
do
customize
build,
and
it's
going
to
reach
out
of
that
directory
back
to
here.
So
if
you
structure
your
repo,
like
that,
it
won't
work
obviously,
but
that
is
a
design
choice
that
we've
made
here
in
pod
info
and
your
mono
repo
would
obviously
be
structured
a
different
way
to
accommodate
that.
B
And
then,
when
you
actually
apply
from
those,
this
is
what
the
customization
looks
like.
It
has
a
reference
to
the
source.
Here's
our
oci
repository
pod
info,
the
pod
info
production,
one
and
here
we've
gone
a
step
further
to
isolate.
So
this
is
not
a
strict
of
isolation.
We've
still
got
access
to
the
entire
deploy
directory.
If
we
want
it,
if
we
can
edit
this
customization,
but
we
we
have
yeah
so
so
here
we
have
the
further
selector
that
says:
I'm
only
deploying
this
one
environment
here
this.
B
C
B
I
see
we
have
a
question
about
the
flex
cli
yeah,
so
the
flux
cli
is,
is
definitely
something
that
you
don't
need
to
use.
If
you
it's,
it's
a
convenience
wrapper
for
a
lot
of
things,
so
flux
bootstrap
is
a
fairly
involved
process
and
so
flux
bootstrap.
We
do
recommend
people
actually
use
the
cli
for
flux
bootstrap,
because
it
involves
handling
secrets
and
that
can
be
messy
and
and
we've
got
a
particular
opinion
about
how
it
should
be
done
for
security
purposes.
B
But
another
great
feature
of
the
cli
is
the
generator
feature.
If
you
are
running
flex
create
anything.
If
I
wanted
to
get
one
of
these
structures
out,
you
can
say,
flux,
create
customization
and
give
it
a
name
and
say
I
want
to
export
this
and
that's
obviously
not
enough
options.
I
haven't
told
it
where
to
pull
from,
but
it
will
give
me
the
entire
structure,
and
here
is
where
I
will
fill
out.
What
I
need
to
pull
from
we've
got
a
couple
of
extra
things
here
that
are
optional
fields.
B
I
do
recommend
that
you
check
those
out
in
the
in
the
docs,
but
if
you're
using
vs
code,
as
you
see,
you
don't
actually
have
to
go
to
the
docs
you
can
just
mouse
over
and
assuming
everything
is
connected
correctly.
You'll
get
one
of
these
at
the
top
of
your
file.
That
tells
you
what
schema
is
being
used
to
parse
this
and
and
then
these
values
will
pop
up
and
you'll
be
able
to
see
what
these
fields
mean
exactly
and
and
how
they're
used
from
the
context.
C
C
Flux
works
very
well,
and
has
you
know
a
lot
of
native
support
for
things
like
helm,
hashick,
vault,
most
recently
and
others
as
well
as
many
integrations
that
we've
been
working
on
with
terraform
and,
as
you
can
see,
vs
code,
openshift,
etc,
and
to
the
question
of
access?
Yes,
your
git
provider
does
have
to
have
access,
but
pinky
was
sharing
also
that
you
can
use
s3
buckets
as
sources
as
well,
so
that
might
be
a
workaround
that
works
for
you.
We
can
keep
checking
into
that.
B
Just
made
my
day,
I
was
really
hoping
for
that
reaction.
This
is
the
here.
It
says
this
is
a
new
source
that
solves
the
issues
I
ran
into
when
previously
trying
to
implement
flux,
and
that
was
the
reaction
that
I
was
hoping
to
get.
I
think
we've
been
saying
this
is
going
to
be
big.
It's
going
to
change
a
lot.
I
was
specifically
instructed
not
to
say
this
changes,
everything,
but
you
just
so.
You
know
where
my
head
is
at.
C
And
and
tonight
remind
everybody-
you
know
this-
these
are
optional,
so
if
you
have
things
set
up
in
a
particular
way,
you
don't
have
to
go,
run
and
change
it
today.
But
if
you
are
like
the
companies
that
we
mentioned
enterprise
companies
who
you
know
gave
us
the
feedback,
hey,
we
are
all
in
with
flux
and
then
we
have
these
greater
needs
around
scalability
and
you
know
lower
complexity.
This
is
why
stefan
and
team
have
been
working
so
hard
to
move
this
forward.
So
we're
really
excited
about
that.
C
I
lost
my
train
of
thought.
I
was
gonna
mention
one
more
thing
that
was
was
the
benefit.
Oh,
we
wanted
to
share.
You
know
we
talked
about
git
ops
and
how
these
follow
the
principles
of
git,
ops,
and
so
maybe
now
that
you
see
it's
not
necessarily
dealing
with
a
git
repo
but
there's
still
get
under
the
under
the
hood
right
kingdom.
B
Yeah
and
and
what
I
mentioned
before,
that
we
want
the
artifacts
to
be
traceable
back
to
a
specific
commit.
This
is
what
I
mentioned.
What
I
meant
specifically
so
this
source
annotation
that
gets
added
to
the
oci
repository
artifact,
tells
whoever
has
access
to
the
metadata
of
that
oci
repository
artifact,
that
it
comes
from
a
particular
origin
source
repo
and
at
a
particular
revision.
B
B
B
B
B
C
Awesome
ed
says:
oh
my
gosh,
I
wish
mutability
rules
was
a
thing
in
ecr
and
other
registries,
so
I
wanted
to
take
a
moment.
Kingdom.
You
had
that
diagram
that
you
showed
earlier
about
everything
moving
to
the
right.
We
wanted
to
take
a
moment
to
return
to
this
and
talk
about
why
there
are
security
benefits
to
this
process.
B
So
in
this
new
model,
all
the
arrows
point
to
the
right.
Now,
when
you
run
your
ci
job,
you
you've
already
been
pushing
a
docker
image.
You're
used
to
that,
so
your
ci
already
has
right
access
to
container
registry
and
it's
downstream.
It's
not
upstream
of
anything
and
all
we're
doing
now
is
we're
creating
another
container
registry
or
in
the
future.
It
can
even
be
the
same
registry.
B
I
don't
have
that
example
today,
but
you
can
push
layers
of
different
media
types,
so
there
would
be
only
one
container
that
has
the
app
itself
and
also
the
manifests
to
deploy
the
app.
So
this
is
a
way
that
you
can
kind
of,
contain
containers
and
the
complexity
of
containers
and
wrap
them
back
up
into
packages
that
you
can
distribute
that
have
all
the
information
necessary
and
they're
cryptographically
secure.
B
So
this
this
right
facing
is
is
really
important
because
again
we
don't
want
to
compromise
our
source
of
truth,
and
we
don't
want
to
grant
right
access
to
anyone
who
is
not
extremely
trustworthy,
but
also
all
of
the
work
that's
being
done
on
container
registries
in
order
to
secure
secure
them,
such
as
cosign
is,
is
all
happening
there.
A
lot
of
the
you
know
we'll
be
still
interested
in
cryptographic.
Verification
of
git
commits,
but
really
where
the
activity
is
happening.
B
C
I
love
the
response.
Jaw
drop.
This
is
great,
so
pinkie's
also
reiterating
answers
in
the
chat.
I
think
you
did
answer
the
question
about
what
cryptographic
methods
are
supported
and
then
yes,
we
have
a
question
about
ui
on
the
roadmap.
Thanks
for
the
question.
Yes,
we
understand
so
so
much
of
this
talk
that
we've
had
about
security.
C
Obviously
you
know
where
and
when
these
are
a
key
point,
so
I
think
the
most
important
thing
is
that
we've
made
sure
that
we
work
with
companies
that
have
ui
so
there's
a
ui,
that's
secure,
and
that
is
supported
by
a
company,
and
so
that's
why,
as
I
mentioned
earlier,
microsoft
has
arc
kubernetes
and
amazon
has
aws
anywhere.
Our
company
weworks
has
beefcaps
which,
by
the
way,
we
have
a
we've,
get
ops
open
source
ui
that
the
company
does
support.
So
it
is
free
and
open
source.
C
So
you
can
try
that
one
and
then
you've,
seen
if
you've
seen
any
of
the
past
talks
around
flux.
The
people
at
red,
hat
and
vmware.
Also
the
tanzu
team
were
doing
different
versions,
and
then
you
know
that's
why
we're
also
looking
into
these
ides,
where,
if
vs
code
is
one
way
that
you
know
you
can
get
some
of
the
information
that
you
need.
It's
not
necessarily
a
type
of
ui
but
we'd
love
to
have
everybody's
feedback
on
like
the
best
ways
that
we
can
make
sure
that
people
can
access.
C
C
But
right
now,
because
security
is
the
number
one
priority,
we've
decided
to
try
these
other
paths
so
that,
if
anybody's
already
using
azure,
they
can
try
our
communities
if
they're
already
using
amazon,
they
can
try
aws
anywhere
et
cetera,
so
sorry
eks
anyway,
I
said
aws
anywhere.
You
know
we
can
get
feedback
for
that.
So
please
keep
giving
us
those
questions
and
feedback
and
find
ways
that
work
for
you.
C
C
If
you
go
there,
you
can
also
see
ways
to
get
started
as
well
as
ways
to
get
started
contributing.
If
that's
what
the
question
was.
We
have
had
great
feedback,
especially
from
some
of
the
companies
that
you
know
we're
starting
to
build.
I
think
there's
a
talk
by
zscaler
and
they
shared
about
how,
like
you
know,
of
course,
in
the
beginning,
they
were
like
build
versus
buy
and
they
started
building
certain
things
and
then
they
realized.
C
There
is
this
vibrant,
active
flux,
community
of
users
and
maintainers
and
contributors
all
answering
questions,
and
you
know
thinking
about
the
next
challenge
and
building
toward
those
and
helping
to
test
et
cetera
that
they
just
said
it
made
sense
to
just
work
with
something
that's
in
the
cncf,
then
obviously
to
build
their
own.
So
that
was
really
gratifying
to
hear
and
that's
why
this
type
of
work
is
there.
C
B
Hopefully
you
all
enjoyed
that
and
you
can
check
out
the
cheat
sheet
for
the
basic
workflow
examples
that
start
from
flux
cli
and
they
move
on
to
github
actions.
If
you,
if
you're
using
github
actions
or
use
something
else,
that's
fine
and
there's
a
docker
build
and
tag
with
version
in
here.
That
is
very
simple.
B
So
what
we've
done
is
we
showed
an
example:
github
actions
for
docker
build
and
push
and
also
flux,
push
and
tag,
and
we've
shown
that
these
are
sort
of
parallel.
Behaviors
they're
meant
to
work
together
in
a
similar
way
and
only
for
oci
manifests,
and
what
did
we
learn
exactly
how
to
deploy
multiple
environments
for
our
application
and
how
to
automate
deployment
promotion
workflow
and
also
what
is
an
oci
repository?
B
How
do
we
ship
those
ammo
manifests
as
oci
repository?
How
do
we
deploy
from
ci
two
different
ways?
There's
a
third
way
in
there.
If
you
look,
we've
chosen
these
ways
because
they
seem
to
fit
the
best.
So
you
notice,
I
say
staging
here,
and
it
was
pre-production
there.
If
you
go
in
and
check
it
out,
you'll
you'll
find
out
exactly
what
was
the
issue
there,
but
there's
lots
of
different
ways.
B
C
Yes,
and
so
the
links
here
will
send
you
to
the
slack
channel
that
we
have,
if
you
have
questions
or
any
other
ways,
that
if
you
want
to
get
started
with
contributing,
I
just
want
to
highlight
you
know:
even
our
community
members
who've
been
using
flux
for
a
long
time,
sometimes
they
forget,
or
if
you're
new
to
it.
You
know
flux
is
so
fast
moving
that
we'll
just
do
a
couple
reminders
that
you
know
flux.
C
Hopefully
it's
clear
to
you
how
it
provides
get
ups
and
it's
constantly
evolving
people
use
it
for
git
ops
for
their
apps
as
well
as
infrastructure,
and
it
is
multi-everything
it's
multi-tenancy.
It
provides
multi-tenancy,
multi-cluster,
multi-everything
and
hopefully
you'll
be
able
to
see.
You
know
how
vibrant
the
community
is.
One
thing
I
think
we
didn't
quite
highlight
is
that
you
know
flux
works
with
your
existing
tools
and
it
works
with
kubernetes
as
well.
C
So
sometimes
people,
you
know,
don't
see
like
what
part
kubernetes
offering
and
what
flux
is
offering,
but
they
flux
works
very
well
with
kubernetes
to
provide
all
these
different
steps
that
creates
the
end
result
of
get
ops.
So
yes
check
out
our
website,
which
is
fluxcd.io
and
also,
of
course,
we're
on
github.
I
think
we
shared
the
links
earlier
and
give
us
a
star
on
github.
If
you
like
us,.
A
B
A
A
Yes,
of
course,
and
if
there's
no
any
final
notes
from
you
guys,
we
can
start
wrapping
the
session
up
such
a
positive
mood
really
great
to
see
that
yeah.
So
thank
you.
Everyone
for
joining
the
latest
cloud
native
live
episode.
It
was
really
great
to
have
amazing
new
speakers
here
with
us,
as
well
as
priyanka
answering
the
questions
on
the
chat
really
great
to
see
that,
and
we
really
also
love
the
interaction
from
the
audience.
Thank
you.
A
So
much
for
all
of
your
questions
and
comments
as
well
as
jar
drops
always
great
to
see
that,
and
as
always,
we
bring
you
the
latest
cloud
native
code
every
wednesday
so
join
us
next
week
as
well,
when
we
will
have
a
session
on
certificate
management
with
linker
d.
So
thanks
for
joining
us
today
and
see
you
next
week
thanks
everybody
bye.