On 7/16/19 2:25 PM, James Slagle wrote:
On Tue, Jul 16, 2019 at 3:23 AM Dmitry Tantsur <dtantsur@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:
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.
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.