►
From YouTube: Kyma Knative Integration WG meeting 20181206
Description
Meeting Notes https://docs.google.com/document/d/1BZoJQ5qsSudlix8PXjykQfsJtfwC7EgUy0BP3oORDsA/edit
A
So
hello
welcome
welcome
everyone
to
this
first
meeting
for
the
quemic,
a
native
integration
of
working
group
and
the
main
item
for
this
working
group
is
we
want
to
first
have
everyone
updated
on
the
goal
of
this
working
group?
What
you
want
to
achieve
as
a
part
of
this,
and
what's
the
current
status,
how
far
we
have
achieved,
what
all
things
are
working,
what
things
are
planned
and
then
the
current
status?
A
A
A
A
It
should
be
possible
to
have
another
another
possible
meditations.
They
are
essentially
called
cluster
for
regionals,
as
a
part
of
the
kinetic
eventing
terminology
will
also
be
kind
of
a
feature
film
because
switch
that
will
technically
you
find
the
behavior
whether
we
are
using
the
kinetic
venting
or
we
are
using
the
current
implementation
that
is
simplified
pendants.
So.
B
C
Okay,
can
you
hear
me
yeah
perfect,
so
maybe
the
rest
could
mute
yourself,
because
we
hadn't
hear
some
voices.
Okay,
thank
you.
So
we
already
did
some
work
and
we
had
a
progress
with
K
native
in
Indy
kima.
Essentially,
we
we
did
some
pieces
actually
two
PLC's
to
check
how
we
can
integrate
kima
with
k
native
and
how
this
can
work
together
and
as
an
outcome
of
our
pieces.
We
have
a
small
proposal
which
Sherman
will
present
right
right
after
me
and
Sherman.
C
A
B
B
We
fought
a
couple
of
problems
which
I
will
describe
in
a
minute
and
came
with
the
final
conclusion:
what's
the
best,
in
our
opinion,
way
to
integrate
kima
into
into
the
2008
kima
with
cognitive
and
what
we
want
to
ask
you
is
to
approve
or
to
make
a
decision
just
yes
or
no.
If
you
are
going
this
way
or
not,
what
were
the
factors
that
we
need
to
the
need
to
needed
to
have
been
taken
into
consideration?
First
of
all,
kima
needs
to
work
without
kinetic
as
it
was
working
before.
B
B
The
first
is
how
to
run
both
K
native
and
kima
on
the
same
kubernetes
cluster,
because
they
both
use
each
do
and
there
may
be
some
conflicts
and
how
to
solve
them,
and
the
second
problem
is
how
to
install
creative
and
how
to
fit
it
into
our
installation
process
and
the
third
problem.
Last
but
not
least,
is
how
to
version
creative
with
kima.
B
So
let
me
let
me
start
with
the
first
one:
how
to
do.
We
want
to
run
cane
kima
and
kinetic
on
the
same
kubernetes
cluster
as
it
appears
there
wasn't
much
problem
because
they
both
run
in
separate
namespaces,
so
they
could
run
out
of
the
box
in
the
same
kubernetes
cluster
without
conflicting
with
each
other,
because
there
there
is
only
one
shorty
resource,
it's
easier,
but
creative
is
running
on
easier
without
any
interest.
If
changes
and
because
of
that,
it's
working
perfectly
with
the
is
our
version
of
Asia.
B
There
was
one
problem:
cognitive
uses,
its
own
ingress
gateway,
which
makes
its
another
entry
point
to
kubernetes
cluster.
So
there
appeared
that
and
we
have
two
options.
First
of
all,
we
can
leave
it
as
as
it
is,
and
make
a
native
use
different
in
grayscale,
fading
kima,
and
the
advantage
of
the
solution
is
easy.
There
we
need
node,
we
need
to
do.
B
The
second
approach
you
to
move
all
the
traffic
that
goes
to
Kemah
through
the
english
gateway
and
the
previous
solution
was
proved
by
Jakob,
a
witch
that
it's
working
with
perfectly
the
second
one
was
done
by
me:
I
moved
I,
basically
switched
all
the
gateways
we
have
to
issue
a
gateway
to
creative
gateway
and
I
had
to
do
two
results
on
context
and
well.
In
the
end,
it
also
worked.
B
What's
the
advantage
of
the
solution,
it's
easier
to
maintain
the
system,
because
there's
only
a
single
point
of
entry,
there
is
less
Diana's
management
because
we
only
need
one
domain.
There
is
less
certificates
management
because
of
the
same
reason
and
which
are
more
tightly
integrated
with
creative.
B
B
The
second
problem
is
how
to
fit
cognitive
into
installation
process
and
because
we
have
the
principal
batteries
included,
cognitive
have
to
be
installed
during
our
installation.
We
cannot
put
the
burden
on
the
user
cognitive.
Has
this
this
approach
of
providing
only
m-files
instant
of
hand
cards,
so
it
came
with
another
approaches
to
the
problem.
First
of
all,
just
use
the
arms
they
create
a
hypnotist
job
which
picks
the
yams
and
apply
them
to
the
the
kubernetes
cluster
and
checks.
B
If
everything
is
installed
properly,
this
approach,
it
makes
a
great
future
updates
of
cognitive
easier
because
we
do
not
do
any
changes
in
Yama's.
We
only
pick
them
and
install
them,
but
there
are
two
problems.
First
of
all,
there's
not
how
installer
is
intended
to
be
used
and
the
second
one
which
is
a
couple
to
this
one.
We
did.
We
make
a
general
rule
to
avoid
bar
scripts.
We
want
to
remove
them
from
the
system
as
much
and
avoid
them
as
much
as
we
can.
B
What's
the
advantages
of
this
approach?
First
of
all,
it's
how
the
installer
is
meant
to
be
used.
This
is
how
it
was
designed
and
and
how
we
would
like
to
use
it.
There
is
no
additional
tool
that
needs
to
be
introduced
to
the
system
and
charts
are
a
lot
easier
to
extend
than
bar
scripts.
So
in
from
accessibility
point
of
view,
because
which
is
important
because
we
need
to
introduce
eventing
and
several
that's
lighter-
and
this
approach
is-
is
a
little
bit
better
was
the
disadvantage,
and
it's
not
a
small
one.
B
We
have
to
do
a
lot
of
changes
in
the
Yama's.
Those
the
upgrades
of
kinetic
later
will
be
harder
until
they
introduce
their
own
health
chart.
What
I
was
talk
about
that?
One
later
and
the
last
problem
we
had
to
resolve
was
how
to
version
creative
intima.
The
first
approach
was
to
not
check
in
Yama's
into
a
Kimura
repository,
but
just
store
the
URLs
to
specific
releases,
and
this
has
a
big
advantage
of
not
having
in
the
yams
in
our
repository.
B
We
don't
have
to
maintain
them
and
we
don't,
but
we
depend
on
availability
of
external
files
and
unfortunately,
this
approach
cannot
be
used
if
we
want
to
embed
Canadians
into
a
chart,
because
we
have
to
modify
them.
So
we
cannot
just
download
them
and
apply
them,
and
the
other
approach
was
to
just
download
the
release
and
store
it
into
kimmel
repository,
and
it
gives
us
better
control
over
what
we
have
and
what
we
are
installing
we
can
play
with
it.
B
B
We
cannot
use
raw
URLs.
We
have
to
check
in
the
kinetic
yams
in
tokima
repository,
and
that
gives
us
the
def
answers
to
the
free
problems
we
had
to
solve.
One
disclaimer
as
governor
of
set
before
the
installing
kima
with
connective
is
optional
and
we
introduced
a
feature
flag
of
Halawa
right,
global
cognitive
with
just
which
enables
Canadian
installation
and
changes
schema
configuration
to
run
on
top
of
it
without
it,
with
the
cob
alternative
flag
set
to
false
or
unset.
The
system
will
remain
as
it
was
before.
B
The
question
to
the
working
group
is:
do
we
embrace
this
approach
or
not?
And
what
are
advantages
of
this
solution?
It's
easier
to
as
a
set
is
easier
to
debug
and
maintain
its
easier
to
extend.
We
are
in
the
because
we're
a
new
have
1080p
arms
checked
in
into
our
conversion.
Control
system
were
independent
of
kinetic
recycle
and
the
problem
with
having
yams
converted
to
helm
chart
can
be
solved
by
contributing
to
tentative
with
the
chart.
We
we
have
and
others
added
the
chart
to
their
product
was
the
problem
with
this
approach.
B
This
problem,
however,
will
be
resolved
in
next
releases
of
cognitive
because
they
decided
to
abandon
their
cognitive,
ingress
gateway
and
move
to
Eastern
ingress
gateway,
which
is
also
a
benefit
for
us,
because
we
don't
not
have
to
do
the
integration
again,
we're
already
integrated
with
them.
We
just
have
to
change
the
name
of
the
of
the
gateway
and
the
problem
is
upgrading
cognitive
because
all
the
changes
they
do
to
the
rihanna's.
B
A
B
No,
there
was
a
nun
discussion
yet
because
the
chart
is
for
now
it's
really
not
production
ready,
it
doesn't
have
many
many
parameters,
etc.
Moreover,
what
I
have
seen
on
the
there's
slack
channel
is
they're
not
really
ready
or
willing
now
to
include
the
home
trust
because
they
have
their
own
problems,
but
that
it
is
on
the
roadmap.
Okay,
and
that's
how
we
want
to
solve
the
problem
of
maintaining
int
by
us
contributed
to
them
make.
B
D
A
Other
thing,
maybe
it
is
something
that
we
need
to
go
back
and
then
give
some
thought
about.
This
is
for
the
for
the
inventing.
How
should
we
approach
should
we
have
a
separate
flag
for
the
eventing,
or
should
it
be
just
one
flag
that
already
decide
whether
K
native
and
then
the
K
native
eventing
is
getting
installed
or
not,
because
it
could
still
happen
that
we
have
a
grave
option
that
we
can
use
taken.
A
C
From
the
hunt,
or
it
should
be
a
separates
flag
in
the
values.
However,
what
also
could
be
mentioned
here?
There
is
a
flag
if
you
would
like
to
run
anything
with
kima.
You
have
a
doctor's
94
d.com,
for
example,
station
off,
like
that.
That
actually
tells
that
we
want
to
have
native,
enable
yeah,
and
then
once
this
is
use
and
is
the
flag
feature
flag
is
propagated
to
the
Installer.
You
could
also
directly
in
the
overrides,
make
another
flag,
for
example,
a
native
eventing
enabled.
C
C
Have
post
the
chart
link
to
the
documentation,
which
is
also
worth
mentioning
because
we
have
this
proposal,
but
additionally,
we
yeah.
We
have
to
commented
how
to
write
now
test
KNAT
with
kima,
and
I
will
post
links
also
to
the
stack
after
the
meeting.
So
you
can
try
out
right
now
from
the
master
branch,
all
the
cognitive
changes
that
were
proposed
right
now.
D
B
Yes,
we
also
have
fun
working
with
the
committee.
We
had
the
problems
in
the
beginning
because
somehow
they
on
master
branch,
they
change
names
of
some
components
and
our
scripts
were
not
working
any
longer.
So
yes,
having
this
ever
having
everything
checked
in,
gives
us
there's
a
lot
of
control
and
also.
A
B
Several
releases,
as
I
mentioned
Kennedy
flight.
It
does
not
of
the
problem.
We
start.
We
started
with
Kennedy
flight,
but
cognitive
light
still
includes
some
monitoring
parts,
not
all
of
them,
but
some
of
them.
Unfortunately,
okay,
if
serving
comes
also
in
release,
non
monitoring
which
completely
disables
the
monitoring,
and
we
have
used
that
okay.
A
Yeah
that
was
just
right.
Maybe
I
was
missing
that
point,
so
thanks,
okay,
so
for
me
at
least,
it
looks
fine
that
if
we
go
with
this
current
decision
because
it
looks
to
me
out
of
those
two
less
complex
and
then
yeah,
of
course
it's
not
the
the
best
thing,
but
it's
better
than
the
other
one,
and
it.
A
A
A
B
A
A
B
A
C
B
C
A
Course
they
are
driving
the
agenda
forward.
That
will
be
interesting
and
regarding
the
meeting
schedule,
so
we
saw
that
this
was
one
of
the
slots.
That
was
like
best
fitting
based
on
all
the
other
meetings
that
we
have
around
the
working
groups
and
the
SIG's.
So
what
does
it
still
looks
like
right
slot,
every
Thursday
from
2:00
to
3:00.
A
B
C
C
A
C
Yes,
maybe
you
what's
next
right:
let's
assume
that
we
have
our
proposal
accepted
and
you
would
like
to
have
yet
another
meeting
in
the
next
week
according
to
the
proposed
schedule.
So
what
are
the
plans
for
for
the
next
week
right
I?
Would
I
would
like
to
have
the
community
review
the
documents
and
play
around
with
with
kima
at
least
locally
on
me
with
Canada?
If
you
can
also
play
with
with
GE,
the
documentation
is
provided
and
then,
let's
start
digging
into
the
eventing
part
right.
A
Yeah
so
I
guess
one
thing
with
you
we
discussed
today
and
then
maybe
it
makes
sense.
So
we
also
need
to
come
up
with
the
kind
of
a
design
first
that
how
the
eventing
should
get
installed.
In
fact,
the
how
the
key
my
venting
on
top
of
k
native
should
get
installed.
Maybe
we
should
have
some
kind
of
propose
around
this.
A
D
D
A
B
A
B
C
Yep
at
the
wrong:
basically,
the
robot
will
be
created
once
we
will
have
the
plant
POCs
done
and
we
will
have
will
have
documented
outcomes
that
will
be
presented
to
the
kheema
council
to
to
make
the
dis
final
decision
because
yeah
some
of
the
beauty
needs
to
be
done.
First
then,
based
on
that
my
constants
to
approve
or
not
the
decisions,
and
then
we
can
done
further.