Open Stack

On 16.07.2019 9:34, Dan Sneddon wrote:
> On Tue, Jul 16, 2019 at 12:19 AM Dmitry Tantsur <dtantsur at redhat.com 
> <mailto: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 <mailto: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.

As it was earlier mentioned in the thread, we'll highly likely need some 
external data store to migrate/upgrade things out of Heat smoothly. That 
probably should be etcd? I don't think a clever ansible inventory could 
handle that fully replacing such a data store.

> 
> --
> Dan Sneddon


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando