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:
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
On Fri, Jul 12, 2019 at 3:59 PM Harald Jensås <hjensas@redhat.com> wrote: 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