The document published says that:

To remove a space from an isolation segment, set the isolation_segment_guid for the space to NULL.

cf.

But I've tried and failed to remove a space from an isolation segment with this method.

$ CF_TRACE=true cf curl /v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013 -X PUT -d '{"isolation_segment_guid": null}'

*** omit ***

REQUEST: [2017-02-24T10:44:58Z]
PUT /v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013 HTTP/1.1
Host: api.<REDUCTED>
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Connection: close
Content-Type: application/json
User-Agent: go-cli 6.23.1+a70deb3.2017-01-13 / linux

{"isolation_segment_guid": null}

RESPONSE: [2017-02-24T10:44:59Z]
HTTP/1.1 201 Created
Connection: close
Content-Length: 1568
Content-Type: application/json;charset=utf-8
Date: Fri, 24 Feb 2017 10:44:26 GMT
Server: nginx
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: f6612ccf-5bc8-4fd8-4be0-783257a3165a
X-Vcap-Request-Id: f6612ccf-5bc8-4fd8-4be0-783257a3165a::c2548d1b-db54-44bc-b117-67893c012a57

{
  "metadata": {
    "guid": "5a1da005-60dd-4095-8903-70bf74c61013",
    "url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013",
    "created_at": "2017-02-23T12:09:15Z",
    "updated_at": "2017-02-24T10:44:26Z"
  },
  "entity": {
    "name": "is1-space",
    "organization_guid": "4f9a58f2-8b86-49e6-b6c0-68b6b20019e9",
    "space_quota_definition_guid": null,
    "isolation_segment_guid": "a5c3ce30-3a31-46d3-ab66-fb44a4ffa758",
    "allow_ssh": true,
    "isolation_segment_url": "/v3/isolation_segments/a5c3ce30-3a31-46d3-ab66-fb44a4ffa758",
    "organization_url": "/v2/organizations/4f9a58f2-8b86-49e6-b6c0-68b6b20019e9",
    "developers_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/developers",
    "managers_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/managers",
    "auditors_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/auditors",
    "apps_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/apps",
    "routes_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/routes",
    "domains_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/domains",
    "service_instances_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/service_instances",
    "app_events_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/app_events",
    "events_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/events",
    "security_groups_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/security_groups",
    "staging_security_groups_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/staging_security_groups"
  }
}

$ cf curl /v3/isolation_segments/a5c3ce30-3a31-46d3-ab66-fb44a4ffa758/relationships/spaces
{
   "data": [
      {
         "name": "is1-space",
         "guid": "5a1da005-60dd-4095-8903-70bf74c61013",
         "link": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013"
      }
   ]
}

This is because a key with null value in a request parameter will be omitted in Cloud Controller NG.
So when I send -d {"isolation_segment_guid": null}, the request_attrs will be {} and thus the if clause will be false (please refer the following source code of Cloud Controller NG).

      if request_attrs['isolation_segment_guid']

(And I think if this would be true, the operation will finally fail because IsolationSegmentModel.where(guid: request_attrs['isolation_segment_guid']) will be empty at line 232.)

For the present implementation, the right operation to remove a Space from an Isolation Segment should be something like curl /v2/spaces/<SPACEGUID>/isolation_segment -X DELETE.
(Please refer to the source code.)

I have succeeded in removal with this operation.

$ cf curl /v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/isolation_segment -X DELETE
{
  "metadata": {
    "guid": "5a1da005-60dd-4095-8903-70bf74c61013",
    "url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013",
    "created_at": "2017-02-23T12:09:15Z",
    "updated_at": "2017-02-24T11:39:55Z"
  },
  "entity": {
    "name": "is1-space",
    "organization_guid": "4f9a58f2-8b86-49e6-b6c0-68b6b20019e9",
    "space_quota_definition_guid": null,
    "isolation_segment_guid": null,
    "allow_ssh": true,
    "organization_url": "/v2/organizations/4f9a58f2-8b86-49e6-b6c0-68b6b20019e9",
    "developers_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/developers",
    "managers_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/managers",
    "auditors_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/auditors",
    "apps_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/apps",
    "routes_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/routes",
    "domains_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/domains",
    "service_instances_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/service_instances",
    "app_events_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/app_events",
    "events_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/events",
    "security_groups_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/security_groups",
    "staging_security_groups_url": "/v2/spaces/5a1da005-60dd-4095-8903-70bf74c61013/staging_security_groups"
  }
}

$ cf curl /v3/isolation_segments/a5c3ce30-3a31-46d3-ab66-fb44a4ffa758/relationships/spaces
{
   "data": []
}

Would you please update the document?

Currently, https://github.com/cloudfoundry/docs-cf-admin/blob/master/quota-plans.html.md.erb does not precise whether cloudfoundry enforces memory usage by counting stopped apps, and crashed/starting app instances.

