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
