►
From YouTube: Foundational Infrastructure Working Group [Nov 4, 2021]
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
welcome
all
to
the
second
foundational
infrastructure
working
group
meeting.
Let's
see
we
have
an
agenda,
let's
do
attendees
didn't
do
that.
Last
time.
A
B
A
No
problem:
okay,
yeah,
let's
dive
straight
in
so
there
was
there's
a
pull
request
currently
for
the
or
stem
cell
builder,
and
in
the
bosch
stem
cell
builder.
We
have
multiple
branches
for
different
stem
cell
lines,
but
it's
the
same,
pull
requests
but
for
the
same
code
and
then
against
three
different
branches.
A
So
we
have
two
three
pull
requests.
How
do
we
wanna
deal
with
those
issues
with
those
in
the
future?
So
currently
I've
just
assigned
reviewers
to
all
of
them,
but
I
actually
screwed
up
a
bit
because
I
assigned
baon
to
review
the
senior
stem
cell,
which
is
actually
something
only
vmware
still
ships.
So
I
mean
that
doesn't
make
sense.
I
mean
it's
all
the
same
but
yeah.
A
So
maybe
it
can
make
more
sense
to
in
the
future,
have
one
pull
request
and
then
maybe
some
tag
to
up
merge
the
pull
request
later
or
something
or
backboard
or
cherry
pick
or
whatever,
but
that
we
just
go
through
the
review
cycle
once
any
ideas
or
opinions.
C
C
C
A
D
I
feel
it's
a
matter
of
understanding
the
requirements,
whether
keeping
separate
branches
makes
sense
or
but
what
we've
seen
with
raman
lately
is
that
I
had
pushed
some
changes
in
master
branch,
bionic
master.
If
I
remember
correctly,
then
I
had
to
match
that
into
the
bionic.
F
D
X
by
an
equal,
node
x
and
then
and
cherry
picked
that
to
the
values,
senior
branches,
as
you
told
me,
reuben
and
yeah.
That
was
quite
complex
and
we
thought
at
least
bionic
master
and
by
enigma
x,
why
the
hell
have
separate
branches,
and
it
seems
to
me
also
that
one
issue
was
related
to
resource
tracking
in
in
terms
of
os
images.
D
Their
references
are
written
in
various
branches,
though
those
things
make
the
branches
divert
diverge
and
possibly,
if
there
was,
this
could
be
located
in
a
separate
repository
for
stage
tracking
or
something
that's,
I
think
yeah.
But
it's
a
matter
for
me
of
gathering
the
requirements.
How
we
want
to
manage
stem
cells
lines.
C
Well,
why
why
it
was
a
separate
stem
cell
line
is
because
for
each
new
major
major
boss
agent,
basically
for
each
new,
a
major
boss
agent,
there
was
created
a
new
new
stem
cell
and
for
the
bosch
agent
they
also
did.
They
also
had
lines
where
they
did
cherry
picking,
and
so
that
was
where
this
whole
lining
stem
cell
lines.
Stuff
is
coming
from.
A
A
That's
why
we
have
separate
lines
I
think
signed
urls,
for
example,
is
something
that
doesn't
work
with
the
older
stem
cells,
the
400
series,
or
maybe
I'm
confused
there,
but
at
least
like
so
it
was
introduced
in
a
line
right.
It's
like
a
a
new
thing,
so.
C
A
F
A
And
you
need
to,
I
mean
actually,
to
be
honest,
I
think
we
should
only
like
review
things
to
the
bionic
branch,
because
the
senior
stuff
is
actually
proprietary
vmware.
So
it's
not
proprietary,
but
I
mean
vmware
is
the
only
one
shipping
it
right,
so
it
feels
a
bit
strange,
maybe
to
spend
community
resources
reviewing
those
changes
there
like
it's
up
to
the
vmware
team
to
backboard
exchanges.
I
think.
C
A
I
mean
like
these.
The
the
changes
going
into
xeno
should
ideally
first
go
into
bionic
right
and
then
get
back
ported.
So
also
if
new
features
are
being
developed
by
vmware
for
the
xenial
stem
cell,
they
should
go,
be
developed
against
bionic
and
then
be
backboarded
to
continue,
because
otherwise
we
have
diverging
branches.
F
It's
I
added
this
to
the
notes.
I
wasn't
sure
how
we
handled
the
spire
list.
There
is
someone
asking
about
the
release.
A
Yeah,
so
what
I've
I
mean,
the
ci
is
still
in
in
being
within
vmware
right
for
this
one,
so
I
would
just
put
a
story
in
the
backlog
to
do
this,
that
we,
it's
just,
I
think
something
that
slipped
through
the
cracks.
So
I've
done
the
same
for
the
director
got
the
director
story.
A
Just
share
number
of
pipelines
and
also
well
that's,
like
the
eyes,
are
only
four
right
yeah,
but
I
mean
it's
also.
The
resources
right.
C
A
Accounts
for
all
the
iss,
especially
openstack,
is
going
to
be
painful.
C
A
D
D
D
D
But
we
have
we
an
easy
way
to
share
those
credentials.
Are.
C
C
Cr,
so
basically,
if
you
are
a
member
of
the
when
you
are
in
the
gcp
project,
a
member
of
the
gcp
project
for
for
bosch,
then
there
is,
there
is
a.
There
is
a
google
secrets
and
basically
the
secrets
for
the
email
for
aws
are
all
in
there.
C
You
can,
basically,
you
have
full
admin
access
for
aws.
I
wanted
to
keep
it
because
we're
not
using
aws
that
much
so
I
was
trying
to
not
to
give
everyone
access
to
aws,
but
at
some
point
I
just
put
the
secrets
in
there.
So
if
you
have
full
access
in
the
gcp
project,
you
can
also
just
easily
go
to
ews.
A
C
A
Maybe
that's
something
to
discuss
with
the
tsc.
I
don't
know
like.
I
assume
that
that
role
like
being
an
approver
means
that
you
will
be
able
to
yeah,
have
access
to
ci
or
at
least
to
the
other
resources
that
are
used
by
ci.
C
A
Wait
for
until
we
have
like
a
real
example
where
someone
actually
needs
access,
and
then
we
can
give
access.
Does
that
make
sense
yeah?
Let's
I
will.
I
will
bring
it
up
with
a
dlc,
let's
figure
out
what
they
what
they
think
about,
that.
D
F
A
Yeah,
I'm
still
flying
for
a
favor
of
switching
to
get
lfs
for
everything,
because
that
solves
that
issue.
But
that's
also-
and
so
that's
something
we
did
for
the
virtualbox.
Apparently
yeah
virtualbox
api
yeah,
but
we
did
it
there
in
a
quite
a
breaking
way.
We
didn't
care
about
previous
blobs.
We
just
wanted
to
move
forward
since
it's
not
like
something
where
people
actually
use
older
versions
of
the
cpi,
but
ideally
migrate,
the
blobs
to
get
rfs.
A
A
So
that's
so
people
making
pull
requests,
aren't
or
don't
have
to
pay
for
it,
which
is
kind
of
nice.
D
Oh
yeah,
I
I
thought
guitar
fs
was
free
well,
at
least
for
the
projects,
the
the
releases
I've
made
using
gtlfs
right.
You
don't
pay
anything.
C
C
A
So,
let's
go
over
the
board
quickly,
so
here's
two
things
that
are
blocked
they're,
both
waiting
for
bosch,
boss,
release
of
the
voice
director.
Then
these
should
be
able
to
get
merged.
A
A
Yes,
yeah,
it's
quite
a
nice
find
yeah.
They
created
tests
as
well.
That
doesn't
work
but
need
some
more
work.
So
this
one
is
waiting,
but
there's
also
another
pull
request
from
baehan
that
addresses
the
things
discussed
here.
So
I've
asked
kenneth
to
look
at
what
beyond
did,
which
is
this
one.
Kenneth
is
not
an
approver,
but
he
was
involved
with
the
original
pull
request.
So
I
thought
maybe
it's
nice
for
him
to
also
get
a
say
in
that.
D
Yeah
we've
presented
things
a
little
bit
differently.
I've
participated
to
that
pr
either
pushing
my
suggestion
for
a
caption
yeah
yeah.
D
Which
is
kind
of
georgian
party,
I
mean,
I
admit.
A
Yeah,
that's
fine,
but
I
I
still
want
kenneth's
opinion
there,
because
it
was
part
of
the
good
discussion
and
then
all
these
c
group
ones
are
part
of
the
same
thing
that
we
discussed
earlier.
Those
are
the
three
pr
pr's
for
the
porsche
linux
stem
cell
builder.
A
Was
made
these
were
made
by
constantine?
The
idea
here
is
to
limit
access
to
the
nets
to
nets
from
the
from
all
the
vms
deployed
by
porsche,
so
that
yeah
I
mean.
D
A
A
Right
that
was
this
point
we
said
like
for
in
the
future,
just
create
an
pr
against
bionic
and
then
bionic.
A
Where
people
should
backboard.
D
A
So
this
one
is
the
against
bionic
master.
Oh.
C
A
A
C
Changed
the
way
how
for
the
certificates,
of
course,
the.
A
C
A
Right
and
I
mean
on
cloud
foundry-
that's
not
a
problem
because
cloud
foundry
limits
access
there
right.
You
cannot
access
that
but
like
if
there's
some
other
workloads
running
and
that
doesn't
limit
access,
then
you
might
want.
So
it's
more
about
like
having
same
defaults
here.
C
A
A
So
that's!
This
was
a
following
of
that.
Okay,
we
discussed
this
one
and
this
one
already
got
merged.
I
don't
know
why
it's
still
on
the
board,
but
yeah
lots
of
stuff
got
merged
quite
happy
with
that.
Still
won't
would
be
nice
to
have
some
some
sort
of
performance
dashboard
where
we
can
track
how
many
things
we
merge
every
week,
but
yeah.
I
think
this
should
I
mean
there's
no
blockers
here.
This
should
all
go
through
pretty
quickly,
so
yeah.
D
Yeah
for
constantine
prs,
I've
reviewed
the
wrong
one
then
because
I've
missed
the
one
on
bionic.
Yes,
should
I
put
my
review
to
the
correct
prr.
F
D
A
D
A
B
Yeah,
I
was
about
to
say
something
very
quickly,
two
things
actually
the
first
one
about
when
ruben
said
it
would
be
nice
if
we
could
like
measure
some
of
this
stuff.
Back
in
time
when
I
was
working
on
the
bosch
team,
I
experimented
with
this
tool
called
openhub
where
you
can
create
a
project
and
you
can
associate
all
the
github
repos
that
you
want
to
track
and
it
gives
you
a
bunch
of
cool
metrics,
so
just
paste
the
link
in
the
dock
as
a
suggestion.
B
Apparently,
but
hopefully
you
can
see
that-
and
this
is
the
project
I
had
created
back
in
time
for
bosch.
So
maybe,
if
you
had
to
experiment
with
that,
I
don't
know
like
if
the
tool
gives
you
the
metrics
you
want,
but
you
could
create,
for
example,
a
project
for
the
working
group
with
like
all
the
repos,
and
then
you
can
track
the
activities
and
hopefully
like
open
brs
and
issues,
and
things
like
that.
B
So,
just
in
case
you
want
to
have
a
look,
and
the
second
thing
I
would
like
to
add
is
that
I
just
checked
the
working
groups
page
that
ruben
you
shared
with
us
on
the
cryogenics
team,
but
just.
F
F
B
We've
been
added
as
approvers
in
other
working
groups,
for
the
components
that
we
are
currently
looking
after,
but
we
haven't
been
added
in
this
working
group,
so
I'll
create
a
pull
request
and
I'll
send
it
over.
So
just
so
that
you
know
when
it
hits
you
what
this
is
about.
A
So
you
will
split
out
a
separate
area
for
disaster
recovery
and
put
your
names
as
approvers.
B
D
All
right
and
so
you're
working
in
with
all
the
bbr
stuff
or
in
which
team
are
you
working
with.
B
Is
looking
after
components
where,
when
vmware
does
not
want
to
add,
like
any
new
features,
for
example?
But
you
know,
like
these
components
are
still
being
used
by
customers
and
we're
still
sort
of
a
packaging
this
component.
So
we
need
them
to
be
patched
and
we
need
like
to
look
after
them.
B
So
you
need
to
learn
and
react
and
like
keep
betraying
we're
doing
the
opposite,
because
we're
optimizing
to
like
a
different
type
of
problem
and
I'm
talking
with
my
hands
and
I'm
just
destroying
my
desk
here,
but
we're
just
making
sure
that
we
can
like
keep
these
components
well
patched
and
then
secure
and
look
after
those
and
maybe
in
the
future.
The
company
will
want
to
add
more
features.
B
And
then,
like
you
know,
the
component,
the
components
are
there
and
they
are
ready-
and
we
have
this
metaphor-
that
we
call
the
freezer
so
like.
Currently,
these
components
are
in
the
freezer
and
then
like,
like
we're
not
adding
new
features
to
these
components,
basically
that
what
this
is
but
we're
still
like
patching
them
and
like
they
are
going
through
ci
and
they're.
You
know
like
okay
to
use
safe
to
use.
D
Your
question
yeah,
and
what
kind
of
big
components
do
you
have
in
this
team?
Quite
everything
related
to
the
what
we
used
to
call
pivotal
cloud
foundry
or.
B
It
depends
like
that.
There's
no
like
clear
cut
like
in
this
case
for
this
working
group
is
bbl.
B
D
B
D
B
F
Maybe
another
question:
do
what's
the
state
with
the
working
agreements,
we
will
have
global
working
agreements,
so
every
each
working
group.
A
They
were
proposed
by
amelia
last
week.
A
So
that
not
this
week,
let's
see
you
see,
there's
like
some
final
work
being
done
and
then
they
will
be
converted
into
pull
requests.
There's
a
document
for
that
probably
go
wrong.
F
A
There's
this
currently
there's
documents
or
where
you
can
ask
or
yeah
there's
discussion
going
on
here,
something
about
getting
github
teams
and
access.
I'll
put
this
in
the
chat.
Okay,.
A
Yes,
and
and
so
because
we
can
iterate
here
faster
or
something
that
was
the
idea,
and
then
this
will
be
converted
into
pull
requests.
There's
still
discussion
going
on
about
where
these
should
land,
but
they
will
probably
end
up
in
the
community
repo
and
then
they
will
apply
to
all
of
us.
A
A
So
that's
now
available
in
our
org
and
there
we
don't
have
that
limitation
of
so
there
you
can
have
pull
requests
across
different
organizations
and
you
don't
have
the
limit
of
25,
so
we
don't
have
to
use
notes
so
yeah.
Maybe
we
should
switch
to
this,
but
haven't
fully
investigated
that
yet,
but
I
will
be
working
on
that
as
well.
So
we
might
switch
to
this
because
here
you
can
have
different
views
right
so
a
few.
A
Yeah,
it's
nice,
I
mean
it's
more
flexible.
You
can
add,
like
your
separate
fields
like
you,
can
have
labels
here
as
well
milestones
repositories
filter
by
any
of
those
so
yeah.
I
think
it's
quite
powerful.
A
A
C
How
can
we,
by
the
way,
put
stillbot
that
it
ignores
a
specific
issue.
A
A
C
C
B
C
Like
where,
where
I
made
a
project
for
myself,
that
was
for
the
focal
focal
stem
cell
creation
and
now
every
14
days,
just
get
a
notification
dude
a.
A
You
can
have
a
draft
pull
request
right.
That's
that's
a
state
where
you're
still
working
on
it.
You
can
already
have
discussion.
Yeah.
A
A
A
A
All
for
attending
see
you
all
next
time.