On 08/04/2016 01:26 PM, Christian Schwede wrote:
On 04.08.16 10:27, Giulio Fidente wrote:
On 08/02/2016 09:36 PM, Christian Schwede wrote:
Hello everyone,
thanks Christian,
I'd like to improve the Swift deployments done by TripleO. There are a
few problems today when deployed with the current defaults:
1. Adding new nodes (or replacing existing nodes) is not possible,
because the rings are built locally on each host and a new node doesn't
know about the "history" of the rings. Therefore rings might become
different on the nodes, and that results in an unusable state eventually.
one of the ideas for this was to use a tempurl in the undercloud swift
where to upload the rings built by a single overcloud node, not by the
undercloud
so I proposed a new heat resource which would permit us to create a
swift tempurl in the undercloud during the deployment
https://review.openstack.org/#/c/350707/
if we build the rings on the undercloud we can ignore this and use a
mistral action instead, as pointed by Steven
the good thing about building rings in the overcloud is that it doesn't
force us to have a static node mapping for each and every deployment but
it makes hard to cope with heterogeneous environments
That's true. However - we still need to collect the device data from all
the nodes from the undercloud, push it to at least one overcloud mode,
build/update the rings there, push it to the undercloud Swift and use
that on all overcloud nodes. Or not?
sure, let's build on the undercloud, when automated with mistral it
shouldn't make a big difference for the user
I was also thinking more about the static node mapping and how to avoid
this. Could we add a host alias using the node UUIDs? That would never
change, it's available from the introspection data and therefore could
be used in the rings.
http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_specific_hieradata.html#collecting-the-node-uuid
right, this is the mechanism I wanted to use to proviude per-node disk
maps, it's how it works for ceph disks as well
2. The rings are only using a single device, and it seems that this is
just a directory and not a mountpoint with a real device. Therefore data
is stored on the root device - even if you have 100TB disk space in the
background. If not fixed manually your root device will run out of space
eventually.
for the disks instead I am thinking to add a create_resources wrapper in
puppet-swift:
https://review.openstack.org/#/c/350790
https://review.openstack.org/#/c/350840/
so that we can pass via hieradata per-node swift::storage::disks maps
we have a mechanism to push per-node hieradata based on the system uuid,
we could extend the tool to capture the nodes (system) uuid and generate
per-node maps
Awesome, thanks Giulio!
I will test that today. So the tool could generate the mapping
automatically, and we don't need to filter puppet facts on the nodes
itself. Nice!
and we could re-use the same tool to generate the ceph::osds disk maps
as well :)
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
