►
From YouTube: OpenShift Commons Briefing Deploy Applications Faster via Spinnaker CD - Gopinath Rebala OpsMx
Description
OpenShift Commons Briefing
Deploy Applications Faster on OpenShift via Spinnaker CD
Guest Speaker: Gopinath Rebala OpsMx
A
Well,
hello,
everybody
and
welcome
to
another
openshift
common
gathering,
we're
really
thrilled
to
have
opps
mix
here
again.
They've
done
some
great
work
with
their
spinnaker
operator
and
that's
now
available
in
operator
hub
do
and
on
operator
hub
inside
of
OpenShift.
So
today
we
have
gothis
Rapala
with
us
who's
going
to
talk
about
deploying
applications
faster
to
OpenShift
with
spinnaker,
and
there
can't
be
anything
better
than
deploying
faster,
but
doing
it
with
spinnaker
is
really
interesting
and
I
think
you'll
all
enjoy
this
talk,
so
cup
smith
go
ahead
and
introduce
yourself
take
it
away.
A
B
Right,
thank
you.
Dan,
my
name
is
gopi.
Not
rubella.
I
am
CEO
of
ops.
Annex
we
provide
continuous
delivery
solutions
with
low-risk
deployments.
We
really
go
through
what
that
means.
We
are
based,
reuse,
the
spinnaker
as
a
base
platform
for
the
continuous
delivery.
Now
we
will
talk
a
little
bit
about
what
the
requirements
are
when
you
are
moving
to
open
share
and
what
enterprises
generally
look
for
for
their
continuous
delivery
and
how
the
spinnaker
can
help
you
achieve
those
requirements.
B
So
generally,
what
we
have
seen
is
the
enterprise's
are
at
various
levels
of
maturity
in
adopting
micro
services,
particularly
kubernetes
containers
and
openshift
platforms,
so
when
they
initially
start
moving
from
monolith,
multi-tier
applications
to
micro
services
and
in
containers,
the
thing
that
they
look
for
is
how
do
I
deploy
these
apps
in
openshift
environment
right.
So
there
are
various
tools
that
available
the
ad-hoc
way
of
doing
it.
But
what
are
the
best
practices?
How
do
I
scale
once
I
start
doing
it?
It
is
also.
B
There
is
some
amount
of
friction
for
developers
in
adopting
the
platforms,
particularly
when
you
are
trying
to
do
different
deployment
strategies
and
deploying
to
open
shirt.
Is
there
a
way
we
can
provide
a
common
templates
to
them,
reduce
the
friction
for
the
developers
to
come
on
board
onto
the
OpenShift
environment
and
the
last,
but,
not
least,
is
usually
in
the
delivery
process.
B
You
have
different
stages,
including
buildings,
Jenkins
automated
has
through
selenium
or
some
other
tools
that
you
have
and
then
going
to
the
day
and
promote
the
production
so
in
the
shift
left
DevOps
in
REO.
If
you
really
want
to
achieve
the
velocity
that
you
need,
you
need
to
have
the
visibility
that's
there
for
both
for
the
developers
and
operations
to
see
what's
going
on
and
where
the
problems
are
and
quickly
identify
and
solve
them,
and
once
you
figure
out
how
to
do
this
deployment
get
the
visibility.
B
And
how
do
I
specify
the
policy
enterprise
policy
on
what
are
the
requirements,
for
example,
Sox
compliance
or
compliance
requirements
or
in
the
policies
in
terms
of
what
kind
of
scans
that
you
need
to
run
before
it
can
be
promoted
to
production?
How
do
you
enforce
all
of
these
policies
for
the
users?
Last
but
not
least,
is
you
need
to
have
the
audit
and
reporting
of
the
continuous
delivery
not
just
for
compliance
purposes,
but
also
to
understand
where
the
inefficiencies
are
and
improve
on
the
delivery
process?
B
Once
we
have
that
the
enterprise's
start
looking
into
saying,
does
this
solution
then
have
scale
to
large
number
of
applications
and
users
that
have?
Is
it
going
to
be
seamless
scaling
or
do
I
have
to
do
something
extraordinary
to
get
the
scale
at
any
paid?
Since
enterprises
don't
only
have
open
shift
environment,
they
also
are
moving
from
existing
cloud
environments
or
something
like
on
from
OpenStack.
B
B
Can
I
provide
some
kind
of
our
automated
verification,
not
just
testing
before
going
to
the
production,
but
you
need
to
have
deployment
strategies
that
even
you
go
to
the
production,
can
I
verify
and
make
sure
the
risk
of
this
new
deployment
is
low
and
if
the
risk
is
high,
can
it
rollback
quickly
so
once
the
purpose-built,
continuous
delivery
solution
will
answer
all
these
questions
for
you,
instead
of
using
some
ad
hoc
tools
that
would
allow
you
to
deploy
quickly
but
will
not
allow
you
to
scale
or
maintain.
So
this
is
where
the
spinnaker
comes
in.
B
Spinnaker
is
purpose-built.
Continuous
delivery
tool
that
is
built
for
multi
cloud
environment
provides
a
shift
left
visibility
to
the
developers
droids
the
fully
automated
code
to
deploy
so
the
one
of
the
things
with
the
delivery.
Also,
is
you
want
to
be
able
to
have
the
pipeline
that
you
describe
to
the
delivery
a
a
detox
base
or
it's
a
code,
the
declarative
system?
You
don't
want
that
to
be
a
another
program
that
you
would
write
as
a
script.
A
B
In
the
continuous
multi
cloud
deployments
and
rollbacks,
so
we
will
also
want
to
be
able
to
provide
the
delivery
system.
That's
consistent
across
multi,
multiple
cloud
environments,
that
is,
if
you
are
deploying
to
OpenShift
environment
delivery
strategy,
that
available
to
you,
this
Bluegreen
and
rollback
capabilities
are
rolling.
B
Update
capabilities
should
also
be
available
to
you
in
AWS,
environment
or
OSHA
or
a
DCP,
so
that
gives
a
consistent
view
both
for
the
developers
and
operations
to
allow
the
deployments
for
the
existing
applications
and
new
applications
that
are
transitioning
to
the
micro
services
and
openshift
environment,
and
so
once
the
velocity
is
required.
You
want
to
minimize
the
production
failures.
B
These
production
failures.
Also
you
put
the
manual
verification
of
these
production
failures
at
velocity
is
error-prone
right,
so
you
want
to
be
able
to
say:
can
I
get
the
risk
evaluation
of
what's
deployed
in
production,
to
know
whether
the
deployment
has
risks
in
it?
That
needs
to
be
told,
or
it's
a
low-risk
enough
that
you
can
continue
this.
We
will
also
look
at
one
of
the
examples
on
how
to
do
this
continuous
verification.
B
B
You
can
convert
them
into
a
templates
and
those
templates
can
be
shared
across
organization
for
the
best
practices.
These
pipelines
also
can
be
orchestrated
in
a
very
complex
way
where
you
can
have
parallel
stages
or
serial
stages,
and
also
make
it
very
simple
for
easy
one,
simple
pipelines.
So
essentially
it
makes
it
easy
for
simple
applications
to
onboard.
At
the
same
time,
you
can
scale
the
pipeline
structure
to
a
fairly
complex
one,
which
can
be
converted
to
the
template
and
used
for
a
very
complex
orchestration
and
deployment.
B
The
entire
system
is
API,
driven
and
so
for
onboarding
new
applications
within
an
enterprise
you
don't
have
to
someone
doesn't
have
to
come
to
the
UI
and
create
these
applications.
So
once
you
have
a
structure,
that's
defined,
you
can
have
a
simple
onboarding
of
these
applications
through
automated
scripts
and
all
these
pipelines
are
declarative.
B
You
can
save
them
in
a
JSON
format
that
can
be
stored
in
the
gate,
and
you
can
also
sync
the
changes
to
the
pipeline
that
you
make
in
the
gate,
with
a
new
pipeline
that
gets
updated
in
vinaka
audit
is
also
automatic.
Any
changes
to
the
pipeline
are
all
logged,
all
the
approvals
that
go
through
the
pipeline
in
terms
of
who
initiated
the
pipeline
and
who
approve
the
pipeline
to
go
through
the
production.
All
of
that
is
also
building.
B
Automated
risk
assessment
is
done
through
analyzing,
the
monitoring,
metrics
and
logs
in
the
system,
so
now,
with
the
distributed
applications
with
large
number
of
micro
services,
the
amount
of
logs
that
are
generated
is
huge.
Some
of
these
applications
can
run
anywhere
between
twenty
to
forty
microservices.
So
when
in
the
continuous
delivery
mode,
as
a
new
application,
new
service
gets
deployed
without
change
to
any
other
services.
B
You
want
to
understand
how
that
is
impacting
the
rest
of
the
application,
also,
so
in
the
continuous
verification
you
can
just
plug
in
the
system
to
interact
with
the
logs
that
are
being
generated
for
the
micro
service,
along
with
the
metrics
and
run
the
analysis
to
compare
the
new
deployment
with
the
previous
production
department.
The
this
one
gives
you
a
comprehensive
score,
based
on
both
errors
that
are
generated
in
the
logs,
as
well
as
differences
in
metrics
like
the
latency,
metrics
or
resource
utilization.
Those
pieces
to
identify
the
deployment
is
risky
or
not.
B
B
We
also
support
centralized
policy
enforcement
where
you
can
specify
these
policies
of
the
enterprise.
These
are
also
declarative
policies.
You
could
specify
every
software
that
is
being
deployed
in
production
must
go
through
some
our
cubes
cap.
It's
just
an
example,
though
these
policies
can
be
specified
and
they
will
be
enforced
at
the
Diploma
in
time.
If
we
audit
all
the
continuous
delivery
pipelines
on
who's,
approving
who's,
running
the
pipelines
etc.
Any
of
these
violations
they
get
notified
all
the
built-in
notification
systems,
common
notification
systems,
including
slack
email,
those
kind
of
notifications
you
can
get.
B
So
as
a
complete,
continuous
delivery
system
going
from
a
simple
deployment
to
a
complex,
Enterprise
wide
deployment
with
the
open
shipped,
we
want
to
be
able
to
provide
all
these
features
that
allow
enterprise
to
scale
from
the
initial
adoption
to
complete
enterprise,
wide
continuous
delivery
for
open,
shipped
and
existing
platforms.
To
do
a
quick
demonstration.
B
B
When
you
run
a
pipeline,
essentially
it
has
stages
where
you
can
specify
what
individual
stage
needs
to
do.
In
this
particular
case,
it's
doing
a
deployment
to
openshift
environment,
it's
deploying
a
particular
service
and
a
container
that's
connected
to
that
service.
So,
if
you
look
at
how
this
is
configured,
this
is
a
configuration
you
can
set
up
triggers
based
on
the
repository
changes
or
jenkins
or
github
changes
any
one
of
those
once
the
trigger
it
comes
in.
B
B
One
of
the
advantages
of
using
spinnaker
is
also
for
the
OpenShift
environment.
After
the
dutiful
deployment
is
complete,
it
waits
until
the
manifest
is
stabilized.
That
means
is,
it
doesn't
just
do
manifest
a
fly,
but
it
waits
until
all
the
requirements
have
met
for
the
deployment
to
be
complete.
For
example,
if
you
are
running
five
instances,
it
waits
until
all
the
instances
are
up
and
running.
You
can
also
say
that
the
deployment
is
complete
there.
B
Now
there
is
a
version
two
that
is
deployed
and
for
this
version
two
you
can
see
the
details
of
the
version
two
on
how
many
instances
that
are
running,
which
are
the
replica
sets
which
load-balanced
it
is
connected
to,
and
you
can
also
see
what
is
the
status
of
each
one
of
the
instances
by
looking
at
the
logs
that
are
generated
right
in
the
same
place
and
in
the
group
of
this
application.
All
the
services
for
these
applications
are
also
displayed
for
the
deployment
you
can
take
the
deployment
actions
right
in
here.
B
You
can
scale
the
number
of
instances
or
you
can
do
a
undo
of
this
rollout
to
any
of
these
previous
versions.
So
it
allows
you
to
have
the
visibility,
as
well
as
the
application
management
capability
in
place
in
one
location,
you
have
the
view
of
all
the
services
that
are
available
for
that
application
and
manage
those
applications.
There
is
all
back
that
you
can
specify
who
can
make
the
changes.
Example,
the
other
one
is
the
Bluegreen
deployment.
B
So
right
now
it
is
deploying
a
newer
version
which
is
a
1.2
version
of
the
service.
We
will
see
how
simple
it
is
for
us
to
go
ahead
and
switch
the
blue-green
deployment
here,
I
put
in
a
manual
judgment.
Usually,
you
would
have
a
continued
mated
verification
stage
that
will
allow
you
to
check
if
the
new
deployment
is
working
properly
and
once
it
is,
you
would
go
ahead
and
apply
the
changes
that
are
required
for
the
blue
green.
So
you
can
also
have
this
one
deploying
a
canary
deployment
be
good
infrastructure.
B
B
B
So,
as
I
was
mentioning,
you
can
build
complex
pipelines
orchestration
with
this
one.
In
this
particular
case,
we
are
doing
a
build
with
the
Jenkins
and
once
the
Jenkins
build
is
done,
we
are
taking
that
artifact,
that's
produced
by
the
Jenkins,
build
and
deploying
it
into
the
open,
shipped
environment
and
then
running
an
automated
analysis
on
that
deployment
to
verify
if
the
deployment
is
functioning
properly,
as
well
as
in
both
in
terms
of
functional
and
the
performance,
and
then
once
that
is
successful,
we
will
promote
it
to
the
production.
So.
B
As
you
can
see,
this
is
a
deployment
that
ran
you
can
you'll
also
get
all
the
details
of
the
deployment
individual
stages
in
place.
You
can
see
the
Jenkins
logs.
You
can
actually
go
to
the
Jenkins
from
here
right
here
and
look
at
the
Jenkins
logs
in
each
of
the
deployments
and
tests
that
is
run.
You
can
get
the
details
of
each
one
of
the
stages
in
the
automated
cannery
also
provides
you
the
score
in
an
integrated
way
and
also
provides
you
a
link
that
allows
you
to
see
what
the
details
of
the
analysis
are.
B
B
Let's
go
to
a
better
example.
Here
you
get
it
comprehensive
score
and
confidence
of
that
score.
There
are
two
things
that
are
going
on
here.
One
is
the
analysis
of
the
logs
here
you
can
see
when
we
compare
the
logs.
It
gives
you
the
new
errors
or
exceptions
that
are
happening.
It's
important
to
see
that
some
new
errors,
because
if
there
are
warnings
that
exist
in
the
current
system
and
the
new
version
of
deployed,
also
has
the
same
kind
of
warnings
or
errors,
then
it
does
not
surface
them.
B
So
you'll
only
see
the
ones
that
are
new,
both
in
terms
of
errors
or
warnings
and
analyze
them
to
identify
the
risk
of
that
deployment.
You
can
also
train
the
system.
This
is
generally
unsupervised
analysis
with
the
natural
language
processing,
but
you
could
also
train
it
to
say,
for
example,
you
made
a
fix
to
the
system
so
that
the
warnings
or
errors
that
you
were
seeing
earlier
are
not
there
anymore.
So
if
those
errors
occur,
you
want
to
surface
them.
B
So
then
you
would
go
and
specify
that
that
particular
item
needs
to
be
surfaced
in
a
new
version.
So
at
this
point,
when
we
do
the
comparison
between
the
old
and
new,
the
errors
will
show
up
in
the
new
system,
even
though
they
existed
in
the
previous
one.
If
they
come
back
again,
you
can
also
identify
some
of
these
line
items
and
say
this
is
not
an
error
that
I
don't
want
to
surface
them.
B
It
learns
that,
based
on
the
feedback
that
you
give
and
then
from
the
next
analysis
onwards,
it
will
ignore
those
and
as
for
the
metrics,
it
will
collect
all
the
metrics
from
the
monitoring
system
for
that
particular
service
and
compare
the
previous
version
with
the
current
version.
In
this
particular
case,
the
latency
is
much
higher
and
based
on
the
latency,
the
changes
identified
that
that
risk
is
higher
in
this
new
deployment
and
fails
the
deployment.
So
the
template
includes
not
just
the
service
metrics,
but
also
system
metrics.
B
B
Essentially,
it
allows
you
to
do
a
simple
deployments
with
application,
onboarding
and
scale
that
to
very
complex
orchestration,
with
the
compliance
and
audit
requirements
and
automated
verification
as
your
organization
grows.
So
here
was
one
of
the
case
study
that
we
have
done
with
fortune
50
company
that
is
transitioning
to
open
shift
environment.
B
B
So
the
the
and
in
the
entire
thing
is
specified
the
central
control
and
compliance
and
audit.
All
the
pipelines
that
are
currently
run
are
compliant
pipelines
that
allow
for
the
enterprise
y
controlled
on
what
stages
that
need
they
need
to
go
through
before
they
go
to
production.
They
are
Sox
compliant.
They
support
this.
Automated
verification
of
the
production
deployments
and
the
plan
is
to
not
just
support
open
shift
environment.
They
are
also
moving
the
using
spinnaker
to
support
OpenShift
and
AWS
and
some
other
environments
they
have
internally.
A
spinnaker
is
very
easy
to
deploy.
B
If
you
have
open
shift
environment
on
premises,
you
can
go
to
operate
a
hub
and
simply
run
the
application
deployment.
If
you
don't
know
what
an
operated
hop
is
it's
a
App
Store
for
the
applications
that
run
on
openshift,
the
kubernetes
is
also
a
supported
platform,
so
you
can
simply
go
to
operate
and
help
that
io
operator
and
spinnaker
operator
and
install
your
application.
B
A
That
was
actually
great
and
thanks
for
the
plug,
and
thanks
for
all
the
work
you
did
to
get
spinnaker
operator
into
operator
hub,
do
it
also
has
a
whole
whole.
Could
good
crew
of
other
operators
as
well,
but
there's
yeah
there
that's
a
great
way
to
show
it.
So
it's
an
easy
way,
whether
you're
running
on
open
shift
or
any
other
kubernetes
to
just
download
and
install
spinnaker
and
and
get
running
getting
up
and
running
really
quickly.
A
A
C
I
think
primarily,
is
the
spinnaker
focuses
on
the
deployment
of
the
artifacts.
You
know
into
various
environments,
with
basically
a
very
no
script,
less
way
of
deployment
of
applications
and
all
the
supported
platforms.
Obviously
openshift
is
something
this
audience
cares
about,
but
the
many
enterprises
actually
have
quite
a
bit
of
quite
a
variety
of
in
Romans
that
they
wanna
support.
So
that
is
where
the
spinnaker
really
shines,
because,
as
the
operators
want
to
deploy
into
various
bonds
of
scripts
different
depending
of
common
strategies,.
A
B
One
thing
I
would
like
to
add
to
that
is
from
our
customers:
they
can.
They
usually
start
with
Jenkins
for
deployment
to
OpenShift
using
a
manifest
files
and,
as
the
grew
larger,
they
start
doing.
Scripting,
which
gets
complex
at
some
point.
It
becomes
unmanageable
and
one
of
the
advantages
of
spinnaker
is
that
you
have
all
the
stages
that
are
declarative.
B
You
don't
actually
have
to
do
a
bunch
of
scripting
for
most
of
the
common
deployment
environments
and
there
is
a
built-in
deployment
strategies,
like
blue
green,
that
apply
not
just
to
open
shift
or
cannery
deployments,
not
just
to
open,
share
kubernetes,
but
also
to
AWS
GCP
energy
environments,
and
they
also
get
consistent
view
of
shift
left
view
for
these
pipelines.
So
you
can
have
the
artifact
specified
on
these
pipelines
where
the
developers
can
trigger
it,
but
the
there
needs
to
be
a
privilege
escalation
that
needs
to
happen
to
go
to
production.
B
At
the
same
time,
developers
do
get
the
visibility
of
the
pipeline
all
the
way
to
the
production.
They
can
see
what
is
deployed
to
production,
and
if
the
production
system
is
working
well
or
not,
and
through
automated
verification
or
the
manual
verification,
they
can
see
what
the
status
is.
So
the
shift
like
feedback
from
operations
to
developers,
essentially
the
core
DevOps,
really
shines
in
terms
of
spinnaker
and
makes
the
maintenance
of
the
system
as
you
grow,
with
large
number
of
applications.
Much
more
easy.
It's.
C
A
dynamic,
I
think:
ok,
we
covered
that
I
think
a
key
part
I
think
what
I
want.
One
of
only
one
comment,
I
would
add:
is
that
vinegar?
You
know
you
deploy.
You
look
at
the
logs
to
see
what
happened,
but
in
spinnaker
you
can
clearly
see
the
different
stages
where
it
failed,
and
you
also
saw
the
automatic
verification,
Peas
and
reporting
on
that,
and
the
developers
can
do
a
record
thicker
rollback.
All
of
them.
You
don't
have
to
write
scripts
for
it,
because
pinnacle
really
takes
care
of
creating
custer's.
C
You
know
resizing
clusters,
changing
load,
balancers,
so
think
of
it
all
the
CD
functions
right
so
said:
kids
instill
you
needed
actually
for
the
build
stage
or
the
CI
Porsche
portion.
Spinnaker
does
not
replace
the
Jenkins
for
those
aspects.
So
I
think
it's
a
complementary
solution,
but
more
people
are
looking
at
spinnaker
as
an
end-to-end
solution
for
CI
CD.
It.
A
C
Yeah,
the
the
audit
and
compliance
portion,
the
audit
portion,
the
the
events,
are
they're
actually
off
some
acts
added
the
audit
ability
and
the
compliance
checks
aspect
of
it.
So
the
open
source
spinnaker
has
all
the
events
right
as
all
the
primitives,
but
in
in
terms
of
you
having
to
be
able
to
use
it,
we
actually
have
a
basically
our
version
of
spinnaker.
Basically,
this
is
open
in
the
sense
that
we
don't.
We
don't
fork
spinnaker
right.
We
just
add
a
layer
of
value
at
on
top.
Okay.
A
This
is
near
and
dear
to
my
heart
as
I
used
to
do
IT
audits,
ages
and
ages
ago,
and
this
is
something
convincing
people
that
we
need.
This
is
really
then
very
important.
In
most
I
TS
groups
inside
of
enterprises,
so
this
is
excellent
to
see
the
you
mentioned,
the
spinnaker
open
source
project.
How
closely
are
you
tied
to
their
release
cycle
when
they
send
out
new
features
and
releases.
C
Yeah
so
basically,
like
I
said,
we
support
open
source
Winokur
right.
That
is
our
primary
product.
We
have
a
layer
or
we
have
it's
basically
another
micro
service.
If
you
look
at
spinnaker
itself,
it's
about
10
micro
services,
so
we
have
a
methyl
micro
service
that
ties
basically
along
over
the
next
next
release
of
the
spinnaker
release.
So
we
just
use
that
API
to
provide
these
value
ads,
and
so
we
are
completely
in
sync.
C
A
D
C
Yeah
you,
if
they
have
you
know
if
they
need
to
deploy
applications
safely
through
Blue
Beam
on
cannery
or
rolling,
update
or
SEO
integration,
and
they
have
challenges
in
all
of
them.
I
think
the
key
part
is
that
the
dollars
get
to
choose
it
with
one
click
right.
So,
if
you
have
like
that's
a
thousand
applications
and
you
imagine,
you
have
to
create
custom
scripts
for
any
of
them,
people
probably
don't
do
it
if
they
just
like
you
know
what
I
will
just
do
one
way
and
one
way
and
that's
it.
C
So,
with
these
options
being
a
pull
down
option
for
the
developers,
they
can
actually
start
doing
safer
great
strategies.
I
don't
have
to
be
like.
Okay,
I,
don't
have
to
do
scripting
for
any
of
these,
so
it's
already
available
out
of
the
box.
So
now
I
will
start
implementing
safe
strategies.
You
can
also
integrate
with
chaos
monkey
you
know
I'm,
not
sure,
that's
the
more
of
a
advanced
topic,
which
is
basically
a
reliability.
C
Analysis
of
applications
right
you've
heard
of
chaos,
monkeys
tools
that
Netflix
talked
about
it's
natively,
integrated,
would
spinnaker
and
so
I
think,
as
you
mature
from
sort
of
a
you
know,
basic
micro
service
deployment.
All
of
these
things
become
important
factor,
a
Netflix,
for
example.
They
uses
6000
deployments
a
day
right,
obviously
that's
extreme,
but
there's
no
way
they
could
do
this
put
any
of
the
you
know,
other
approaches,
verification,
even
everything
is
automated.
So
everybody
is
not
looking
at
manual
logs
or
letters
and
things
like
that
they
just
fully
automate
it.
C
So
that's
you
want
velocity,
that's
another
criteria.
One
is
multi-cloud.
Other
is
a
you
know.
I
want
to
go
faster,
I
want
to
eliminate
any
manual
steps
if
possible.
Right
there'll
always
be
some
things
that
you
want
to
do
manual,
verification
or
manual
approvals.
But
for
most
part,
if
you
want
to
eliminate
anything,
that's
a
eliminate
able.
Then
then
it's
a
good
choice.
D
D
D
C
I
would
say
is
if
you're
going
from,
if
there's
a
transition,
that's
happening,
you
know,
meaning
you
are
going
from,
maybe
a
VM
type
of
deployment,
container
deployments
or
some
sort
of
transition
you're
trying
to
you
know,
let's
say
they
deploy
to
a
new
environment.
You
used
to
be
on
prem,
but
now
you
want
to
deploy
to
AWS
or
somewhere
else,
for
example,
but
there's
a
transition
happening.
The
point
is:
why
carry
the
burden
of
the
past
by
you
know
redoing
the
scripts
again
for
different
environments
or
different
types
of
application.
C
A
C
That
they're
still
a
valuable
not
to
have
to
create
it.
Most
people
only
look
at
things
when
they
have
to
do
it
for
some
transition
right
everything
is
working,
they
probably
don't
wanna
like
redo
it
just
for
the
heck
of
it
right.
It
is
I
need
to
go.
Read
wind
everything
again
for
some
other
change.
Should
I
bother
with
make
this
thing,
Sarah,
geez
or
should
I
go
for
go
for
newer?
Not
it.
D
A
C
Lot
of
fun,
world
I,
guess
Gopi,
you
can
add
sure
as
well
yeah.
If
you
have
any
interest
in
sort
of
trialing
or
demoing,
more
personal
demo
or
POC,
for
example,
sure
does
an
email.
It's
just
simple
hello,
hello
at
obstinate
calm,
hello
adopts
nice
calm.
So
if
we
can
be,
we
do
we
help
people
with
free
trials.
So
spinnaker
so
don't
feel
shy
if
you'll
reach
out-
and
we
was
happy
to
help.
B
So
you
can
reach
us
out
a
table.
Some
XCOM,
the
one
good
thing.
That
spinnaker
is
that
you
can
start
small,
do
a
pilot
for
a
small
group
and
that
will
allow
you
to
do
the
POC
get
comfortable
with
the
spinnaker
and
it
can
scale
with
your
organization,
as
you
scale,
to
different
groups
and
multiple
environments,
though.
A
A
So
thanks
very
much
for
coming
today.
This
is
great.
You
can
also
reach
these
guys
on
the
verge
of
commons
/
channel.
If
you're
not
there
send
an
email
to
me,
D
Mueller,
at
Red,
Hat,
calm
and
I'll
get
you
hooked
up
and
again
we
look
forward
to
another
update
sometime
not-too-distant
future
on
new
releases
and
if
you
have
a
customer
story,
would
love
to
hear
that
too.
And
if
anyone
has
questions,
please
do
reach
out.
A
We
really
appreciate
your
feedback
on
this
and
all
the
other
aspects
of
the
commons
efforts,
but
thanks
again
guys
for
coming
today
and
we'll
talk
to
you
all
soon
and
hopefully
we'll
see
you
at
some
of
the
spinnaker
events
that
are
coming
up,
I
think
there's
a
spinnaker
summit
November
and
a
few
other
ones
as
well.
So
we'll
keep
you
all
posted.