►
From YouTube: Kyma Prow Migration WG meeting 20181109
Description
Meeting notes: https://docs.google.com/document/d/1ljEAoCBJXlxx_ATPyvKZ1KoyFOSIBzEAOkN-2H-HhUY/edit
A
B
And
let
me
know
if
you
can
see
my
screen
with
the
meeting
notes:
yep.
Okay,
so
welcome
everyone
on
the
next
kheema
working
group
promulgation
and
today.
I
am
your
host
and
Sir
Edmund
will
take
notes.
Agenda
for
this
meeting
is
quite
simple
at
the
beginning.
I
will,
if
you
status,
update
and
I
would
like
to
present
next
priorities
and
later
Tomic
semesters
provide
more
details
about
GE
cluster
integration
job
and
let's
have
a
look
on
our
board.
So
since
Monday
we
most
three
issues
to
accept
column.
B
First
one
is
about
problems
with
the
integration
test.
So
after
running
our
integration
tests
for
a
week
or
two,
we
got
following
error.
Logging
profile
service
exceeded
32
kilobytes,
so
the
reason
was
following:
we
use
one
service
account
for
provisioning,
virtual
machine
to
run
or
our
tests,
and
that
service
account
stores,
public
keys
for
this
short-lived
virtual
machines
and
its
profile
grows,
and
at
some
point
it
was
too
big
to
provision
next
door
to
a
machine.
B
So
all
fix
was
quite
simple:
we
defined
the
periodic
job
which
is
run
everyday
from
Monday
through
Friday
at
7
a.m.
and
we
just
performed
some.
Some
cleaner
and
next
next
issue
was
done
by
women,
so
he
made
some
refactoring
regarding
immigration,
a
job
so,
first
of
all,
and
you
can
see
that
we
integration
job
is
currently
inside
jobs
directory.
It
is
in
the
common
integration
file.
B
Additionally,
Sulaiman
moves
some
some
scripts
which
are
strictly
related
to
kima
to
the
common
repository,
and
we
have
also
one
back,
which
is
already
fixed
in
the
relief
column.
There
is
a
issue
about
proposal
for
release
process
since
last
meeting
I,
let's
say
productize
scripts.
So
it's
not
only
proposal,
but
it
will
be
just
after
murdering
that
poor
request,
it
will
be
just
working
solution
and
so
with
the
reviewers.
B
We
already
agreed
with
general
ideas,
and
now
we
are
only
discussing
details
and
to
me
how
today
move
to
the
review
column
to
issue
about
running
static
analyses
for
our
share
script.
So
because
we
have
more
and
more
share
scripts,
we
we
need
to
have
some
something
to
check
its
quality,
and
here
maybe
I
would
add
one
comment
because,
as
you
probably
remember
on
one
of
the
previous
meeting,
we
decided
to
use
go
language
as
our
primary
tool.
B
A
B
That
nothing
so
yes,
so
our
short-term
goal
is
to
enable
teams
to
migrate
the
components.
So
what
we
need
to
do
I
found
three
or
four
for
tasks
which
needs
to
be
done
before
that.
So,
first
of
all,
we
have
at
least
one
working
example
and
it
can
be
UAP
layer
component,
but
we
need
to
finish
two
issues.
B
First,
one
is
this
proposal
for
release
process,
because
in
that
proposal
we
define
job
which
will
be
run
for
releases
of
that
component
and
we
also
need
to
define
post
submit
to
job
for
your
ap
layer,
but
it
will
be
easy,
peasy
tasks,
so
it
will
be
quite
fast
done.
Next.
We
need
to
provide
the
documentation
to
the
people
which
explain
how
to
migrate
the
component
step
by
step.
So
we
have
issue
for
that.
I
just
move
it
from
the
to
do
column
to
in
progress
and
I
assigned
myself
to
do
that
and
next
one.
B
We
need
to
define
jobs
for
the
test,
infrared,
apposite
or
e.
So,
whenever
anyone
provide
any
changes
for
the
jobs
definition,
it
should
be
validated
by
our
continuous
integration
server
and
the
last
point
is
defining
brand
protections
because
right
now,
Pro
consent
checks
for
for
to
the
github,
but
they
are
not
marked
as
required.
So
still
you
can
merge
your
a
pull
request,
even
if
that
checks
are
fine.
B
So
currently
we
we
found
these
four
topics
that
needs
to
be
need
to
be
addressed
before
we
ask
teams
to
migrate
a
component
and
also
we
do
not
want
to
start
emigration
surance
all
teams
at
the
same
time.
So
probably
we
will
do
it
in
one
team
and
then
next,
and
so
we
do
not
want
to
I,
don't
know
solve
the
same
problems,
and/or
block
all
the
teams
at
the
same
time.
So
do
you
have
any
questions?
What
would
I
present
it?
B
So
our
next
goal
or
the
status
of
our
current
work
I,
would
have
only
one
question
about
this
suggestion
that
yeah
we
should
use
golang
for
for
our
logic,
I
I
wasn't
there
when
it
was
discussed.
So
that's
my
question
that
that's
where
my
question
come
from,
I
mean
how
to
judge-
and
this
thing
where
bar
script
is
say:
okay
and
well,
when
should
we
use
go?
Should
this
be
discussed
before
raising
pull
request?
B
Somehow
I
would
say
that
bar
scripts
can
be
quite
non-trivial
and
still
be
kind
of
valid
from
the
engineering
point
of
view,
because
investment
in
in
in
compiled
binary
probably
only
pays
off
when
it's
heavily
really
reusable
like
we
are
doing
just
good
general
purpose
tool,
for
example
that
will
be
reused.
Otherwise
it's.
B
To
me,
yes,
I
think
it
do
not
have
to
be
all
the
time
at
the
binary.
We
can
usually
go
run
command
and
execute
your
your
go
application
and,
to
be
honest,
if
I
would
choose
tool
on
the
basis
what
is
simpler.
So
if
I,
if
I,
have
good
as
the
good
SDK,
for
example,
for
D
cloud
I
would
prefer
to
use
and
go
application
because
I'm
I
can
somehow
I
can
test
it
and
in
case
of
scripts,
it's
more
more
difficult
so
that
that
that
might
answer.
So
what
is
simpler
to
you?
B
So
if
there
is
only
one
liner
or
two
lines
which
makes
execute
some
other
tool
and
it
is
difficult
to
port
it
to
go,
I
think
it
does
not
make
sense
to
to
rewrite
to
go,
but
otherwise
we
should
use
okay,
so
we
go
well.
We
will
try
to
use
the
goal
round.
Yes,
approach,
okay,
that
so
that's
one
answer:
it's
silly
yeah
means
it
will
be
compiled
during
every
execution
of
the
job.
Yes,
I
believe
as
far
as
I
know,
it
still
is
compiled
in
the
background
yeah,
but
process.
A
B
Small
files,
it
does
not
matter
that
much
okay,
okay,
go
we'll,
come
back
for
sure
this
question
sooner
or
later.
So
then
we
will.
We
need
more
use
cases.
He
has
to
be
able
to
somehow
find
the
good
balance
yes
between
using
batch
scripts
and
go
perhaps
Thanks.
So
thank
you
for
the
question
so
and
if
anyone
else.
B
B
C
B
B
We
still
have
some
poor
requests
that
requires
review.
It
is
a
very
small
like
release
IP
address
from
DCP.
This
is
versions
very
tiny
script,
so
that
shouldn't
take
too
much
I.
Hope
I
expect
that
today
it
will
be
merged,
because
it's
really
hard
to
you
know
yeah
find
any
anything
wrong
in
such
a
small
thing.
These
are
too
small
scripts
that
will
be
used
in
a
main
script
for
the
pipeline,
which
is
this
one?
B
It's
still
VVIP,
so
you
can
start
looking
at
it,
but
just
don't
pay
too
much
too
much
attention
to
the
details
because
it
will
be
polished
and-
and
you
know,
smooth
until
I
will
remove
the
ap
label.
What
essentially
does
the
script?
It
is
provisioning
and
de-provisioning
all
external
resources,
and
we
want
to
merge
it
as
it
is.
So
this
is
an
important
step,
so
we
know
that
we
can
run
it.
B
It
will
preview,
a
reserved
IP
address,
create
DNS
entry,
of
course,
wait
appropriate
time
for
all
those
things
to
be
available,
then
provision
the
cluster
and
then
that
provision
those
things
so
that
we
are
sure
it
there
are
no
leftovers.
There
are
no
longer
but
it's
safe
to
use
yeah.
So
that's
our
purpose
for
today
and
yeah
to
make
this
pull
request
to
be
merged
so
that
we
can
proper
test
it
yeah
and
the
next
step
that
will
will
continue
next
week
from
from
Tuesday,
because
unfortunately,
Monday
is
free
it.
B
Poland
will
be,
to
just
add
one
tiny
step
with
kima
installation,
because
we
should
have
everything
ready,
I
mean
all
the
values
should
be
there.
Dns
IP.
All
that's
left
is
to
actually
install
kima
on
that
and
with
that
set,
we
plan
to
finish
the
entire
pipeline
if
nothing
wrong
will
happen
again
somewhere
around
Wednesday
next
week.
Thank
you.
That's
the
status.
Are
there
any
questions
to
that.
I
have
three
questions,
so
this
group
is
only
to
be
executed
on
a
per
request,
so
the
cluster
is
provisioned.
Tests
are
run
and
then
is
the
provisioned.
B
Yes
right
now.
Yes,
we
want
to
have
this
right
now.
Yes,
you
can
see
here
in
the
names,
for
example,
its
PR
something-something
for
then
will
be
a
similar
pipeline
for
for
the
commits,
merge
to
master,
and
it
will
generally
use
the
same
logic,
but
of
course,
names
will
be
different
there,
because
we
will
not
have
any
kiosk
them
and
then
once
this
is
ready,
we
plan
to
prepare
another
one
and
find
common
places,
yes
make
it
generic
and
then
make
two
jobs
out
of
it.
Out
of
this,
you
want
one
for
pull
requests.
B
A
A
C
B
A
Okay,
so
let's
say
follow-up
question
at
soon:
we'll
start
to
integrate,
let's
say
existing
scripts
and
from
chimera
process
already
like
setting
up
cluster
with
overrides
and
installing
comma
itself
and
testing
and
so
on
and
so
on.
Would
you
suggest
that
we
should
somehow
think
about
rewriting
those
two
go
language
as
well:
I.
C
D
A
It's
something
like
calling
G
crowd,
stool
right,
so
we
are
saying
that
sooner
or
later,
let's
say
we
will
have
CLI
tool
for
setting
up
for
instant
ink
kima.
Does
it
make
sense
to
wrap
that
in
go
application?
You
know
what
I
mean
don't,
oh
in
from
my
point
of
view,
it
is
easier
to
have
a
sh
script,
which
is
just
calling
G
clout
or
cube
city
or
comma
C
alive.
If.
A
D
Tom
said
that
it
depends
on
the
case,
for
example,
I'm
working
with
a
validation
of
config
files
and
right
at
the
very
deterring
go
then
a
creative
idea,
Turing
bar
script
right
in
your
case,
you'll
just
call
the
coop
city,
crib
CD
cloud
and
it's
easier
to
play
it
in
bash.
So
every
case
is
different
and
we
don't
force
a
single
rack.
It
depends
what
is
introduced.
B
Okay,
guys
so
just
to
finalize
that
I
would
personally
prefer
to
stay
with
the
bar
script
for
this
poori
west
and
if
we
find
this
case,
for
example,
to
be
a
good
candidate
to
do
a
kind
of
PLC
or
maybe
just
try
just
to
provide
alternate
version
in
go
and
then
compare
them.
Yes,
that
it's
not
I'm
not
objecting
this
idea.
B
Perhaps
it's
good
idea,
maybe
it
will
turn
out
that
the
go
code
will
be
simpler
than
bash
code,
for
example
for
sure
the
finally
close-
or
you
know
this
thing-
that
always
must
happen,
regardless
of
any
exceptions
or
errors,
is
kind
of
cryptic
in
bash.
Indeed,
I
agree,
it's
small
clearing,
though
so
perhaps
the
go
version
would
be
better
about.
B
We
should
I
would
say
personally
that
we
should
finish
that
and
that
maybe
provide
go
version
and
then
compare-
and
this
is
something
we
can
do
in
the
near
future-
and
that's
just
my
opinion
on
this
topic
and
then
try
to
see
whether
which
version
is
better
which
is
yeah.
Perhaps
it
will
turn
out
that,
for
this
particular
case,
indeed
go
is
a
better
choice.
Perhaps
not
it's
hard
to
tell
just
without
comparing
them.
B
B
B
If
not,
I
would
like
to
remind
you
that
we
have
meetings
on
Tuesday
and
Thursday
for
the
active
contributors
at
state
and
10:00
a.m.
and
our
next
meeting
our
next
review.
Our
meeting
will
be
on
the
next
Friday
at
1:00
p.m.
so
if
there
is
no
more
topics,
thank
you
for
today's
meetings
and
see
you
on
the
next
one.
Thank
you
thank.