In other words, when reaching a quota limit, can users stop apps to leave room for other apps to start within quotas, or should user instead reduce number of app instances or stop applications.

securing-traffic.html.md.erb is wrong/outdated since it doesn’t account for Envoy.

The guidance provided at https://gist.github.com/nikhilsuvarna/bd0aa0ef01880270c13d145c61a4af22 should be incorporated to correctly show how TLS is established between the GoRouter and AppContainer.

That is, The CF guide shows:

and:

but not anything like the current state with TLS to the container:

My knowledge of CF isn't enough to determine how much of the current document needs to be deleted as obsolete vs. just adding new content, so I'll start with an issue instead of a PR.

When reading the section - "Mutual Authentication with Clients" (https://docs.pivotal.io/pivotalcf/2-3/adminguide/securing-traffic.html#gorouter_mutual_auth), the correct setting is extremely unclear due to what seems to be contradictory instructions.

First we see this section:

Router does not request client certificates. The Gorouter does not request client certificates in TLS handshakes so clients will not provide them and validation of client certificates does not occur. This option is incompatible with the XFCC configuration options TLS terminated for the first time at HAProxy and TLS terminated for the first time at the Router in PAS because these options require mutual authentication.

This section implies that if you Terminate at the GoRouter you CANNOT use this setting due to the second clause: "This option is incompatible with the XFCC configuration options.... TLS terminated for the first time at the Router".

Then later in the same doc, it says bluntly that Router does not request client certificates. is the ONLY valid setting to use if terminating the GoRouter:

If Gorouter is the first point of TLS termination (your load balancer does not terminate TLS, and passes the request through to Gorouter over TCP), consider the following:

Only option Router does not request client certificates should be used with PAS, as the Gorouters are in that product receive requests for the system domain. Many clients of CF platform APIs do not present client certificates in TLS handshakes, so the first point of TLS termination for requests to the system domain must not request them.

My Suspicion is that the clause of TLS terminated for the first time at the Router should probably instead be TLS terminated for the first time at the load balancer, but I am not 100% sure on that.

What's the relationship between the lowest port exposed by the Docker image and $PORT (8080 on Diego) set by Cloud Controller?

AFAIK this note is not accurate. It is not enough to be org admin in order to create a buildpack. You must be cloud controller admin in order to do that.
Am I right?

As noted in the CFF Slack workspace at https://cloudfoundry.slack.com/archives/C02FL4A2K/p1528132160000151 (#general, 2018-06-04), the example of the manifest changes at https://docs.cloudfoundry.org/adminguide/isolation-segments.html#bosh-segments is out of date now that the cf-deployment has replaced the previous manifest-generation system. Something like https://github.com/cloudfoundry/cf-deployment/blob/683f5044781f600104f6cc9e5a4e13d200d35c77/operations/test/add-persistent-isolation-segment-diego-cell.yml#L50-L51 is more relevant.

I'm happy to work with the Docs team to update these instructions, but I don't have time right now to PR a change in myself.

Also /cc @heyjcollins @dsabeti

Quick and easy.

https://github.com/cloudfoundry/docs-cf-admin/blob/12.0/notifications.html.md.erb

Line 31 is missing the "u" in uaac.

Github issue corresponding to PR: #72

There are two number of documentation issues in the cf curl examples

1. Major: Incorrect \ escape of new lines in the -d POST/PUT/PATCH blocks of data. E.g. line 342:

$ cf curl "/v2/organizations/45a66ed9-cb76-46c3-92dd-b29187b50bfb" \
 -X PUT \
 -d '{ 
   "default_isolation_segment_guid":"323f211e-fea3-4161-9bd1-615392327913" 
 }'

instead of

$ cf curl "/v2/organizations/45a66ed9-cb76-46c3-92dd-b29187b50bfb" \
  -X PUT \
  -d '{ \
    "default_isolation_segment_guid":"323f211e-fea3-4161-9bd1-615392327913" \
  }'

2. Major: Incorrect \ escapes of _ in request path. E.g. line 82: /v3/isolation_segment not /v3/isolation\_segment
3. Minor: Incorrect \ escapes of _ in the JSON fields. E.g. "created_at" not "created\_at"
4. Cosmetic:cf curl does not need -X GET request method. Unlike the original curl command HTTP GET is assumed with cf curl.
5. Cosmetic: -X DELETE does not need to be on a separate line if there is no -d data after

uaac curl https://notifications.user.example.com/notifications -X PUT --data '{ "source_name": "Cloud Ops Team",
"notifications": {
"system-going-down": {"critical": true, "description": "Cloud going down" },
"system-up": { "critical": true, "description": "Cloud back up" }
}
}'

