►
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
So
we
are
discussing
the
terraform
registry
with
matt
who's
developing
the
back
end,
nicole
who's
gonna,
develop
the
front
end
into
the
package
product
designer
and
he's
familiar
with
the
product
design
of
the
packaging
registries
and
myself
the
configure
designer
who
I'm
I've
designed
the
server
for
registry
module
module.
Okay,
sorry.
B
No
worries,
so
that's
a
great
introduction,
so
what
we're
looking
at
here
is
just
a
a
sample.
Ci
configuration
for
publishing
a
module.
I
think
the
the
the
fi
the
ci
template
that
we
put
in
the
product
will
be
very
different
from
this,
but
you
know
the
usage
of
the
template
would
be.
You
know,
just
include
a
template
and
the
name
of
the
template
so
and
then
you
would
kind
of
get
some
of
this
stuff.
B
So
right
now,
I'm
just
you
know,
hardcovering
a
version,
but
you
could
base
it
off
of
tags
so
that
if
you
tag
it,
we
would
use
the
ci
commit
tag
variable
to
establish
what
the
version
should
be,
and
all
this
is
doing
is
using
tar
to
archive
the
contents
of
the
repository
and
using
curl
to
upload
it.
The
upload
for
terraform
module
works
very
similarly
and
is
based
off
of
the
upload
for
generic
packages,
which
work
like
this
as
well.
So
there's
just
a
curl.
B
The
endpoint
is
different,
of
course,
but
very
similarly
you
can
use
I'm
building
it
to
be
able
to
use
the
three
different
types
of
token
headers
private
token
deploy
token
and
job
token,
so
that
it's
easy
to
use
curl
for
this.
So
it's
a
very
simple
curl
command.
B
That
not
it's
not
a
rule,
I
think
that's
the
most
common
case,
that's
kind
of
the
it's.
It's
a
terraform
best
practice
to
have
a
single
module
per
repository,
but
I
can
tell
you
that
there's
a
lot
of
a
lot
of
mono
repos
out
there,
where
it's,
you
know
a
folder
per
per
module
in
a
single
repo.
B
It
could
yeah,
but
then
you,
wouldn't
you
probably
wouldn't
be
using
a
module
registry
in
that
case,
you'd
be
just
including
the
local
module
from
a
folder
path,
so
most
likely,
if
you're,
using
a
module
registry
and
you're
using
a
your
publishing
modules,
you're
most
likely
doing
it
from
a
repo
other
than
your
main
terraform
repo.
A
B
Yeah,
so
you
would
just
in
that
case
you
would
just
change
your
tar
command
to
archive
a
folder
path
or
something.
B
So
you
would,
you
would
do
a
tar
per
module
and
then
you
would
do
a
curl
per
module.
So
I
think.
B
A
B
But
in
this
case
we're
creating
verbose,
a
gzipped
file
and
then
you
can
change
into
a
folder,
so
you
could
like.
You,
could
go
into
modules.
You
know
module
one
and
then
archive
that.
B
B
A
D
D
A
B
Yeah
we
can
go.
We
can
go.
Look
at
the
front
end
next
after
this
kind
of
the
stuff
that
we
get
for
free
from
package,
which
is
actually
quite
a
bit
perfect.
A
First,
look
at
the
package
designs
and
then
maybe
what
bits
and
pieces
are
useful
for
terraform,
for
the
modules
are
everything
is
everything
applicable
or.
B
I'm
not
sure
so
we
can,
we
can
take
a
look.
I
don't
think
I
got
a
pipeline
to
run
off
of
that.
It
looks
like
the
commit
went
in,
but
something
went
wrong
and
it
didn't
doesn't
look
like
a
triggered
pipeline.
C
B
Something
is
broken
in
my
gdk.
I
guess
I
should
have
like
a
new
pipeline
button.
B
B
Basically,
the
the
project
id
will
come
from.
You
know
ci
project
id
variable
and
then
the
way
that
you
name
your
module
is
basically
the
module
name
right
here.
So
the
module
name
is
get
lab
file.
The
system
it
applies
to
is
local,
that's
a
terraform
thing,
and
then
you
have
a
version
and
then
we're
uploading.
The
file
for
that
version.
So
I'll
go
ahead
and
upload
0.8.
D
Do
you
have
any
uniqueness
constraints?
What
what
I'm
asking
this
is
for
in
the
group
level?
Will
this
generate
problems.
B
Is
something
I
think
we
have
to
talk
about?
I
think
what
we
want
and
I'm
not
sure
if
I've
gotten
this
working,
the
way
I
need
it
to
yet
is
we
want
the
we
want
the
package
name
and
version
to
be
unique
at
the
top
level
name
space.
B
D
B
Basically,
yeah
they're
they're
yeah,
the
so
the
the
packages
will
upload
to
a
project
but
the
way
that
terraform
queries
them.
The
only
thing
that
we
get
to
kind
of
scope
down
by
is
a
single
name
space
and
we
had
to
make
a
decision
whether
we
wanted
to,
like
you
know,
percent
2f,
encode,
all
the
slashes
to
drill
down
to
the
the
pro
the
actual
specific
project
and
what
we
decided
to
do
was
to
do
the
group
level
instead.
C
D
B
They
do
but
terraform
terraform
isn't
going
to
look
for
them
there.
So
the
way
that
terraform
references
modules,
if
I,
if
my
font
size,
is
too
small
just
let
me
know.
B
B
Go
ahead
and
delete
some
lines
that
have
commented
out
so
this
is
this
is
a
module
source
in
in
in
terraform.
So,
basically,
you
can
provide
a
host
which
is
getting
us
to
the
gitlab
instance.
B
It
then
does
service
discovery
based
off
of
the
host
to
find
out
the
api
endpoints
that
it
needs
to
use,
and
then
it
provides
a
namespace,
a
module
name
and
a
system
they
used
to
call
this
provider
and
they've
changed
to
calling
it
a
system
now,
basically
like
this,
would
be
like
local
or
aws
or
gcp
or
azure
like
this
is
the
it
it
used
to
correspond
one
to
one
to
the
provider
plug-in
that
was
being
used
by
the
like,
predominantly
used
by
the
module
and
they've
kind
of
tried
to
genericize
it
to
a
system.
B
B
C
I
ask
a
quick
question:
if
we
have
a
complicated
group
structure,
so
we
have
the
instance
a
group,
a
subgroup
and
then
multiple
subgroups
from
there.
Two
of
those
projects
in
those
subgroups
that
are
very
varied
both
have
their
own
unique
terraport
module
and
it
has
the
same
name
but
they're
in
two
different
projects
under
maybe
even
two
different
groups
under
the
main
group
like
if
we're
not
able
to
parse
down.
How
do
we
handle
that
identical
name
issue,
or
is
that
non-non-problem
with
terraform.
B
I
think
that's
what
I
think:
that's
what
nico's
talking
about
with
a
uniqueness
constraint.
So
I
think
that's
where
we
have
to
enforce
it
at
package
creation
time.
So,
if
the
first,
if
the
first
project
has
already
come
along
and
published
a
package
with
that
name
and
then
the
second
project
comes
along
and
tries
to
publish
one
with
the
same
name,
the
second
one
should
fail.
B
Yeah,
I
think
it
would
basically
be
incurring
the
the
group
packages
finder
call,
which
is
again
it's
scoped
scoped
to
the
top
level
namespace.
So
we
just
at
least
have
that,
but
like
we're
not
scanning
the
entire
instance.
D
The
reason
that
I
ask
do
you
plan
this
to
be
on
a
synchronous
operation
or
I
think,
because
packages
often
have
a
sync
operation.
So
you
accept
the
package
and
then
you
say
well.
We
will
kick
off
a
worker
and
then
decide
if
you
like
it,
yes
or
not,
or
you
plan
to
do
this
synchronously,
because
this
instead
has
impact
for
the
ui.
B
I
think,
and
I
think
right
now
it's
it
would
be
synchronous.
I
haven't
seen
an
example
of
of
asynchronous
with
package
creation.
I
may
have.
B
D
B
I
may
have
to
ask
for
some
help
figuring
out
how
they're
doing
how
they're
doing
it
asynchronously,
because
from
the
code
it
looked
like,
they
were
just
their
crate
pad
like
the
maven
crate
package
service.
Just
calls
create
package.
B
Okay
sounds
good.
Thank
you.
Yeah
I'd
love
an
example
of
that,
because
I
think
yeah
asynchronously
would
be
better,
but
just
in
case
that
the
group
package
finder
call
is
too
expensive.
B
B
A
Whether
it's
handled
in
the
back
end
or
front
end,
but
according
to
your
conversation,
I
figured
it's
handled
in
the
back
end.
But
if
we
have
a
list
a
list
of
modules,
it
could
also
be
handled
in
the
front
end.
By
checking
against
this
list.
B
Well,
I
think
it
has
to
be
backend
just
because
there's
no
there's
no
front
end
for
for
uploading
a
package
or
creating
a
package
for
this,
so
it
would
all
be.
B
B
Yeah,
I
think
right
now.
The
the
way
I
have
the
the
current
package
exists
check
is
not
the
way
that
we
want
it.
So
I
think
right
now,
it's
only
going
to
enforce
it
under
the
project.
So
it's
going
to
have
to
be
unique
in
the
project,
but
not
top
level
name
space.
So
that's
another
thing.
I
need
to
fix.
D
I
sent
you
the
package
manager
that
a
worker
to
process
the
file
on
slack.
They
asked
and
got
an
answer,
so
it's
new
get
going
and
so
cool
and
debian
and
ruby
gems
new
cat
is
the
released
one.
All
the
others
will
be
under
future
flag.
If
you
want
to
look
at
an
implementation
for
it,
cool
and.
D
B
Yeah,
it's
extracting
the
the
new
spec.
B
B
D
From
from
the
ux
point
of
view,
I'm
really
interested
in
point
three
of
the
agenda,
but
I
don't
want
to
hijack.
I
see
that
and
maria
are
typing,
so
you
totally
got
this
mika.
We
were
having
a
conversation.
A
Sorry,
let
me
ask
like
next
question,
but
I
think
I
have
the
answer.
I
think
I'm
going
to
jump
to
the
third
question
that
I'm
discussing
within.
So
in
my
original
designs,
I
had
created
a
separate
navigation
item
under
packages
and
registries
that
was,
infrastructure
registering,
and
I
was
asking
if
we're
gonna
increment
it
in
the
next
iteration
or
whether
it's
still
relevant.
A
I
haven't
checked
the
conversation.
I
think
that
ian's
referring
to
so.
D
Oh
no
go
ahead
nico,
so
we
can
actually
still
implement.
That
is
the
own
sidebar,
because
we
schedule
for
this
milestone
the
ability
to
to
store
the
type,
so
the
package
ui
as
a
as
a
filter
right
and
you
are
able
to
filter
by
type.
So
we
will
be
putting
that
in
the
url
and
so
the
sidebar
as
a
first
iteration
could
still
hit
the
package
registry
with
the
pre-field
on
the
type
terraform
and
that's
that's
we
can
achieve
on
the
first
iteration.
D
I'm
confident
that
I
can
work
with
mats
on
that
no
problem
and
if
we
want
that
way,
we
could
also
make
so
that
the
general
listing
never
returns
up
tera4
module.
So
you
will
see
the
type
terraform
module
only
when
you
are
coming
from
the
sidebar,
so
the
user
wouldn't
get
that
they
are
getting
terraform
packages
from
the
package
register.
Then
they
won't
get
it
anymore
from
the
from
the
package
registry
when
we
move
completely
to
their
own
ui.
C
So
from
the
ux
perspective
in
terms
of
package,
it
would
be
preferred
when
we
talk
to
our
users.
The
reason
the
container
registry
and
the
package
registry
are
separate
in
theory,
they're
the
same
thing
in
just
a
different
technology,
but
the
way
that
users
think
about
them
is
inherently
different.
I
think
terraform
fits
in
that
same
bubble
of
the
way
that
you
use
terraform
the
users
that
use
it
are
just
different
than
the
package
registration,
so
they
should,
especially
as
we
expand
the
infrastructure
stuff
that
gets
stored
there.
C
A
B
B
I
guess
backing
up.
If
I,
if
I
have
my
my
projects,
kind
of
organized,
you
know
I
might
have
like
some
application
projects
and
some
infrastructure
projects
and
then
some
terraform
modules.
B
B
It's
it's
simpler
for
me
to
think
of,
like
looking
for,
like
a
versioned
artifact
of
something,
whether
it's
an
application
or
an
infrastructure
repo
or
a
terraform
module,
it's
simpler
for
me
to
find
them
in
one
place,
whereas
we're
kind
of
we
have
these
whole
sections
of
of
the
product
that
we're
not
using
like
for
a
specific
project,
and
we
already
have
that
with
container
registry.
You
know
and
pretty
much
all
of
my
projects,
there's
nothing
in
the
container
registry,
but
I
have
this
navigation
item
and
this
whole
feature
of
the
product.
B
B
Yeah
like
trying
to
track
down
where,
where
like
what
what
the
latest
version
of
a
thing
is
because,
like
I'm
locked
to
a
version
in
in
this
project,
you
know
of
a
dependency,
and
I
I
may
not
want
to
go
to
the
just-
take
the
version
constraint
off.
So
I
want
to
go
find
what
the
latest
one
is
to
see.
B
If
I
want
to
bump
to
that,
like
that
kind
of
a
thing
and
like
the
group,
the
group
level
package
registry
is
actually
really
nice
for
that,
because
you
can
just
kind
of
search
across
everything
to
find
things.
A
Yeah,
the
problem
is
we're
targeting
large
organizations
where
well,
you
are
the
developer
and
the
platform
engineer
in
like
in
one
role
in
larger
organizations.
These
would
be
different
personas
and
we
haven't
really
decided
which
way
we
want
to
go
like.
We
want
to
cater
one
and
the
other.
In
this
case,
we
would
split
it
for
the
large
organization,
but
we
would
merge
it
with
a
smaller
one,
and
I.
C
The
package
side
of
things
as
we've
been
kind
of
looking
over
our
personas
on
the
ones
that
are
most
interested
in
what
we're
offering
we
tend
to
lean
to
the
enterprise.
They
need
the
big,
complicated
solutions.
It
would
be
cool
to
get
everybody,
obviously,
but
small
organizations,
and
maybe
nico
and
matt-
can
attest
to
something
like
this.
But
if
you're
in
a
scrappy,
startup
you're,
probably
going
to
use
whatever
package
manager
is
the
default
one
and
you
wouldn't
use
our
operating
anyway.
So
we
tend
to
tailor
ourselves
to.
B
Yeah
and
I've
actually
kind
of
made
a
point
in
the
implementation
to
make
sure
that,
like
I'm
using
finder
methods
that
will
find
like
a
user's
name
space-
not
just
a
top
level
group.
B
For
this
to
be
able
to
make
sure
that
this
feature
is
usable
for
for
core
users,
because
we
want,
we
want
to
be
able
to
kind
of
let
people
use
the
functionality
at
least
the
the
basic
functionality
so
that
they
know
it's
there,
so
that
when
they
are
upgrading
to
a
license
or
they're,
using
something
in
a
licensed
org
that
they
then
have
access
to
more
features
on
it.
But
they
at
least
know
that
it's
there
and
they're
already
used
to
using
it.
B
Therefore,
module
for,
for
me
is
that
kind
of
thing
where
it's
useful.
There
isn't
really
a
great,
like
alternative
other
than
you
have
to
host
it
in
github,
so
the
the
upstream
terraform
official
terraform
registry,
the
hosted
one,
will
only
let
you
publish
things
from
github
repos,
and
so
this
is
a
way
for
git
lab
to
kind
of
get
into
like
letting
have
letting
users
actually
publish
their
own
modules
from
a
gitlab
repo
and
not
have
to
be
forced
to.
B
C
B
Yeah,
I
know
for
sure
I
didn't
think
that's
what
you're
saying
I
just
yeah.
I
just
wanted
to
make
sure
that
we
are
like
like
if,
if
we,
if
we
need
to
lean
to
the
enterprise
for
things,
I
also
want
to
make
sure
that
we're
keeping
an
eye
on
our
on
on
the
smaller
users,
because
I
think
they're
also
going
to
be
kind
of
important
for
like
getting
us
into
those
bigger
organizations.
B
At
the
only
reason
that
we
moved
to
move
to
get
gitlab
was
because
we
had
a
user
who
was
a
a
community
contribution.
We
had
an
employee
who
was
a
community
contributor
who
kind
of
like
bootstrapped
us
into
gitlab,
and
then
we
had
compliance
stuff
happen
and
then
we
were
like.
Oh
we're,
definitely
moving
everything
in
to
go
so.
C
D
Based
on
the
like
the
ownership
of
the
areas,
so
if
we
mix
and
match
everything
inside
package,
we
may
end
up
in
situation
where
we
want
to
change
a
bit
of
the
ui
or
the
data
module,
or
I
think
the
dependency
proxy
or
even
the
package
may
have
a
three
layer
organization,
three
page
organization,
where
we
go
in
the
detail
of
a
file
of
the
package,
for
example-
and
this
will
complicate
it
a
little
bit.
D
So
I
think,
as
an
iterative
step
mixing
between
one
ui.
It's
an
amazing
solution
to
the
solution
that
we
should
go.
But
if
we
can
start
with
something
that
then
can
steer
the
ui
on
his
own
place,
maybe
at
the
maintainability
of
the
code
is
a
bit
easier
afterwards,
especially
because
it
comes
from
two
different
stage
right.
So
sometimes
we
may
not
communicate
with
each
other
or
miss
some
information,
and
you
know,
generate
an
issue
because
of
that.
B
Yeah,
that's
a
great
it's
a
great
point.
I
guess
going
into
this.
I
was
a
bit
concerned
of
like
relying
so
much
on
the
existing
package
code
for
implementation
kind
of
because
of
that,
but
then
you
know
I
really
question
whether
or
not
I
should
just
start
with
separate
models
and
separate
object,
storage
and
separate
everything.
B
But
as
soon
as
I
started
on
that,
I
realized
how
much
code
I
would
be
duplicating
from
package
and
it
felt
felt
like
a
really
bad
decision,
so
at
least
for
the
especially
for
the
first
iteration.
D
Yeah,
I
agree
with
you.
I
agree
on
the
present
with
you
and
just
trying
to
keep
a
look
for
the
long
term,
because
I
see
package
slowing
down
a
little
bit
to
take
care
of
on
feature
in
future
release,
take
care
of
reliability
and
stability
because
of
concerns-
and
I
don't
want
that.
Terraforming
then,
is
like
dragged
down
by
this.
If
you
have
a
different
speed
right,
I
mean
we
already
communicated
that
there
was
a
performance
issue
that
might
have
impact
this.
Luckily,
we
are
okay,
it's
just
in
this.
B
D
I
think
if
we
can
have
a
solution
where
we
can
keep
the
code
like
this
and
just
reduce
the
the
stress
for
the
user
by
having
everything
in
registers
and
then
moved.
So
if
we
can
have
the
terraform
register
on
the
side
that
points
to
the
package
registry
pre-filter
it
I
think.
That's
I
mean
then
the
then
maria
and
yen
can
confirm
this.
A
Is
the
user,
the
same
user?
That's
my
question.
Like
I
again
packages
I
think
are
published
by
developers
right
and
terraform
is
purely
managed,
at
least
in
a
large
org
from
a
sysadmin
or
platform
engineer,
so
either
way
it
makes
sense
to
prep
and
then
split
it
or
somehow.
A
D
A
A
I
see
then
nov
will
be
a
bit
confusing
in
my
opinion,
like
clicking
somewhere
and
landing
somewhere
else.
C
D
B
We
want
to
do
for
iterations
like
as
a
first
iteration,
I
think,
make
a
suggestion
of
of
basically
you're
you're
getting
the
the
navigation
item
over
here
with
the
least
amount
of
of
effort,
so
that
people
are
clicking
in
the
same
place
and
yeah.
Initially,
then
it
was
in
the
first
iteration.
It
would
take
them
to
a
page
that
says
package
registry
and
has
typed
terraform
module.
The
next
iteration
could
clone
this
page
change
this
to
infrastructure.
B
Get
rid
of
this.
You
know,
but
they'd
still
be
clicking
on
the
same
thing.
So
you
know
if
we
would
have
to
leave
that
up
to
you.
If
that's,
if
you
think
that's
worth
the
the
first
iteration,
if
you
think
it's
worth
it
worth
that
or
maybe
we
don't
do
that
first
iteration,
we
wait
for
it
to
take
longer
and
do
the
second
one
does
that
make
sense.
A
There's
no
such
thing
so
for
me
it's
very
confusing.
We
could
get
away
with
putting
some
messaging
on
the
page
if
we
wanted
to
release
it
like
transferring
it
to
the
package
by
saying
I
don't
know,
the
page
is
not
ready
yet
or
something
like
that,
but
I
would
rather,
we
do
the
more
complex
solution
as
a
first
iteration,
but
depending
on
how
much
time
it
will
take
obviously
ian
what
do
you
think.
C
I
agree
with
you,
I
think
our
first
time
kind
of
showing
hey-
we
can
do
this
in
the
ui
and
introducing
this
feature
set
to
the
user
is
going
to
confuse
them.
We're
going
to
kind
of
get
a
bad
taste
in
in
a
community
that
can
sometimes
be
unforgiving
and
hold
their
opinions
really
strongly.
So
I
do
think
if
we're
we're
splitting
it
off
and
giving
it
its
own
unique
path
that
first
experience
has
to
be.
This
is
a
unique
thing
in
its
own
registry,
not
a
otherwise.
C
C
D
I
have
a
question:
what
generates
a
bad
experience,
the
fact
it
is
called
package
registry
and
it-
and
it
has
the
text
that
says
publisher,
share
packages,
it's
those
two
things
that
is
a
problem
so.
A
C
The
first
thing
is
that
when
you
have
a
navigation
item
that
lands
you
in
a
different
place
than
you
expected,
you've
broken
the
mental
model
of
how
the
application
is
put
together.
Yeah
we're
already
asking
a
lot
for
them
to
like
know
what
project
in
what
group
and
what
instance
they're
in
so
that
navigation
is,
has
to
be
pretty
clear
and
then
the
other
part
of
it
is
we're.
Inferring,
there's
a
connection
between
generic,
like
code
packages
and
terraform,
and
then
there
isn't
later
that
will
create
a
jarring
experience.
D
D
The
url
is
terraform,
it's
not
packages,
okay,
and
it
says
terraform
registry
and
possibly
a
different,
a
different
text
on
the
left-
and
you
know
everything
that
is
packaged
become
module.
I
guess
it's
called
module
right.
D
C
D
It's
much
better,
that
we
have
a
customizable
one,
and
this
is
this-
is
achievable
with
more
or
less
the
same
amount
of
work
as
doing
the
pre-filtering
that
I
suggested
in
the
beginning.
B
Yeah,
I
think
I
think
I
agree
with
that,
and
I
think
it
also.
If
we
do
this
amount
of
work,
it's
a
lot
less
than
cloning.
The
whole
ui
into
its
own,
its
own
front,
end,
which
is
good,
and
I
think
that
lets
us
ship
a
bit
sooner
and
the
other
advantage
to
that
is
that
if
we
did
decide
to
completely
separate
terraform
modules
from
package
just
entirely
on
the
on
both
the
back
end
and
front
end,
the
front
end,
experience
would
not
actually
have
to
change
at
all.
D
B
It
would
be
completely
behind
the
scenes
from
one
release
to
another.
You
know
the
the
the
migrate
rake
task
would
move
all
the
all
the
files
from
one
object:
storage
to
another.
You
know
all
the
database
rows
would
be
migrated
and
the
ui
would
completely
change,
but
not
it
would
just
be
behind
the
scenes.
D
B
B
D
B
D
So
I
could
work
on
this
in
parallel
with
month
and
achieve
this.
What
we
discussed
now
I'll,
I
think
I'll,
update
the
issue.
I
think
the
one
that
ian
linked
on
the
agenda
to
respect
this,
if
everybody
is
on.
D
B
I'm
on
board
don't
mind
me:
I'm
just
mocking
a
ui
just
to
see
what
it
is.
Yeah.
C
Yeah
sounds
good
to
me:
should
how
should
we
capture
the
idea
that
we'll
have
to
update,
because
that's
even
like
really
good
finding
polish
code
situation
we're
kind
of
faking
it?
Should
we
capture
that
we
need
to
like
refine
it
into
whatever
it's
going
to
be,
or
will
that
organically
happen
whenever
it's
ready.
D
You
mean
the
further
refinement
after
the
first
iteration
is
released
yeah.
I
don't
know
how
the
capture
they
were
want
to
be
captured.
There
is
going
to
be
a
point
where,
if
the
two
registers
diverge
too
much
one
single
from
that
won't
be
able
to
have
the
customization
for
both,
but
I
think
this
will
happen
down
the
line.
D
I
think
the
package
ui
is
still
much
richer
than
what
the
terraform
is
for
now,
so
we
will
have
element
ready
to
satisfy
terraform
needs
for
a
while,
and
then
maybe
we
want
to
have
an
issue
that
keeps
track
of
the
turning
point
and
says:
hey.
You
know
it's
enough.
We
can't
really
and
we
need
to
move
on
from
this.
A
It
does
my
only
worry,
nico
is
if
you
move
to
other
work,
and
then
you
don't
have
time
to
help
us
with
the
ui
for
splitting
it
to
its
own
gain.
That's
my
only
concern.
D
Well,
I'll
there's,
I
think
the
best
count,
not
the
best.
The
best
help
for
this
is
that
I'll
keep
involved.
Whoever
wants
from
configure
to
be
kept
on
up
to
date
with
packages
I
was
doing
before
with
emily,
wherever
I
would
modify
something
that
I
knew
that
you
would
impact
terraform.
I
will
also
ping
air.
I
can
keep
pinging
emily
or
I
can
be
being
mad
or
whoever
is
interested
to
be
kept
up
to
date.
B
B
Registry
then,
potentially
we
would
have.
B
A
A
A
B
A
B
We
could
underlying,
I
think
they
would
all
be
pretty
identical,
so
we,
I
guess
you'd-
have
to
decide
if
it's
okay
to
mix
them
together
under
the
terraform
tab
or
to
be
separate
again.
This
is
a.
B
This
is
a
thing
I
struggle
with,
because
it
would
be
very
unlikely
for
a
single
project
to
be
publishing
both
modules
and
providers
and
back-ends
right.
They
would
only
typically
be
publishing
one
of
those.
C
C
So
we
remove
the
tabs
in
general
and
you
have
the
ability
to
sort
by
type,
we're
working
on
and
nico,
and
I
actually
have
some
time
devoted
to
this,
of
refining
the
filter
and
sort
functionality.
So
thinking
of
terraform
is
having
three
different
types.
What
we
may
do
is
you
can
filter
by
terraform
as
the
like
infrastructure
module
type
and
it
could
be
puppet
later
on
and
we'll
have
that.
But
then
you
could
also
have
a
piece
of
metadata.
That's
like
this
terraform
back
in
this
terraform
provider.
This
is
a
terraform.
A
C
Just
a
terraform
title
and
then
there's
some
metadata
like
the
number
of
terraform
modules
and
the
size
of
it's
available.
There's
like
six
pieces
of
metadata
and
I
have
no
idea
what
was
implemented
or
not.
But
there's
some
there's
like
a
title
component:
correct
nico
that
we've
like
already
formulated,
match.
D
A
note
here,
if
we
end
up
the
nominee
since
we
are
moving
in
the
direction
of
cloning,
the
package
ui
right.
What
we
will
get
to
customize
in
the
first
distance
is
basically
name
and
text
blobs
and
with
blobs
I
mean
like
paragraphs
modifying
more
than
that
would
be
in
force
of
splitting
and
add
two
different
proteins
for
it
and
none
and
the
other
thing
sorry.
A
A
Oh,
I
need,
I
think
we
need
to
maybe
work
sync
on
that,
because
the
copy
here
is
old.
It
relies
on
the
tagging
solution
where
you
didn't
need
to
run
a
ci
job
to
publish,
so
I
think
we'll
need
to
somehow
work
on
the
copy,
even
through
mrs,
when
you
are
ready
for.
C
I
perfect
have
a
question
as
we're
thinking
about.
I
know
we're
almost
the
time,
so
I
want
to
be
quick
about
it,
plugging
in
and
we're
going
to
be
copying
the
package
ui.
Would
it
be
beneficial
maria
to
partner,
maybe
sync,
with
niko
for
a
little
bit
just
one-on-one
and
say
these
are
the
components
that
are
available
in
the
package
ui
and
then
you
have
the
knowledge
already
to
be
like
that.
A
D
Yeah
we
can
schedule
something
early
next
week
because
I
would
like
to
start
this
early
in
the
milestone,
because
I
think
it
is
going
to
be
some
iteration
over
the
mrs.
A
C
B
I
realize
that
not
everybody
has
used
terraform
or
chair
for
models.
I
thought
it
might
be
useful
just
to
show
you
how
people
will
actually
consume
these,
so
they'll
actually
just
define
their
module
with
the
module
source
that
we
saw
before
and
when
they
run
terraform
init.
Here
this
happens,
so
it
download
it
finds
the
module
from
gitlab
and
downloads
it
and
uses
it.
It's
very
it's
a
very
seamless
experience
and
that's
what
we
want.
B
So
this
is
the
majority
of
how
people
will
consume
these,
so
they're
not
going
to
be
interacting
with
gitlab,
really
at
all.
The
only
one
people
who
are
going
to
be
interacting
with
gitlab
around
modules
are
the
people
who
are
publishing
them
or
creating
them
and
deleting
them,
and
you
know
deleting
ones
that
they
put
secrets
in
by
accident
that
they
weren't
supposed
to,
or
you
know
things
like
that.
D
Button
matt,
quick
question:
do
you
have
factories
that
build
fake
terraforms
in
inside
your?
Mr.
B
Yes,
there's
a
factory
that
builds
the
fake
one
and
there's
there's
a
spec
fixture
that
contains.
B
This
actual
this
actual
sample
module
that
I
have
here
so
this
is
this
is
a
module,
a
very
basic
one,
main
outputs
and
variables,
and
so
all
this
one
does
is
require
a
version
of
terraform
and
it
creates
a
file
perfect
yeah.
So
this
is
this:
is
the
spec
fixture.
B
I'm
trying
to
think
anything
else,
I
think
I'm.
I
think
I'm
really
good.
If
anyone
has
any
any
questions
about
any
of
it
feel
free
to
find
me
on
slack
and
I'll
be
more
than
happy
to
help
in
any
way.
I
can.
D
Would
it
make
sense
to
have
a
slack
channel
for
this
collaboration?
So
we
all
talking
on
the
same
space,
because
in
the
past
we
had
a
bit
of
fragmentation
of
info.
B
We
have,
we
have
a
channel,
we
can
reuse
for
that.
I
think
we
have
f
terraform
registry
I'll,
go
ahead
and
invite
you
both
to
it.
A
B
Perfect
yeah
and
ian
and
nico.
Thank
you
in
advance
for
all
of
the
help
and
and
all
of
the
existing
work
and
package
that
made
this
so
much
simpler.
B
Yeah,
steve
and
and
david
have
already
given
me
some
feedback
on
on
one
of
my,
mrs,
and
they
were
like
you
used
our
new
authentication
module.
I
was
like
it's
awesome.