Hi Nanduni, Currently there's no way to push a Dockerfile that I'm aware of. Your best bet (assuming you can't push your image to Docker Hub) is to run a Docker registry locally. This can be done

Hi all, Is there any way for pushing Dockerfiles to Cloud Foundry instead of using publicly available Docker images in Docker Hub? Actually my requirement is to run some artifacts[1] in MicroPCF or

Hi, Is there any way to push a Dockerfile and start an application instead of pushing a publicly available docker image in Cloud Foundry. The problem is that I want to run some Docker images on Cloud

Hi, Daniel CF:230 Diego: 0.1441.0 Garden-linux: 0.327.0 I ran “chmod a+x *” under my application’s “bin” folder and then zip all files. The command for starting application is

Thanks Amit, to have odd number of cluster size , we have added 4 new members in the new deployment. now the plan is to remove the old 3 member + 1 member in new deployment. , but while doing this ,

Orchestrating the etcd cluster is fairly complex, and what you're describing is not a recommended usage. I'm not sure why you need a new 4 node cluster (why not just use the existing 3-node cluster?

Hi Amit, Thanks for taking time to respond. actually we are maintaining deployment manifest templates and from there we are generating each components manifest using spruce. So there by we are

Hi Lingesh, I don't think easier deployment and maintenance is that simple. Each manifest may become smaller, but now you have to maintain multiple small manifests. And keep them in sync. And make

Hi Amit The main advantage that we are targeting is to reduce deployment time for any changes in the cloud foundry. The advantages include but not limited to * Target specific components for changes *

Hi Jayaraj, Yes, you need to generate a new manifest for each upgrade of a CF version. Properties might be added, jobs may change, new resource pools may be required, older ones may be removed, etc

Hi Rohit, We did not generate a fresh manifest for the CF version 230. We had a manifest file which is used for deploying CF version 205. Do we need to generate the manifest file for each CF release?

Those properties are used to specify the etcd machines to loggregator. Those typically get auto-filled by spiff and you don't need to specify them explicitly in the properties section [1]. Did you not

Hi Rohit, I added the cloud_controller IP for the below property and I am running into the below exception now:- Started preparing configuration > Binding configuration. Failed: Error filling in

Thanks for the feedback. I've updated my plans with those steps which should help make it safer to verify the migration did work.

I believe in the long run the current work being done in BOSH around AZ and links will get rid of this problem for us, but I have to figure out a way to upgrade in the interim. My main goal currently

Thanks Rohit! That worked for metro_agent issue. Now running into the following issue after filling the property you mentioned. Started preparing configuration > Binding configuration. Failed:

OK cool. The error which you are getting now is different from what you had originally posted. You need to include the following property in your deployment and it should get fixed: properties:

Hi Tom, The only features that the routing-api currently provides are all experimental, mostly related to registering HTTP and TCP routes. This means that it is not necessary at all for a working

Hi Rohit, Please see the output:- root(a)vms-inception-vm-2:/opt/cisco/vms-installer/tenant-vmsdev5control/cf-deploy# bosh -n deploy Acting as user 'admin' on deployment 'cf-vmsdev5control' on

Hi Surendhar, May I ask why you want to split the deployment into multiple deployments? What problem are you having that you're trying to solve by doing this? Best, Amit