►
From YouTube: 20190703 scl cluster api office hours
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
Hello
today
is
July
3rd
2019.
This
is
the
cluster
API
office
hours
some
project,
if
sequester
lifecycle.
As
always,
we
have
a
code
of
conduct
policy
which
basically
boils
down
to
don't
be
a
jerk.
Are
we
have
agenda
here
if
folks
want
to
add
their
deets
to
the
meatiness
that'd
be
highly
useful?
Also,
if
you
have
things
that
you
would
like
to
discuss,
feel
free
to
add
an
agenda
item
here,.
B
Tobias
accounts
for
testing,
yes,
a
while
back.
We
ended
up
disabling
the
janitor
for
the
cluster
API
tests
because
we
found
out
that
the
10,
what
we
thought
were
AWS
accounts
were
just
10,
different
AWS
credentials
and
the
same
accounts.
The
cops
account
I
know:
Justin
was
looking
into
this
a
while
back
and
I
just
wanted
to
kind
of
follow
up
to
see
where
that
was
I
have.
C
Tracked
it
down
I
need
to
or
I
or
anyone
needs
to
basically
PRA
request.
The
blocker
is
being
a
Google
Group.
This
is
underwear,
kabuki,
Kate's,
infra
I
need
to
PR
requests
in
to
create
said
group,
and
then
it
should
be
created
and
then
we
should
be
able
to
create
these
sub
accounts
via
means
to
be
determined,
but
the
first
step
was
the
email
I
think
I
can
do
that.
I
can
create
the
sub
accounts.
They
gave
me
temporary
permission
so,
but
we
do
need
to
email.
C
B
The
issue
is:
is
that
I
think
we're
hit
in
a
couple
of
places
right
now,
where
we're
getting
intermittent
issues,
if
we
have
to
test
run
between
the
inter
minute,
janitor
runs
that
are
running
today
and
we're
looking
at
banding
the
testing
as
well,
which
is
only
going
to
potentially
cause
more
issues
there.
So,
okay,
yeah
I'll
work
on
it.
B
B
B
D
Yeah,
so
so
Seth
and
I
on
my
team
here
at
New
Relic
have
been
working
mostly
in
the
Kappas
space.
So
far
with
some
smaller
contributions
to
the
cluster
API
upstream,
as
the
kind
of
V
1
alpha,
2
architecture
starts
becoming
a
little
bit
more
of
a
reality
and
that
code
comes
in
I
think
our
involvement
at
the
cluster
API
level
will
likely
increase,
especially
with
the
bootstrap
provider.
Stuff.
D
A
few
months
ago
we
had
expressed
some
kind
of
soft
requirements
for
being
able
to
use
more
ignition
style
bootstrapping
and
in
discussing
a
lot
of
the
bootstrap
provider
proposal
you
know
discussing
with
Vince
and
others.
You
know
that
the
bootstrapper
area
is
kind
of
where
that
work
may
be
able
to
come
into
play.
D
So
there's
myself
and
Seth
we've
seen
PRS
from
there
is
Mark
who
usually
can't
make
this
call
because
he's
in
Barcelona,
and
then
we
have
Matt
on
my
team,
is
pretty
much
the
core
OS
expert,
so
I
think
all
of
us
are
probably
going
to
get
more
involved
within
thinning
in
the
next
couple
of
weeks.
Next
couple
of
months,
numbers
are
hard,
but
I
said
for
myself
like
easily
six
to
eight
hours
a
week.
If
you
know,
if
it's
more
relevant
to
the
stuff
that
my
team
is
looking
at,
you
know,
maybe
more
than
that.
A
Right
I
think
TLDR.
Please
go
to
that
issue
in
general.
We
should
be
doing
this
as
a
funk
that
one
off
like
every
cycle.
We
should
do
their
promotion
policy,
which
is
standard
for
SiC
Lester
life
cycle.
We
go
through
this
pretty
regularly
and
we
talked
about
it
even
yesterday
where
we
go
through
at
the
end
of
any
cycle.
We
do.
A
We
do
the
lunging
and
demoting
too,
as
well
so
like,
if,
if
somebody's,
not
active
and
they're
in
the
approvers
list
or
the
reviewers
list,
you
know
ask
them
if
they
still
want
to
do
that
or
if
they
have
time
to
do
it,
because
it's
it's
an
ongoing
maintenance
thing.
So
please
put
your
comments
in
MPR.
If
you're
interested
in
helping
out
you
can
you
have
committed
and
are
intending
to
commit?
That's
that's
key!
So
we
for
some
people
who
are
new
and
haven't
actually
fully
committed.
F
D
So
we
think
it
does,
because
a
couple
of
assumptions
we
made
about
that
proposal
where
that
the
bootstrappers
output
would
just
be
the
configuration
that,
let's
say
in
the
case
of
AWS,
would
become
like
user
data
or
what
have
you
that
is
currently
in
alignment
with
the
pattern
that
we
use
to
administer
ignition
for
core
OS.
So
there's
no
code
for
this,
so
like
I,
it's
pretty
hard
to
I,
guess.
F
G
F
H
Yeah,
so
this
was
an
issue
I
usually
open
by
Pablo
like
she
wants
ago,
and
it
was
pretty
much
like
to
remove
provider
spec
and
provider
status
from
the
cluster
as
well.
The
same
as
we
did
like
for
the
machine
I
wanted
to
push
this
a
little
bit
more
forward,
not
sure
if
bubbles
on
the
call,
but
if
there
are
any
updates
or
my
talks
around
this
I'm.
G
Here
briefly,
to
comment:
tell
you
all
these,
like
research
means
that,
did
you
look
at
the
comment
from
Andy?
He
suggested
our
actual
plan
that
I
thought
it
was
make
sense.
It
would
basically
I
suggested
to
moving
steps.
The
first
step
was
just
to
take
the
existent
embedded
of
aspect
just
make
a
reference
to
an
external
co
d,
and
that
takes
me
without
any
changes,
just
change
it,
the
actual
feel
for
our
object.
Reference
as
I
mentioned
that
they,
this
is
pretty
simple.
G
I
wanted
to
test
it
somehow,
but
I
was
looking
for
a
provider
to
test
it
and
neither
did
tests
provided
the
one
we
use
in
the
test
know
the
cap,
the
docker
provider
that
shot
his
development
actually
use
the
specs,
so
I
can
make
a
shame,
because
is
it
simple
or
how
to
test
it?
How
I
want
to
mostly
to
to
try
to
figure
out
what
is
the
the
impact
in
the
in
the
existing
provider?
So
that's
a
little
less
situation.
H
G
H
Yeah
so
like
so
that's
what
we
kind
of
discussing
the
issue
like
a
while
ago.
So
if
we
open
like
a
simple
cap
which
is
like
scope
them
like
it,
just
changing
provide
expect
to
have
its
own
external
CRD
and
nothing
else.
I
think
it
would
be
very
small
engine,
but
the
like.
Oh,
we
can
actually
push
it
through
relatively
easy
only
and
indeed
you
have
any
thing
to
add.
Yeah.
G
C
G
No
really
dude
to
be
honest,
nobody
kept.
This
is
not
going
to
be
much
different
from
what's
already
in
the
in
the
in
the
issue.
If
you
look
at
the
description
initial,
this
key
to
the
issue,
there's
a
text
I
just
will
look
at
other
steps
to
try
to
screw
the
same
format,
but
regarding
content,
I,
don't
have
much
to
add
to
that.
Okay,.
H
Is
what
yeah?
This
is
something
that
yeah
you
open
up,
and
we
were
briefly
chatting
at
yesterday's
cig
meeting.
So
in
general,
like
we
have
a
version
skew,
we
can
say
like
a
between
cluster
API
and
providers,
and
now
that
we're
also
going
to
split
into
infrastructure
providers
and
pusher
providers,
the
matrix
of
you
know,
compatibility
matrix,
will
be
even
harder
to
understand
for
users.
I
don't
have
any
proposal
in
this.
I
would
like
to
here
life.
A
I
actually
gonna
say
that,
instead
of
bike
shedding
in
this
meeting,
it
should
be
more
of
a
PSA.
If
you
have
thoughts
or
ideas
to
rally
on
that
issue
and
then
maybe
once
we
have
more
distilled
feedback,
we
can
actually
talk
about
it.
Talk
about
that
issue
with
some
concrete.
A
set
of
action
items
sounds
good.
A
H
You're
up
next
again:
okay,
so
4
V,
1,
alpha
2,
so
quick
status
update.
First,
we
have
merged
the
pipes.
We
changed
the
domain
to
cluster,
the
sixth
okay,
stereo
DVDs,
that's
actually
gonna
stay,
or
it's
going
to
go
back
to
cluster.
The
kids
that
I,
oh
I,
guess
like
will
help,
will
find
an
answer
like
in
the
coming
days.
There
was
this
PR
up,
which
had
like
a
lot
of
comments
and
I
was
hoping
that
we
could
like
either
solve
them
or
like
close
to
PR.
H
If,
like
we
want
to
keep
these
fields,
this
is
removing
addresses
and
machine
gun
conditions
from
machine
da
status
which,
as
far
as
I
know,
they're
not
like
really
use
especially
conditions
and
in
D
1.
Alpha
2
addresses
should
move
to
the
e
vector
provider.
If
there
is
a
need
for
comments,
questions
concerns.
J
I
J
My
concern
with
conditions,
as
we
talked
about
this
for
weeks
previously
and
the
PR
doesn't
have
a
lot
of
justification
for
why
we
should
change
things
and
I'm,
not
sure
that
the
people
involved
now
or
many
people
that
are
active
now
we're
actually
aware
of
the
previous
discussions.
So
that
was
the
main
reason
I
brought
it
up.
I
don't
feel
strongly
about
keeping
it
if
no
one's
using
it.
J
J
Yeah
I
don't
know,
I
think
this
is
something
we
might
want
to
also
discuss
at
Justin's
later
topic
on
API
review,
but
this
PR
again
I
mean
it
removes
two
fields:
it
doesn't
change
functionality,
at
least
for
any
one
that
was
on
v1
l1,
so
I
don't
feel
strongly
about
removing
it.
I
also
don't
feel
like
it
does
anything.
A
So
so
I
think
that's
one
concrete
actionable
feedback,
I
have
and
I
guess
the
other
concrete
actual
feedback
would
be
to
try
and
maybe
do
a
little
bit
more
history,
diving
and
maybe
maybe
David
you
have.
You
can
link
to
the
issues
or
something
before
we
make
a
final
call
on
this
particular
one.
Yes,.
K
H
H
I
I
think
the
biggest
thing
that
I'm
interested
in
and
one
of
the
reasons
that
I
suggested
removing
these
two
events
was
that
when
I
first
started
looking
at
the
API
for
cluster
API,
I
realized
there's
a
lot
of
fields
that
the
cluster
API
repository
has
no
code,
that
it
does
anything
with.
And
that
was
confusing
to
me
as
a
newcomer
to
the
project.
And
so
if
we
decided
that
we
wanted
to
keep
these
or
any
other
fields
that
close
to
API
itself
doesn't
touch.
I
Then
I
would
strongly
encourage
us,
as
part
of
all
of
the
effort
that
we're
doing
to
create
conformance
tests
that
make
it.
So
that
requires
or
sorry
that
providers
to
fill
in
these
fields,
because
they
are
there
for
a
reason
and
if
they
are
used
by
some
providers
and
not
used
by
other
providers
than
that
they
must
be
optional
and
documented
as
such.
But
the
fact
that
there's
fields
on
there
that,
like
may
or
may
not
be
used
or
processed,
is
a
concern
to
me.
I.
I
L
There
were
comments
about
so
the
initial
proposal
talked
about
phases
in
the
Machine
object,
and
then
there
were
comments
saying
you
know
we
should
be
using
the
could
the
conditions
conventions
that
that's
what's
recommended
and
that's
what's
used
in.
You
know
another
in
core
kubernetes
api
and
so
I
see
I'm
a
little
confused.
Why?
Why
are
we
removing
conditions
if
it's
something
I,
so
it
may
not
be
part
of
that
proposal
might
not
be
implemented
right
now,
but
it's
I
thought
it
was
in
in
discussions
on
that
PR
that
we
were.
J
A
K
Okay,
I
would
say
I've
confirmed
field
in
my
overall
concern
is:
if
we
remove
this
information
from
the
machine,
then
we're
now
changing
four
external
components:
the
source
of
truth
to
a
different
place
and,
for
instance,
like
if
the
bootstrap
controller
has
to
do
something
with
these
address
fields.
You
know
it
has
to
look
up
the
Machine
and
then
look
up
the
infrastructure
object
in
the.
So
it's
about
what
information
is
supposed
to
live.
Where.
A
That's
fair,
I
think
slash
fold.
The
issue
for
a
week
puts
your
comments
in
I.
Have
comments
about
conditions
in
particular.
If
you
have
comments
about
the
Machine
addresses,
please
add
the
details
there
and,
if
anything,
if
even
if
the
fields
are
not
removed,
we
should
do
the
second
half
and
II
proudly
said,
which
is
have
better
documentation
of
where
they're
used.
I
Indie
you're
next,
so
we
are
interested
in
trying
to
organize
a
hopefully
two-day
face-to-face
community
meeting,
maybe
in
September
some
time
would
be
shortly
after
we
get
V
1
alpha
2
released.
If
the
timing
goes
well
and
we
would
want
to
use
this
time
to
talk
about
V
1,
alpha
3
designs
and
proposals,
so
just
wanted
to
bring
this
up.
I
realize
that
this
is
the
day
before
us
holiday.
I
I
A
I
A
I
Think
we'd
certainly
be
interested
in
hearing
from
the
community.
What
area
or
areas
are
most
favorable,
so
Bahamas
would
be
nice,
but
but
yeah
I
know
like
we
have
fairly
easy
access,
I
think
to
some
space
in
both
Palo
Alto
and
Seattle
or
Bellevue.
But
if
there's
other
people
who'd
be
interested
in
hosting,
we
certainly
can
talk
about
that
as
well.
I'm
guessing
we'll
probably
have
like
I,
don't
know
20
to
30
people
depending
on
availability,
maybe
more
if
there's
more
interest.
So
we
just
need
to
kind
of
keep
the
size
in
mind
as
well.
A
A
Apparently
Bahamas
is
the
winner
already,
so
we'll
we'll
see
a
room
there.
Next
up
just
a
PSA
that
ace
had
a
proposal.
I
didn't
know
how
many
people
would
be
here
today,
there's
actually
quite
a
few
which
I'm
a
little
surprised
by
before
us
holiday.
But
if
folks
could
review
that
and
have
comments,
hopefully
we
can
discuss
them
next
week.
H
E
I
D
A
So
if
you,
if
you
are
interested
in
helping
the
docks,
please
feel
free
to
add
your
name
to
the
binos.
The
MIDI
notes
are
open
and
before
the
before
folks,
do
a
handoff
or
whatever
to
make
sure
that
there's
some
time
out.
So
if
other
people
are
interested
or
just
quiet
right
now,
they
can
add
themselves
to
the
Dinos
and
get
involved
smells.
E
And
if
so,
do
we
have
any
details
on
like
I
know
there
was
a
deep
dive
planned.
Is
that
still
on
the
plan
and
what
information
or
what
details
are
on
the
deep
type,
just
to
make
sure
that
people
talking
giving
general
talks
on
Cluster
api
kind
of
take
steer
clear
of
that
and
there
is
no
overlap.
So
I
just
wanted
to
kind
of
hear
what
you
all
think.
A
E
I
I
A
A
So
if
you
are
interested
in
talking
very
similar
to
how
we
did
this,
if
you're
interested
in
talking-
please
add
your
deets
here
and
we'll
collect
that
list
and
then
sit
closer
lifecycle,
we'll
have
to
figure
out
how
we
arbitrate
people
who
want
to
talk
in
this
particular
one.
Obviously,
if
you
want
to
submit
a
separate
talk,
that's
user-facing,
that's
not
on
the
developer
track,
then
you're
free
to
do
so
at
any
time.
A
C
So
this
is
sort
of
in
general,
like
what
came
out
of
the
discussion
of
whether
there
are
API
group
should
be
sync.
Cluster
dachsies,
okay,
every
customer
can
say.
Oh,
is
that
my
understanding
is
that
being
in
sync,
okay
said
it
is
not
necessarily
free
us
from
the
need
for
an
API
review
being
in
Katie
sale
may
or
may
not
require
us
have
an
API
review.
C
It
doesn't
seem
like
it's.
I
was
just
wondering
whether
we
should
actually
request
the
API
review
formally
and
go
through
that
formal
process.
It
seems
like
it's
certainly
something
that
we
iterate
on
and
having
input
input
from
the
like
stewards
of
kubernetes
api
is
self-appointed,
may
be
valuable
and
I've.
You
know
full
disclosure
I
put
it
in
for,
like
the
other
projects
that
I'm
involved
in
that
I
am
like
a
sort
of
primary
owner
on,
but
I
didn't
feel
like
I
could
just
make
Ann
Arbor.
She
decision
here.
I
know.
A
Jason
has
raised
his
hand,
but
I
want
to
talk
on
this
one
in
particular,
because
it
there
is
governance
problems
with
this
currently
so
I'm
totally
cool
with
the
idea
of
going
through
an
API
review,
but
I
also
want
it
to
be
quote-unquote
non-binding.
So
if
there
are
decisions,
we
need
to
make
I
don't
want
it
to
hamper
us,
but
I
also
don't
want
it
to
be
a
formal
procedure
that
is
required
for
things
that
are
outside
of
the
core.
A
B
Yeah
so
I
think
the
big
issue
that
we
worry
about
right
now
is
blocking
any
and
all
API
changes
as
well
iterating
on
these
early
alphas
on
API
reviews,
because
it's
a
small
group
of
contributors
that
are
already
overwhelmed,
we've
already
done
several
informal
API
reviews
with
some
of
the
API
reviewers
and
I
think.
Once
we
get
to
a
more
stabilized
version
when
we're
ready
to
start
getting
into
betas,
then
I
think
it'll
be
more
proper
to
you
know
completely
block
progress
on
iterating,
the
API
on
the
formal
API
reviews.
B
It
just
seems
very
heavy
way,
and
especially
since
all
of
the
proposals
that
we
generally
work
on
now.
Well,
we
think
we're
you
know,
accounting
for
all
of
the
things
that
we
need
to
do
for
that
milestone.
I
suspect
that
by
the
time
we
get
to
actually
shipping
B
1
alpha
2
we're
going
to
have
to
tweak
what
we
already
have
in
the
proposal
for
that
final
bit
as
we
try
to
get
everything
wired
back
together,
I.
H
And
I
would
love
like
an
imperious,
like
others
have
mentioned.
I
really
would
like
to
wait
and
feel
like.
We
are
a
lot
more
mature,
really
earlier
right
now
like
to
have
like
a
full
review,
or
you
know,
as
Tim
mentioned
like
before,
like
kind
of
like
it
being
non
descriptive
as
well
like
we
welcome
feedback
at
any
point.
H
One
thing
that
I
wanted
to
mention
like
if
this
is
more
a
question
to
Justin's
like
is
this
like
it
related
to
changing
back
to
kids,
Dario
and,
if
so,
like
I
would
be
plus
one
to
that,
because
I
don't
really
like
the
idea
of
like
exposing
sixth
okay.
Sorry,
oh
because
that
gives
nothing
to
users,
but
if
we
are
like
kind
of
going
back
and
forth
between
this
discussion
like
I'm,
completely
fine
keeping
it
as
it
is
yeah.
But
there's
there's.
J
Just
wanted
to
say
that
I
think
we
definitely
should
have
an
API
review.
I
concur
with
Jason
and
bents
that
we
probably
want
to
wait.
Because-
and
this
is
the
last
thing-
the
last
important
point-
I,
don't
think
will
be-
would
cast
an
API
review
now.
I'm
actually
curious,
who
had
informal
reviews
and
if
anyone
like
daniel
Smith,
Jordan
Liggett
any
of
those
guys
reviewed
it
because
I
don't
think
we'd
pass
right
now.
C
Next
up,
Justin
yeah,
so
I.
Thank
you
so
I
agree
with
I
think
whatever
I
said
I
my
feel
is.
We
do
have
to
forget
these
governments
things
as
a
point
of
order.
I,
don't
think
Singh
stuck.
It
said.
Okay,
so
do
actually
look
from
the
current
rules,
which
are
other
steps.
C
That's
just
not
gonna
happen
and
so
like
they
have
to
there.
There
are
things
that
have
to
happen
on
both
sides,
and
part
of
that
is
us
actually
going
through
this
process.
Understanding
like
what
the
problems
are,
so
that
we
can
eventually
be
in
a
happy
place,
but
also
you
know,
understanding
how
we
can
work
with
them
to
get
the
cycle
time
down
to
something
acceptable
for
a
project
that
is
not
like,
like
pods
right.
Pods
should
not
change
rapidly,
but
we
are
not
a
pod
API.
We
are
a
on
earlyer,
API,
yeah,.
A
So
it
seems,
like
an
action
item,
would
be
for
us
to
actually
go
through
the
process
and
are
there
people
that
want
to
actually
do
this,
but
we
also
I
think
we
generally
agree
that
it
should
be
non-blocking
at
this
time.
I
think
I
really
agree
with
the
idea
of
doing
it
early
earlier
to
try
and
get
feedback.
Where
possible,
we
had
an
informal
review,
not
a
formal
one,
which
you
know.
Justin
has
sorry.
Jordan
has
talked
about
it.
So
are
there
people
that
want
to
actually
follow
up
on
this
I.
C
Mean
I
definitely
want
to
I
want
to
do
them.
I
think
they
are
valuable.
I
I
as
far
as
I
understand
the
action
item
from
our
site
is
to
create
an
issue
and
tag
it
and
it's
not
clear
what
then
happens
in
terms
of
the
API
review,
I'm
very
much
against
the
idea
of
some
backroom
thing
that
happens
on
any
venue
other
than
github
or
docks
of
some
sort.
C
A
I
I
H
C
A
J
There
are
currently
two
different
attempts
to
solve
to
tackle
this
problem.
One
is
the
get
book
has
manual
instructions
that
one
must
read
and
then
go
through
cut
and
paste
code
fix
things
up
manually
and
should
result
in
working
provider
for
one
alpha.
One
I
believe
that
needs
to
be
updated
from
v1l
to
two
there's.
H
Wanted
to
say,
like
so,
the
talk
of
provider
and
the
human
provider
at
your
billion,
mostly
for
me
when
alpha
2
is
actually
going
through
the
scaffolding,
but
your
builder
b2,
so
whoever's
gonna
work
on
that
like
it
would
be
great
to
like
a
document.
The
process
like
a
one
needs
to
be
changed
so
that
we
cannot
that
we
can
first
improve
queue
builder.
If
there's
any
issues,
because
its
beta
and
second
document
apart,
so
that
in
the
gate
purpose
David
mentioned
so
that
others
can
follow
as
well.
B
Jason,
yes,
so
I'll
say
the
first
approach
we
took
with
v1
alpha.
One
was
actually
an
example,
repository
that
that
David
had
said,
and
what
we
found
is,
is
that
it
ended
up
being
quite
error-prone,
because
people
had
to
find
and
replace
things
with
different
cases
and
things
like
that
and
we've
had
less
kind
of
user
related
issues
with
implementation.
Since
we
moved
to
the
get
book
based
approach.
G
K
Yeah
sounds
like
a
long
issue
and
we
can
have
more
meaningful
discussion
there
just
curious
if
this
existed
yeah
and
it
sounds
like
has
it
been
explored
deeply,
at
least
in
the
context
of
feeling
alpha
2.
So
that
sounds
good.
Ok,.
A
H
A
So,
typically,
what
I
do
for
cases
like
where
the
person,
if
it's
a
useful
patch
and
a
person
has
not
been
responsive,
is
to
modify
they're,
basically
sure
pick
their
passion
is
a
branch,
so
they
have
attribution,
but
then
do
the
modification
for
whatever
the
review
comments
are
going
forwards
if
they're
not
responsive
and
it's
useful
comes
good.
Okay.
Next
up
was
the
this
one
seemed
kind
of
trivial,
but
it
also
just
languished
so.
B
J
I,
like
your
question,
okay,
so
briefly,
this
is
non-trivial.
This
is
difficult
because
I've
spent
a
couple
hours
on
it,
but
basically
we're
doing
yakoo
builder
annotation
cogeneration.
We
have
cogeneration
and
then
we
have
yet
book.
Cogeneration
I
can
only
get
two
of
the
three
to
work
at
any
given
time,
but
I
haven't
done
an
exhaustive
search.
I
think.
The
next
step
is
actually
to
open
an
issue
against
the
cogent
utility
and
fix
that,
since
it's
under
our
control
as
a
community
I
can
take
an
action.
C
J
And
there's
a
number
of
different
doxygen
markers
since
the
oxygen
is
theoretically
language,
agnostic,
there's
a
number
of
different
ways.
You
can
embed
the
marker
in
a
comment
when
you
embed
it
using
a
C++
style
markers
just
triple
dash.
That
is
interpreting
correctly
by
go
doc
when
you
use
an
alternative
mechanism,
I
think
that
causes
problems
for
COO
builder,
okay,.
A
If
you
can
update
that
come
out
there
and
log
an
issue
against
this,
perhaps
we
can
split
out
portions
of
modifications.
It
seems
like
some
of
this
could
be
split
into
changes
that
could
work
I,
don't
see
why
they
shouldn't,
but
some
of
them
I,
don't
know,
I
mean
I
kind
of
agree
with
Justin
I
think
there's
pieces
here
that
I
don't
see
how
they
could
not
work
and
there
are
pieces
that
I
think
you
know
are
the
Troublesome
ones.
You're.
A
G
Yeah
I
opened
this
because
I
was
trying
to
to
really
change
and
then
I
found
these
issues.
It's
mostly
to
keep
track
of
the
problems,
so
probably
can
keep
that
out
the
problem
to
solve
them,
because
here
the
probably
have
is
that,
with
the
alpha
one
version,
the
compilation
break.
So
we
need
to
use
the
other
two,
because
the
the
way
we
use
it
is
different.
So
I
don't
know.
What's
the
order
to
dress
this,
you
know
what
I
mean
I
think.
A
A
B
E
E
E
A
The
only
other
one
that
I
wanted
to
call
comments
to
you
is
that
I
opened
up
this
issue
last
week,
I
mentioned
it
too
as
well.
If
you
have
thoughts
with
regards
to
an
operator
for
managing
cross
cluster
or
cross
providers,
please
add
details
they're
currently
trying
to
draft
up
the
document
for
broader
review.
A
A
Not
really,
oh,
that's
right,
yeah
I
kind
of
feel
like
this
is
the
repo
and
the
issues
are
open,
like
the
typical
modus
operandi
for
cluster
lifecycle,
things
is
that
we
do
everything
in
issues
log
everything
in
issues
make
that
be
the
canonical
source
of
truth,
because
sometimes,
when
you
open
up
to
the
mailing
lists,
you
get
the
drive
bye-bye
or
death
by
a
thousand
cuts
by
drive-bys.
So
I
think
if
you
care
about
the
repository
you're,
looking
at
you're,
watching
it
and
you're
part
of
this
meeting
so.