What does the url refer to from the above command?
When I tried https://notifications./notifications , I am getting 404. should I enable something for this to work?

The page https://docs.cloudfoundry.org/adminguide/diego-cell-upgrade.html#limitations-considerations mentions limit on "started" containers, whereas it should read "starting" containers

If too many app instances are started at once, then the load of these starts on the rest of the system can cause other applications that are already running to crash and be rescheduled. These events can result in a cascading failure.

To prevent overload, Cloud Foundry provides two major throttle configurations:

The maximum number of starting containers that Diego can start in Cloud Foundry: This is a deployment-wide limit. The default value and ability to override this configuration depends on the version of Cloud Foundry deployed. For information about how to configure this setting, 
see the Setting a Maximum Number of **Started** Containers topic.

The instructions at https://github.com/cloudfoundry/docs-cf-admin/blob/master/notifications.html.md.erb talk about setting up for sending a notification, but there is no example included for actually sending the notification. Alternatively, a link to the API for the notifications service might suffice.

Outside PCF, I have a CAS (sso) server of HTTPS protocol. The client is located on PCF. How should I arrange certificates on PCF?

The current quota management does not include the app instance ephemeral disk storage limit.

The cf app command however still display the upper disk quota (returned by the http://apidocs.cloudfoundry.org/247/apps/get_detailed_stats_for_a_started_app.html CC API)

``
cf app hello-world
Showing health and status for app hello-world in [...]
OK

requested state: started
instances: 1/1
usage: 512M x 1 instances
[...]

 state     since                    cpu    memory         disk         details

#0 running 2016-11-23 10:13:59 AM 0.0% 3.6M of 512M 6.8M of 1G
``

It would be useful to mention in https://github.com/cloudfoundry/docs-cf-admin/blob/master/quota-plans.html.md.erb that the 1G disk limit is configurable per CF deployment within the http://bosh.io/jobs/cloud_controller_ng?source=github.com/cloudfoundry/cf-release&version=247#p=cc.default_app_disk_in_mb property.

This is not a doc issue (#49) but I wuld like to know why do we have a limit on the container image size. Why not constrain it by org/space quota but the size of the container is not restricted at a deployment level.

Use cases:

i can have some 2 GB, 1 GB or 4 GB containers. I don't want to have a site wide 4 GB size and 4 GB reserved for every container, rather based on the manifest file I can control the size of the container.

Thanks, Rajesh

On this cf create-user docs page... https://docs.cloudfoundry.org/adminguide/cli-user-management.html#create-user
...there's no reference to the --origin option that is included in the cf cli help listed below.

The use case is that admins may have multiple origins, and this option can enable them to specify the correct one. You may want to contact UAA for more details.

cf cli help:

$ cf create-user -h
NAME:
create-user - Create a new user

USAGE:
cf create-user USERNAME PASSWORD
cf create-user USERNAME --origin ORIGIN

EXAMPLES:
cf create-user [email protected] S3cr3t # internal user
cf create-user [email protected] --origin ldap # LDAP user
cf create-user [email protected] --origin provider-alias # SAML or OpenID Connect federated user

OPTIONS:
--origin Origin for mapping a user account to a user in an external identity provider

SEE ALSO:
passwd, set-org-role, set-space-role

Inspired by the simple example at https://docs.cloudfoundry.org/adminguide/cli-user-management.html
I tried this:

cf create-user john pswd
Creating user john...
FAILED
Error creating user john.
Server error, status code: 403, error code: insufficient_scope, message: Insufficient scope for this resource

I don't understand the error message. I'll have to search.

The page starts out with "This topics describes" - remove the "s" from topic

We see that the doc here talks about configuring External Domain:
https://docs.pivotal.io/platform/application-service/2-8/operating/deploying-service-mesh.html

This page says it is a limitation that it is hardcoded to *.mesh.apps-domain.com

Can we make the docs consistent?

The intention of the code seems to be that only OSS CF should have the "Prepare BOSH to Support Isolation Segments" subtopic because of:

<% if vars.product_name == 'CF' %>
## <a id="prepare"></a>Prepare BOSH to Support Isolation Segments

To enable isolation segments for a deployment, you must first assign Diego cells a `placement_tags` property in your Diego manifest by following the steps below:

But the "Prepare BOSH to Support Isolation Segments" subtopic heading shows up in the ToC in the PCF docs as well, but the link is dead presumably because the "" is never rendered. I guess the ToC is built by scanning the document without regards to what actually ends up getting rendered in the end?

Some of the files contain PCF specific if clauses to display partials. An example is https://github.com/cloudfoundry/docs-cf-admin/blob/master/securing-traffic.html.md.erb#L117.

I think that OSS documentation shouldn't contain anything which is specific to one provider. In my case, Bookbinder always wants to use the PCF partial instead of the CF one because my product is not named "CF". Is there any way of turning these if clauses around so that it defaults to using the OSS version and not the PCF version? I've had to create the partials as the files required by the PCF version and fill them with the OSS version which isn't nice...

I find the line To manage users, organizations, and roles with the cf CLI, you must log in with UAA Administrator user credentials. confusing/misleading, and just received a feature request for the cf CLI to do make role management possible by Org Managers. It already is!

I'm not sure what "UAA Administrator user credentials" means - did a search and this is the only page that uses "UAA Administrator". Is that different from the CF operator (the "admin")?

Assuming it is the same, note that if the feature flag set_roles_by_username is enabled, Org Managers can assign roles to (existing) users in their org. Even Space Managers can assign (space) roles to users in their space.

_tcp_modify_ports_after.html.md.erb

The document
https://docs.cloudfoundry.org/adminguide/isolation-segments.html#add_org_is
says that

When you add an org to one isolation segment, it becomes the default isolation segment for that org unless another default is already set. This means that new spaces created within the org will be in its default isolation segment unless specified otherwise.

(source code:

However, when I added an org to an isolation segment that is not shared, it did not become the default isolation segment for the org.

I've checked the source code of Cloud Controller NG and found that the current implementation seems (intentionally) to not set the default isolation segment on adding orgs if the IS is not shared segment.
https://github.com/cloudfoundry/cloud_controller_ng/blob/70f794ca6e2aa9d718fabe3d1e84f4fe5dcc5a29/app/actions/isolation_segment_assign.rb#L11-L15

          if org.default_isolation_segment_model.nil?
            if isolation_segment.is_shared_segment?
              org.update(default_isolation_segment_model: isolation_segment)
            end
          end

The unit tests for the method seem backing this intention.

• https://github.com/cloudfoundry/cloud_controller_ng/blob/70f794ca6e2aa9d718fabe3d1e84f4fe5dcc5a29/spec/unit/actions/isolation_segment_assign_spec.rb#L30-L33
• https://github.com/cloudfoundry/cloud_controller_ng/blob/70f794ca6e2aa9d718fabe3d1e84f4fe5dcc5a29/spec/unit/actions/isolation_segment_assign_spec.rb#L66-L71

What's your thought on this?

Last update to https://github.com/cloudfoundry/docs-cf-admin/blob/master/enabling_ipv6.html.md.erb was in November 2016 and since then AWS has made some big improvements https://aws.amazon.com/blogs/aws/new-ipv6-support-for-ec2-instances-in-virtual-private-clouds/

Probably other IaaSes have as well. What's the latest Cloud Foundry recommendation on this? I assume it's a moderately fast-moving space, so not making a pull request in deference to those who know.

Hi,

I went through the documentation. However i could not find how to pass to pass parameters to run Dockee image like -p or
-e.

Is it possible to use them along with CF PUSH ?

I find the doc on buildpack lock too short
https://github.com/cloudfoundry/docs-cf-admin/blob/master/buildpacks.html.md.erb

Scenario is that

• cf ops install a cf-release version X with buildpack (say Java BP) 3.6
• cf admin update JBP to 3.8.1 (note JBP 3.6 does not support spring boot 1.4 for example)
• cf admin does not lock the buildpack (default)
  any deploy would remove the upgraded buildpack and return to the cf-release defined one
  (that will then mean any deployed spring boot 1.4 app will stop working if restage, which means risk of downtime while cf admin and cf ops introduces divergence)

I think we should provide more emphasys on buildpack lock and suggest a best practice after any buildpack upgrade or such.

In Pre-Deployment Steps, Step 3 and Step 5:

• Link to AWS links to unknown page
• Link for OpenStack and vSphere resolves to Step 18, but it should resolve to item 18 of Step 4

This documentation seems to indicate that you can set diego cell node max-in-flight values as either an explicit integer value for max-in-flight, or a percentage. In ERT 1.10.21 this does not appear to hold true. OpsManager gives the following error when an integer is used for cell node max-in-flight. Other VM types can use integers without issue. Also, can a note be added here for what specific API call to be making to ops-manager to override this? Searching for it in the docs does point directly to it, just to "product settings", and it's buried in there.

{
  "errors": {
    "max_in_flight": [
      "must be a positive percentage"
    ]
  }
}

https://github.com/cloudfoundry/docs-cf-admin/blob/12.0/securing-traffic.html.md.erb

line 321 "If the Gorouter is the first point of TLS,"

What is meant here? If it is the first TLS termination point (i.e. the load balancer uses 'pass through' mode)?

Perhaps rephrasing to "When terminating TLS at the Gorouter only," is more clear?

Hi,

I can't see in documentation how it's possible to pass parameters to run Dockee image like -p or
-e.

Is it possible to use them ?