Signed-off-by: Michael Adam <obnox@redhat.com>

Signed-off-by: Michael Adam <obnox@redhat.com>

From https://github.com/dgrijalva/jwt-go/pull/139

 it is understood
that if the machine where jwt token is generated and/or the machine
where jwt token is verified have any clock skew then there is a
possibility of getting a "Token used before issued" error.  Considering
that we also check for expiration with delta of 5 minutes, disabling iat
claim until the patch is merged in jwt.

Signed-off-by: Raghavendra Talur <rtalur@redhat.com>

When this function was refactored in preparation for robust delete
behavior the "friendly" error message was moved into the utility
function used for counting the number of lvs in a thin pool.
However, the errors from this function need to be checked to see
if lvm errors out because the thin pool is missing vs. another
reason. Changing the raw lvm error to a friendly error in this
case is wrong. Move the friendly error back to the upper function
call.

Fixes issue #1242

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: Raghavendra Talur <rtalur@redhat.com>

Signed-off-by: Raghavendra Talur <rtalur@redhat.com>

Fixes #1226

Signed-off-by: Michael Adam <obnox@redhat.com>

When running `make vendor` without `hg` in the path, the build fails
with the following error:

   [WARN] Unable to checkout bitbucket.org/ww/goautoneg
   [ERROR] Update failed for bitbucket.org/ww/goautoneg: hg is not installed
   [ERROR] Failed to install: hg is not installed
   make: *** [Makefile:74: vendor] Error 1

Glide needs to fetch a repository from bitbucket.org, which is a
Mercurial hosting site. The `hg` executable needs to be available to
download the requires pkgs.

Reported-by: Madhu Rajanna <mrajanna@redhat.com>
Signed-off-by: Niels de Vos <ndevos@redhat.com>

Unfortunately, block hosting volumes were structured different from
regular volumes in where the volume was mostly configured (pre-exec
vs. post-exec). With the introduction of operations this lead to
some incorrect code reuse in the delete and rollback cases in that
the create case does not update the block hosting volume size
immediately (this is a bug too, IMO) but only in finalize.
Thus trying to give space back to the block hosting volume in
rollback was incorrect behavior.
This somewhat hacky approach tries to fix this issue minimally
by not adjusting the block hosting volume size on rollback.

Future cleanups of the structure of block volume creation
should try to sort out what should be set before the exec, but
that's for another PR.

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Instead of "open coding" the logic involved in modifying the block
hosting volume's free space, provide a function call on the
volume entry that also checks some invariants using godbc.

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Previously, output was "Device  updated".
Now it is of the form  "Device <DEVICE-ID> updated".

Fixes #1240

Signed-off-by: Michael Adam <obnox@redhat.com>

Signed-off-by: Madhu Rajanna <mrajanna@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Instead of deriving all of the lvm names like heketi has
traditionally done switch to using the new explicit lvm
params.

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Now that cloned volumes exist, we need to track the LVM properties
of the brick independently of the brick ids. The alternative would
be to backtrack from known values (the brick path) but this would
not be reliable in the case of partial deletes.

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

If a delete of a volume errors out with the does-not-exist error
treat it as a success condition and continue on with life.

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: John Mulligan <jmulligan@redhat.com>

Signed-off-by: Raghavendra Talur <rtalur@redhat.com>

If a volume is expanded and has a block flag set to true, then we
should also update the free size attribute of the volume in blockinfo.

Signed-off-by: Raghavendra Talur <rtalur@redhat.com>

Don't fail the deletion of a block-hosting volume if
it references a block volume id, that does not
exist in the database.

Signed-off-by: Michael Adam <obnox@redhat.com>

Signed-off-by: Michael Adam <obnox@redhat.com>

Signed-off-by: Michael Adam <obnox@redhat.com>

Signed-off-by: Michael Adam <obnox@redhat.com>

If a volume links back to a brick-id that does not
exist any more in the db, this does not harm otherwise,
so let's not have heketi refuse to start up in this
situation.

Signed-off-by: Michael Adam <obnox@redhat.com>

Instead looping over
clusters -> volumes in the cluster-> bricks in the volume

loop over
volumes -> bricks in the volume

This reduces the complexity, while at the same
time preventing startup from failing if cluster's
volume-list has a volume-id which does not have
a volume entry in the DB any more.

This patch is best viewn with "git show -w"
(ignore white space changes).

Signed-off-by: Michael Adam <obnox@redhat.com>

Add container images for the CentOS Container Registry that is
available at https://registry.centos.org/containers/

 . The images are
built from RPMs that are available from the CentOS Storage SIG.

Currently two flavours are provided:
1. built from the CentOS Storage SIG stable/released repository
2. built from the CentOS Storage SIG testing repository

Signed-off-by: Niels de Vos <ndevos@redhat.com>

This is a bare minimum set of fixes needed to get the container
image building on dockerhub again.

Signed-off-by: John Mulligan <jmulligan@redhat.com>