►
From YouTube: Kubernetes SIG Service Catalog 20161130
Description
SIG service catalog discusses numerous development topics.
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
Okay,
everybody
welcome
to
the
e
November
30th
2016
special
edition
of
cobranet
e-cigs
Service
Catalog.
So
today
we
have
a
pretty
full
agenda.
For
that
reason,
I
suggest,
let's
see
we
have
five
main
bullet
points
on
the
agenda
here:
let's,
let's
time
box
them
to
ten
minutes
a
piece
and
let's
see
if
somebody
would
start
a
10
minute,
timer,
let's,
let's
go
ahead
and
and
begin
talking
about
the
first
point
on
here
which
I
will
paste
into
the
chat-
and
I
created
this
issue
today,
which
is
basically
so
I.
A
I
have
found
myself
saying.
Well,
you
know
we
should
try
to
emulate
what
Cooper
Nettie's
does
Cooper
Nettie's
does
X
crew
benetti's.
Does
why
and
like?
I
am
not
a
fan
of
arguments
to
Authority,
so
issue
79
articulates
in
fairly
exhaustive
detail.
My
rationale,
which
is
like
behind
the
shorthand
of
well
Cooper
nutties
coo
benetti's.
A
Does
it
X
or
Y
way
and
I'm
going
to
go
ahead
and
just
bring
this
up
so
I
can
articulate
wit,
not
distracted,
Paul
wrote
down
for
this
and
actually
I'll
go
ahead
and
share
my
screen
so
that
those
recording
can
get
some
get.
Some
goodness
out
of
that
and
like
okay
I
can't
figure
out
how
to
share
just
this
window.
So
we
will
look
at
my
desktop
so.
A
I
can
everybody
see
my
screen
now.
Okay,
issue
number
79
lays
out
my
rationale
for
why
I
think
that
we
should
strive
to
like
the
the
highest
possible
level
to
make
this
project.
Look
like
urban,
Eddie's
and
I
tried
to
make
a
strong
argument
on
the
merits
of
this
because,
as
I
said,
I'm
not
a
fan
of
argument
to
Authority
and
developers,
especially
hate
argument
to
authorities.
A
A
I
played
a
movie
forward
six
months
one
year,
especially
after
API
Federation
becomes
the
norm
that
we
are
going
to
have
a
lot
of
folks
that
want
to
make
things
that
are
structured
like
Cooper
Nettie's,
which
are
tiny
little
smaller
micro,
Cooper
Nettie's
with
different
problem
spaces
and
I.
Think
that,
since
we're
one
of
the
first
folks
group
of
folks
to
want
to
do
that,
it
would
be
great
if
we
could
point
to
this
repo
and
say
hey
guys,
guys
and
girls.
Everybody
who's
interested.
A
Right
now
and
the
path
of
least
resistance
is
very
much
towards
just
kind
of
go
with
the
flow
rather
than
to
begin
discussions
about
genera
fying.
Those
things
I
know
that
that,
basically
everybody
that's
working
in
this
repo
so
far
is
really
interested
in
expediency
and
so
that
that
number
that
fifth
bullet
point
there
is
really
about
the
expediency
aspect.
A
It
means
you
don't
matter,
that's
not
what
it
means
at
all.
It's
really
more
a
question
of
utility
and
trying
to
go
along
with
the
community
that
were
part
of.
So
thank
you
for
listening
to
me
talk
if
anybody
wants
to
respond
to
this,
let's
go
ahead
and
have
it
now.
We've
got
about
three
minutes
on
the
10
minute
timer.
If
my
math
is
correct,.
B
So
so
my
only
thought
is
so
I
think
it's
perfectly
fine
to
go
and
follow
I
think
Doug
Budapest
best
and
one
of
the
things
with
just
consistency,
right,
I
think
that
is
fantastic.
I
think
my
only
thought
was
that
if
there
are
things
that
we
know
that
are
incorrect
in
the
coup
burn,
a
DS
for
some
reason
are
there
any
plans
for
them,
for
example,
to
move
off
of
it
so
that
we
don't.
B
We
don't
go
ahead
and
start
down
the
path
of
doing
something
wrong,
just
to
go
and
then
migrated
out
of
there
later
on.
That
was
my
thought
there.
So,
for
example,
I
could
look,
let's
say,
let's,
let's
say
using
the
go
depths,
that
they
have
a
plan
to
go
ahead
and
move
into
as
an
example
right,
then
it
would
make
sense
to
go
ahead
and
move
into
glide
now
and
say.
Yes,
eventually,
this
will
look
like
them.
That
is
my
own
thought
on
that
yeah.
A
So
that's
a
good
point
and
I
and
I
hear
you
at
the
same
time,
there's
also
like
there's
a
finite
amount
of
energy
that
we
have
in
the
group
and
a
finite
amount
of
a
social
and
temporal
bandwidth
that
we
had
to
work
with,
and
so
I
can
appreciate
like
if
we
think
we've
got
a
better
way,
then
let's
not
throw
that
way
out,
but
I
also
would
like
to
if
we
feel
like
we
have
it.
A
good
idea
to
share
with
the
community.
A
I
would
really
like
to
start
by
sharing
with
the
community
in
like
a
mailing
list.
Instead
of
developing
like
a
high
procedural
and
practical
Delta
between
what
we
do
in
the
incubator,
repo
and
in
Maine,
kuber
Nettie's.
Does
that
make
sense?
That's
my
own
personal
preference,
not
trying
to
be
dictatorial.
C
Yeah
I
Paul,
this
is,
can
I
think
that
I
think
that
this
really
makes
a
lot
of
sense,
III
think
to
Villa
days.
Point
I
think
that
maybe
we
need
to
not
just
be
looking
at
the
changes
that
they're
considering
implementing
in
the
way
that
they
do
things.
But
I
think
if
we
perceive
something
to
be
a
mistake,
or
even
maybe
painful
in
the
way
that
they
do
things
I,
don't
think
we
should
be
keen
to
repeat
it.
C
So,
just
as
an
example,
because
I
think
a
lot
of
the
issues
and
PRS
that
I've
started
to
open,
probably
tipped
my
hand
in
terms
of
me
being
very
focused
on
ensuring
a
very
smooth
and
positive
developer
experience.
You
know
with
a
few
modest
contributions
that
I've
made
to
the
actual
communities
core.
My
feeling
is
that
it's
not
a
very
positive
experience.
It's
for
a
new
developer
coming
into
the
project,
doing
something
like
building
Cooper
Nettie's
from
source.
C
For
you
know,
a
specific
target
operating
system
and
architecture,
for
instance,
is
an
incredibly
painful
thing
to
do.
You
can
easily
waste
eight
hours
digging
into
undocumented,
build
scripts,
and
things
like
that
trying
to
figure
out
how
things
work
and
I
don't
think
that
we
should
necessarily
be
eager
to
repeat
or
adopts
the
kind
of
developer
experience
that
they
have
so
adopting
their
structure
in
general
seems
like
a
water
bowl,
but
I
think
that
we
should
be
wary
of
repeating
some
possible
mistakes.
Yeah.
A
The
and
I've
hit
this
to
like
I've
spent
the
vast
majority
of
my
time
over
the
last
two
years,
developing
for
Cooper
Nettie's
in
my
professional
life,
so
I
I
can
empathize
with
those
things
and
I
think
the
key
here
is
documentation
and
I
know
that
there's
already
been
discussion
about
some
people
want
to
build
for
mac,
and
I
think
that
is
totally
makes
sense.
We
should
have
a
way
to
do
it.
A
We
part
of
part
of
this
is
like
tending
the
garden
right.
We
need
to
ensure
that,
as
we
do,
things
like
make
a
build
for
mac
or
a
cross,
build
for
different
operating
systems
or
architectures,
whatever
that
we
document
it,
and
then
we
keep
that
documentation
up
to
date.
So
I
think
this
becomes
more
and
more
important
as
things
get
more
popular
like
an
experience
that
we
had
with
the
main
communities
repos
that
it
became,
it
became
popular
at
some
point
like
in
faster
than
people.
A
Could
I
cope
with
the
increasing
popularity
as
something
gets
more
popular?
You
have
more
people
that
are
like
hey
I,
want
to
work
on
this
thing
and
I,
don't
even
know
what
I
want
to
do.
I
just
want
to
do
something,
because
it's
the
hot
thing
right
now
and
I
I
think
there
were
like
a
few
inflection
points
where
Cooper
Nettie's
increased
wildly
and
popularity
had
a
ton,
more
people
coming
in
a
ton,
more
people
making
contributions
and,
like
not
all
of
those
people,
turn
into
folks
that
actually
continued
to
work
on
the
project.
A
There's
people
that
want
to
land
like
vanity
commits
people
that
are
like
always
chasing
the
new
thing
want
to
play
around
that's
a
totally
natural
totally
those
those
behaviors
are
all
completely
natural,
but
we
need
to
ensure
that
as
we
as
we
grow
this
repo
and
make
it
do
more
things
that
we
try
to
keep
documentation
on
how
to
do
those
things
up
today.
So
this
I
I
hope
that
you
all
can
search
your
memories
and
I
hope.
A
This
is
consistent
with
my
prior
behaviors
of
wanting
to
have
used
cases
with
now
wanting
to
have
documentation
for
how
the
API
is
used,
because
those
are
those
are
like
almost
impossible
to
do.
If
you
go
six
months
down
the
road
and
you
need
to
do
it
from
scratch,
it's
much
easier
to
ten
them
from
the
beginning
than
it
is
to
put
them
together
afterwards.
So
I
think
some
of
your
concerning
tent
is
one
that
documentation
can
solve.
Do
you
agree.
A
D
D
A
Okay,
yeah
I
saw
that
you
added
those
things
more
than
I
appreciate
it.
I
haven't
had
a
chance
to
read
them
in
detail
yet,
but
I
will
and
and
I'll
write
something
in
there
too.
At
least
let
you
know
that
I
have
read
it
and
thought
about.
It
sounds
good
thanks.
Let
me
just
wait.
One
more
point
on
this
is
that
like
I
completely
agree
like
there
is
no
reason
to
do
something
that
nobody
likes
just
to
be
consistent.
A
I
hope
that
we
will
find,
as
we
like,
gradually
nudge
the
repo
in
this
direction,
that
the
those
things
are
are
limited,
but
we
do
need
to
move
on.
So,
let's,
let's
do
that.
I
think
the
next
thing
on
the
agenda
is
glide
versus
checking
dependencies
into
vendor.
I
am
not
sure
who
added
this.
Would
you
put
your
hand
up
or
speak
and
I'll?
Let
you
introduce
this
topic.
A
D
So
I
added
that
one
based
on
the
discussion
that
several
of
us
had
and
now
on
slack
and
whatnot,
whether
we
check-in
dependencies
or
do
glide
or
godet
or
whatnot,
and
an
interesting
point
is
like
since
we
want
to
align
with
Governor
days,
I
hear
they're
moving
to
basil,
or
should
we
do
that
instead,
so
I
just
wanted
to
give
opportunity
people
to
discuss
there
was
a
good
discussion
on
slack.
Is
there
anything
else
to
add?
Has
decision
been
made?
I,
don't
think
it
has,
but
maybe
worse,
arriving
at
one
here
if
it's
possible?
D
A
So
I
think
there's
a
few
different
dimensions
to
this.
The
one
dimension
is:
do
we
do
we
check
vendor
dependencies
in
another
dimension,
is:
do
we
which
tool
to
be
used
to
manage
the
vendor
directory
and
then
a
third
dimension
is?
Is
there
a
supplemental,
build
tool
like
basil
that
we
want
to
use,
and
let
me
say
first
on
the
subject
of
basil:
I
am
not
yet
comfortable
enough
with
basil
personally
that
I
want
it
its
use
in
this
project.
Yet
can
we
can
we
resolve
this
now?
D
Personally,
don't
feel
the
need
to
pursue
it,
although
if
it
is
the
future
of
go
brandy
score,
it
does
bring
the
question
back
to
to
what
degree
do
we
want
to
align
yet
governess
is
heading
and,
to
a
degree
make
it
make
ourselves
are
bitterly
different.
Like
personally,
I
have
used
basil
I
like
it
for
this
project.
We
didn't
go
that
way
for
the
skied
code,
with
similar
rationale
is
just
another
tool
and
other
dependencies
written
in
Java,
so
slightly
I.
Think.
E
E
E
More
I
think
it's
awesome.
I
would
love
to
go
towards
it
personally,
but
I
think
we
should
probably
scope
this
discussion
just
to
only
dependency
management
of
basil
is
the
one
and
we're
willing
to
take
on
the
additional
complexity
of
the
builds
and
everything
that's
cool
of
me,
but
I
I
just
wanted
to
bring
that
up.
I
personally
think
it's
out
of
scope,
I
want.
E
Is
yes,
you're
you're
right?
The
the
only
way
to
do
it
is
if
the
patch
is
checked
in
to
the
dependencies
repository
and
it
has
a
tag
or
a
branch
associated
with
it
or
commit
associated
with
it.
So
for
purposes
of
this
discussion
right
now,
we
can't
read
glide
and
go
to
eps
as
the
same
functionality.
E
Yeah
just
as
goat
ups
download
stuff
into
the
vendor
directory
and
cooper
Nettie's
happens
to
check
it
in
glide,
also
download
stuff
give
us
a
git
clone
or
hg
check
out
or
whatever
it's
called
I'm,
not
very
up
on
mercurial,
just
as
good
ups
does
that
stuff
glide.
Does
that
the
same
and
puts
it
into
the
same
directory
structure
under
vendor,
and
we
can
choose
to
check
that
into
yeah.
A
A
If
we
can
agree
for
now
that
we
should
vendor
these
dependencies
like
and
I
I
feel
where
people
are
coming
from
when
they
say,
oh
well,
that
makes
the
the
git
checkout
enormous
it
does,
but
you
download
the
same
code
either
way,
whether
glide
does
it
after
you
do
a
clone
or
you
do
it
during
checkout,
and
the
advantage
of
doing
excuse
me
of
getting
it
during
a
clone
or
a
poll.
Is
that
you
don't
get
fooled
into
thinking.
A
You
have
everything
you
need
to
build
before
you
get
on
the
plane
and
you're
like
hey
I,
clone
this
repo,
then
now
I
can't
download
the
stuff,
so
that's
sort
of
where
I'm
coming
from
I
really
don't
want
to
be
prescriptive,
though.
How
do
people
feel
about
the
vendor
versus
download
at
time
of
use?
Question
at
this
point,
I
think.
F
Your
argument
about
doing
a
clone
and
knowing
that
everything
is
there
without
having
to
worry
about
commitments,
get
pulled
down
later.
It's
actually
really
a
good
one,
because
that
airplane
example
is
something
I
could
see
myself
doing.
But
let
me
ask
a
slight
different
question:
how
do
people
right
now
handle
patches
when
there's
a
vendor
directory,
ignoring
whether
it's
glide
or
go
deficit
that
that
created
the
vendor
directory
and
your
experience
how
to
pull
handle
those
patches
so.
A
What
we,
what
we
do
in
Cooper
Nettie's
and
we
follow
this
pretty
closely
an
open
shift-
is
that
we
will
apply
a
patch
to
the
vendor
directory
as
a
commit
and
like
a
I'm,
actually
far
more
familiar
with
this
process
and
open
shift.
Then
what
we
do
in
upstream,
but
basically
there
is
a
marker,
like
some
kind
of
convey,
so
in
open
shift.
There
is
a
convention
that
we
use
to
say
this
is
a
patch
were
carrying
for
dependency,
because
we
we
constantly
rebase
all
of
open
shift
on
all
of
brunette
ease.
A
If
you,
if
you
folks,
can
believe
that
and
we
need
it
a
way
to
we
needed
convention
so
that
the
people
who
do
this
rebase
that
are
barely
holding
on
to
their
sanity
because
that's
their
job,
it
can
sift
through
what
needs
to
be
retained
in
what
can
be
dropped.
So
we
we
have
a
similar
process
in
upstream,
where
you
make
a
poll
that
changes
the
vendor
directory
and
you.
A
F
So
that's
what
I'm
to
understand
so
I
do
a
PR.
This
is
oh
I
need
to
do
a
patch
to
some
dependency,
I
make
a
change
to
the
vendor
directory
and
we
accept
that
PR
great
okay,
it's
part
of
our
vendor
directory.
Now,
if
we
need
to
do
a
refresh
on
that
vendor
directory,
how
do
we
do
we
do
a
pull
and
then
a
like
a
rebase
okay?
How
does
how
does
that
new
patch
get
applied
on,
say
the
new
version
of
crew
benetti's
that
we
just
vendor
dead.
A
And
like
I,
see
stuff
in
the
in
the
chat
that
says,
sounds
painful.
It's
super
painful.
It
only
works
because
we
had
people
with
brains
that
are
like
so
big
that
they're
just
throbbing,
you
can
see
they're
like
brain
wrinkles
through
their
skulls
they're,
so
big
I
think
it's
safe
to
say
that
that
isn't
how
anybody
here
wants
to
spend
their
time,
though
right,
it's
not
how
anybody
wants
to
spend
their
time.
But
if
you
got
a
bug
in
a
dependency
and
you
can't
get
it
fixed
in
time,
you
don't
have
a
choice.
C
C
F
A
I'm
agnostic
on
it
for
now
I
think
that
we
can
handle
it
at
in
as
needed
basis,
but
I
will,
I
will
say,
like
I,
think
that
a
we
will
probably
need
to
before
we
release
anything
for
this
go
to
a
vendor
directory
so
that
we
avoid
a
problems
of
well
I
did
gly
wrong
and
that
I
got.
Could
that
didn't
work,
but
I
can
be
convinced
otherwise,
by
the
way
I
think
we
are
out
of
time
for
this
subject.
So,
let's,
let's
put
it
to
a
vote,
I
I
I,
propose
that
we
table
this.
A
E
I
wanted
to
just
touch
on
that
for
a
second.
We
we
can
do
the
exact
same
thing
with
glide,
as
Cooper
Nettie's
does,
with
goat
ups
and
I'm
I'm,
not
a
fan
of
that,
but
it
will
bring
us
like
that.
One
step
closer
to
what
Cooper
dennys
does
and
when
I
say
I'm,
not
a
fan
of
that
like
I
hate
it
but
I'm
willing
to
do
it
as
a
kind
of
a
step
towards
moving
to
what
Cooper
Nettie's
is
doing
more
of
and.
B
C
Can
I
ask
a
silly
question
having
to
do
with
like
governance,
hear
it
when,
when
a
projects
actually
includes
like
the
vendor
directory
in
the
repo
and
something
gets
patched
in
there
like
who
who's
reviewing
all
of
that
stuff
like
how?
How
does
anybody
know
that?
How
does
anybody
who's
reviewing?
Something
know
that
you
know
a
change
in
one
of
the
vendor
pieces
of
code
is
like
a
legitimate
change
and
not
like
something
that
somebody
else
snuck
in
now,
I'm
not
saying
that
there's
any
malevolent
actor
here
or
anybody
acting
in
bad
faith.
C
A
F
C
So
considered
the
fact
that
this
can
even
happen
accidentally,
though
right
we've
all
done
this
before
we're
hacking
on
like
a
ruby
project
or
something-
and
you
start
wondering
oh
I,
wonder
what
happens
if
I
just
change
this
line
or
add
this
bit
of
debug
code
to
this
gem
and
you
go
to
where
that
gem
is
on
your
system,
and
you
just
add
the
line
that
you
want
right.
The
same
thing
is
going
to
happen
with
the
vendor
directory.
C
F
So
just
comment
on
that:
I
understand
that
you're
making
an
argument
for
not
checking
the
vendor
Ector
a
bender
director,
but
I
just
want
to
comment
on.
If
someone
does
make
a
change
like
that,
because
they're
just
doing
a
quick
little
debug
thing
in
their
vendor
directory
chances
are
they're
not
going
to
be
doing
that
the
exact
same
time
that
they're
reeve
ndering
stuff
and
it's
very
easy
to
notice
those
types
of
changes,
because
it's
a
one-line
change
or
so
in
the
environment
in
the
vendor
directory
right.
F
C
A
A
C
So
there
has
been
some
discussion
about
this
already
today
and
and
especially
with
martin,
and
I
think
that
we're
all
pretty
much
in
agreement,
at
least
you
martin,
myself
and
I've,
talked
to
Aaron
about
it
as
well
that
we
do
want
to
eliminate
the
the
GCR
bias
that
looks
relatively
easy
to
do.
I'm
about
halfway.
C
There
I'd
be
all
the
way
there
if
I
didn't
have
so
many
meetings
today,
so
I'll
PR
that
later,
ok,
the
thing
that
I
think
we
should
still
talk
about
those
I
think
there's
still
a
G
ke
bias,
that's
kind
of
present
and
some
of
like
the
hacking
scripts.
Ok
like
that
and
I
think
that
we
should
look
to
kind
of
eliminate
those
biases
wherever
we
spot
them.
C
A
Me
say
a
few
words
on
this:
like
I
I
have
corporate
GCE
and
AWS
accounts
and
I
very
rarely
use
them
unless
I
am
testing
change
as
I
think
a
bunch.
You
know,
I've
done
a
fair
amount
of
work
on
community
storage,
so
occasionally
I
will
do
something
that
affects
how
GCE
persistent
disk
works
and
Cooper
Nettie's
or
AWS
EDS
I.
A
For
my
local
for
my
development,
like
normally
I
run
a
local
cluster
and
I
I
think
that
I
I
would
like
it
to
be
a
requirement
for
us
that
we
are
local
cluster
friendly,
I,
don't
even
use
mini.
You
I
run
the
big
cube
'let
on
my
laptop,
because
that's
how
I
roll
it's
the
only
way
to
fly
if
you
want
Expediency
of
turn
around.
So
it's
really
really
important
to
me
personally
that
we
that
we
make
things
local
cluster
friendly.
A
But
with
that
said,
my
dirty
little
secret
is
that
I,
like
the
the
stake
leadership
duties,
have
been
enough
of
my
time
that
I
have
not
had
much
time
to
actually
play
with
the
repo
yet
so
I'm
I
am
using
Kent
as
my
spirit
animal
on
this
subject,
because
he
seems
to
know
what
he's
talking
about
with
local
clustering
eof
for
me,
what
do
I?
What
do
others
think
I
would.
D
D
So
it
exists
because
we
have
machinery
that
will
essentially
spin
up
gk
clusters
and
deploy
catalogue
into
it
and
run
and
10
tests
on
it.
So
to
that
extent,
to
the
extent
that
we
use
some
of
these
systems
for
testing
the
bias
will
be
President,
whichever
system
we
use,
unless
we
make
it
completely
agnostic
and
say
in
the
Jenkins
ey,
there
be
a
parameters
that
will
point
the
system
to
deploy
into
a
double
yes
vs.
gke
or
what
not
just
the
history
on
it.
D
A
So
in
response
to
that,
I
think
that
probably
what
we
will
naturally
converge
on
is
you'll
have
a
Cooper
Nettie's
cluster
you'll
run
the
API
server
and
controller
in
a
pot,
and
so
the
machinery
for
where
you
spin,
that
cur
benetti's
cluster
up
becomes
sort
of
orthogonal
to
the
content
of
the
repo
and,
if
you're,
basically
just
saying
point
cube,
CTL
or
helm
or
whatever
tool
you're
going
to
use
to
create
these
pods
at
a
cluster,
make
pods
bam.
You're
done
this.
This
problem
goes
away.
A
D
Completely
the
last
I
agree
that
too
large
excited
does
the
the
one
thing
that
we
imposed
as
a
requirement
on
these
in
10
tests,
especially
given
that
we're
early
into
development
and
we
mess
up
and
we
damage
namespaces
entities
and
install
things
incorrectly.
So
we
basically
create
a
whole
new
cluster
for
each
test
and
then
shut
it
down
afterwards,
which
is
the
thing
that
becomes
impossible,
because
that's
the
thing
that
has
dependency
on
the
target
deployment
of
space
yeah.
A
So
there's
another
there's
another
concern
that,
like
steady-state
play
the
movie
forward
six
months,
part
of
our
ed-e
on
this
is
going
to
be.
I
given
a
running
cluster,
make
sure
that
I
got
the
secrets,
make
sure
I
got
the
config
Maps
make
sure
I
got
the
sift
that
I
want
to
make
sure
that
my
pod
descriptor
was
mutated
in
the
way
that
I
expected
so
there
there
may
not
be
a
way
to
completely
eliminate
this,
but
I
think
it
bears
careful
consideration
because
it
is
a.
It
is
a
tough
nut
to
crack.
A
I
need
to
spend
a
lot
of
time.
Thinking
about
this
I
and
it's
something
that's
like
on
my
mental
list
of
hurdles
that
have
to
be
jumped.
I
don't
have
a
good
answer
for
it
now,
but
maybe
we
can
at
least
I'll
start
thinking
about
it
and
try
to
make
the
the
dimensions
of
I
don't
want
to
stay
coupling,
but
the
amount
of
the
number
of
bytes
in
the
project
devoted
to
a
particular
cloud
provider
as
low
as
possible
for
now,
I.
Don't.
D
Disagree:
I
lost
he
kinda
halfway
through
I,
wasn't
sure
if
you
were
arguing
that
if
we
have
a
long-running
clusters
into
which
in
which
we
play,
they
accrue
baggage
in
them,
which
will
affect
potentially
negatively
any
subsequent
tests
to
be
running
against
the
cluster.
Because
of
the
setup
that
has
been
done
and
we
kind
of
forgot
that
is
there
or
if
you
arguing
that's,
actually
a
good
thing
that
we
have
that
baggage,
because
we
always
have
to
make
sure
that
everything
is
cleaned
up
and
redone
from
scratch
correctly.
So.
A
I,
I
was
actually
making
a
different
point.
I
was
saying
like
if
you,
if
you
look
at
where
this
project
will
be
in
six
months,
we
part
of
successfully
NN
testing
this
project
is
it
needs
to
play
nice
and
do
the
right
things
in
Coober
Nettie's
in
a
cooper
Nettie's
cluster.
So
there
is
a
problem
of
to
fully
ete
this
thing
we
it
needs
to
live
alongside
Akubra
Nettie's,
and
so
it
is.
It
is
natural
that
our
test
infrastructure,
this
project
probably
does
involve
spinning
up
a
goober,
Nettie's
cluster.
A
E
E
Would
it
be
possible
to
pull
out
a
lot
of
the
common,
build
and
deploy
infrastructure
and
then
put
on
top
some
make
file
targets
to
do
the
e2e
tests
and
then
also
put
on
some
make
targets
to
make
it
easy
for
developers
to
do
builds
docker
bills,
docker
pushes
so
on
and
so
forth?
That's
it
that's
a
good
at
least
short-term
solution
here.
So.
A
There's
a
number
of
different
salt
like
things
that
people
use
but
the
when
I'm
the
thrust
of
what
I'm
trying
to
say
is
that
maybe
we
need
a
cluster
directory
with
this
is
how
you
run
this
on.
This
is
how
you
run
this
on
AWS,
the
site.
You
run
this
on
GCE
and
if
we
have
people
that
are
like
hey,
I
really
want
to
do
this
on
other
cloud.
We
have
a
good
way
for
them
to
do
that
without
ripple
effect
through
the
whole
repo.
E
Yeah,
it
sounds
reasonable.
Pretty
much
I
should
have
said
it
a
little
simpler.
Pretty
much.
Can
we
just
focus
on
make
file
targets
right
now
that
are,
as
can't
just
wrote
this
Finch
at
actually
that
our
vendor
agnostic,
you
can
use,
make
deploy,
set
some
variables
or
environment
variables
or
whatever
and
get
this
thing
pushed
up
the
dog
or
hub
and
deploy
it
on
to
KU
Nettie's
cluster
X.
Wherever
that
might
run
later
on,
then
we
can
confront
the
dual
use.
Salt.
E
A
A
D
A
A
E
A
D
A
D
Quick
intro,
you
probably
noticed
in
the
repo
that
there
is
a
Jenkins
file
and
the
Jenkins
5
refers
scripts
in
the
script
directory.
Those
are
artifacts
from
the
CI
pipeline.
We
run
at
Google
for
purposes
of
building
this
code
from
ground
up
and
with
a
seeded
can
I
made
it
in
so
I
was
kind
of
deliberating.
D
Do
we
want
it
now
that
we
have
basic
Travis,
which
basically
does
only
unit
test
at
this
point
which
are
kind
of
people
at
best,
but
we
have
it,
but
the
drinking's
in
addition
to
what
what
the
Travis
is
we
have
it
as
of
today
does
is
what
we
discussed
earlier
in
a
cluster
in
gke,
candid
and
afterwards
deploy
everything
into
it.
Start
a
service
bind
to
it.
Bounce
API
calls
off
of
it
to
make
sure
that
things
actually
work
after
every
chicken
into
end.
D
We
could
look
for
ways
to
run
these
jenkins
against
the
github
repo
as
well.
There
is
some
challenges
with
who
might
have
access
to
it,
I'm
not
sure
out
actually
hard
and
Jenkins.
For
now.
It's
basically
internal
only
to
google
burning
jenkins
is
hard
right.
So
do
we
want
to
benefit
from
it
understanding
that
there
is
a
limited
ability
to
access
it
and
knowing
that
maybe
over
time
we
will
be
felt
Travis
and
maybe
do
something
else
following
the
Cabrini's
practices?
Is
it
short
term
useful?
Should
we
just
stare
it
down
either
option?
It's
fine.
B
D
F
A
We
tend
to
do
like
enough
things
and
see
I
that
if
you
just
if
you
have
one
CI
job
and
it's
like
hey
I,
failed,
you
get
to
have
a
magical,
45-minute
adventure
sifting
through
the
results
of
the
single
build
I
I,
think
that
will
find
that
we
can
leverage
Travis
for
some
of
those
things
more
easily
and
for
certain
things
we
are
going
to
need
to
go
to
a
Jenkins
I.
Think
having
a
CNC,
f,
I
know
that
runs
Jenkins.
I
do
agree
Doug.
It
is
slightly
different,
but
now
I've
made
mistakes.
A
F
At
least
some
sort
of
try
out
Travis
Jenkins
type
is
set
up,
perhaps
even
something
much
bigger
than
that
later,
but
Leslie's
start
that
ball
rolling
and
see
if
it's
possible,
because
I
know
in
the
past,
when
we've
used
it,
they
wanted
us
to
use
it
on
a
temporary
basis
and
obviously
we
need
this
on
a
permanent
basis.
So
let
me
go
and
do
some
of
the
gasification
devastating
impossible.
Yeah.
A
A
It
would
be
awesome,
as
cnc
f
could
have
like
a
longer
running
a
more
permanent
communities
that
people
could
use
for
for
permanent
things,
but
I
I
would
suggest
that
probably
the
tenancy
multi-tenancy
capabilities
are
not
fully
there
an
upstream
yet
to
make
that
a
thing
that
I'd
be
interested
in
doing
as
an
operator.
So
we'll
see
right.
D
Let
me
let
me
I
think
our
Jenkins
runs
on
actually
Cooper
nice
cluster.
So
let
me
look
up
the
size
of
it.
In
the
meantime,
I
would
like
people
to
ponder
the
question.
Do
we
stay
course
and
not
touch
the
Jenkins
machinery
that
is
in
the
repo'd?
We
pull
it
out
or
do
we
do?
We
allow
allow
Google
to
keep
advances
in
it,
understanding
that
Google
is
running
something
internally,
that
it
helps
and
if
something
breaks
we
can
notify
people,
but
there
is
very
little
visibility
from
the
outside
into
it
for
now,
so
so.
A
A
D
A
D
A
A
Is
also
probably
an
area
where
we
can
lead
by
example
for
other
incubator
repos
that
are
interested
in
setting
up
see
I
so
but
hey
we're
actually
we're
at
time
now.
I,
don't
like
meetings
that
run
over
I
know
other
people,
don't
so
I'm
going
to
stop
the
recording
here,
and
maybe
we
can
continue
talking
on
slack
everybody.
Okay
with
that.