►
From YouTube: Syneto 2
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).
B
A
Yeah
we're
getting
to
the
meat
right.
How
many
of
you
are
developers
here?
I
guess
a
lot
of
us
not
too
many.
So
I'm
gonna
talk
about
continuously
delivering
a
zfs
based
os,
especially
storage
device.
Let's
choose
the
next
one.
This
one.
A
Skip
that
yeah,
so
what
we
do
a
few
years
ago,
when
we
started
doing
the
storage
os
project,
there
were
a
lot
of
techniques
in
developing
software.
A
lot
of
people
were
using
waterfall
methodologies
like
clear,
strict
specifications,
and
we
did
that
with
the
last
project
and
we
decided
it's
not
the
way
to
build
software
anymore,
so
we
decided
to
to
change
the
way
we
we
build
our
products
and
the
change
we
the
the
way
we
deploy
the
software.
B
A
We
started
doing
agile
five
years
ago
when
we
started
the
project
and
using
techniques
like
xp
programming,
mostly
all
the
features
that
come
out
in
storage
os
for
the
management
part
for
everything
else
are
done
in
pair
programming.
Usually
two
developers
work
at
the
same
time
to
to
to
do
a
feature.
So
you
have
four
pairs
of
eyes.
Then
we
use
a
lot
of
regression
testing.
We
use
a
lot
of
unit
testing
we'll
see
that
later
and
we
try
to
implement
a
build
system.
That's
fully
automated
each
time
a
change
gets
in.
A
A
So,
storage
os,
as
as
a
source
repository,
is
built
out
of
five
other
repositories
which
we
keep
separate,
so
they
can
evolve
independently.
It's
something
that
I
mean
even
sun.
The
way
they
did
it
they
have.
Actually
here,
where
are
the
three
dots
that
say?
It's
pick
up
a
g
gate
so
because
we're
using
ips
for
packaging,
so
we
have
all
the
repositories
separated
the
uni
store
is
the.
A
It's
really
similar
to
the
illumos
gate
upstream,
but
has
some
changes
that
we
with
it
and
everything
stays
within
a
single
storage,
os
repository,
which
is
in
our
on
our
main
storage
on
top
of
the
zfs
file
system.
So
we
have
snapshots
on
this
one
also
and
all
the
changes
that
happen
in
this
main
repository
either
they
they
happen
on
each
of
the
of
the
small
repositories.
A
Then
a
build
is
triggered
and
a
test
and
publish
phase
is,
is
done
so
I'm
gonna,
I'm
gonna,
show
you
what
we
use
for
the
test
and
publish
phase,
so
we
use
we
actually
use
a
branching
model.
Each
of
the
repositories
we
have
even
illumos
is
on
three
branches.
We
have
a
dev
branch
where
people,
when
they
do
some
experimental
stuff
or
we're
developing
something
new.
They
always
push
on
the
dev
branch
and
the
branching
model
is,
is
on
all
three
reposit
on
all
five
repositories.
A
We
find
that
kind
of
development
to
use
the
branching
models
really
suits
us
very
well.
So
we
can
deploy.
A
You
know
a
quick
hotfix
on
a
branch
or
whatever
it
just
suits
us
really
well,
and
so,
when
one
change
happens
on
one
branch,
then
we
use
a
team
city
server,
which
is
mainly
the
same
as
jenkins.
I
don't
know
if
people
are
familiar
with
jenkins,
but
yeah
it's
the
same
as
jenkins,
but
I
think
jank
is
is
horrible
as
oh
web
ui,
I
just
I
I
don't
know
it's
just
horrible
to
me.
So
that's
we
decided
to
use
team
cd
which
works
really
well
and
what
happens
when
a
change
comes
to
a
branch.
A
Then
the
packages
are
published
to
you
to
an
ips
repository
yeah.
So
this
is
the
theme
city
server.
This
is
the
web
ui
for
each
for
each
repository
we
have
a
project
so,
for
example,
for
illumos
you
have
the
development
branch,
the
hotfixes
branch.
This
is
the
sinetto
branch.
This
is
actually
the
stable
branch.
We
call
it
sinetto,
but
yeah
and
you
can
actually
manually
run
each
on
each
of
the
builds.
A
The
builds
are
done.
Incrementally
it's
the
normal
illumos
build
procedure.
A
Then
we
have
the
management
for
each.
Each
source.
Repository
has
has
its
own
project
on
teamcity,
and
then
we
have
other
projects
which
are
called
builders,
which
are
the
ones
that
actually
take
everything
and
put
them
into
place,
yep
and
then
ui
and
then.
C
A
A
Okay,
so
the
unit
tests
we
run
against
our
management
application
software.
We
have
1331
tests
with
this,
so
many
assertions
running
in
two
minutes
and
72.75
minutes.
These
tests
are
actually
mocking
and
stubbing
the
whole
subsystem.
So
we
don't
touch
the
file
system.
We
don't
touch
anything.
We
just
run
tests
against
mock
data
and
we
just
test
the
the
business
logic
of
our
application.
Here.
A
These
tests
are
normally
language
agnostic.
We
develop
management
software
in
all
kinds
of
languages.
For
example,
I
would
say
that
we
wrote
unit
tests
even
for
management
parts
that
were
written
in
cornshell.
You
can.
Actually
you
do.
You
actually
have
frameworks
for
unit
testing
in
bash,
which
is
yeah.
It's
fascinating,
though.
A
Here
we
have
php
tests.
We
have
ruby
tests,
we
have
c,
we
have
shell
tests
all
running
and
not
just
testing
the
business
logic.
Simply.
We
really
find
this
really
useful
to
keep
this
only
in
memory.
So.
B
A
A
We
are
now
relying
on
zfs
command,
outputs
to
actually
parse
the
output
of
zfs
commands,
and
we
want
to
make
sure
that
the
output
of
those
commands
remains
consistent
between
two
builds,
because
if
something
changes
this
for
changes,
for
example,
in
z,
pool
status
output,
we're
not
going
to
get
the
full
configuration
like
we
want
to
have
so
here
we
we
run
a
suit
of
tests
that
actually
touch
the
system
and
they
execute
all
the
zfs
commands.
So
we
know,
for
example,
create
a
write
z2.
A
A
Maybe
the
channel
program,
maybe
where
a
lot
of
developers
do
writing
in
different
kind
of
languages,
would
benefit
for
interacting
with
zfs
in
a
more
friendly
manner.
I'm
not
sure
yet
how?
But
I
think
this
will
help
the
community,
the
development
community
a
lot
like
a
lot,
because
I
guess
a
lot
of
people
are
doing-
are
actually
doing
this,
so
this
is,
these
are
the
contract
tests.
A
Test
we
use
a
framework
called
roboto
framework
which
you
can
actually
exercise
the
whole
system.
So
let's
say
we
start
the
test
underneath
the
web
ui
and
go
through
the
whole
stacks
to
let's
say
test
the
functionality
of
creating
a
zfs
pool
or
testing
the
functionality
of
sharing
or
whatever
the
user
is
trying
to
do
from
the
management
ui.
A
We
also
at
this
step
run.
Maybe
these
are
familiar
yeah,
we
run
them
too.
We
also
run
the
zfs
yeah,
the
zfs
tests.
We,
we
run
the
zfs
test
suit
on
the
end-to-end
test
phase.
A
A
C
They
checked
the
distribution
so
that
we
had
to
to
customize
that
string
so
that
we
pass
as
open
indiana,
for
example,.
A
What
I
wanted
to
say
that
all
the
contrast,
tests
and
end-to-end
tests
after
the
unit
test
pass,
another
virtual
machine
gets
updated
and
all
the
contract
tests
and
end-to-end
tests
are
run
against
a
virtual
machine
that
has
the
packages
updated.
So
we
run
the
zfs
testing
the
contract
tests
on
an
updated
machine.
A
And
then
we
have
the
unit
tests
the
unit
tests.
We
we
run
the
unit
tests
to
check
for
javascript
errors
like
something
that's
not
really
well
aligned.
The
page
is
not
rendered
on
the
management.
Ui
part,
then
something
that
the
developer
really
messed
up
the
css
or
whatever
it's
just
a
visual.
We
just
as
the
visual
part.
We
don't
touch
the
system
in
any
way.
Here
we
stop
everything
and
we
actually
have
a
fake
business
model
where
all
the
data
is
stopped.
So
we
just
check
and
test
the
dui
part.
A
Okay,
after
after
all,
these
steps,
after
all,
the
tests
are
run
and
everything
is
into
place.
We
have
another
project,
which
is
the
release
builder,
that
actually
republishes
all
the
packages
with
our
publisher
with
cineto.net
in
another
ips
repository,
and
the
publish
phase
is
done
to
to
update
the
ips
repo,
where
the
the
clients
can
update
their
their
their
machine
from
this,
the
ips
repo.
A
This
is
also
kept
in
a
zfs
file
system,
because,
to
be
honest,
we
had
moments
when,
let's
say
we
had
a
version
where
a
new
feature
flag
was
introduced,
for
example,
and
we
forgot
to
update
the
group
stage
2,
for
example,
and
having
the
the
upstream
repo
in
a
zfs
file
system
and
having
each
version
each
release
version
tagged
with
a
snapshot.
A
It's
it's
just
so
easy
to
roll
back
like
we,
we
you
can
roll
back
like
in
in
a
second
and
then
you,
you
reduce
the
damages,
you
you
can,
you
might
create
it.
So
this
is.
This
is
really
useful,
so
whoever
is
doing
development.
I
really
suggest
using
zfs
repos,
for
when,
when
you
provide
an
ips
right
before
updating
it's,
it's
really
useful.
Yeah,
that's
it!
A
B
Those
contract
tests
look
really
really
useful
and
I
agree
we
should
figure
out
some
way
to
have
a
more
programmatic
interface
to
zfs
in
general,
but
are
those
available
on
your
github
as
well.
The
contract
test
stuff.
A
No,
the
contracts
tests
are
actually
part
of
the
uni
store
the
management
framework
because
they
actually
use
objects
and
classes
defined
within
the
the
management
framework,
so
they
can
build
the,
for
example.
These
pool
objects
because
we
we
are
like
going
object,
oriented
a
lot
when
developing
this.
So
we
have
this
abstractization
over
this
poles
over
disks
over
all
this
stuff.
So
yeah,
that's
not
public,
but
I
think
I
don't
know
it's.
It
would
be
interesting
to
have
them
like
available
publicly.
So
I
don't
know
yeah
we
can.
We
can
do
that.
D
So
I
think
this
stuff
is
all
really
cool.
We
do
similar
kinds
of
things
at
delfix
in
terms
of
testing
we
use
jenkins.
Dui
does
suck
also
the
back
end,
where
you're
actually
implementing
the
various
jobs.
Also
super
sucks.
Thankfully,
that's
not
my
job
to
implement
them
on
the
reliable,
like
interfaces
for
you
know
getting
information
about
zfs.
D
I
I
agree
with
you
there
we
need.
We
need
to
do
a
little
bit
better.
For
some
stuff
I
mean
the
for
most
of
the
ui
is
actually
should
be
stable.
D
Z
pool
status
is
the
exception
to
that,
but
you
can
get
a
lot
of
that
information
from
zpool
list
which
you
can
do
like
in
a
personal
format,
and
and
all
that
I
believe
so-
that's
probably
a
closer
to
a
supported
interface
than
z,
pool
status
like
you
know,
zebulus
dash
v,
and
it
shows
you,
like
all
the
different
devices.
A
I
can
totally
agree
with
you:
there
are
a
lot
of
zfs
commands,
for
example,
zfs
get
or
list
that
you
can
do
minus
hp
or
whatever.
So
you
can
have
the
output
without
the
headers
and
then
you
can
have
the
output
possible.
That's
all
right!
I
don't.
I
don't
mind
that
too
much,
but
the
zed
pull
status
command.
It's
in
my
opinion,
the
worst
one
for
parsing
the
out.
It's.
D
D
So
yeah
agreed,
we
do
the
same
thing
we
actually
we
do
kind
of
maybe
one
bet
either
one
better
or
one
worse,
depending
on
your
point
of
view,
in
that
we
interface
with
like
libsy
fs
and
actually
get
the
like
this,
the
z,
the
pool
config
envy
list
that
has
all
the
information
that
then
userland
turns
into
that
big
string.
I'm
not
sure
if
that's
actually
better
or
worse,
because
it's
like
even
less
documented
and
hard
to
figure
out
what
what
it
does,
but.
A
A
I
don't
say
I
I
think
the
zfs
commands
are
great
and
they
provide
you
like
they're,
really
really
useful,
but
I
think
that
building
applications
on
top
of
zfs
would
really
benefit,
because
this
is
how
you
spread
the
word
to
people
in
the
tech,
industry
and
people
in
tech.
Industry
developers
are
the
ones
that
they
share.
The
information
like
really
fast
and
I
think.
D
We
should
do
that.
So
are
you
talking
specifically
about
like
apis
that
you
can
call
from
you
know
c
or
some
other
language
as
opposed
to
command.
A
Line
the
thing
is,
I
I've
seen
a
few
people
tried
to
actually
build
modules
for
different
programming
languages.
Let's
say
if
you
use
php
or
ruby
or
whatever
else
you
can
actually
write
your
own
modules
in
c.
What
you
would
have
to
do,
you
would
have
to
include
the
zfs
headers
and
then
you
will
have
to
talk
directly
with
libsrfs.
I
don't
know
what
the
status
of
you
were
saying
a
few
years
ago.
I
don't
remember
exactly
two
years
ago
that
you
are
actually
working
on
having
a
new
api
or-
and
I
don't
know,
what's.
D
The
status
on
we've
done
a
little
bit
of
work
on
lib
cfs
core,
which
is
like
supposed
to
be
a
stable,
simpler
interface.
To
do
zfs
administration
with
you,
know,
programmatically,
but
it
it's
not
complete
by
any
means
we
we
internally,
we
use
a
combination
of
like
lib,
zfs,
core
lib
zfs
and
the
command
line.
You
know,
preferring
the
cfs
core
over
the
other
ones,
but
it
still
needs
a
lot
of
work.
So
we
definitely
would
want
to.
You
know
work
with
you
on
that.
A
Yeah,
I
know
I've
seen
the
leaps
out
of
score,
but
the
thing
is
it's
really
really
targeted.
What
with
what
you
are
guys
doing
so
the
first
things
you
see
in
leaps
rfs
course
are
the
snapshot
management
stuff.
So
yeah,
I'm
like
okay,
but
it
really
needs
to
be
expanded
way.
More
than
that
for
the
leaps
out
of
the
score,
I
mean.