[openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes
openstack at nemebean.com
Fri Jul 20 18:54:49 UTC 2018
Okay, based on a private conversation this is coming off as way more
troll-ish than I intended. I don't understand where this work is going,
but I don't really need to so I'll step back from the discussion.
Apologies for any offense.
On 07/20/2018 12:20 PM, Ben Nemec wrote:
> On 07/20/2018 01:18 AM, Bogdan Dobrelya wrote:
>> On 7/20/18 2:13 AM, Ben Nemec wrote:
>>> On 07/19/2018 03:37 PM, Emilien Macchi wrote:
>>>> Today I played a little bit with Standalone deployment  to deploy
>>>> a single OpenStack cloud without the need of an undercloud and
>>>> 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:
>>>> 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? ;-)
>> Ansible may orchestrate that for day 2. Deploying Heat stacks is
>> already made ephemeral for standalone/underclouds so only thing you'll
>> need for day 2 is ansible really. Hence, the need of undercloud
>> shrinks into having an ansible control node, like your laptop, to
>> control all clouds via inventory.
> So I guess the answer to my last question is yes. :-)
> Are we planning to reimplement all of our API workflows in Ansible or
> are users expected to do that themselves?
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev