Doc update -- we're not as "hard-wired" any more.

README.md

@@ -23,9 +23,6 @@ limitations, expected to be removed over time, including:
 * Only one Ingress definition in a namespace is valid at a time. If
   more than one definition is added to the namespace, then the most
   recent definition becomes valid.
-* A variety of elements in the implementation are hard-wired, as
-  detailed in the documentation. These are expected to become configurable
-  in further development.
 
 Other features are subject to change on short notice. Testing and
 feedback are nevertheless welcome, and very valuable at this early

container/README.md

@@ -65,18 +65,11 @@ Varnish runs with two listeners:
       after it has loaded the configuration for an Ingress at the
       instance. When it is not ready, it responds with status 503.
 
-**TO DO**: The listeners are currently hard-wired at ports 80 and
-8080, respectively.  It is presently not possible to specify the PROXY
-protocol for a listener. The readiness check is hard-wired at the URL
-path ``/ready``.
-
 Another listener is opened to receive administrative commands (see
 [``varnish-cli(7)``](https://varnish-cache.org/docs/6.0/reference/varnish-cli.html));
 this connection will be used by the controller to manage the Varnish
 instance.
 
-**TO DO**: The admin port is currently hard-wired as port 6081.
-
 Use of the administrative interface requires authorization based on a
 secret that must be shared by the Varnish instances and the
 controller. This must be deployed as a k8s Secret, whose contents are
@@ -84,9 +77,6 @@ in a file mounted to a path on each Varnish instance, and are obtained
 by the controller from the cluster API. The configurations in the
 [``deploy/``](/deploy) folder show how this is done.
 
-**TO DO**: The path of the secret file on the Varnish instance is
-currently hard-wired as ``/var/run/varnish/_.secret``.
-
 The Varnish instance is configured to start with a start script that
 does the following: