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

Hi Rohit, Following steps followed :- * git clone https://github.com/cloudfoundry/cf-release.git * root(a)vms-inception-vm-2:/opt/cisco/vms-installer/cf-release/scripts# ./update

Can you also list the commands on how you are creating, uploading and deploying the release? jayark(a)cisco.com> wrote:

Thanks a lot Rohit for replying back very quickly! I have run the scripts/update command after cloning the cf-release GIT repo. Please see the command output

Hey Jeff, Can you describe the burden you're feeling from the monolithic deployment? We are actively working on splitting up *cf-release* into multiple smaller, reusable, composable *releases*, but

Openstack, cf 230 Following a manifest for 225, routing-api is part of the api_z instance. Generating the manifest for 230, routing-api is not included. Following on what worked, I added it. Api

that looks pretty good. i'd probably change the following: 8) Stop jobs on old database cluster 9) Validate CF is working and connected to new database 10) Validate old database files are not changed

Did you make sure to run "scripts/update" after cloning the cf-release repo? Can you run "find . -type d -maxdepth 2" from within the "src/loggregator" directory in cf-release and reply with what you

Thank you, Filip. Your information makes the situation clear. Now our team can go to the next step considering how to cope with the situation. Filip Hanik wrote ----- I'm not a ... noburou

Thanks, it worked! however the results (attached) does not show the precise start time of individual containers... For example the app "bend" goes directly from 16 instances to 26. I wanted to study

Yes, Keystone support was intentionally removed. There were no contributions, and the keystone repository kept changing making our continuous integration pipeline break, and there was no one

I suspect you're running into this: https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#file-permission-modes What version of cf are you using? What is

Many thanks for the invitation

Thanks, I guessed this would be the recommendation. I was slightly surprised there is no function for this built in. The suggestion about adding routes In a system domain is good too although do you