These were used on a previous patch as a debug, let's remove them. They
are not intended to be displayed.
Signed-off-by: Sébastien Han <seb@redhat.com>
This method does not start anything but creates the deployment. So let's
rename it to createDeployment() instead.
Signed-off-by: Sébastien Han <seb@redhat.com>
rgw wasn't using UpdateDeploymentAndWait() to update its deployment
configuration. We now use it so that it's consistent with the other
daemons configuration.
Signed-off-by: Sébastien Han <seb@redhat.com>
When a cluster is updated with a different image version, this triggers
a serialized restart of all the pods. Prior to this commit, no safety
check were performed and rook was hoping for the best outcome.
Now before doing restarting a daemon we check it can be restarted. Once
it's restarted we also check we can pursue with the rest of the
platform. For instance, with monitors we check that they are in quorum,
for OSD we check that PGs are clean and for MDS we make sure they are
all active.
Fixes: https://github.com/rook/rook/issues/2889
Signed-off-by: Sébastien Han <seb@redhat.com>
The ceph image isn't needed every time the rook image is updated.
Thus, make it optional to copy the ceph image into the cluster.
Pushing the ceph image can be done by uncommenting in the script
when needed.
Signed-off-by: travisn <tnielsen@redhat.com>
In the 0.9 release rook converted the v1beta1 CRD resources
to v1 resources. This conversion code is no longer necessary
as we will be using v1 resources going forward.
The code paths will not be triggered anymore, thus
removing the dead code.
Signed-off-by: travisn <tnielsen@redhat.com>
Add missing docstrings for container image
functions in pod.go, noting the behavior
when getting a container image from a pod
which only has a single container defined.
Signed-off-by: Kristoffer Grönlund <kgronlund@suse.com>
Follow-up to #3436:
The validation module has a defined constant for
label value max length. It makes sense to use it
here.
Signed-off-by: Kristoffer Grönlund <kgronlund@suse.com>
This is not a recommended workflow but useful if people click on "Don’t
see your issue here? Open a regular issue."
Signed-off-by: Sébastien Han <seb@redhat.com>
Run the script like this:
./contrib/backport_to_stable_branch.sh STABLE_BRANCH_NAME COMMIT_SHA1 BACKPORT_BRANCH_NAME
Signed-off-by: Sébastien Han <seb@redhat.com>
Update the upgrade-from-*.yaml files to be appropriate for upgrade from
v1.0 to master. Currently no creations or deletions are necessary, but
the files are kept as a placeholder for the upcoming v1.1 upgrade docs.
Signed-off-by: Blaine Gardner <blaine.gardner@suse.com>
The CI only needs to be run for PRs that have code changes.
PRs that are only documentation, yaml, or other files
that are not built should skip the long and tedious
CI process. This makes the [skip ci] flag more discoverable.
Signed-off-by: travisn <tnielsen@redhat.com>
this patch introduces failure-domain aware scheduling for monitor pods.
previously the only policy was to avoid scheduling monitors on the same
nodes. the new policy tries to spread monitors across zones and nodes.
NOTE: this patch only enforces the well-known k8s "zone"
failure-domain label (i.e. it does not look for region labels). this
decision is made for two reasons. first, eliminating explicit
scheduling is an important goal and will be done as part of upcoming
work. this will enable all supported failure-domain labels to be
handled. second, the "zone" domain is likely more appropriate for a
larger portion of users (as opposed to the geographical distinction
made with region), and supporting multiple failure domain types would
add significant complexity for a temporary resolution to failure
domain scheduling.
at a high-level this patch introduces a data structure `NodeUsage` that
is a pairing of a v1.Node and metadata relevant to scheduling: number of
monitor pods on the node, and its status w.r.t. to being scheduable for
new monitor pods.
each scheduling event computes a unified data structure that organizes
for each node a `NodeUsage` structure into per-failure-zone groups.
subsequent algorithms rely soley on this unified structure to make
scheduling decisions.
there are two entry points to the changes made:
1) during orchestration mon:Cluster:assignMons is invoked to make a
place new monitor pods onto nodes. the core scheduling logic is now
self-contained in mon:scheduleMonitor which implements node and zone
aware scheduling policies.
2) periodic health checks resolve any conflicts that may occur due to
changes to the cluster (e.g. new nodes, configuration changes, etc...).
the two existing checks: mons on invalid nodes, and overloaded nodes are
both handled.
fixes: #2603
Signed-off-by: Noah Watkins <noahwatkins@gmail.com>
Add `--region :default-placement` in RadosGW tutorial to avoid the InvalidLocationConstraint error
Signed-off-by: Maxime Guyot <maxime.guyot@elits.com>
* when submitting code people must be provide unit tests
* when submitting code for a new functionnality, integration tests must
be added so we can get coverage of that feature in the CI.
Signed-off-by: Sébastien Han <seb@redhat.com>
Empty deployment list made the operator to crash as the condition check
was checking if the value at the 0th location is nill wich fails in case
of empty list. Updated it to check length of list not equals 0.
Signed-off-by: rohan47 <rohgupta@redhat.com>
Linear raid can be created using `mdadm --create --level=linear`,
By creating a linear raid disk on top of a logical volume,
we can pass the linear device to `ceph-volume lvm batch --prepare`
to provision a new OSD on top of the logical volume since
`ceph-volume` does not take lv as the data device.
Signed-off-by: Ash Wu <hSATAC@gmail.com>
Example of failure scenarios:
- requested PVC 500M = 500,000,000 bytes
- PV is created as:
(500M / 2**20)Mi = "476"Mi
But 476Mi = 476 * 2**20 = 499122176 < 500M
From the k8s documentation:
Claims will remain unbound indefinitely if a matching volume does not
exist. Claims will be bound as matching volumes become available. For
example, a cluster provisioned with many 50Gi PVs would not match a
PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added
to the cluster.
which is inline with the behavior observed in which a 500M PVC is never
bound. However, the documentation also states:
If a PV was dynamically provisioned for a new PVC, the loop will
always bind that PV to the PVC. Otherwise, the user will always get
at least what they asked for
which suggests that an _explicit_ binding can be created, and perhaps
something has changed with respect to this binding that has caused the
failures in newer versions of k8s.
fixes: #3391fixes: #2922
Signed-off-by: Noah Watkins <noahwatkins@gmail.com>
The beast fronted configuration for rgw is quite different than civetweb
so we adapted the construct of the arg line based on that configuration
requirement.
Closes: https://github.com/rook/rook/issues/3411
Signed-off-by: Sébastien Han <seb@redhat.com>
Sébastien Han
Dinar Valeev
travisn
Blaine Gardner
Alexander Trost
Kristoffer Grönlund
Noah Watkins
Maxime Guyot
rohan47
Dmitry Yusupov
Khanh Ngo
Ash Wu