►
From YouTube: Kubernetes SIG Scheduling Weekly Meeting for 20211118
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
B
All
right
I'll
do
that
back
to
you
thanks
yeah,
I
I
have
two
main
like
you
know,
topics
so
feel
free.
If
you
didn't
get
a
chance
to
add
your
topic
to
the
agenda
to,
let
me
know
if,
if
there
are
other
things
that
you
want
to
talk
about,
so
the
first
one
is
really
quick.
So
I
want
to
thank
like
mike
for,
like
really
persisting
through
that
change
of
making
multiple
plugin
config.
B
B
All
the
potential
you
know
issues
that
could
arise
from
having
this
new
multi-point
extension
point.
I'm
gonna
give
it
to
mike.
If,
if
you
would
like
to
have
like
you
know,
like
a
minute
summary
of
what
we've
done,
I
think,
because
this
is
one
of
the
major
things
we've
done
in
the
com
and
the
component
config
api.
So
I
think
it's
worth
talking
about
it.
Now.
That's
measured.
C
Yeah,
absolutely
so
this
multi-point
plug-in
config
was,
I
think
you
actually
proposed
it
originally,
and
the
general
idea
is
that
you
know
right
now,
our
component
config,
to
configure
individual
plug-ins.
You
have
to
enable
them
for
each
individual
extension
point.
So
if
you
have
a
plug-in
that,
for
example,
does
filter
and
score
and
you
want
to
enable
the
whole
plug-in
you
have
to
go
through
in
your
component
config
and
actually
enable
it
for
filter
and
score,
and
that's
the
same
for
pre-filter
pre-score,
all
those
so
for
most
cluster
users,
administrators.
C
Those
extension
points
are
really
irrelevant.
They
either
just
want
the
plugin
enabled
or
they
don't.
You
know
these
extension
points
themselves
are
kind
of
more
relevant
to
developers
and
those
kind
of
users.
C
The
idea
of
you
can
enable
a
plug-in
through
this
new
setting
this
new
field,
and
it
will
automatically
be
registered
for
all
of
the
individual
extension
points
that
it
implements,
and
so
within
that
you
can
still
go
and
disable
it
for
specific
extension
points.
If
you
want
so
you
have
that
kind
of
flexibility
and
that
just
sort
of
fits
in
with
the
existing
behavior
for
these
configs
so
yeah.
This
is
just
really
going
to
simplify
the
ability
to
enable
and
disable
plug-ins.
C
You
know
without
having
to
have
a
big,
complicated
configuration
and
make
sure
that
you
have
enabled
in
all
different
extension
points
that
you
need.
So
we
got
the
changes
merged.
We
are
still
working
on
the
docs
changes
which
are
going
to
try
to
cover
a
lot
more
edge
cases.
C
You
know
and
a
lot
of
the
different
combinations
that
you
can
have
with
this
because,
like
like
abdul,
was
mentioning
there's,
you
know
a
lot
of
different
combinations
that
you
can
have
with
multi-point
and
individual
extension
points
and
different
kind
of
settings
like
that.
So
I'll
add
the
link
to
the
docs
pr
into
the
agenda
here
but
yeah.
If
anyone
has
any
feedback
for
that
feel
free
to
share
it
and
add
your
comments
to
the
doc's
beer,
I'm
just
adding
it
to
the
agenda
right
now,
but
yeah.
C
So
this
was
really
great.
We
went
through
a
lot
of
review.
We
had
a
lot
of
you
know:
everyone
was
paying
really
close
attention
to
the
different
corner
cases
and
the
ways
that
this
could
affect
current
configs
and
our
goal
is
to
really
make
this
as
transparent
of
a
of
a
shift
as
possible
so
that
it
doesn't
affect
running
configs
that
people
have
right
now,
if
they're
using
the
individual
extension
points,
but
the
transition
to
multi-point
should
be
pretty
seamless.
So
that's
it
in
a
nutshell.
C
This
is
you
know,
yeah,
like
you
saying
one
of
the
bigger
changes
that
we've
made
to
component
config
in
a
while.
So
it's
great
to
see
it,
and
I
think
that
this
is
probably
one
of
the
last
big
changes
that
we'll
make
before
graduating
it
to
ga
so
good
job
everyone
and
thank
you
to
everyone
that
helped
review
it
and
help
provide
feedback
on
it.
It's
definitely
a
pretty
cool
feature
that
we've
added.
B
Thanks
mike
thanks
mike
yeah,
please
feel
free
to
comment
on
the
docs
vr
again,
like
it's
really
important
to
make
sure
that
everybody
understands
how
this
new
configuration
mode
works
and
so
and
the
best
way
to
do
that
is
to
make
the
dots
as
clear
as
possible.
So
yeah,
please
take
a
look
at
it.
The
other
end
of
the
item
that
I
want
to
quickly
go
through
is
like
we
have.
B
I
can
I
I
know
four
main
features
that
we
might
have
kept
for
them
in
the
next
cycle.
I
just
want
to
bring
the
community's
attention
to
them.
If
you
have
strong
opinions
in
one
way
or
another,
please
comment
on
those
potential
new
features.
I
don't
think
I
think
we
only
have
one
cap
raised
for
one
of
these
features,
but
still
we
are
it's
a
very
in
the
very
early
stage.
If
you
have
strong
opinions.
B
B
The
first
one
is
I'm
taking
taints
intolerations
into
consideration
when
calculating
the
quality
spread,
and
this
is
mostly
needed,
because
when
you,
when
you
cordon
a
node
and
trying
to
basically
upgrade
a
group
of
nodes,
you
cordon
it-
you
basically
taint
it
with
unscalable
paint,
and
this
node
is
supposed
to
be
like
you
know,
go
away
and-
and
you
know
in
a
matter
of
in
a
short
time-
and
so
so
the
pods
that
are
running
on
it.
B
They're
gonna
get
killed
eventually,
and
so
we
shouldn't
really
be
taking
those
pods
into
account
when
calculating
skew.
So
that's
the
main
use
case
for
taking
things
into
relation
to
account.
We
currently
already
take
no
dfinity,
so
the
proposal
here
is
to
add
things
and
operations.
So
the
second
one.
D
Yeah
one
second
yeah
abdullah,
so
some
some
additional
comments
so
basically
right
now,
the
consensus
is
that
at
least
that
we
should
consider
the
unscheduled
unit,
but
another
option:
I'm
thinking
about
is
that
make
it
configurable
so
that
user
can
define
what
kind
of
tents
they
want
to
exclude.
D
D
A
B
I
I
didn't
mean
like
to
get
into
the
details
of,
and
initially
details
of,
design
of
this
one.
I
just
want
to
highlight
that
this
is
something
in
the
pipeline.
There
are
potential
compatibility
issues
related
to
it,
and
it's
really
important
to
have
the
community
comment
make
sure
that
we
take
all
the
current
cases
into
account
yeah.
I
just
want
to
go
through
the
others
quickly,
so
that
we
give
the
unicorn
folks
some
time
to
ask
questions.
B
So
we
don't
really
need
to
go
like
open
the
issues
or
or
anything
so
put.
The
party
spread,
do
not
schedule
to
schedule
any
fallback
mode
and-
and
we've
discussed
this
in
the
issue.
The
main
motivation
here
is
to
basically
have
a
way
like
to
yeah
switch
to
switch
modes
like,
for
example,
if
cluster
or
scalar
is
not
able
to
bring
up
a
new
zone
because
zone
is
basically
is
out
of
commission,
and
then
at
this
point
you,
you
really
probably
want
to
fall
back
into
okay.
B
Let
me
schedule
all
the
parts
in
the
same
zone
or
in
two
zones
rather
than
three,
and
so
so
I
think
this
mode
could
solve
that
problem
and
it
would
probably
be
useful
in
general,
it's
it's
prob.
It's
it's
backward
compatible,
it's
an
added
feature.
B
So,
let's
hear
your,
like
you
know,
thoughts
on
this
proposals
were
on
the
issue.
Hopefully
someone
would
pick
it
up
as
well
and
start
a
kit.
I
think.
E
B
Okay,
so
I
guess
the
other
one:
is
it's
actually
right,
so
the
the
next
one,
the
third
one
which
is
tuning
the
number
of
domains,
is
the
one
that
someone
started.
The
cap
for
and
again
it's
in
the
context
of
improving
portability
spread
api,
where
we
would
like
to
have
to
inform
basically
kubernetes
of
how
many
domains
do
we
expect
the
spreading
to
occur.
B
The
reason
we
might
want
to
do
this
is
because,
right
now
the
scheduler
makes
an
assumption
about
the
based
on
existing
nodes.
So,
for
example,
if
you're
trying
to
spread
across
two
zones-
but
currently
you
only
have
a
single
par,
a
single
node
in
one
zone,
there's
no
way
for
the
scheduler
to
know
that
there
would
be
a
second.
B
There
should
be
a
second
zone
with
new
nodes
that
would
come
up
if
like
using
cluster
or
scalar,
for
example,
and
so
it
would
assume
that
the
whole
cluster
only
contains
a
single
domain
which
is
like,
for
example,
zone
a
and
will
basically
schedule
all
the
parts
on
that
same
node
or
horizontally
without
triggering.
B
You
know
an
unscheduled
like
you
know,
without
saying
schedule,
and
so
you
can
trigger
a
basic
cluster
autoscaler
to
bring
up
nodes
in
a
in
a
different
zone,
so
this
is
basically
a
parameter
that
will
allow
customers
to
basically
set
the
minimum
number
of
domains
like.
I
expected
this,
for
example,
deployment
to
be
spread
across
at
least
two
zones
or
three
zones.
B
B
And
last
but
not
least,
there's
the
one-to-one
part
to
note
assignment.
I
think
we
discussed
this
two
meetings
ago,
so
I'm
not
gonna
really
go
into
too
much
detail
into
this
one
but
again
feel
free
to
comment
on
the
on
the
issue.
B
I
think
someone
is
planning
to
submit
a
cap,
but
I
think
I
better
see
anything
here.
B
All
right,
so
we've
got
15
minutes
for
the
unicorn
folks
to
have
to
ask
any
questions.
They
would
like
about
scheduler.
F
And
skill
replies
awesome.
Thank
you.
Thank
you
abdullah.
So
this
is
wayway
from
unicorn
community
and
we've.
We
have
a
few
other
folks,
also
from
unit
community
joined
today,
and
we
have
some
questions
about
schedule
planning.
But
let
me
give
you
some
context.
First,
you
may
or
may
not
know
about
unicorn
project.
So
this
is
our
project
project.
It's
also
a
scheduler
for
kubernetes
and
when
we
start
a
project,
there's
no
really
a
scheduling,
a
framework
available
in
the
kubernetes.
So
we
want
to
provide
a
provide
enough
capability
for
bad
scheduling.
F
So
so
we
start
from
scratch
and
unicorn
standalone
project
and
it's
a
standalone
kubernetes
scheduler
since
then,
but
as
we
see
now
today,
kubernetes
has
the
scheduling,
plug-in
and
start
to
think
about
think
about
the
possibilities
that
if
we
can
contribute
a
unicorn-based
schedule
packing.
So
that's
where
that's
when
we
start
to
when
we
think
about
this
problem,
then
we
start
to
realize
a
bunch
of
issues.
That's
why
we
come
here
and
ask
some
questions.
F
I
will
start
from
my
questions
and
folks
online
can
can
ask
more
and
the
first
first
question
I
have.
Is
we
notice
we?
We
did
some
investigation
and
we
see
there
is
a
kubernetes
scheduler
plugins
repo
on
github.
So
my
first
question
is:
is
this
the
is
this
the
official
repo
to
host
all
the
scheduled
plugins.
D
Yes,
so
no
so
basically,
gradual
plugins
is
a
place
for
incubating
some,
some
some
good
ideas
to
fit
for
some
scheduling
requirements
that
haven't
been
implemented
in
the
default
scheduler.
So,
for
example,
a
lot
of
people
have
the
code
scheduling
requirements.
A
lot
of
people
have
the
like
elastic
capacity,
scheduling
requirements,
so
they
raise
caps
and
submit
their
implications
there,
but
it's
not
necessary
to
we.
Don't
we
don't
enforce
you
to
sort
of
submit
your
implication
there.
D
F
Oh
thanks
that
that's
that
is
helpful
helpful
because
we
we
already
have
a
repo
approach.
So
if
we
we
start
to
work
in
the
repo
and
host
there,
that
is
also
fine
right.
Yeah
yeah
sounds
good.
G
So
so
yeah,
a
quick
follow-up
question
to
that
is
so
you
mentioned
that
plugins
repo
is
for
incubating
some
ideas
that
haven't
been
implemented
in
the
default
scheduler.
Then
what
is
the
process
of
promoting
those
ideas
once
the
community
thinks
that
they
are
mature
and
it's
time
to
incorporate
those
plugins
into
the
default
cancer?
What's
the
timeline
or
the
process
of
promoting
a
plugin.
D
I
think
we
have
an
issue
discussing
the
general
guidance
and
the
criterias
for
for
making
the
out
of
trade
parking
back
to
entry.
So
several
points
that
abdullah
aldo
mike
pointed
out
is
that
first,
one
should
be
very
universally
applicable
to
all
users
and
very
beneficial
to
the
whole
kubernetes
ecosystem,
not
only
to
a
particular
vendor
or
sort
of
thing
right,
the
applicability.
D
The
second
thing
is
shouldn't,
make
the
make
the
implementation
and
the
internal
logic
way
too
complicated,
like
you
have
to
pay
over
overhead
extra
overhead
to
making
this
full
field
right.
So,
basically,
the
rule
is
that
the
users
who
don't
want
to
use
this
kind
of
feature
shouldn't
be
kind
of
penalized.
So
there's
a
second
option.
D
Point
and
third
point-
is
that
some,
I
think
the
third
one
is
that
some
implications
may
come
with
the
crv
if
you're
thinking
about
the
out
of
three
plugins,
so
you
have
to
think
about
whether
the
crd
can
be
merged
into
the
upstream
as
a
core
api
resource.
For
example.
I
recently
the
the
motivation
to
bring
up
this
discussion
is
the
whether
we
should
or
not
to
move
the
pub
group
api
to
the
kubernetes
upstream.
D
Yeah
the
point
third
point:
maybe
the
most
challenging
one,
because
typically
the
kubernetes
doesn't
vendor
a
crd
in.
In
the
I
mean
the
kubernetes
kubernetes
code
base
right,
so
all
its
vendor
is
its
own
core
api
resources.
Instead
of
the
external
crd.
F
So
basically,
we
have
the
scheduled
plugins
repo,
but
this
that's
the
place
for
incubating
ideas,
and
the
purpose
is
actually
when
that
is
mature
enough.
Those
plugins
can
be
able
to
to
merge
back
to
the
entry
scheduler
is
that
is
that
idea.
B
B
So
the
thing
is
like
kubernetes
in
general
has
grown
so
much
right
like
we
want
to
pay
attention
to
the
maintainability
and
production
readiness
of
of
the
of
the
product
right
and
so
at
the
same
time
we
want
to
allow
the
community
to
innovate
and
implement
whatever
features
they
want
and
so
we're
providing
these
hooks.
B
So,
at
the
end
of
the
day,
I
think
it's
going
to
be
a
case-by-case
thing.
We
can't
make
a
general
rule
or
if
you
check
these
boxes,
then
yeah
sure
you're
gonna
get
like
this
plug-in
measured
into
into
kk.
There
are
multiple
dimensions
that
needs
to
be
evaluated
and
there
is
no
set.
You
know
threshold,
if
you,
if
you
cross
it,
then
and
then
the
plug-in
should
be
it
should
be
in
kkk.
B
It
includes
again
like
scalability
of
the
plug-in
how
it
impacts.
You
know
maintainability
how
it
impacts
complexity
of
the
code
itself,
how
it
impacts
you
know
like
general
performance
and
and
and
whatnot.
So
I
feel
that
there
is
no
like
hard
like
answer
here.
It's
going
to
be
case
by
case
we
are
trying
we
are
discussing
in
that
issue.
B
What
like
you
know,
what
is
the
general
criteria
and
framework
that
we
can
use
to
discuss
this,
but
it
doesn't
mean
that
there
would
be
like
you
know,
a
checklist
once
you
do
it,
then
that
once
once
a
plug-in
does
it
then
then
it's
in
it
it's
hard
like
to
just
actually
come
up
with
that,
because
subjective
and
and
and
it's
it's
the
case.
My
case.
D
Yeah
just
think
about
think
of
your
structure,
plugging
as
a
lego
building
block,
and
it
doesn't
matter
where
you
place
this
building
block.
You
can
be
listening,
the
scheduled
plugins
you
can
place
in
your
apache
project
and
the
final
lego
product
is
just
a
building
from
both
the
entry
and
optional
with
out
of
three
yeah
building
blocks
and
then
go
compose
them
as
the
final
schedule.
So
that's
it.
F
F
I
guess
another
question
I
have
is:
what
is
the
best
way
to
let
user
to
use
the
schedule
plugin?
So
we
know.
E
F
Yeah,
please,
could
you
please
yeah?
Could
you
please
give
some
suggestions.
D
Yeah
good
question
good
question,
so
yeah
that
is
also
one,
if
not
the
main
purpose
is
also
by
product
of
the
psychiatric
privacy.
So
in
the
very
beginning
we
discuss
what's
the
motivation
and
what's
the
optimal
goal
of
the
schedule,
plugins,
whether
we
treat
it
as
just
sdks
or
as
a
sort
of
image
product
for
for
the
users
to
just
use
out
of
a
box.
D
You
can
choose
the
disabling
number,
then
you
can
also
choose
to
enable
default,
the
the
plugins
in
the
schedule
plugins,
so
you
treat
them
as
a
sdk
instead
of
all
in
one
product,
but
in
another
way,
so
some
beginners
doesn't
understand
so
deep
on
the
skeleton
framework
as
well
as
unplugging
the
mechanism
they
just
want
to
start
using
this
and
to
try
out
some
basic
ideas
so
so
that
the
schedule
plugin
also
released
the
images
to
compile
all
the
plugins
out
there,
because
with
the
schedule
config,
you
can
disable
enable
any
one
of
them.
D
B
So
there
are
two
aspects
to
this
right
like
there's:
one
is
how
do
you
advertise
it?
The
other
thing
is,
how
do
you
get
users
to
use
it
so
the
first
one
yeah,
maybe
yeah,
the
schedules
plug-in
briefly,
is
the
most
visible
place
for
for
scheduled
plugin,
but
how
to
get
users
to
use
it.
I
mean
if
it
is
actually
solving
a
problem
that
users
are
facing,
then
wooden
I
mean
naturally,
user
starts
to
use
it
and
pick
up
like
you
know
that
plugin.
F
Thanks
yeah
yeah
that
makes
sense,
and
so
today
do
we
have
a
do.
We
have
an
option
to
when
we
when
we
from
provisional
kubernetes
cluster,
we
do
not
enable
default
schedule
but
schedule
packing.
Do
you
have
a
way
to
do
that.
D
D
We
have
installed
things
so
here
we
mentioned
two
options,
so
you
can
just
use
the
hem
chart
to
install
the
the
image
at
the
second
schedule.
So
in
that
case
you
have
to
schedule
running
there.
This
is
not
the
ideal
way.
This
is
not
that
unrecommended
that
can
get
beginners
very
quickly
start
with
the
schedule
plugin.
D
F
F
I
see
so
is
there.
Anybody
in
the
community
are
using
schedule
plugin
as
a
second
scheduler.
C
Yeah
we
have
a
project
to
try
to
productize
secondary
schedulers
to
users
so
that
we
can
in
open
shift
so
that
we
can
ship
our
platform
with
the
default
scheduler.
Without
you
know
having
to
worry
about
users,
you
know
affecting
cluster
stability,
but
they
still
have
a
lot
of
needs
for
secondary
schedulers
like
I
know
that,
there's
a
lot
of
ai
and
ml
use
cases
for
like
co-scheduling.
C
We
have
a
couple
other
teams
that
are
working
on
my
topology,
aware
scheduling,
so
we
do
have
some
customer
use
cases
for
getting
a
secondary
scheduler
in.
So
it's
just
really
looking
for,
like
the
the
like
maturity
of
the
platform
and
the
well,
I
mean
the
platform
is
mature
but
more
like
the
kind
of
adoption
and
a
productized
and
supported
way
to
get
it
to
people.
So
that's
what
we're
doing
here
and
that's
gonna
kind
of
help.
C
This
framework
grow,
because
you
know
a
lot
of
the
questions
that
you
guys
have
are
pretty
common
questions
that
people
are
having
right
now
with
how
to
get
involved
with
the
custom
scheduler
setups.
So
it's
just
trying
to
spread
that
knowledge
around
and
get
more
people
involved
and
more
contributors
we'll
get
some
some
steam
going
for
this
project.
D
Yeah,
I
also
know
some.
The
big
companies,
like
alibaba
apple,
are
using
the
schedule
plugin
extensively
as
well
as
tencent,
and
also
some
startups,
like
litway,
I'm
not
sure
he's
on
the
on
this
meeting,
so
that
went
from
open
ai,
also
using
the
schedule
plugins
extensively
and
the
day.
I
think
in
the
last
year
released
some
blood
very
hard
process,
opening
a
support
model
as.
F
D
B
D
So
for
now
I'm
the
approval
and
I
think
everyone
can
contribute-
it's
not
mandatory
for
me
to
approve
this.
I
I'd
like
to
delegate
other
some
of
my
you
know.
Responsibilities
for
other
people
have
the
expertise
to
understand
the
code
base
and
yeah.
I'm
happy
to
dedicate
my
own
privilege,
yeah.
F
E
A
D
It's,
I
would
say
one
release
behind,
but
not
too
much.
For
example,
the
the
latest
is
rendering
yeah
122.
so
right
now,
123
is
not
released
yet
right.
So
it's
rendering
the
latest
release,
but
it's
only
the
master.
D
F
D
That,
because
making
the
master
for
rendering
the
latest
kubernetes
kubernetes
can
give
some
buffer
to
fix
some
bugs.
If
we
are
not
adapting
to
the
latest
branch.
C
This
is
one
example
of
that
and
it's
got
a
lot
of
custom
plug-ins
in
it,
but
really
a
custom
scheduler
with
the
framework
can
be
written
in
a
couple
lines
of
code
and
you
can
import
all
of
the
plugins
from
this
repo.
If
you
want
so
yeah
yeah,
okay
yeah
this
is
this:
isn't
like
the
only
place
that
custom
plugins
can
go.
This
is
just
probably
the
prime
example
of
setting
it
up.
So
you
keep
that
in
mind
that
the
point
of
the
framework
is
that
anyone
can
make
their
own
scheduler
plugins
repo.
Basically.
F
Okay,
so
yeah
we
we
want
to
have
a
unicorn-based
schedule
plug-in
and
if
we
have
that
someday,
how
can
we?
How
can
we
advertise
and
let
people
know
about
this
schedule
plug-in?
Can
we
add
a
link
here
or
something
if
I
mean
if
we
host
our
code
in
still
in
our
part
report.
D
A
D
Yeah,
because
we
are,
we
are
all
yeah.
Our
goal
is
consistent
to
make
the
scheduling,
plugins
and
scheduling
framework
to
more
adopted
by
a
lot
of
users,
so
they
don't
run
into.
They
don't
need
to
maintain
multiple
schedules
right
that
is
crap,
so
yeah.
I
think
our
goal
is
the
same.
So
yeah
we
can
different
yeah
list
here,
like
plugins.
We
just
mentioned
here
that,
for
example,
this
is
also
a
schedule
plugin,
but
it's
hosted
elsewhere.
So
that's
it.
F
Okay,
that's
all
the
questions
from
me.
I'm
not
sure
if
there's
any
other
question
from
other
unicorn
folks.
E
I
have
one
more
question,
which
is:
would
it
be
possible
in
the
readme
on
the
scheduler
plug-in
repo
to
put
in
a
very
targeted
tested
in
this
version
of
kubernetes?
Just
for
clarity.
D
So
I
want
to,
I
want
to
understand
whether
I
what's
your
question,
so
your
question.
E
D
F
Oh
one
more
question,
so
does
that
mean
one
skip
one
version
of
schedule?
Plugin
can
only
work
with
one
version
of
kubernetes.
D
D
So
so
I
would
say
strictly
was
the
best
if
you
have
the
same
version,
but
it
shouldn't
work
most
of
the
time
with
the
lower
versions.
F
F
Okay
thanks
well,
I
I
really
appreciate
all
the
the
answers
that
really
helped
us
a
lot
and
right
now
we're
in
a
very
early
stage,
and
we
still
think
about
how
we
can
get
it
get
a
schedule
plugging
down
with
based
on
unicorn.
A
D
Having
us
now,
we
can,
and
maybe
the
next
week
is
vacation
week,
and
we
will
see
you
in
two
weeks
yeah.
Thank
you.
Everyone.