CMK release - version v1.5.2.

Makefile

@@ -16,7 +16,7 @@
 
 all: docker
 
-version=v1.5.1
+version=v1.5.2
 
 # TODO: This target should be changed, when e2e tests will be ready and test
 # entrypoint will be defined.

README.md

@@ -72,7 +72,7 @@ Options:
   --cmk-cmd-list=<list>        Comma seperated list of CMK sub-commands to run
                                on each host
                                [default: init,reconcile,install,discover,nodereport].
-  --cmk-img=<img>              CMK Docker image [default: cmk:v1.5.1].
+  --cmk-img=<img>              CMK Docker image [default: cmk:v1.5.2].
   --cmk-img-pol=<pol>          Image pull policy for the CMK Docker image
                                [default: IfNotPresent].
   --conf-dir=<dir>             CMK configuration directory [default: /etc/cmk].

RELEASE.md

@@ -120,21 +120,21 @@ Running Vagrant locally syncs your repository directory into `/cmk` using by def
  - check whether current branch is `master` and if it's "clean"
  - fetch origin
  - check whether `CMK_RELEASE_VER` is set, follows proper pattern and there in no existing tag with it's value
- - check whether there is no `cmk-release-v1.5.1` branch neither locally nor remotely
- - get previous version string from `Makefile` (`version=v1.5.1`) and check
+ - check whether there is no `cmk-release-v1.5.2` branch neither locally nor remotely
+ - get previous version string from `Makefile` (`version=v1.5.2`) and check
 
 If all above checks pass, script will:
- - create local branch `cmk-release-v1.5.1`
- - replace old release string (`v1.5.1`) with new one (`v1.5.1`) in all repo files
- - commit changes with message `CMK release - version v1.5.1.`
+ - create local branch `cmk-release-v1.5.2`
+ - replace old release string (`v1.5.2`) with new one (`v1.5.2`) in all repo files
+ - commit changes with message `CMK release - version v1.5.2.`
  - push branch to origin
  - checkout to `master` branch.
 
 **What will happen after PR gets to `master` branch**
 After PR is "Rebased and merged" into `master` branch, Jenkins CI/CD will start VM based on `.release/Vagrantfile` and execute `.release/make_release.py` inside the VM.
 
 **What will `make_release.py` do :**
-- check latest commit message for `CMK release - version v1.5.1.` string
-- `v1.5.1` will become tag value
+- check latest commit message for `CMK release - version v1.5.2.` string
+- `v1.5.2` will become tag value
 - generate change log
 - create release with change log based on tag found in commit message

cmk.py

@@ -63,7 +63,7 @@
   --cmk-cmd-list=<list>        Comma seperated list of CMK sub-commands to run
                                on each host
                                [default: init,reconcile,install,discover,nodereport].
-  --cmk-img=<img>              CMK Docker image [default: cmk:v1.5.1].
+  --cmk-img=<img>              CMK Docker image [default: cmk:v1.5.2].
   --cmk-img-pol=<pol>          Image pull policy for the CMK Docker image
                                [default: IfNotPresent].
   --install-dir=<dir>          CMK install directory [default: /opt/bin].
@@ -119,7 +119,7 @@
 def main():
     setup_logging()
 
-    args = docopt(__doc__, version="CMK v1.5.1")
+    args = docopt(__doc__, version="CMK v1.5.2")
     if args["cluster-init"]:
         clusterinit.cluster_init(args["--host-list"], args["--all-hosts"],
                                  args["--cmk-cmd-list"], args["--cmk-img"],

docs/cli.md

@@ -68,7 +68,7 @@ Options:
   --cmk-cmd-list=<list>        Comma seperated list of CMK sub-commands to run
                                on each host
                                [default: init,reconcile,install,discover,nodereport].
-  --cmk-img=<img>              CMK Docker image [default: cmk:v1.5.1].
+  --cmk-img=<img>              CMK Docker image [default: cmk:v1.5.2].
   --cmk-img-pol=<pol>          Image pull policy for the CMK Docker image
                                [default: IfNotPresent].
   --install-dir=<dir>          CMK install directory [default: /opt/bin].

docs/html/docs/architecture.html

@@ -82,19 +82,19 @@ <h2>
 <p>CMK accomplishes core isolation by controlling what logical CPUs each
 container may use for execution by wrapping target application commands
 with the CMK command-line program. The <code>cmk</code> wrapper program maintains
-state in a directory hierarchy on disk that describes <strong>pools</strong> from
+state in a <a href="https://kubernetes.io/docs/concepts/configuration/configmap/" rel="nofollow">Kubernetes configmap</a> that describes <strong>pools</strong> from
 which user containers can acquire available <strong>CPU lists</strong>. These pools
 can be exclusive (only one container per CPU list) or non-exclusive
-(multiple containers can share a CPU list.) Each CPU list directory
+(multiple containers can share a CPU list.) Each CPU list entry
 contains a <code>tasks</code> file that tracks process IDs of the container
 subcommand(s) that acquired the CPU list. When the child process exits,
 the <code>cmk</code> wrapper program clears its PID from the tasks file. If the
 wrapper program is killed before it can perform this cleanup step, a
 separate periodic reconciliation program detects this condition and cleans
-the tasks file accordingly. A file system lock guards against conflicting
+the tasks file accordingly. A lock mechanism guards against conflicting
 concurrent modifications.</p>
 <p>The rest of this document discusses the high-level design of CMK.</p>
-<p>For more information about the structure of state on disk, see
+<p>For more information about the structure of state in the configmap, see
 <a href="config.html">The cmk configuration directory</a>.</p>
 <p>For more information about how to use the <code>cmk</code> wrapper program, see
 <a href="cli.html">Using the cmk command-line tool</a>.</p>
@@ -111,10 +111,6 @@ <h2>
 times on the order of ones to tens of seconds or greater.</p>
 </li>
 <li>
-<p>After a workload has started executing, there is no need to
-dynamically update its CPU assignments.</p>
-</li>
-<li>
 <p>Machines running workloads explicitly isolated by <code>cmk</code> must be guarded
 against other workloads that <em>do not</em> consult the <code>cmk</code> tool chain.
 The recommended way to do this is for the operator to taint the node.
@@ -157,7 +153,7 @@ <h2>
 </li>
 <li>
 <p>Interoperate well with the <code>isolcpus</code> kernel parameter. When
-initializing the CMK configuration directory, prefer to align
+initializing the CMK configuration configmap, prefer to align
 exclusive CPU lists with fully-isolated physical cores.</p>
 </li>
 <li>
@@ -256,10 +252,6 @@ <h2>
 <td align="left">This should be extremely rare in practice, but it relates to the above scenario. If a PID of a <code>cmk</code> subcommand leaks as described above and is recycled by the kernel before <code>reconcile</code> runs, then when <code>reconcile</code> does run, it will see that the PID refers to a running process and will not remove that PID from the <code>tasks</code> file. There is currently no mitigation in place to protect against this scenario.</td>
 </tr>
 <tr>
-<td align="left">CMK <code>init</code> flag values for <code>--num-shared-cores</code> and <code>--num-exclusive-cores</code> must be positive integers.</td>
-<td align="left">Zero is unsupported by the tool chain.</td>
-</tr>
-<tr>
 <td align="left">The flag values for <code>--interval</code> (used in <code>cmk reconcile</code> and <code>cmk node-report</code>) must be integers.</td>
 <td align="left">Fractional seconds are not supported by the tool chain.</td>
 </tr>