Open Stack

On Wed, 2016-08-17 at 23:42 +0000, Arkady_Kanevsky at DELL.com wrote:
> What is the goal of undercloud?
> Primarily to deploy and manage/upgrade/update overcloud.
> It is not targeted for multitenancy and the only “application”
> running on it is overcloud.
> While it may have a couple of VMs running in undercloud it is more
> convenience than actual need.
>  
> So what are the OpenStack projects need to run in undercloud to
> achieve its primary goal?

Our "TripleO" undercloud only requires a subset of the available
services that we run int the Overcloud. So ironic, heat, mistral,
zaqar, keystone, nova, swift, glance, neutron. These would mostly
satisfy our needs.

>  
> Having robust undercloud so it can handle faults, like node or
> network failures, is more important than being able to deploy all
> OpenStack services on it.

I think we can have all of these things. By using Heat we are a step
closer to an HA undercloud. The fact that we can deploy all the other
services on the undercloud too may seem irrelevant, until it doesn't.
This sort of "everything can be in your undercloud" use case could be
quite cool in fact. I don't think we'd force the idea on anyone though
and if it takes some time for people to warm up to the latter use case
that is fine.

The primary points in doing all this are to help benefit the TripleO
undercloud via code and template re-use. I think this stands on its
own.

Dan

>  
> Arkady
> -----Original Message-----
> From: Dan Prince [mailto:dprince at redhat.com] 
> Sent: Friday, August 05, 2016 6:35 AM
> To: OpenStack Development Mailing List (not for usage questions) 
> Subject: Re: [openstack-dev] [TripleO] a new Undercloud install
> driven by Heat
> 
> On Fri, 2016-08-05 at 12:27 +0200, Dmitry Tantsur wrote:
> > On 08/04/2016 11:48 PM, Dan Prince wrote:
> > > 
> > > Last week I started some prototype work on what could be a new
> way 
> > > to install the Undercloud. The driving force behind this was some
> of 
> > > the recent "composable services" work we've done in TripleO so 
> > > initially I called in composable undercloud. There is an
> etherpad 
> > > here with links to some of the patches already posted upstream
> (many 
> > > of which stand as general imporovements on their own outside the 
> > > scope of what I'm talking about here).
> > > 
> > > https://etherpad.openstack.org/p/tripleo-composable-undercloud
> > > 
> > > The idea in short is that we could spin up a small single process
> > > all-
> > > in-one heat-all (engine and API) and thereby avoid things like 
> > > Rabbit, and MySQL. Then we can use Heat templates to drive the 
> > > Undercloud deployment just like we do in the Overcloud.
> > I don't want to sound rude, but please no. The fact that you have
> a 
> > hammer does not mean everything around is nails :( What problem
> are 
> > you trying to solve by doing it?
> 
> Several problems I think.
> 
> One is TripleO has gradually moved away from elements. And while we
> still use DIB elements for some things we no longer favor that tool
> and instead rely on Heat and config management tooling to do our
> stepwise deployment ordering. This leaves us using instack-undercloud 
> a tool built specifically to install elements locally as a means to
> create our undercloud. It works... and I do think we've packaged it
> nicely but it isn't the best architectural fit for where we are going
> I think. I actually think that from an end/user contribution
> standpoint using t-h- t could be quite nice for adding features to
> the Undercloud.
> 
> Second would be re-use. We just spent a huge amount of time in Newton
> (and some in Mitaka) refactoring t-h-t around composable services. So
> say you add a new composable service for Barbican in the Overcloud...
> wouldn't it be nice to be able to consume the same thing in your
> Undercloud as well? Right now you can't, you have to do some of the
> work twice and in quite different formats I think. Sure, there is
> some amount of shared puppet work but that is only part of the
> picture I think.
> 
> There are new features to think about here too. Once upon a time
> TripleO supported multi-node underclouds. When we switched to
> instack- undercloud we moved away from that. By switching back to
> tripleo-heat- templates we could structure our templates around
> abstractions like resource groups and the new 'deployed-server' trick
> that allow you to create machines either locally or perhaps via
> Ironic too. We could avoid Ironic entirely and always install the
> Undercloud on existing servers via 'deployed-server' as well.
> 
> Lastly, there is container work ongoing for the Overcloud. Again, I'd
> like to see us adopt a format that would allow it to be used in the
> Undercloud as well as opposed to having to re-implement features in
> the Over and Under clouds all the time.
> 
> > 
> > Undercloud installation is already sometimes fragile, but it's 
> > probably the least fragile part right now (at least from my 
> > experience) And at the very least it's pretty obviously debuggable
> in 
> > most cases. THT is hard to understand and often impossible to
> debug. 
> > I'd prefer we move away from THT completely rather than trying to
> fix 
> > it in one more place where heat does not fit..
> 
> What tool did you have in mind. FWIW I started with heat because by
> using just Heat I was able to take the initial steps to prototype
> this.
> 
> In my mind Mistral might be next here and in fact it already supports
> the single process launching idea thing. Keeping the undercloud
> installer as light as possible would be ideal though.
> 
> Dan
> 
> > 
> > > 
> > > 
> > > I created a short video demonstration which goes over some of
> the 
> > > history behind the approach, and shows a live demo of all of
> this 
> > > working with the patches above:
> > > 
> > > https://www.youtube.com/watch?v=y1qMDLAf26Q
> > > 
> > > Thoughts? Would it be cool to have a session to discuss this more
> in 
> > > Barcelona?
> > > 
> > > Dan Prince (dprince)
> > > 
> > >
> ___________________________________________________________________
> > > _______
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:un
> su
> > > bscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > 
> > 
> >
> _____________________________________________________________________
> > _____
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsu
> bs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev