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.

> 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.

> > - >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'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(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list >

Andrew Lau <andrew(a)andrewklau.com&gt; writes: > - 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] > > [1] https://github.com/andrewklau/astapor > [2] http://openstack.redhat.com/ML2_plugin > [3] http://www.fpaste.org/85834/94970823/ I haven't tried Foreman+ML2 on Icehouse yet, but I've seen several weird database issues caused by tables using the myisam engine instead of innodb. A quick workaround to try is... cat <<EOF > /etc/mysql/conf.d/innodb.cnf [mysqld] default-storage-engine = innodb EOF service mysqld restart mysql -e 'drop database neutron; create database neutron;' Then rerun neutron-db-manage. That'll default all the tables to use innodb. The 1000 byte key length limit is a constraint of MyISAM. InnoDB has a similar constraint but it appears more generous. How many bytes a field actually takes up in the key length seems to depend on the encoding and maybe some other stuff that I'm not sure offhand. However this test shows switching engines very well may fix that particular error: mysql> create table test (field1 VARCHAR(512) NOT NULL, field2 VARCHAR(512) NOT NULL, PRIMARY KEY(field1, field2)) ENGINE=MyISAM; ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes mysql> create table test (field1 VARCHAR(512) NOT NULL, field2 VARCHAR(512) NOT NULL, PRIMARY KEY(field1, field2)) ENGINE=InnoDB; Query OK, 0 rows affected (0.04 sec)

Andrew Lau <andrew(a)andrewklau.com&gt; writes: > Hi John, > > Thanks for that suggestion, it got me passed that first step and into > another error :D > sqlalchemy.exc.ProgrammingError: (ProgrammingError) (1146, "Table > 'neutron_ml2.agents' doesn't exist") 'ALTER TABLE agents ADD CONSTRAINT > uniq_agents0agent_type0host UNIQUE (agent_type, host)' () > > Which seems to be very similar to this BZ here: > https://bugzilla.redhat.com/show_bug.cgi?id=1061378 Yep, I ran across that today as well. https://bugzilla.redhat.com/show_bug.cgi?id=1017281#c30 That one-line patch fixes the agents table.