►
From YouTube: Kubernetes Federation WG sync 20180228
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
A
A
D
A
C
B
Okay,
I
guess
I
I
did
not
I
mean
I
was
not
available.
This
Monday
so
I
think
whatever
discussion
happened.
The
outcome
of
the
discussion
Rawls,
probably
what
Winton
tried
to
capture
in
the
doc
he
has
a
plated,
so
today's
discussion,
I
guess,
might
be
focused
around
the
same
or
how
to
take
that
forward.
A
I
realize
most
of
the
comments
on
the
dock,
we're
probably
because
he
had
to
stock
pre-existing
and
at
least
the
idea
is
pre-existing,
and
so
he
kind
of
added
the
workflow
bit
to
it.
But
some
of
the
some
of
the
descriptions
of
objects
and
workflow
didn't
really
make
sense
to
me.
So
I'm
assuming
it
was
just
maybe
a
bit
of
a
mismatch.
B
B
A
A
A
There
would
be
only
like
placement
resources
for
replica
sets
that
refer
to
replica
sets
and
that
name
space
could
somehow
I
could
see
anyway,
schemes
to
enforce
a
one-to-one
mapping,
but
without,
if
there
being
like
a
specific
replica,
set
placement
type
or
just
a
placement
time,
and
it's
just
a
reference,
then
it's
like
well
down
to
mission
controllers.
If
I
wanted
to
try
to
restrict
them,
which
I
guess
is
fine,
but
it
just
seems
kind
of
messy
I'm
starting
to
question
whether
or
not
happen,
resources
is
actually
a
valuable
thing
to
do.
Sorry.
E
E
D
A
So
I'm
kind
of
like
well
I
could
do
it
this
way
or
I
could
do
it
that
way.
Other
one
really
seems
ideal.
I
mean
the
other
challenge
with
I
mean
if
it's
something
very
trivial
to
discover
like
if
I
have
a
placement
resource
with
the
same
name
and
it's
like
okay,
let's
find
a
placement
resource
get
me.
You
know
a
placement
with
this
name
in
this
namespace
does
exist
and
done
yeah.
A
If,
however,
it's
based
on
a
reference
which
is
kind
of
how
I've
been
trying
to
work
through
it,
then
it's
it's
discoverable
like
if
I
have
a
watch
or
a
list.
This
so
I
have
an
informer
on
the
placement
type.
I
could
go.
Oh
look,
there's
you
know
a
reference
for
this
object
and
I'll
store
it
in
a
map
that
is,
like
you
know,
object
reference
to
to
placement
super
easy
to
deal
with.
A
E
A
E
E
E
Jobs,
etc,
right
and
I'm
wondering
to
myself
what
type
of
how
much
do
we
want
to
try
to
optimize
so
that
if
you
have
a
new
resource
that
creates
a
generation
of
pods,
that
is
just
like
the
cat's
pajamas,
like
replica
set
to
electric
boogaloo.
What
kind
of
work
do
we
think
is
appropriate
to
have
to
do
when
you
want
to
add
the
ability
to
distribute
those
resources,
the
the
Federation
mechanism?
That's.
E
F
Say
that
there's
actually
another
potential
Pro
is
that
if
it
is
a
generic
mechanism,
then
a
user
who
wants
to
federates,
ER
DS
doesn't
have
to
do
as
much
work.
So
if
a
user
has
a
lot
of
custom
resource
types
defined
and
the
Federation
mechanisms
are
generic
enough
to
support
working
with
those
without
too
much
work
that
opens
up
potential
for
users
who
are
federating
things
other
than
core
kubernetes
objects.
I
could
certainly
see
being
a
use
case,
especially
if
Federation
is
used
for
more
complicated
kinds
of
application
deployments.
Yeah.
C
A
Forms
it,
though,
sorry
if
I
had
no,
if
I
had
a
federated,
if
I
had
a
placement
resource-
and
it
was
a
specific
rather
than
being
something
there
was
for
everything,
so
I'd
have
a
replica
set
placement.
I
know:
what's
stopping
me
from
having
a
CRT
place,
not
I
mean
the
actual
data
we're
talking
about
is
generic.
It's
all
things.
That's
hard.
A
C
C
And
so
what
is
the
problem
with
a
basic
inheritance
mechanism
where
every
type
has
a
specific
placement
type
and
inside
there
is
a
generic
placement
type
which
has
all
the
standard
stuff
like
which
clusters
you
want
to
go
to,
and
then
each
specific
type
specific
part
adds
to
that.
Whatever
is
specific
to
its
type
like.
If
it's
a
deployment,
you
know
how
it
rolls
out,
maybe
yeah
Dan
if
it
fits
in
there
or
if
it's
a
replica
said
like
how
many
replicas
you
want
in
each
cluster
and
what
the
waiting
is
simpler.
A
Than
that
placement
is,
is
just
a
list
of
clusters,
it's
where
do
I
put
a
resource
but
you're
most
of
what
you're
saying
is
that's
what
we're
talking
about
just
that
it's
it's
really
simple.
How
do
I
is
those
say,
the
list
of
clusters
with
a
given
federated
resource,
generically
or
type-specific,
and
they
both
have
their
pros
and
cons.
Yeah.
E
E
Think
it
might
also
to
keep
in
mind
the
scope
that,
like
there
are
the
types
we
know
that
today
there
are
arbitrary
CR
DS
and
then
there
are
everything
else
like
types
that
we
don't
know
about
and
we
need
to
decide
if
we,
if
supporting
arbitrary
types
beyond
the
CRTs
without
altering
Federation
itself,
is
a
goal.
I
guess:
I,
don't.
C
So
if,
if
adding
a
CR
D
involved
like
adding
the
CR
D
type
name
to
a
list
of
existing
type
names,
and
then
the
generic
placement
thing
knows
that
it
needs
to
look
inside
that
type
as
well,
you
know
watch
those
types
and
inside
you
know
all
the
types
in
its
list.
There
is
always
a
generic
placement
request
requirement
field
and
it
pulls
that
out
and
it
always
looks
the
same
in
all
the
types
and
it
just
does
its
thing.
C
A
C
E
Okay,
I
have
an
idea
about
CRT
I'm,
not
sure.
If
it's
good
light
here
we
go
so
I
we
could
have
for
CRT
support.
We
could.
We
could
think
about
at
least
having
a
CRT
like
mechanism,
that
you
would
say,
here's
a
custom,
federated
resource
definite
and
it
would
generate
for
you
the
generate
for
you.
The
set
of
resources
for
that
particular
CRT,
so
just
for
content
packs.
What
what
happens
when
you
create
a
custom
resource
definition
is
that
the
basically
you
have
new,
a
new
resource
generated
for
you
by
kubernetes.
E
Agree
with
you
and
I
I
want
to
just
finish
my
thought
quickly.
So
you
you
add
a
CRD
to
kubernetes.
It
gives
you
a
new
resource.
That
is
that's
like
the
implementation
of
that
CRD
to
handle
CR
DS
for
Federation.
You
can
have
a
similar
thing
that
would
generate
the
Federated
CRT.
That
would
generate
the
placement
that
would
generate
the
overrides,
and
then
you
don't
have.
E
The
problem
of
you've
got
one
bucket
for
bird,
like
a
generic
CRD
placement
that
you
can't
do
the
name
alignment
on
so
that
if
you
want
to
support
CRTs
like
in
Federation,
you
can
make
like
the
whatever
this
resource.
Is
it's
like
federated
CRT
for
frob
you
later
and
it
creates
those
resources
for
you
so
that
you
get
one
bucket
percy
rd
e
of'.
C
C
A
Context
so
my
conception
of
of
implementing
sort
of
the
base
primitives
for
propagation
is
that
I
want
absolute
minimum.
I,
don't
want
any
special
I,
don't
want
selectors
I,
don't
want
anything
that
could
be
there
kind
of
worry
order.
I
just
want
to
want
a
list
of
on
a
template,
a
list
of
clusters
and
the
list
of
overwrites
substitutions
whatever
yeah.
D
A
A
C
A
Reason
I'm
confused
or
was
is
that
if
I
look
at
I
think
page
two
in
the
example,
it
describes
creating
a
placement
decision,
but
it
uses
selectors.
It's
of
the
form
that
I
think
must
be
from
the
BI,
brainstorming,
doc
kind
of
verbatim
and
so
like
it
sounds
like
we're
herbally
on
the
same
page,
but
the
doc
doesn't
quite
match
them.
Let.
C
Me
look
at
the
doc
because
you
might
well
be
right.
I
might
have
screwed
something
up
and
in
which
case,
I
apologize
for
the
confusion,
while
I'm
trying
to
find
that
dark.
I
will
tell
you
what
I
meant
to
say
in
the
doc,
which
is
I.
Think
so.
I
think
it
would
be
good
to
have
a
single
placement
decision,
which
is
basically
a
list
of
clusters
and
be
able
to
share
that
across
multiple
resources
in
the
future
and
I
probably
didn't
write
that
explicitly
in
the
doc.
A
You
say
something
they
don't
want
to
push
back
on
that
idea
and
not
that
I.
Don't
think
that
having
a
placement
for
more
than
one
resource
is
useful
because
it
certainly
is
now
I
think
there
needs
to
be
an
authoritative
way
to
say
for
this
resource
I
want
to
set
these
clusters
and
as
soon
as
we
start
setting,
oh,
you
can
have
a
placement
resource
applying
too
many.
A
C
C
So
I
want
to
address
your
specific
question
so
you're.
Looking
at
the
example,
a
federated
deployment,
simple
partially
manual
case-
is
that
what
you're,
referring
to
yeah
item
number
two
in
the
document
yeah,
which
is
a
placement
decision
right,
and
it
basically
has
two
important
fields-
a
resource
selector,
which
says
this
placement
applies
to
everything
with
this
label
and
if
you
don't
want
it
to
apply
to
more
than
one
thing,
what
you
do
is
you
just
like?
Have
your
special
unique
label
on
your
special
resource?
C
And
then
you,
if
you
change
this
thing,
you
know
that
it
won't
affect
anything
else.
If
that's
what
you
want,
I
think
that
a
lot
of
cases
will
not
want
them,
but
but
you
can
totally
do
that
if
you
want
to-
and
the
second
thing
is
a
cluster
selector,
which
is
nothing
other
than
a
list
of
clusters,
which
I
think
is
what
you
want.
I
kind.
A
Of
want
it
to
be
simpler,
I
don't
want
I
understand
you
wanted
to
be
simpler,
but
that
precludes
like
a
whole
bunch
of
other
use
cases
and
we
don't
want
to
recruit
any
use
case.
That's
the
whole
point
of
this
is
having
a
very
simple
base
resource
that
everything
else
boils
down
to.
So
this
is
like
your
primitive
it's
machine
code.
You
want
to
do
something
higher
order.
You
can
do
that,
but
this
makes
sure
that
everybody
is
on
the
same
page
when
it
comes
to
driving
propagation.
C
C
A
C
A
A
But
if
you
wanted
to
change
a
placement
decision
for
any
one
of
those,
you
could
do
it
very
like
there's
just
a
very
simple
way
to
do.
It
just
change
the
placement
resource
for
that
specific
resource,
cuz
I'm,
trying
to
make
this
sort
of
trivial
or
a
controller
to
work
with
I,
don't
want
to
have
to
think
about
how
do
I
change
the
resource
selector.
So
it
excludes
this
one
thing:
you
know
I'm
going
to
create
another
resource.
D
C
A
C
I
guess
I,
understand
and
I
support
your
philosophy,
I
guess.
My
concern
is
that
if
we
build
things
that
are
so
specific
that
we
already
know
they
don't
support
future
things.
We
know
we
want
to
do
and
we
have
to
build
more
stuff.
On
top
of
this,
like,
for
example,
at
the
dish,
API
objects
as
soon
as
we
want
to
have
a
placement
decision
applied
to
more
than
one
resource,
for
example,
then
we
you
know,
we've
already
got
this
kind
of
explosion.
We
started
off
with
you
know.
A
I,
don't
necessarily
think
this
should
be
a
separate
resource
like
I
mean
I've
been
kind
of
going
back
and
forth
on
this,
but
I'm
kind
of
the
opinion
that
I
would
like
to
see.
All
federal
resources
covers
the
cluster
names
if
we
want
to
have
something
else
outside
of
that,
that's
fine,
but
this
is
like
this
is
the
base
case.
Don't
have
a
separate
resource
if
you
want
to
have
something
that
influences
that
go
ahead,
so
I.
E
This
conversation
has
a
very
high
velocity.
Let
me
for
the
stink
of
my
own
self-interest
and
hopefully
for
other
folks
that
are
following
along
see
if
I
can
catch
up
with
this,
let's
work
backwards,
Maru
I'm
a
little
confused
what
you
mean
by
not
a
separate
resource.
So
could
you
be
a
little
bit
more
specific
about
where
this
information
would
live?
Is
this
on
the
federated
resource,
correct.
A
D
A
Have
cluster
names
and
my
reasoning
for
this
is
even
if
you
don't
use
it
like
your
federating
resources,
where
is
that
resource
go?
It
goes
into
clusters
which
clusters
here's
your
list
of
cluster
names
it
to
me.
That
seems
like
a
fundamental,
primitive
you
can
you
can
decide
which
clusters
in
any
number
of
ways
using
you
know
any
number
of
ancillary
resources,
but
in
the
end,
it's
like
that's
the
decision
that
you
can.
You
can
make
and.
E
C
I'll,
try
and
summarize
what
my
requirement
is.
My
requirement
is
that
it
should
be
possible
for
a
human
to
specify
the
names
of
the
clusters
they
want
to
put
their
resources
in.
It
should
be
possible
for
them
to
specify
that
they
want
a
group
of
resources
in
the
same
set
of
clusters,
and
they
should
ideally
not
then
have
to
cut
and
paste
that
list
of
clusters
into
all
of
the
resources
that
they
want
to
exist
in
the
same
clusters.
C
They
should
say:
here's
a
set
of
clusters
and
I
want
all
of
these
resources
to
exist
in
that
set
of
clusters,
and
if
I
change
my
mind
and
I
want
all
of
them
to
exist
in
a
different
set
of
clusters,
I
should
be
able
to
update
one
thing
and
not
have
to
go
to
all
of
the
things
that
I
want
to
be
in
those
clusters
and
update
them
all.
So
that's
one
set
of
requirements.
C
C
So
the
same
piece
of
code
selects
the
clusters,
does
the
template,
substitution
and
does
the
propagation
or
whether
it's
three
separate
controllers
and
I,
can
mix
and
match
the
ones
that
I
like
that?
That
seems
useful
I
mean
I,
think
that
has
been
the
main
motivation
behind
your
naruse
attempt
to
like
pull
these
things
apart.
E
E
E
E
The
idea
would
be
that
whatever
resources
describe
the
requirements
Clinton
that
you've
just
said
that,
like
you,
want
to
be
able
to
specify
one
place
where
multiple
resources
are
multiple,
where,
where
you
update
the
placement
preferences-
and
you
don't
have
to
like
cascade
those
down
to
individual
resources,
I
view
that
as
something
that
you
would
you
would
build
and
that
it
would
reprogram
the
the
the
primitive
list.
It's
that
accurate,
both
of
you
I,
think.
A
I've
been
I've
been
maybe
thinking
about
the
difference
between
like
placement
and
group
placements
and
I'm
kind
of
just
focused
on
the
placement.
How
does
an
individual,
which
clusters
does
an
individual
resource
go
into
and
Quinten?
If
I'm
hearing
you
correctly
you're
very
much
interested
in
group
placement?
How
does
this
group
of
resources
potentially
own
census?
It's
not.
A
C
I'm
just
trying
to
think
so
so
I
don't
have
a
major
problem
with
pushing
it
back
in
I
mean
I'd
like
us
to
stop
kind
of
oscillating
backwards
and
forwards.
But
if
you
want
to
put
it
back
in
the
base
resource,
I,
don't
have
a
major
objection.
I
guess
I'll
just
observe
that
that
prevents
us
from
being
able
to
share
it
across
multiple
resources.
But
we
can,
you
know,
write
software
to
like
copy
it
from
one
resource
to
many
or
approach
it.
Some
other
way,
I
think.
E
Quinton
I
have
a
question
about
I
feel
like
there's
something
important
to
you
that
I'm
not
grasping
and
I
wonder
if
I
may
be
missing
something.
No
so
is
it.
Is
it
a
goal
that
there
should
be
whatever
the
formulation
you
choose
of
how
you
expressed
placement
like?
Is
it?
Is
it
a
goal
for
you
that
there's
one,
and
only
one
expression
of
placement
like
is
the
idea
of
a
primitive
that
other
things
program
like
is
that
is
that
an
anti
goal
for
you?
No,
no
I,
think.
C
I
believe
that
we
have
consensus
that
there
should
be
multiple
ways
of
specifying
way.
One
thing:
one
and
I've
split
it
into
two
classes.
The
one
class
is
where
you
don't
give
the
explicit
cluster
names
you
give
some
set
of
preferences
and
the
system
uses
those
preferences
to
pick
a
specific
set
of
cluster
names
at
a
given
point
in
time,
and
it
can
actually
change
those
names
over
time
because
it
knows
what
you
want,
and
it
knows
what
the
possibilities
are.
C
So
it
could,
you
know,
move
things
around
or
make
different
choices
at
different
times,
and
then
there
is
another
thing
which
I
think
is
Marie's
main
goal,
which
is
a
user
just
wants
to
give
me,
give
the
system
a
specific
set
of
clusters
with
names,
and
the
system
has
just
put
stuff
in
those
clusters
and
if
it
can't,
then
the
user
must
sorted
out
because
the
user
gave
them.
No
information
gave
the
system
no
information
other
than
the
specific
names
of
the
clusters
at
once.
C
Things
in
and
I
think
that's
a
very
reasonable
goal,
and
currently
in
the
diagram
that
I
have.
Can
everyone
see
the
thing
that
I'm
projecting
yes
at
the
near
the
top
left
of
the
diagram
is
a
thing
called
cluster
placement
preferences
which
are
intended
to
be
preferences
so
Europe,
you
know
PCI
compliant
whatever,
and
then
there
are
to
the
right
of
that.
There
are
things
called
cluster
placement
decisions,
which
is
somebody
decided
that
these
are
the
clusters
we're
going
into
and
those
are
captured
in
there
and
I
think
so.
C
The
the
explicit
proposal
in
the
document
currently
is
that
a
cluster
placement
decision
has
a
resource
selector
in
it
which
says
this
placement
decision
applies
to
this
set
of
resources
and
I.
Think
Meru
doesn't
like
that.
He
wants
it
to
refer
to
one
resource
specifically,
and
his
first
proposal
was
that
it
should
therefore
have
a
named
resource
reference
in
it,
so
that
it's
applies
to
specifically
one
resource
and
then
I
think.
The
second
proposal
was
in
fact
that
we
roll
it
back
into
the
base
federated
resource.
C
A
Kind
of
I
mean
no
I,
guess
you're
right,
I
think
that
I'm,
like
I'm,
not
trying
to
preclude
Lycans
they're,
just
behind
a
little
higher
level
like
functionality,
I'm
just
trying
to
have
sort
of
what
I'm
trying
to
do
is
have
base
primitives
that
can
generate
down
to
them
and
to
me
selectors,
don't
really
have
good
qualities
when
it
comes
to
multiple
things,
interacting
because
it's
not
definitive.
It's
like
how
do
I
exclude
something
from
a
selector.
Well,
I
have
to
have
to
really
know
what
I'm
doing
like.
Maybe
a
policy
engine
can
decide.
A
You
know,
I
want
this
selector
for
I
want
these
clusters
based
on
the
selector.
That
makes
sense,
but
if
I
wanted
to
go
and
head
it
like
a
placement
decision
that
was
selector
based
I
could
do
it
as
a
human
for
sure,
I'm,
less
confident
in
arbitrary
mechanisms
to
decide
placement
being
able
to
interact
at
that
level.
There's
nothing
sense.
C
F
C
C
Which
fields
are
we
talking
about
the
ones
in
cluster
placement
decisions
which
are
on
page
four
I?
Think
this
one
over
here?
So
there's
a
thing
here
called
placement
decision?
Oh
sorry,
I'm,
not
highlighting
very
well.
The
thing
here
called
a
placement
decision.
It
currently
has
a
resource
selector
and
a
cluster
selector.
So
what
we
could
do
is
take
this
thing:
smash
it
back
into
the
federated
deployment
API,
for
example,
any
federated
resource
which
would
mean
need
a
resource
selector
anymore.
We
just
need
a
cluster
selector
and
it's
just
the
name
of
clusters.
E
Here
well,
I,
don't
think
there
is
a
mismatch,
so
I
think
the
mismatch.
Is
that
like
quinton,
would
you
scroll
back
to
your
diagram
sure,
and
maybe
it's
not
a
mismatch,
but
maybe
it's
just
my
own
personal
opinion
anyway.
So
I
look
at
this
and
I
see
cluster
placement
preferences
and
I,
see
cluster
placement
decisions
and
I
think
the
Preferences
verse
decisions
distinction
is
very
valuable
I
when
I
am
thinking
about
this
problem
and
trying
to
figure
out
what
I
think
is
the
best
thing
I
view
the.
E
The
placement
decisions
as
something
that
can
generate
like
a
lower
level,
primitive
and
I
think
that
Meru
is
in
by
the
way,
I
think
that
we
should
deep
personalize.
This,
like
like
the
question
here,
is
not
make
one
person
happy
or
not
it's
about
like
what
is
the
right,
API
construction
that
gives
us
the
right
properties.
I
I,
do
think
that
the
idea
that
we're
talking
about
here,
I,
like
is
our
fully
come.
E
The
ideas
that
we're
talking
about
are
fully
compatible
with
one
another
in
the
sense
of
forget
where
it
lives,
but
like
it
doesn't
make
sense
to
me
that
people
want
or
like
some
people
may
want
Quentin
what
you've
articulated.
As
far
as
like
the
cluster
placement
decisions,
and
the
sense
of
they
may
want
for
very
good
reasons
that
specific
API
construction
I
see
no
reason
that
the
there
can't
be
a
controller
behind
that
that
is
turning
those
decisions
into
a
even
lower-level,
primitive
and
I.
E
A
C
Maybe
part
of
the
problem
is
that
you
know
I've
got
the
full
content
of
the
document
in
my
head
and
other
people
may
not
have,
and
that's
I
mean
totally
understandable.
The
document
was
published
like
12
hours
ago
or
whatever
it
was
I,
do
not
expect
everyone
to
have
time
to
read
it.
So
maybe
we
should
just
adjourn
right
now
and
like
come
back
when
everyone's
read
the
document
and
had
a
chance
to
comment
on
it.
Having
read
the
whole
document
and
I
already.
A
Want
that,
but
not
really,
though,
I
mean
I,
want
something
that
makes
sense
at
the
lowest
level.
I
understand
on
top
that's
fine,
but
like
I,
don't
even
want
to
consider
that
complexity
at
this
point,
because
it's
totally
time,
but
you
do
need
to
understand
it
in
the
context
of
other
people
wanting
to
do
things,
and
so,
but
this
doesn't
preclude
that's
the
whole
point.
If
you
want
to
tell
me.
E
E
C
But
it
seems
like
we
might
talk
past
each
other
until
we've
all
read
the
document
and
feel
free
to
comment
on
it
and
all
of
that
stuff,
and
then
maybe
we
hopefully,
we
can
have
a
productive
discussion
and
if
there
are
specific
things
that
people
don't
like
or
think
there
are
better
ways
of
doing
it.
I
think
it'd
be
great
to
write
those
down
and
say
I
think
this
would
be
a
better
way
for
these
reasons
or
I.
B
B
Apart
from
that,
the
use
case
I
see
is
the
actual
federated
use
case
where
you
people
want
to
active
or
reconcile
no
form
of
additions
and
told
me.
So
these
are
the
two
valid
use
cases
I
have
seen.
If
there
is
any
other
use
case
in
between
then
maybe
we,
it
makes
sense
to
me
to
have
so
many
discussions
around
either
segregating
veal,
the
sauces
or
how
exactly
she
eats
or
should
be,
or
maybe
just
go
ahead
with
having
an
option
of
being
able
to
implement
the
two
major
use
cases
there
are.
E
E
Fun,
I'm
not
sure
if
I
can
directly
respond
to
your
your
your
question,
I'm
I'm
a
bit
distracted
because
I
feel
like
we
are
really
talking
about
two
different
things
that,
like
the
the
contention
in
this
conversation,
has
been
around
like
we're
talking
about
different
conceptual
levels,
I
think
it's
probably
appropriate
to
just
end
the
meeting
here,
and
maybe
we
can
decide
later
in
the
week
if
we
want
to
come
back
on
Monday
but
I
I'm.
Not
we
are
over
time
now
and
I
think
we're
probably
talked
out
for
today.