Open Stack

On Tue, Jul 16, 2019 at 12:19 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.
>
> Dmitry
>
>
My concerns about network ports boil down to technical debt with Heat. It
would be great if we can make the individual nodes completely independent
of Heat, and somehow migrate from the old Heat-based definition for
upgrades.

--
Dan Sneddon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190716/4a4194dd/attachment-0001.html>