Open Stack

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.

-Ben

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 [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?
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev