►
From YouTube: 2020/01/19 - Distribution Maintainers Meeting
Description
Distribution Maintainers topics for the month
A
A
A
The
agenda
document
is
the
same
as
it
had
previously
been
for
maintainers
meetings
and
it
is
linked
in
the
calendar
invite
as
well
so
the
first
topic
I
have,
I
actually
want
to
put
to
the
end
of
the
meeting,
but
it's
to
do
with
meeting
cadence
and
how
often
we
want
to
have
this
meeting
so
just
something
to
keep
in
mind
as
we're
going
through
today's
topics
when
we
get
to
the
end.
I
think
that
that
should
be
the
discussion.
A
That's
I'm
proposing
that
to
be
the
discussion
that
we
end
the
meeting
on
today,
the
next
item
on
the
agenda.
This
was
just
a
heads
up
on
how
the
list
of
mrs
obviously
being
that
this
is
now
instead
of
a
weekly
meeting.
This
is
now
monthly
meeting
and
released.
It
was
supposed
to
be
a
monthly
meeting
at
this
cadence
and
then
it's
been
more
like
a
month
and
a
half,
so
not
all
of
the
mrs
that
went
in
in
the
month
and
a
half
went
into
the
list
below.
A
So
I
was
just
mentioning
here
in
the
topic
that
for
my
own
items,
I
basically
went
through
the
distribution,
maintainers
channel
and
reposted
any
of
the
merge
requests
that
I
called
out
of
my
of
my
own
there
and
that
that
was
kind
of
my
process
for
that
and
then
in
terms
of
this
meeting,
and
why
put
them
there
here
or
here
in
this
meeting
at
all
just
kind
of
re-engage
on
things
we
we've
posted
in
the
maintainers
channel?
My
hope
is
that
the
maintainers
channel
is
like
the
first
place.
A
We
post
it,
but
of
course
that's
not
a
way
to
like
document.
These
things
were
discussed
or
anything
like
that,
as
we
eventually
will
lose.
Those
conversations
so
bring
rebringing
up
here
in
the
meetings
just
to
make
sure
that
we
have
a
second
go
round
at
ones
that
maybe
didn't
get
seen
or
didn't,
or
maybe
they
didn't
get
any
maintainers
feedback
on.
A
A
A
A
We
have
our
defaults
file,
which
is
fine,
but
then,
when
it
comes
to
configuring
omnibus,
based
on
other
config
that
the
user
has
provided
so
the
user
provides
something
and
then
based
on
that
configuration,
we
know
to
set
a
bunch
of
other
things.
We
kind
of
have
two
methods.
One
is
within
the
service
library
files.
A
We
typically
have
a
convention
of
a
parse
variables
method.
That
goes
and
does
that
kind
of
more
in
a
ruby
type
fashion,
and
then
we
also
you'll
see
sprinkled
throat
recipes
in
recipes
themselves.
You'll
see
calls
to
default
to
do
those
overrides.
So
we
have
these
kind
of
two
different
practices
and
we
want
to
make
it
consistent.
There's
already
some
conversation
there
in
that
item
about
how
we
want
to
do
that.
It
was
kind
of
like
whether
we
went
one
way
or
the
other.
A
I
think
I
think
we've
basically
come
to
the
conclusion
that
we
want
to
do
the
in
recipe
style,
but
we
don't
want
to
do
it
in
the
further
down
recipes.
We
want
to
do
it
like
right
away
as
kind
of
the
first
thing
after
configuration
is,
is
figured
out
that
we'd
start
running
through
the
rest
of
this
parts.
Config.
B
A
So
it
was
and
then
it
also
with
it
refreshed.
So
that's
how
the
conversation
restarted
up
was
through
the
tech
that
review
and
then
further
down
this
maintainer
list
you'll
see
a
mention
of
the
last
one
at
the
bottom,
which
we,
I
guess
we
can
jump
to
right
now
is
public
activities
may
not
be
generated
when
reconfigure
fails
in
the
middle
of
it.
A
So
the
I
think
at
this
point
we've
come
to
the
point
where
the
proposed
solution
for
this
first
item
making
the
the
attributes
consistent
is
now
a
prerequisite
to
fixing
the
or
with,
in
the
current
plan,
at
least
the
fact
that
the
public
attributes
aren't
generated
when
we
configure
fails
or
not
fully
fixing
but
improving
the
situation
so
yeah.
It
was
initially
a
tactic
item
and
now
it's
a
bit
of
a
blocking
other
items.
A
A
A
This
is
just
about
providing
another
way
through
of
environment
variable
now
to
disable
auto
migrations.
This
is
for
an
improvement
in
the
geo
documentation
where
they
currently
have
to
disable
migrations
run
migrate.
Do
the
replication,
re-enable
migrations
and
run
reconfigure
again.
Sorry,
do
I
say
run
migrate,
I
meant
run
run
reconfigure,
disable
migrations,
run,
reconfigure,
run,
replication,
re-enable
migrations
and
run
reconfigure
again.
A
A
C
C
The
the
long
of
it
we
have
it
referred
to
as
task
runner
from
the
beginning,
because,
basically,
when
you
need
to
go,
do
something
inside
the
application,
you
go
run
that
inside
of
this
little
task
container.
Hence
task
runner,
but
renaming
it
to
some
sort
of
console
or
thing
makes
some
sense
to
me.
But
can
I
because
I'm
so
close
to
the
project?
I've
never
screwed
up
which
runner
was
which
so.
D
Because
gke
has
like
this
command
that
you
get
on
all
your
notes
called
toolbox,
which
spins
up
a
container
that
has
a
bunch
of
utilities
that
you
can
use
for
troubleshooting.
This
is
how
like,
if
you
ssh
to
one
of
their
nodes
or
once
in
one
of
the
gke
nodes,
and
you
need
to
do
some
maintenance,
like
let's
say
you
need
to
run
s
trace
or
something
on
one
of
the
processes.
D
A
Yeah,
so
I
think
I
think,
we're
kind
of
like
saying
we're
we're
good
with
changing
the
name,
we're
still
looking
for
a
good
name
and
probably
the
change.
I
imagine
it's
not
really
pressing.
This
is
probably
like
the
next
major
revision
type
thing.
Once
we
figure
out
the
name,
I'm
bidding,
that's
where
we
kind
of
target
right.
C
And
we'll
have
to
communicate
that
we're
renaming
this,
because
there
are
people
that
have
some
amount
of
automated
behaviors
around
this
or
their
run
books,
and
especially
when
we
start
changing
primary
container
names.
We're
gonna
have
to
let
them
know
that,
hey
by
the
way,
your
your
pvc
name
may
change
your
bindings
may
change
your
rbac
may
change,
because
you
manually
did
that,
so
we
need
to
give
them.
You
know
two
or
three
releases
to
get
the
warning.
A
Yeah
so
feel
free
to
continue
leaving
suggestions
for
names
in
that
issue.
The
next
one
is
replacing
erb
with
something
else
for
configuration,
template
behaviors,
I
think
we're
also.
This
is
another
case
where
we're
we're
at
the
point
where
I
think
yes,
that's
what
we
want
to
look
into
doing
and
it's
more
of
a
we're.
Looking
for.
A
C
Essentially,
this
needs,
as
dj
said,
explored.
We
need
to
do
a
base,
research
spike
and
see
what
we
can
and
can't
do
and
then
look
into
what
this
will
end
up.
Breaking
out
to
this
is
a
straight
up
proposal.
It
will
should
we
go
down
this
route
and,
in
my
opinion,
obviously
we
should.
It
will
be
broken
into
one
or
more
epic
and
a
number
of
issues
created
from
that
one,
because
we
have
to
do
exploratory,
we
have
to
find
out
which
containers
actually
need
to
be
modified.
C
B
C
A
A
Typically,
a
bunch
of
the
attribute
files
gets
deleted
at
the
beginning
of
reconfigure,
and
then
they
get
recreated
at
the
very
end.
That's
so
that's
with
the
basic
node
attributes
file.
We
also
have
our
own
public
attributes
file,
which
is
one
that
we
use
in
several
of
the
commands,
such
as
the
the
pg
bouncer
notify
for
notifying
a
new
postgres,
backend
and
stuff
like
that
that
rely
on
this
file
being
available.
A
The
problem
with
it
the
public
attributes
file
coming
at
the
end,
is
that,
if
reconfigure
fails,
none
of
the
rest
of
the
commands
have
any
idea
of
your
configuration.
So
the
proposal
here
in
this
issue
is
to
render
out
that
file.
Basically,
as
as
soon
as
we
have
all
this,
as
long
as
the
rake
figure
has
gotten
far
enough
to
parse
all
of
the
config,
it
doesn't
necessarily
have
to
have
successfully
written
out
or
done
all
of
its
work.
A
E
But
how
will
we
ensure
item
potency
like
what
is
the
command
gitlab
control
command?
That
is
using?
This
value
expects
the
value
to
be
present
on
the
node.
What
if
we
configure
failed
before
doing
that?
How
how?
How
do
we
ensure
the
control
command?
Gitlab
control
command
is
getting
the
correct
value.
E
Public
attributes
has
one
value,
but
we
have
no
guarantee
that
value
is
what
is
applied
on
the
node
right.
We
populated
it,
but
the
comp,
the
chef
chef
friend
didn't
complete.
It
didn't
get
applied
to
the
node.
How
would
we
ensure
the
command
is
working
on
actual
values,
not
just
something
computed.
E
F
F
F
A
Yeah,
so
the
current
issue
we're
running
into
is,
of
course,
with
petroni
and
we've
added
a
new
ctl
command
and
during
the
reconfigure
run
we
sometimes
call
that
command,
but
that
command
also
depends
on
public
attributes
that
reconfigure
would
have
to
have
created
so
yeah.
We
have
created
chicken
in
an
egg
problem
yeah
at
this
point,
so
the.
A
F
A
E
A
A
C
A
Yeah
and
then
I
think,
last
week
we
had
it
coming
from
a
couple
different
directions
as
well
as
well
as
as
issues
with
the
the
charts
in
production
as
well,
because
there
was
a
cloudflare
issue
last
week
and
things
other
than
gitlab
were
down
and
all
of
a
sudden
dependencies
are
are
dependencies.
That
weren't
on
registry.getlab.com
were
not
working.
C
A
C
C
A
C
I
have
a
number
of
items
here
that
are
basically
follow-up
listing
from
a
lot
of
changes.
In
december.
There
have
been
a
couple
things
that
happened
very
recently.
I
don't
have
really
anything
else
to
call
out
other
than
to
watch
out
for
major
version
upgrades
and
the
changes
coming
in.
Regards
to
gitlab
pages
balo
has
been
instrumental
in
getting
the
primary
functionality
to
configure
gitlab
pages,
deploy
gitlab
pages
and
now
we're
looking
into
the
extended
attributes
of
access,
control
and
oauth.
A
Yeah
from
my
side,
what
I
wanted
to
call
it
in
charts
one
is
that
we
we've
switched
to
helm
three
in
the
review.
Apps
so
be
aware,
if
you
need
to
access
the
ci
clusters
and
check
out
the
releases
or
do
any
fixes
there,
the
eks
or
the
gke
cluster
that
you
need
to
now
be
using
the
helm,
3,
binaries
and
no
longer
use
helm2
or
the
tiller.
So
tiller
is
still
sitting
in
the
clusters,
but
it
should
have
no
releases
in
it.
Currently.
A
The
other
one
is
a
round
gitlab
shell,
so
in
our
master
branch
in
the
charts
we
are
now
pointing
at
the
get
lab
shell
main
branch,
so
github
shell
has
made
the
move
from
master
to
main
and
that's
just
something
to
be
aware
of,
and
shell
should
be
using,
that
through
gitlab,
but
other
other
projects
will
probably
be
making.
This
switch
as
well.
A
That's
it
for
me
on
charts
for
things
I
wanted
to
call
out
on
the
omnibus.
I
wanted
to
call
out
that
the
we've
been
continuing
to
move
some
of
the
items
out
of
the
get
lab
cookbook
into
their
own
cookbooks.
So
in
this
last
release
we
did
the
pg
bouncer
exporter
recipes
have
been
moved,
so
just
be
aware
of
with
this
release,
issues
that
might
arise
from
that
and
then
also
we
had.
We
did
do
a
major
petronie
upgrade
from
my
testing.
A
It
was
fully
backwards
compatible
with
the
previous
one
and
could
be
used
in
a
mixed
environment.
Wanted
to
call
that
out.
Then
we
went
from
like
a
164
to
a
201
and
then
also
a
change
that
we
haven't,
that
we've
made
in
the
builder
docker
files,
but
haven't
ruled
we
haven't
started
using
it
in
the
ci.
A
A
End
here
and
if
anyone
has
any
questions
about
the
ones
listed
in
the
gitlab
operator,
please
post
in
the
maintainers
meeting
channel,
and
then
we
didn't
get
a
chance
to
talk
about
the
meeting
cadence.
So
I
will
as
soon
as
I
can.
I
will
kind
of
start
a
conversation
in
the
distribution
maintainers
channel
and
we
can
discuss
the
cadence
there
and
we'll
get
the
next
one
scheduled.