Open Stack

On 7/16/19 12:26 AM, Steve Baker wrote:
> 
> On 15/07/19 9:12 PM, Harald Jensås wrote:
>> On Sat, 2019-07-13 at 16:19 -0400, James Slagle wrote:
>>> On Fri, Jul 12, 2019 at 3:59 PM Harald Jensås <hjensas at redhat.com>
>>> wrote:
>>>> I've said this before, but I think we should turn this nova-less
>>>> around. Now with nova-less we create a bunch of servers, and write
>>>> up
>>>> the parameters file to use the deployed-server approach.
>>>> Effectively we
>>>> still neet to have the resource group in heat making a server
>>>> resource
>>>> for every server. Creating the fake server resource is fast,
>>>> because
>>>> Heat does'nt call Nova,Ironic to create any resources. But the
>>>> stack is
>>>> equally big, with a stack for every node. i.e not N=1.
>>>>
>>>> What you are doing here, is essentially to say we don't create a
>>>> resource group that then creates N number of role stacks, one for
>>>> each
>>>> overcloud node. You are creating a single generic "server"
>>>> definition
>>>> per Role. So we drop the resource group and create
>>>> OS::Triple::{{Role}}.Server 1-time (once). To me it's backwards to
>>>> push
>>>> a large struct with properties for N=many nodes into the creation
>>>> of
>>>> that stack.
>>> I'm not entirely following what you're saying is backwards. What I've
>>> proposed is that we *don't* have any node specific data in the stack.
>>> It sounds like you're saying the way we do it today is backwards.
>>>
>> What I mean to say is that I think the way we are integrating nova-less
>> by first deploying the servers, to then provide the data to Heat to
>> create the resource groups as we do today becomes backwards when your
>> work on N=1 is introduced.
>>
>>
>>> It's correct that what's been proposed with metalsmith currently
>>> still
>>> requires the full ResourceGroup with a member for each node. With the
>>> template changes I'm proposing, that wouldn't be required, so we
>>> could
>>> actually do the Heat stack first, then metalsmith.
>>>
>> Yes, this is what I think we should do. Especially if your changes here
>> removes the resource group entirely. It makes more sense to create the
>> stack, and once that is created we can do deployment, scaling etc
>> without updating the stack again.
> 
> I think this is something we can move towards after James has finished this 
> work. It would probably mean deprecating "openstack overcloud node provision" 
> and providing some other way of running the baremetal provisioning in isolation 
> after the heat stack operation, like an equivalent to "openstack overcloud 
> deploy --config-download-only"
> 
> 

I'm very much against on deprecating "openstack overcloud node provision", it's 
one of the reasons of this whole effort. I'm equally -2 on making the bare metal 
provisioning depending on heat in any way for the same reason.

Dmitry