[openstack-dev] [Fuel] Relocation of freshly deployed OpenStack by Fuel
Andrew Woodward
xarses at gmail.com
Tue Dec 23 23:59:09 UTC 2014
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.skowron at 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.skowron at intel.com
>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Andrew
Mirantis
Ceph community
More information about the OpenStack-dev
mailing list