On Fri, 2016-08-05 at 13:39 +0200, Thomas Herve wrote: > On Thu, Aug 4, 2016 at 11:48 PM, Dan Prince <dpri...@redhat.com> > 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. > I saw those patches coming, I'm interested in the all-in-one > approach, > if only for testing purpose. I hope to be able to propose a solution > with broker-less RPC instead of fake RPC at some point, but it's a > good first step. > > I'm a bit more intrigued by the no-auth patch. It seems that Heat > would rely heavily on Keystone interactions even after initial > authentication, so I wonder how that work. As it seems you would need > to push the same approach to Ironic, have you considered starting > Keystone instead? It's a simple WSGI service, and can work with > SQLite > as well I believe.
You are correct. Noauth wasn't enough. I had to add a bit more to make OS::Heat::SoftwareDeployments happy to get the templates I showed in the demo working. Surprisingly though if I avoid Heat OS::Heat::SoftwareDeployments and only used OS:Heat::SoftwareConfig's in my templates no extra keystone auth was needed. This is because heat only creates the extra Keystone user, trust, etc. when realizing the software deployments I think. I started with this which should work for multiple projects besides just Heat: https://review.openstack.org/#/c/351351/2/tripleoclient/fake _keystone.py I'd be happy to swap in full Keystone if people prefer but that would be more memory, and setup. Keystone dropped it's eventlet runner recently so we'd have to fork another WSGI process to run it I think somewhere in an out of the way (non-default ports, etc) fashion. I was trying to keep the project list minimal so I went and stubbed in only what was functionally needed for this here with an eye that we'd actually (at some point) make heat support true noauth again. Dan > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev