Pawel, I'm not sure that it's common at all to move the deployed cloud. Hopefully fuel made it easy enough to deploy that you could simply reset the cluster and re-deploy with the new network settings. I'd be interested in understanding why this would be more painful than re-configuring the public network settings.
Things that need to be changed: all of the keystone public endpoints all of the config files using the public endpoints, so anything that speaks with another endpoint (usually nova [compute & controller], neutron, possibly others) corosync config for public vip (6.0) corosync config for ping_public_gw host-os nic settings ie /etc/networking/interfaces.d/ now with all that said, I think rather than updating these by hand, we could get puppet to update these values for us. The non-repeatable way is to hack on /etc/astute.yaml and then re-apply puppet (/etc/puppet/manifests/site.pp for each "role: " you would have had for /etc/astute.yaml the more-repeatable way is to hack out the public range in the nailgun database, as well as replace the public_vip value once these are changed, you should be able to manually apply puppet using the deploy api (fuelclient can call this) 'fuel --env 1 --node 1,2,3 --deploy' I've never done this before, but it should be that simple, and puppet will re-apply based on the current value in the database (as long as you didn't upload custom node yaml prior to your initial deployment) On Sat, Dec 20, 2014 at 11:27 AM, Skowron, Pawel <pawel.skow...@intel.com> wrote: > -Need a little guidance with Mirantis version of OpenStack. > > > > We want move freshly deployed cloud, without running instances but with HA > option to other physical location. > > The other location means different ranges of public network. And I really > want move my installation without cloud redeployment. > > > > What I think is required to change is public network settings. The public > network settings can be divided in two different areas: > > 1) Floating ip range for external access to running VM instances > > 2) Fuel reserved pool for service endpoints (virtual ips and staticly > assigned ips) > > > > The first one 1) I believe but I haven't tested that _is not a problem_ but > any insight will be invaluable. > > I think it would be possible change to floating network ranges, as an admin > in OpenStack itself. I will just add another "network" as external network. > > > > But the second issue 2) is I am worried about. What I found the virtual ips > (vip) are assigned to one of controller (primary role of HA) > > and written in haproxy/pacemaker configuration. To allow access from public > network by this ips I would probably need > > to reconfigure all HA support services which have hardcoded vips in its > configuration files, but it looks very complicated and fragile. > > > > I have even found that public_vip is used in nova.conf (to get access to > glance). So the relocation will require reconfiguration of nova and maybe > other openstack services. > > In the case of KeyStone it would be a real problem (ips are stored in > database). > > > > Has someone any experience with this kind of scenario and would be kind to > share it ? Please help. > > > > I have used Fuel 6.0 technical preview. > > > > Pawel Skowron > > pawel.skow...@intel.com > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Andrew Mirantis Ceph community _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
