Hi Mike,

A few extra discoveries and notes, both icehouse and havana aren't including the admin_hosts override after the install. I need to re-import the puppet classes, override the admin_hosts variable in the controller/compute sections and then update the variable in the hostgroup settings. I'm confused, why this is used if there's already priv and pub host.

Further notes inline.

On Mon, Mar 17, 2014 at 2:53 AM, Mike Orazi <morazi@redhat.com> wrote:
Andrew,

See a few comments inline below, but first thanks for giving the foreman
installer a shot.  It looks like you have had a good amount of success
and made some good discoveries along the way!

I really appreciate the fact that you have gotten so far & the feedback
on areas where you are running into issues.

Thanks,
Mike



On 03/16/2014 08:02 AM, Andrew Lau wrote:
> Hi all,
>
> So far, I've been successful with the following setup on havana, but
> icehouse had issue as below:
> 1x Controller
> 2x Compute + Network + Gluster
>
> I forked the astapor repo so I can run the compute + networker in the
> same module, along with a few other tweaks. [1]
>

Nice -- this is one variation that a lot of people seem interested in.
We'd probably have to give some thought on how to fold things together
but I bet it would be a good candidate for further discussion and
potential inclusion at some point in the future.

It would be a nice concept if the modules could be integrated as nested hostgroups, it would just be a matter of having to some how remove the duplicate class calls when they get nested.

 

> So far everything is working, I plan on uploading my notes in a few days
> but I've run into a few issues which I'm hoping someone could help:
>
> - When using the icehouse repo, the controller hostgroup will install
> but httpd will fail with 'no listening sockets available, shutting down,
> Unable to open logs'. There were no selinux denies, or anything else in
> the log files.

The "Listen 0.0.0.0:80" in /etc/http/conf/httpd.conf some how does not get added, I noticed in the  havana modules, it would keep removing and adding this. I recall seeing somewhere this related to puppetlabs/apache. So havana it works, icehouse no..
 
>
> - >From a brief look at the manifest and trial and error, it looks like
> the ml2 plugin does have some support in the quickstack files. It
> however fails at the neutron-db-manage. Manual steps: [2]
> Error Output: [3]

The team has been working to track down the remaining issues in
neutron-db-manage.  John Eckersberg (added to the message to make sure
he sees this) is eck or jeckersb on irc and is likely a good person to
coordinate with in terms of the foreman side of the equation.  He has
been working with some neutron folks to try to run this down.

I look forward to hearing from him.
 

>
> I'm aware there's a few new projects going on to bridge the foreman and
> rdo integration, I like the current foreman setup because it's very
> customizable, but the key flaws are too many options. ie. if I'm using
> VLANs, I don't want to see tunnel options etc.
>

Yes!  A lot of the present work can be broken down into 2 bits.  The
quickstack work proper to make several reasonably easy to deploy cloud
examples + a good amount of usability work that is presently just
getting started to help weave things together a lot more elegantly for
end-user consumption.  A lot of the "I'm using VLAN please don't bother
showing me params that apply only to tunnel solutions" falls into that
latter set of work.


> Thanks,
> Andrew.
>
> [1] https://github.com/andrewklau/astapor
> [2] http://openstack.redhat.com/ML2_plugin
> [3] http://www.fpaste.org/85834/94970823/
>
>
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>