Open Stack

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 [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? ;-)
> 
> 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?