BOSH data migrate and version upgrade

[ShaoFeng Shi]

Hello bosh_dev group, 

I'm new in BOSH but I face two issues now; if anyone can give some advice to me that will be much appreciated!

We use a microbosh managing a cloud foundry; as the cf grows, we hope we can switch to a distributed bosh to manage those vms (keep the vms as much as possible, not re-build from scratch); did someone successfully make this happen? is it easy to migrate from microbosh to bosh?

Another issue is, the stemcell that our cf built on is old; Now we build a new stemcell with a new version of bosh agent built-in, while the agent in the new stemcell may not be compatible with the microbosh director that we're using; in this case, how can I proceed this upgrade? 

Many thanks for any suggestion or comment!

[Dr Nic Williams]

There are three pieces of persistent data for your future migration:

* the postgres database

* redis (task queue) - unsure if any permanent data is stored there or if it's just the todo list of task items

* blobstore

Firstly I'd choose a remote blobstore today - swift, Ceph, AWS s3. It's probably the hardest to migrate all the blobs from a microbosh local blobstore to a remote one.

The postgres & Redis DBs are just databases which can be moved and restarted.

I _hope_ that any configuration relating to the bosh is purely loaded from static config and isn't duplicated in the postgres DB. If it is, it will need changing too after migration. But I doubt that this is an issue. 

If you're using Internal PowerDNS, then your future bosh may have a different root domain (.microbosh -> .bosh) and all your deployments might start having DNS issues. They'll need fixing and redeploying to get the new DNS hostnames.

To unsubscribe from this group and stop receiving emails from it, send an email to bosh-dev+u...@cloudfoundry.org.

[Dr Nic Williams]

The ruby agent hasn't changed in ages. I assume no changes since they started work on the go agent 6 months ago. Newer stemcells hopefully only have kernel/security improvements and not compatibility issues.

On Wed, May 7, 2014 at 7:39 AM, ShaoFeng Shi <shaof...@gmail.com> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to bosh-dev+u...@cloudfoundry.org.

[Dr Nic Williams]

My point - sorry for not having one - is that I think that many versions of the director probably work with many versions of the stemcells.

[Greg Oehmen]

Yes.  I agree with Dr. Nic here.  The intention is to maintain as much backward compatibility between director/stemcell versions as possible.

Greg Oehmen

Cloud Foundry Product Manager - Bosh

Pivotal

[ranchuan ran]

Hi Dr. Nic, Greg,

I am also interested in the topic that Shao Feng brought up. Here I have some questions on this. Thanks for your time in advance!

1. Does that mean a newer version director should be compatible with an older stemcell(ruby-agent)?

2. @Dr. Nic, => I _hope_ that any configuration relating to the bosh is purely loaded from static config and isn't duplicated in the postgres DB,  I don't quite follow your idea here, can you give an example on some configurations here? What do you mean by "duplicated"? If it is a pure postgresql DB of the DBOSH, there would be no possibility of "duplicated", right?

Thanks!

[Dr Nic Williams]

Things deployed by BOSH, including BOSH itself, are configured via static config files or (via flags/env variables in the monit start scripts... and those start scripts are also static, so its all static files). Those things - called processes - might then take this initial configuration (from files, env vars or command line flags) and store it in memory and use it to configure itself.

Some apps/processes might be implemented to take this configuration as pure seed config - initial starting point configuration - and ultimately the end users can reconfigure the process. Take wordpress - it has a default theme, defaults to asking the first user to create an account, etc. After that, wordpress itself starts collecting configuration data. Now, the app/process and the static configuration diverge.

If you were to migrate a wordpress app - you would have to move the mysql database AND possible actually change configuration within the mysql database. The configuration isn't just in static files anymore.

So I'm not sure if BOSH has any configuration in it that would need to be migrated after you upgraded the data from .microbosh to a full bosh. I _think_ all the data in its postgres/redis/blobstores is independent of which bosh is actually running it.

--

Dr Nic Williams

Stark & Wayne LLC - consultancy for Cloud Foundry users

http://drnicwilliams.com

http://starkandwayne.com

cell +1 (415) 860-2185

twitter @drnic

[ShaoFeng Shi]

Hi Dr. Nic and Greg, Thanks for your comment!

I have migrated the data (postgres, blobstore, powerdns) from the microbosh to the distributed bosh; At the first, the bosh couldn't show the vms status; I realized the cf vms still connects with the nats/blobstore/powerdns of the microbosh; then I use a script to replaced the addresses in /var/vcap/bosh/setting.json, user_data.json and /etc/resolv.conf, after that the vms can show up in the new bosh. I'm testing other functions like bosh deploy and got some problem which is under investigation. I had thought it might be agent compitable issue now I know it should be not. Your suggestion on the configuration is nice and I will double check that.

Regarding the PowerDNS, after move from microbosh to distributed bosh, I didn't change the domain name, I see the new PowerDNS can resolve the old domain names that ended with .microbosh (like 0.data.xxxx.microbosh) and I hope to keep them, will this be a problem?

Thanks for your comment!

Shao Feng, Shi

在 2014年5月8日星期四UTC+8上午12时00分06秒，Dr Nic Williams写道：