►
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).
C
All
right
how
about
now?
Can
you
hear
me
sorry
about
that?
For
some
reason,
my
my
MacBook
sometimes
does
not
like
my
my
headphones
there.
So
yeah
we
can
get
started.
I
added
the
meeting
notes
into
the
the
thing
there
feel
free
to
add
your
attendance
as
well
as
anything
anything
from
an
agenda
perspective
and
for
anybody
who
joined
who's
joining
now
feel
free
to
just
sort
of
add
your
stuff
there.
C
So
before
we
get
into
the
agenda,
does
anybody
want
to
who's?
Maybe
new
want
to
new
to
this
meeting
want
to
introduce
themselves.
D
Yeah
I'll
introduce
myself.
This
is
Jay
Jay
White
from
Microsoft,
pretty
new
to
me.
I've
been
trying
to
make
this
meeting
for
a
while.
It
just
happens
really
early
in
the
morning.
For
me,
we're
glad
I'm
here,
I
co-lead,
the
s2c2f
Sig
I'm,
a
member
of
the
supply
chain,
Integrity
working
group
and
I'm
very
active
in
the
salsa
specification
and
positioning
meetings,
so
I
felt
it
necessary
to
attend
this
meeting
as
well,
because
all
of
our
stuff
seems
to
work
together.
D
It
seems
to
blend
together
and
I
want
to
make
sure
that
that
you
know
we
are
across
cross,
collaborating
and
cross-communicating
on
our
different
different
initiatives.
E
Hi
I'm
Alfred
Tom
I
represent
the
sunspec
alliance,
which
is
a
Consortium
in
the
distributed
energy
space
and
also
lumion
Foundation,
which
is
a
spin
out
of
sunspec,
and
it's
a
governing
body
for
a
layer,
one
blockchain
to
secure
the
energy
grid
and
I'm
just
interested
in
getting
involved,
because
we
want
to
there's
a
National
Energy
Resource
Council
nerc,
which
is
the
one
of
the
governing
bodies
for
the
energy
within
the
United.
E
States,
has
a
requirement
in
the
future
for
managing
software
billing
materials
for
every
asset
that
goes
on
the
grid
exports
and
you
know,
takes
on
energy.
So
that's
what
we
need
to
you
know
get
involved
with
you
guys:
ossf,
that's
fine
everywhere
and
whatnot
to
get
that
implemented
for
for
for
the
grid.
C
Cool
would
love
to
hear
more
about
your
like
use
cases
and
and,
and
you
know,
sort
of
challenges
in
the
future
sure.
A
C
C
Gonna
be
one
second
here,
so
I
gave
a
talk
at
open
source
Summit
Japan
last
week
on
Fresca,
mostly
related
to
the
and
I
posted
a
link
here
and
I'll,
also
post
a
link
in
the
meeting
notes
and
just
wanted
to
sort
of.
A
C
Cool
one
second
here,
let
me
also
just
add
this
to
the
meeting
notes
as
well.
All.
A
A
C
C
You
know
a
lot
of
the
focus,
obviously,
given
that
it
was
in
Japan
and
there's
a
big
Auto
industry
out
there.
A
lot
of
the
discussion
was
on
similar
things
like
optane,
which
is
sort
of
in
Toto,
plus
some
in
Toto,
tough
and
some
other
sort
of
Linux
Foundation
cncf
openssf
sort
of
tools
and
how
they
kind
of
all
interact
to
help
secure
sort
of
stuff
like
over-the-air
updates.
For
you
know
automobiles
as
well
as
other
stuff
like
that,
so
it
was
overall,
very
interesting
thing.
C
They
they
they
just
uploaded
the
talks.
It
looks
like
in
the
past
day
or
so
I'm
still
out
here
in
Asia,
so
sometimes
I'm
not
exactly
sure
what
what
time
everybody
else
is
in
so
there
was
some
a
lot
of
interesting
stuff
there.
There
also
seemed
to
be
some
interesting
feedback
on
Fresca.
C
A
few
folks
from
NTT
have
been
doing
something
similar
to
a
Fresca
in
their
own
sort
of
world,
where
they've
been
using
Q
to
try
cue,
the
the
Q
language
in
order
to
try
and
Abstract
out
pipelines,
they
ran
into
a
lot
of
the
same
challenges
we
have
and
I've
been
trying
to
kind
of
get
in
contact
with
some
of
those
folks
to
see
if
we
can
kind
of
collaborate
on
some
stuff
here
as
as
well,
there
was
also
some
discussion
based
on
some
of
the
new
stuff
coming
out
of
openssf,
potentially
this
New
Direction
or
whatever
there's
some
work
potentially
next
year
to
to
start
looking
at.
C
You
know
increasing
openss
sort
of
tool
chain
around
sort
of
open
source
security,
so
that
they
can
kind
of
help,
provide
additional
guidance,
and
maybe
even
some,
you
know,
implementation
guidance
on
secure
development,
secure,
build
and
secure
production,
and
so
one
of
the
things
here
is
hey.
Fresca
is
a
a
build
tool.
That's
intended
to.
You
know,
help
with
secure
builds,
and
so
there
was
some
stuff
there
that
that
seemed
pretty
interesting.
C
There's
going
to
be
probably
some
follow-ups
in
the
the
coming
weeks
around
that
on
how
to
sort
of
tie
in
all
of
the
best
practices
and
standards,
and
things
like
that
that
are
coming
out
of
stuff
like
scorecards
or
skirt
card
I,
can't
remember
which
one
they
decided
on
some
of
that
stuff.
C
On
scorecard
and
some
of
the
other
things
there
and
sort
of
trying
to
take
that
and
then
saying
hey
are
there
things
that
hit
the
high
levels
of
that,
and
can
we
sort
of
show
that
off?
As
you
know,
projects
for
secure,
build
and
secure
development
and
all
the
good
stuff.
So
that's
probably
going
to
be
coming
up.
You
know,
there's
some
interest
in
sort
of
how
you
know.
C
Fresca
can
maybe
be
a
bigger
part
in
that
there's
also
some
practical
elements
of
moving
at
least
the
primary
Fresca
repo
over
to
openssf
one
of
the
reasons
why
it
wasn't.
C
Originally,
there
was
because
of
some
you
know,
logistical
issues,
because
we
also
have
a
bunch
of
example
projects
and
we
didn't
want
to
upload,
like
you
know,
two
dozen
projects
to
open
ssf,
especially
when
some
of
those
projects
are,
you
know,
potentially,
like
quote
unquote:
evil
example
they're
not
like
malicious
malware
but
they're
trying
to
show
like
bad
practices,
and
it's
the
sort
of
thing
without
additional
context
could
be
confusing
to
somebody.
Who's
just
sees
the
org,
and
so
there
might
be.
C
You
know
on
that
end,
the
primary
Fresco
repo
would
go
over
to
open
ssf,
but
the
other
stuff
would
fall
under
something
like
ossf
underscore
build
Sir
with
build
security
or
whatever
so
there's
some
discussion
there,
that'll,
probably
in
the
next
few
weeks,
we'll
have
some
more
info
on
that.
C
So
that
leads
in
sort
of
into
the
next
piece
of
want
to
one
of
the.
What
I
wanted
to
talk
about
briefly,
which
is
the
which
is
the
Fresca
pipeline
sort
of
framework
document,
give
me
one
second
here
to
pull
it
up.
We're
gonna
put
that
tab,
and
so
it's
still
a
work
in
progress,
but
just
and
I
know
a
few
of
the
the
other
maintainers
couldn't
make
the
meeting
today,
so
I'll
try
and
get
their
feedback
as
well.
Where
did
this
go?
C
C
C
So
one
of
the
big
things
that
I
talked
about
in
the
open
source,
Summit
Japan
talk
right,
was
so
in
previous
talks.
I
I
had
focused
on
Fresca
as
an
architecture
Fresca
as
a
running
system,
which,
for
folks
who
are
not
super
familiar,
is,
is
once
again
it's
like
a
combination
of
using
tecton
plus
key
Verno,
plus
a
bunch
of
other
tools
trying
to
follow
the
salsa
framework,
trying
to
sort
of
make
stuff
like
the
adoption
of
what's
being
built
by
Fresca
super
simple.
C
So
to
make
sort
of
things
like
the
sc2f
stuff
easy
as
well,
and
so
one
of
the
things
there
right
is
is
a
lot
of
the
stuff
from
the
architectural
standpoint
is,
is
kind
of
coming
along
there's
a
few
folks
on
our
end,
who
are
working
on
building
out
making
it
easy
to
really
deploy
Fresca,
because
right
now,
the
stuff.
That's
in
the
repo
is
like
it's
a
bunch
of
shell
scripts
that
are
called
from
a
make
file,
and
it's
not
necessarily
the
easiest
thing
to
deploy
in.
C
You
know
to
play
out.
So,
there's
a
bunch
of
work
kind
of
happening
to
make
that
easier
to
deploy
out.
But
the
second
piece
is:
how
do
we
make
the
actual
operation
of
Fresca
simple?
So
if
Fresca
is
once
again,
it
uses
tecton
it
uses
kuberno
it
uses.
Spire
uses
a
bunch
of
these
different
things
when
you're
deploying
a
new
pipeline
to
to
something
like
Fresca.
C
If
you
include
all
of
these
different,
you
know
it's
running
on
kubernetes.
If
you
are
using
all
these
things
like
config
maps
and
and
tecton
tasks
and
tecton
pipelines
and
kiverno
policies,
and
all
that
good
stuff,
normally
you
would
have
to
go
and
create.
You
know
all
different
kubernetes
resources
via
you
know
the
yaml
config
and
that's
not
exactly
the
easiest
thing
to
do,
and
so
what
can
we
do
there?
We
already
have
some
examples
that
use
Q
inside
of
the
repo.
C
The
problem
is,
like
you
know
it's
it's
structured
a
certain
way,
but
we
want
to
kind
of
make
it
into
a
real
library
and
probably
actually
pull
it
out
into
its
own.
Make
it
a
real
sort
of
component
of
Fresco,
whether
it's
in
the
same
repo
or
not
or
whatever
it's
a
separate
thing
so
yeah?
Let
me
kind
of
go
through
just
at
a
high
level,
some
of
the
elements
of
this
document,
so
the
problem
right
is
pay.
C
As
I
mentioned,
it's
difficult
to
sort
of
deploy
all
these
different
yamls
kind
of
keep
the
stuff
consistent,
not
have
to
copy
paste
different
values
between
them.
Like
references
and
yayada,
you
want
to
just
be
able
to
say:
hey
I,
have
some
code
and
just
generate
actually
out
all
the
config
as
I
as
I
need
to
you
know.
We
want
to
some
of
the
requirements
here
right.
We
want
to
make
sure
hey
it's
easy
generation.
C
We
want
to
be
able
to
also
generate
policy
out
of
that
same
sort
of
configuration,
so
we
don't
want
to
have
to
have
like
a
separate
policy
around.
You
know
some
of
this.
We
want
to
make
sure
that
the
policy
can
be
generated.
We
want
to
also
essentially
validate
the
configuration
against
governance
and
policy,
so
we
don't
want
to
just
have
runtime
validation
via
converno
and
similar
policy
systems
like
that.
We
also
want
to
say:
hey
I'm,
about
to
run
a
pipe
like
I
want
to
deploy
a
pipeline.
Will
this
deploy?
C
Will
this
pipeline?
Does
this
pipeline
fit
our
governance
rules,
fit
our
policy
and,
and
that
sort
of
thing
you
know
we
want
to
prevent
you
know,
obviously
insecure
pipelines.
C
So,
for
example,
you
know
Fresca
plans
to
make
it
a
requirement
to
generate
an
s-bomb
as
part
of
your
pipeline,
and
so,
if
you
try
to
like
not
include
an
s-bomb
step
for
some
reason
or
try
to
you
know,
pull
out
an
s-bomb
stuff,
we
want
to
make
sure
that
that
could
be
prevented
as
well
and
things
like
that
right
and
then
beyond
that
right.
We
want
to
make
sure
that
it's
flexible
as
long
as
we're
still
being
secure.
C
So
we
want
to
allow
folks
to
say
you
know
hey
if
something
is
not
supported
by
like
the
default
Fresca
catalog
of
things,
which
would
probably
ingest
a
bunch
of
stuff
from
the
tecton
catalog,
we
want
to
make
sure
that
that
you
know
we
can
still
be
flexible.
So
if
there's
some
new
language
that
comes
out-
and
you
know-
we
don't
have
something
in
the
catalog
there
right,
we
want
to
say
hey
as
long
as
you're.
C
Still
following
the
rules
of
of
Fresca
and
including
an
s-bomb
generation
step
and
all
that
good
stuff,
you
can
kind
of
create
your
own
pipelines
and
that
sort
of
thing
we
want
to
make
sure
that
there's
like
helper
functionality
as
well,
so
that
you
know
it
makes
it
easy.
So,
for
example,
if
we
want
to
make
sure
that
we
validate
pinning
of
images
and
then
all
that
sort
of
stuff
great
could
is
there
like
it's
not
really
functions
in
in
queue,
but
is
that
functionality
available?
C
We
also
want
to
make
sure
like
one
of
the
other
things
is.
We
want
to
start
to
Define
vocabulary
around
this
because,
as
I've
already
sort
of
mentioned
here,
it's
like
Q
itself
doesn't
really
have
this
concept
of
functions,
but
it
has
things
that
are
sort
of
like
functions,
and
so
we
kind
of
want
to
make
sure
that
we
can
call
these
things
in
consistent
ways
as
well.
C
C
You
know
using
the
Q
data,
configuration
and
validation
language
to
sort
of
help
us
out
here,
and
a
lot
of
this
is
sort
of
talked
about
in
my
my
talk,
so
I'm
not
going
to
go
too
deep
in
here,
but
I'll
I'll,
just
at
the
very
high
level,
there's
going
to
be
sort
of
a
shared
library
and
some
baseline
stuff
that
is
owned
by
us
in
green
Fresca
and
then
everything
else
here
like
the
organization,
config
Department,
config
team,
config
and
project
config
and
so
on.
C
Those
are
things
that
would
be
owned
by
your
organization,
your
team,
your
project,
and
the
idea
here
is,
you
know,
Fresca
up
here
and
the
shared
libraries
and
the
Fresca
config
establishes
a
baseline
that
is
enforced
by
you
know
your
org
can't
override
Fresca
default.
You
know
baselines
that
about
security
right.
If
you
know
we
don't
allow
you
to
overwrite
that
just
because
hey
look,
you
know,
Fresca
has
intended
to
be
an
opinionated
set
of
things
that
is
trying
to
follow
stuff
like
salsa
sc2s,
sc2ct
TF,
as
well
as
other
things.
C
We
want
to
make
sure
that
you
know
we
can
do
all
that
sort
of
stuff
and
the
same
thing
kind
of
goes
here
with
stuff
like
Department
config,
right,
Department
config
like
if
an
org
says
we
support
Python
and
rust,
and
a
department
says
well,
we
want
to
support,
go
sorry.
The
org
says
you're
only
supporting
you
know
what
you
support
and
we
want
to
make
it
super
easy
that
once
you
get
to
the
project
config
most
of
this
should
just
get
generated
for
you.
So
the
end
user
doesn't
have
to
think
about.
C
Like
the
end
user
developer.
Doesn't
have
to
think
about,
oh
I
need
to
include
an
s-bomb
step,
so
I
need
to
make
sure
I
write
about
your
s-bomb,
config
and
yeah
yeah.
It
just
should
just
be,
you
know,
provided
by
default,
and
so
all
of
this
sort
of
config
here
right,
so
you
have
stuff
like
vendor
dependencies
and-
and
you
know,
various
config
and
yayada,
plus
some
Fresca
tooling,
that
would
be
managed
by
you
know
a
Fresca
CTL
and
so
on
should
be.
C
You
know,
we'll
deploy
out
a
bunch
of
different
kubernetes
config
and
all
that
good
stuff
right.
So
you
have
like
tasks
and,
and
you
know,
secrets
and
pipelines
and
whatever,
and
so
that
should
all
get
deployed
out
and
then
the
actual
components
of
a
pipeline
here
right
are
that
would
be
managed
by
you
know.
C
Managed
by
this
framework
would
be
you
can
imagine
right,
like
a
a
Fresca
pipeline,
consists
of
one
tecton
pipeline,
one
or
more
tecton
tasks,
a
tecton
trigger
for
actually
triggering
based
on,
like
pull
requests,
zero
or
more
policies
related
to
the
pipeline
right,
zero
or
more
config
maps
for
things
that
you
want
to
have
as
as
available
to
the
tasks
in
the
pipeline,
as
well
as
like
zero
or
more
secrets
for
things
like
test
resources
and
all
that
good
stuff,
and
then
to
kind
of
highlight
again
some
of
this
stuff
here
on
like
constraints
on
a
pipeline
right.
C
You
you
imagine
here
so
that
was
kind
of
talking
about
how
it
all
gets
generated,
but
then,
like
what
does
this
actually
look
like,
as
we
start
to
kind
of
go
through?
Well,
one
of
the
things
here
is,
you
might
imagine
like
at
the
high
level,
and
once
again,
this
is
supposed
to
be
just
sort
of
generic,
just
sort
of
examples,
not
the
way
that
this
is
100
going
to
be
implemented.
C
Once
you
sort
of
have
the
name
of
the
project,
it
automatically
fills
into
the
naming
scheme
and
you
don't
have
to
sort
of
worry
about
any
of
that
other
stuff
and
as
long
as
you
know-
and
you
wouldn't
also
allow
people
to
sort
of
just
override
the
naming
scheme
unless
you
you
allowed
them
to,
and
so
you
can
imagine
as
well
right
like
if,
if
an
org
says
hey,
we
use,
you
know
a
git
server
called
git.internal,
and
if
somebody
comes
in
and
says,
hey
I
want
to
use
public
GitHub
to
build
our
stuff.
C
Sorry,
you're
not
allowed
to
you
require
to
use
the
internal.
You
know
thing.
We
want
to
make
sure
that
orgs
have
that
ability
to
sort
of
do
that,
teams
you
know
and
so
on,
and
then
the
other
big
thing
here
right
is,
you
know
a
Fresca
pipeline
which
is
a
struct
as
far
as
acute
concept
is
concerned,
right,
which
would
then
generate
all
the
actual
stuff
that
is
sort
of
outlined
up
here.
C
This
sort
of
struct
here
right,
you
can
imagine,
you
know
an
individual
org
might
say
hey.
These
are
some
additional
steps
we
want
to
include
in
there
as
long
as
they
don't
conflict
with
certain
rules
that
make
up
that
sort
of
Fresca
contract,
then
you're
allowed
to
sort
of
do
whatever
you
want
there,
and
then
you
know
in
org
and
departments
and
teams
would
be
able
to
have
some
flexibility
to
sort
of
say,
Hey.
You
know
we're.
A
C
Know
we
support
Cyclone
DX
and
not
spdx
related
tools,
great
okay,
you
know,
you're,
you
know
you're.
You
still
have
an
s-bomb
generation
step
which
is
required
by
Fresca,
but
you
want
to
use
Cyclone
DX
and
not
spdx
yeah
go
ahead,
so
that's
kind
of
what
we
want
to
be
able
to
do
on
that
level
and
then
here
is
kind
of
you
know
an
idea
around
what
a
pipeline
might
look
like
right.
So
for
folks
who
are
not
super
familiar
with
q,
we
have
stuff
like
vendor
dependencies.
C
So
these
are
things
like
Q
has
the
native
ability
to
import
kubernetes
resources
and
custom
resources
and
custom
resource
definitions
and
turn
them
into
queue
that
can
then
be
used
for
schema
validation
as
well
as
code
generation
or
sorry
config
generation?
C
And
so
then
you
can
end
up
with
stuff
like
in
your
Fresca
Library
like
different
generators
for
things
like
you
know,
config
maps
and
secrets,
and
then
you
can
sort
of
do
all
that
to
sort
of
create
now
like
Fresca
types
that
are
based
on
those
sort
of
kubernetes
custom
res.
You
know
kubernetes
and
other
custom
resources,
and
so
then
you
can
imagine
like
we
would
then
have
a
Fresca
catalog,
which
would
be
based
on
things
that
may
probably
come
out
of
the
tecton
catalog
as
well.
C
As
you
know,
various
other
custom
things,
and
then
you
know
you.
We
would
have
something
like
a
baseline
pipeline.
That
would
define
a
bunch
of
sort
of
defaults
that
are,
you
know,
a
bunch
of
defaults
as
well
as
constraints
around
what
a
pipeline,
what
a
Fresca
pipeline
that
sort
of
abides
by
that
Fresca
secure
contract
that
meets
all
of
these
different
best
practices
and
then,
while
still
allowing
sort
of
the
end
user,
you
know
to
come
in
and
say:
hey
I.
C
You
know
Fresca
defined
a
build
packs
pipeline,
but
I
want
to
override
once
again
that
s-bomb
generation
step
as
I
posted
using
this
tool
I
want
to
use
this
other
tool
that
we
support
right
and
it's
still
an
s-bomb
tool.
C
You
know
thing
and
it
still
matches
the
contract,
the
interface
so
yeah
you're
allowed
to
use
it
and
then,
at
the
end
of
the
day,
right
like
you
know,
you
end
up
with
a
couple
of
different
projects
here
that
are
the
actual
sort
of
literal
sort
of
pipelines
and
as
well
as
all
the
various
kubernetes
resources.
C
So
really
that's
the
majority
of
the
stuff
there
feel
free
to
read
through
the
document
provide
some
additional
feedback
I'm
going
to
be
trying
to
over
the
next
couple
of
weeks,
building
out
some
pocs
around
this
to
try
and
tease
some
of
this
stuff
out
I'm
also
going
to
be
talking
with
the
Q
language.
You
know
maintainers
themselves
to
see
if
they
can
help
us
out
here,
because
Q
is
not.
One
of
the
big
challenges
is
Q
is
not
the
easiest
language
to
use.
It's
still
relatively
early.
C
The
the
documentation
I
know
is
going,
is
in
flux
and
is
being
sort
of
improved,
but
it
is
definitely
getting
adopted
by
a
lot
of
different
projects.
For
example,
it's
adopted
by
six
door,
it's
adopted
by
I
believe
istio
and
a
few
other
folks.
So
it
is
definitely
sort
of
growing
in
popularity,
but
yeah
cool
yeah,
that's
about
it.
Do
folks
have
questions
or
comments
on
this.
C
All
right,
if
not
feel,
free
to
sort
of
once
again,
you
know,
provide
feedback
in
the
the
document.
C
You
know
I'm
gonna
leave
it
open
for
a
while
here
to
get
some
additional
feedback
from
folks
and
yeah.
If
no
other
comments
on
that,
we
can
move
on
to
the
next
topic,
which
is
let
me
just
the
production
deployment
thoughts.
I,
don't
know
who
put
that
out.
There.
B
Sorry
that
was
me
and
I
lost
my
zoom
window.
That's
what's
like,
oh
god,
yeah.
So
anyway,
it
was
just
more
of
a
discussion
on
I
might
need
to
wait
for
some
of
the
other
maintainers
to
jump
in,
but
I
just
did
want
to
talk
through
what
we
were
thinking
in
terms
of
deploying
Fresca
in
a
production
environment
versus
the
current.
B
The
a
lot
of
the
discussions
today
have
been
more
around
how
you
deploy
Fresco,
while
you're
working
on
Fresca,
which
I
think
is
quite
a
different
set
of
concerns,
and
just
some
of
the
stuff
that
we
learned
and
talked
through
and
and
thoughts.
I
know
a
lot
of
it
gets
into
your
pipeline
framework
and
just
some
of
the
general
issues.
B
I
just
wanted
to
start
to
bring
up
and
just
get
some
discussion
around
I
do
think
it's
going
to
be
tough
to
do
without
in
be
Mitch
and
Brad
and
those
folks,
but
just
the
sorts
of
themes
that
we
that
we
had
just
so
just
to
start
sharing
a
little
bit
were
automation
around
the
configuration
of
the
pipelines
is
something
that
that
we're
that
we're
working
on
a
little
bit
we
did
and
we
did
put
a
good
amount
of
work
into
a
Helm
chart.
B
However,
the
way
that
we're
deploying
Fresca
right
now
is
everything
in
one
big
piece
with
the
pipeline
framework:
tectons
chains,
all
that
stuff
co-located
with
the
cert
manager,
Vault
and
spire,
is
not
really
practical
in
a
production
environment.
So
what
we
did
is
we
split
it
out
into
having
a
basically
like
a
cert
cluster
I,
don't
know
a
better
word
for
it
and
and
a
pipeline
cluster,
and
the
pipeline
cluster
is
very
easy
to
helpify
and
use
git
Ops
to
manage
and
all
that
stuff,
because
it's
all
super
configurable.
B
And
if
it's
right
in
with
kind
of
the
concerns
that
you
were
talking
about
on
the
pipeline
management,
but
the
other
piece
is
not
like
as
an
example:
cert
manager
cannot
be
embedded
as
a
sub-chart
like
they
just
they.
They
well
the
doc's
kind
of
weird.
It
starts
off
telling
you
that
never
do
this
and
it
explains
exactly
how
to
do
it,
but
you
shouldn't
really
be
doing
that
it
kind
of
it's
a
cluster-wide
configuration,
so
you
don't
really
want
to
be
managing
that
separately.
So
we
anyway,
that
was
one
big
thing.
B
I
just
wanted
to
kind
of
talk
through
with
some
of
the
maintainers
just
if
that
kind
of
makes
sense,
if
it
would
be
useful
if
we
took
our
Helm
chart
and
pushed
it
up
into
open,
open
source
for
the
pieces
that
are
there
and
then
just
general
thoughts
around
that
other
piece,
the
the
cert
cluster,
again
name
pending
with
some
of
the
stuff
that
that
we
were
hitting
separately
just
the
interaction
with
the
cluster
when
it's
in
a
production
namespace
is
not
something
you
generally
want
most
I,
think
devs
touching.
B
So
this
just
got
into
how
how
the
interaction
between
the
pipelines
and
everything
worked
and
who's
managing
and
how
and
how
how
that
works
again.
I
think
there's
different
models
for
this.
We
certainly
did
one
particular
way
for
the
deployment
that
we're
working
on
here,
but
I
think
it's
kind
of
the
list
of
General
concerns.
I
just
want
to
start
talking
through
with
some
folks
who
you
know.
B
C
Think
one
of
the
other
I
know,
questions
and
I
know
Brandon's
not
here
to
speak
up,
but
you
know
so.
I
know
that
there
was
also
some
questions
because
there's
a
couple
of
things
that
we
are
currently
doing
from
a
Dev
capacity
like
deploying
out
Vault
inside
the
same
cluster
as
as
the
actual
stuff
and
and
obviously
from
the
architectural
diagrams.
C
We
want
to
have
things
like
the
the
Spire
server,
as
well
as
the
Vault
server
in
a
separate
cluster,
and
so
have
you
given
any
thought
to
some
of
that,
because
obviously
that
would
not
all
be
one
chart.
B
Yeah,
well,
that's
what
I'm
saying
is
like
because
I'm
not
entirely
sure
if
we
want
to
even
tackle
that
problem.
As
part
of
this,
like
the
Fresca
setup
like
we
might
just
want
to
say,
use
these
things
and
then
the
Fresco
the
Fresca
Helm
chart
can
just
have
it.
It
needs
a
spider
agent
and
it
needs
a
config
for
what
to
point
to.
B
So
I
I
think
it
was
just
scoping
of
Fresca
in
a
production
deployment
is
a
little
different
than
it
currently
looks
and
yeah
effectively.
It
means
cleaving
that
stuff
off
into
a
separate
externalized
component,
but
yeah
I.
Don't
necessarily
think
you
would
manage
that
other
cluster
with
a
Helm
chart.
It's
just
not
how
it
goes.
The
reason
is
a
lot
of
that.
Other
config
is
cluster
level
crds.
That
really
can
only
be
touched
once
and
if
you
mess
them
up
by
running
a
Helm
chart
again
you're.
B
Not
a
great
mechanism
for
home
that
part,
so
I
I
think
how
we
were
going
to
do
it
was.
B
We
were
basically
just
going
to
manage
that
a
separate
way
like
that's,
basically,
a
one
undone
back
it
up
have
some
have
some
scripts,
maybe
maybe
some
something
like
Argo
or
run
Helm
to
get
things
like
certain
manager
stood
up
and
then
from
there
it's
it's
effectively
part
of
the
infrastructure
that
connects
to
our
Fresca
cluster
and
in
that,
but
yeah,
it's
something
to
to
think
through
a
little
bit
it
just
some
of
some
of
those
other
components
are
a
little
bit
dangerous,
especially
when
you
call
it
colic
Polo
picked
them
because
it
goes
they're
quite
brittle
foreign.
B
Yeah,
it's
probably
worth
taking
a
look
at
like
the
cert
manager,
Helm
chart
and
kind
of
list,
the
warnings
that
are
in
there
and
then
just
how
it
works
and
some
of
the
issues
and
what
happens
if
you
run
it
twice
like
it's
the
things
things
like
things
like
that
are
kind
of
what
drove
us
to
to
split
it
all
out
and
I
yeah,
but
yeah
kind
of
it
just
kind
of
kind
of
sent.
This
mindset
of
like
there's
one
set
working
on
Fresca
itself
as
a
product.
B
It
makes
total
sense
to
co-locate
the
software
together,
make
it
make
it
scriptable
put
it
in
mini
Cube
or
whatever
you
want
to
do,
that.
That
makes
total
sense,
but
yeah
completely
a
completely
separate
Playbook,
and
what
you're
actually
talking
about
when
you're,
really
running
it
for
real
is
a
probably
something
that
we
can
start
contributing
a
little
bit
at
least
documentation
to
our
initial
thoughts.
If
what
we're
saying
actually
lines
up
with
what
people
want
to
do,.
C
Yeah
yeah
no
I
definitely
want
to
hear
folks
like
Brad
and
Brendan's
sort
of
input
on
that,
because
I
know
like
some
of
the
other
things
that
I
know
are
also
becoming
bigger
issues,
and
it's
something
Brandon
wants
to
bring
up.
He
obviously
has
a
conflict,
so
he
couldn't
make
this
one,
but
one
of
the
things
was
I
believe
like
with
kieverno
like
upgrading.
C
Kyverno
is
a
non-trivial
thing,
and
a
few
of
the
other
things
are
are
just
very
much
non-trivial,
even
with
in
like,
if
you
have
a
Helm
chart,
it's
just
like
the
way.
A
lot
of
these
things
are
set
up
and
then
also
stuff
like
the
cert
manager
and
yeah
yeah
like
upgrading
it.
You
know
all
this,
you
know
one
because
it's
it's
so
I
think
on
that
end.
It's
also
part
of
that
same
conversation
of
like
hey.
C
Not
only
do
how
do
we
deploy
this,
but
then
how
do
we
sort
of
upgrade
in
a
reasonable
way,
given
that
right
now,
obviously
most
of
our
work
has
been
just
purely
Dev
and
when
we
kind
of
run
into
an
issue,
we
just
say
whatever:
I'll
just
kill
the
mini
Cube
or
whatever,
like
the
k3s
and
and
spin
up
a
new
one,
but
obviously
folks
who
are
running
you
know
eventually,
when
we
want
to
start
releasing
this
and
and
people
are
gonna,
hopefully
release
this
into
production,
I'm
sure
they're
going
to
have
questions
and
concerns
about
like
Hey.
B
Yeah,
it's
all
it's
all
the
those
are
all
the
same
kinds
of
concerns
that
we
had
even
in
just
trying
to
to
script
it
at
all.
So
it's
all.
It's
all
the
same.
The
same
thing,
yeah,
yes,
I,
definitely
think
we
have
to
talk
with
with
those
folks
about
about
what
we're
thinking
and
and
go
from
there.
F
Was
it
somewhat
relevant,
I
missed
the
intros
earlier
sorry,
I
used
to
be
a
little
bit
more
active
in
these
meetings.
Back
may,
but
have
a
11th
month.
Old
at
home
is
eating
up
a
little
bit
more
of
my
time,
but
a
while
ago,
I
opened
an
issue
in
the
repo,
regarding
kind
of,
like
an
example,
get
Ops
directory
to
be
able
to
deploy
the
Fresca
stack
with
something
like
flux,
so
I
kind
of
had
the
idea
of
what
about
a
directory.
F
B
Yeah
we
could
we
could
we,
we
have
we'd
have
to
scrub
it,
but
we
were
using
Argo
to
do
a
similar
thing.
You
know
just
get.
Ops
drive,
drive
the
drive
the
config
and
then
and
then
push
the
trigger
the
helm
chart
that
we
wrote
up
to
configure
pipelines
and
all
that
stuff.
B
So
that
would
be
interesting
to
folks.
We
could
always
show
that
next
time
again,
we
have
to
scrub
out
a
little
bit.
It's
a
client
not
comfortable
having
their
their
stuff
out
there,
but
yeah.
That's
a
similar
idea,
that's
kind
of
where
we
landed,
and
there
was
that
plus
just
the
addition
about
like
what
actually
is
Fresco
when
you're
configuring
it.
That
way.
B
Would
that
be?
Would
that
be
something
you
might
take
a
look
at
or
I
can
also.
We
can
also
do
it
offline.
If
you
wanted
to
compare
notes.
A
C
Which
we
know
is
not
really
in
in
a
sort
of
production-ready
state
yet,
but
we're
hoping
in
the
coming
months
to
to
make
it
more.
You
know
reasonable
we'd
love
to
hear
like
folks,
like
their
challenges,
use
cases
as
well
as
we
try
and
sort
of
you
know,
build
this
out
and
also
I
know
it's
one
of
the
big
things.
C
That's
been
coming
out
up
a
lot
in
recent
openssf
meetings
generally,
which
is
just
like
hey,
like
you
know,
with
some
of
the
tools
that
we're
sort
of
doing
like
what
sorts
of
things
are
people
actually
looking
for
in
some
of
these
things.
You
know
some
of
the
folks
and
then
this
also
goes
like
this
goes
for
stuff
like
secure,
build,
which
we're
trying
to
do
here
with
Fresca,
as
well
as
like,
what's
actually
running
in
the
secure
build.
C
A
A
C
If,
if
there's
nothing
else,
we
can
end
it
about
20
minutes
early
and
probably
see
you
all
in
a
few
weeks.
Actually,
when
is
our
next
meeting
I
want
to
make
sure
that
it
doesn't
overlap
with
like
New
Year's
or
something
actually,
probably,
it's
probably
worthwhile
to
cancel
the
next
meeting?
Isn't
it
yeah.
C
Yeah
so
I'm
sure
a
lot
of
folks
are
going
to
be
off
between
sort
of
the
at
least
here
in
the
U.S,
between
the
sort
of
Christmas
holiday
and
New
Year's.
A
lot
of
folks
just
have
off
around
then
so
CEO,
probably
in
January
and
I'll
I'll,
make
a
note
of
it
in
the
slack,
as
well
as
reach
out
to
open
ssf
to
to
show
a
cancellation
for
the
next
meeting.