While it is possible to change the CloudBees Core domain name using kubectl, the change would be overwritten during an upgrade. Thus, domain name should be exposed as an optional parameter.

Once added, existing users should be able to fill in this parameter during their next upgrade. If the domain name was already changed using kubectl then there should be no effect on the environment.

For new installations, if a domain name is entered, then CloudBees Core won't be accessible until a CNAME is created which maps the domain name to the ELB.

Section heading:
Documentation issue description:
stack is failing with S3 Putpolicy error. This is not helping us to build environment at all

The annotations on ingress/cjoc:
https://github.com/aws-quickstart/quickstart-cloudbees-core/blob/master/templates/cloudbees-core-workload.template.yaml#L315-L323

Are not applied to the cluster during deployment:

[ec2-user@ip-10-0-152-53 ~]$ kubectl get ingress
NAME      HOSTS                                                                    ADDRESS   PORTS     AGE
cjoc      a5a069efd06ff11eaa5b60add6ba1aaf-151001025.us-east-1.elb.amazonaws.com             80        65m
[ec2-user@ip-10-0-152-53 ~]$ kubectl describe ingress cjoc
Name:             cjoc
Namespace:        default
Address:
Default backend:  default-http-backend:80 (<none>)
Rules:
  Host                                                                    Path  Backends
  ----                                                                    ----  --------
  a5a069efd06ff11eaa5b60add6ba1aaf-151001025.us-east-1.elb.amazonaws.com
                                                                          /cjoc   cjoc:80 (<none>)
Annotations:
  kubectl.kubernetes.io/last-applied-configuration:  {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{},"name":"cjoc","namespace":"default"},"spec":{"rules":[{"host":"a5a069efd06ff11eaa5b60add6ba1aaf-151001025.us-east-1.elb.amazonaws.com","http":{"paths":[{"backend":{"serviceName":"cjoc","servicePort":80},"path":"/cjoc"}]}}]}}

Events:  <none>
[ec2-user@ip-10-0-152-53 ~]$

This issue is known to cause problems with the CLI (jenkins-cli.jar) in a default installation.

The issue is resolved by applying the annotations in the aforementioned link manually using kubectl edit ingress cjoc. Then find the ingress controller pod using kubectl get po -n ingress-nginx and delete (restart) it.

The CLI specifically needs the following annotation to function properly:
nginx.ingress.kubernetes.io/proxy-request-buffering: off

Hi Team,

I’m trying to use your quick start guide templates to set up cloudbees ci in my environment.

I’m using this template( https://github.com/aws-quickstart/quickstart-cloudbees-ci/blob/main/templates/cloudbees-ci-workload.template.yaml ) to deploy jenkins into an existing cluster.

After jenkins set up I’m looking to deploy ssl Certs into jenkins url via cloudformation template but this quick start guide doesn’t provide that template.

cloudbees has ssl steps from below link which cannot be automated via cft. Do you have any way deploy ssl certs using cft please let me know
https://docs.cloudbees.com/docs/cloudbees-ci/2.235.2.3/cloud-admin-guide/kubernetes-self-signed-certificates#_installing_self_signed_certificates_on_kubernetes

I am running stack and its failing with below error.
Any workaround ?

ArtifactCopyPolicy | CREATE_FAILED | API: s3:PutBucketPolicy Access Denied

When deploying to a fresh VPC I get this error in SpotAgentNodesStack:

Template error: Unable to get mapping for K8sVersionMap::1.13::STD

It looks like 1.13 needs to be added to the mapping below, and 1.10 should be dropped since it's no longer supported in the amazon-eks-nodegroup template.

https://github.com/aws-quickstart/quickstart-cloudbees-core/blob/3c13ac9a7514691b166d727971761c5f21713603/templates/cloudbees-core-spot-nodes.template.yaml#L439-L448.

After ce0d5a7, this appears in controller logs:

2021-01-21 13:32:49.407+0000 [id=36]	WARNING	o.c.j.p.k.KubernetesCloud#provision: Failed to count the # of live instances on Kubernetes
io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: GET at: https://10.100.0.1/api/v1/namespaces/default/pods?labelSelector=jenkins%3Dslave. Message: Forbidden!Configured service account doesn't have access. Service account may have been revoked. pods is forbidden: User "system:serviceaccount:default:jenkins" cannot list resource "pods" in API group "" in the namespace "default".
	at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestFailure(OperationSupport.java:589)
...

To fix the problem, add this to the Kubernetes Shared Cloud item in Operations Center:

We expect a fix to be released in February which automatically configures this field.

Issue

When tying to deploy to an existing EKS cluster using template cloudbees-core-existing-cluster.template.yaml the OPTIONAL parameter LambdaZipsBucketName is used unconditionally in Custom::CopyZips and all AWS::Lambda::Function resources.

While condition CreateLambdaZipsBucket based on presence of LambdaZipsBucketName is effectively used to create an S3 bucket, this bucket is never actually used.

Python 2.7 is EOL in January 2020. We need to upgrade the CopyZips function prior to then.