[openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes
Ben Nemec
openstack at nemebean.com
Thu Jul 19 23:13:46 UTC 2018
On 07/19/2018 03:37 PM, Emilien Macchi wrote:
> Today I played a little bit with Standalone deployment [1] to deploy a
> single OpenStack cloud without the need of an undercloud and overcloud.
> The use-case I am testing is the following:
> "As an operator, I want to deploy a single node OpenStack, that I can
> extend with remote compute nodes on the edge when needed."
>
> We still have a bunch of things to figure out so it works out of the
> box, but so far I was able to build something that worked, and I found
> useful to share it early to gather some feedback:
> https://gitlab.com/emacchi/tripleo-standalone-edge
>
> Keep in mind this is a proof of concept, based on upstream documentation
> and re-using 100% what is in TripleO today. The only thing I'm doing is
> to change the environment and the roles for the remote compute node.
> I plan to work on cleaning the manual steps that I had to do to make it
> working, like hardcoding some hiera parameters and figure out how to
> override ServiceNetmap.
>
> Anyway, feel free to test / ask questions / provide feedback.
What is the benefit of doing this over just using deployed server to
install a remote server from the central management system? You need to
have connectivity back to the central location anyway. Won't this
become unwieldy with a large number of edge nodes? I thought we told
people not to use Packstack for multi-node deployments for exactly that
reason.
I guess my concern is that eliminating the undercloud makes sense for
single-node PoC's and development work, but for what sounds like a
production workload I feel like you're cutting off your nose to spite
your face. In the interest of saving one VM's worth of resources, now
all of your day 2 operations have no built-in orchestration. Every time
you want to change a configuration it's "copy new script to system, ssh
to system, run script, repeat for all systems. So maybe this is a
backdoor way to make Ansible our API? ;-)
More information about the OpenStack-dev
mailing list