Open Stack

On 7/16/19 2:25 PM, James Slagle wrote:
> On Tue, Jul 16, 2019 at 3:23 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>>
>> 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.
> 
> I think what's being proposed here is just that we'd change the
> ordering of the workflow in that we'd do the Heat stack first.
> 
> That being said, I see the lack of dependency working both ways.
> Baremetal provisioning should not depend on Heat, and Heat should not
> depend on baremetal provisioning. You should be able to create the
> Heat stack without the servers actually existing (same as you can do
> today with pre-provisioned nodes).
> 

Right, and we should be able to provision bare metals without pre-creating heat 
stack.. and then I don't understand why we want to change the current proposal.