Does anyone have a step by step list for building MIQ on a RHEL 6 box?
This is what I used to get manageiq started:
First make sure you have the following channel enabled:
As root Build the miqbuilder user
useradd miqbuilder passwd miqbuilder
Download and install the epel package
wget http://mirror.nexcess.net/epel/6/i386/epel-release-6-8.noarch.rpm yum -y install epel-release-6-8.noarch.rpm
miqbuilder should be set to use sudo
Add the line to /etc/sudoers:
miqbuilder ALL=(ALL) ALL
yum -y install git yum -y install libxml2-devel yum -y install libxslt libxslt-devel yum -y install postgresql-server postgresql-devel yum -y install memcached
service memcached start chkconfig memcached on
Initialize the db
service postgresql initdb
/var/lib/pgsql/data/pg_hba.conf, comment out everything and add the following line:
local all all trust
/var/lib/pgsql/data/postgresql.conf and add
Start the db
service postgresql start
Log in as postgres generate the databases and the user. Then assign the
su - postgres for i in test production development;do createdb vmdb_$i;done psql -c "create role evm login password 'smartvm'" psql -c "alter database vmdb_development owner to evm"
Ctrl-D Out to root again. Log in as miqbuilder
su - miqbuilder
I use rvm for development environment
\curl -sSL https://get.rvm.io | bash -s stable source ~/.profile rvm install 1.9.3
CTRL-D out and log back in as miqbuilder. This will allow the rvm environment to load.
su - miqbuilder rvm --default use 1.9.3
Install the bundler we will be using
gem install bundler -v '1.3.5'
Get rid of the new version of bundler because we can only use version 1.3.5
gem uninstall -i /home/miqbuilder/.rvm/gems/ruby-1.9.3-p547@global bundler -v '1.6.2'
Clone the ManageIQ repo.
cd manageiq/vmdb bundle install --without qpid
Some places don’t allow the of git:// so you may have to…
git config --global url."https://".insteadOf git://
###Why does this next part have to be done???
cd .. vmdb/bin/rake build:shared_objects cd vmdb
This again to install
bundle install --without qpid
Edit the config/database.pg.yml file. Add the evm user for the vmdb_develeopment database.
Initialize the database and start the service.
bin/rake db:migrate bin/rake evm:start
Access manageiq at
Is there a getting started guide for developers?
Thanks! Those steps worked great!
Shouldn’t that be
listen_addresses = '*'?
The “–without qpid” is due to a recent issue which people were having building the qpid gem - not sure exactly what the issue was.
I understand about the
I dont understand why the below is not built during the first
bundle install --without qpid
If you don’t go back down one directory and don’t
../rake build:shared_objects, then if you try the
bin/rake db:migrate, you get an error. To correct it I need to do the following to build that and then it works. Why?
I also had an issue with the first rvm install - it installs sudo but behind the scenes, and it blocks waiting for the user to enter a root password we haven’t set at this point.
It’s strange, because sudo is installed, I use it to become root beforehand. The way I got around it was to set a root password in a root prompt with passwd, and re-enter that password in the “rvm install” terminal.
I figured this out - it is because sudo was getting updated. So updating sudo to the latest version should be a prerequisite before running rvm the first time.
And, to answer your question, I have no idea why you might need to run it a second time. Not a very good answer, but…
<code> </code> is inline, not a block (compare to the defaults of
Since this site supports Markdown, the best way to mark code inline is with backticks and codeblocks blocks is with GitHub style code fences comprised of backticks.
`code here` (you can still use
<code> </code> for this, but backticks are easier and cleaner, so they’re preferred when writing Markdown.
Code block example:
``` your code here ```
You can (usually) specify the language too, such as
```bash #!/bin/bash echo "hello world" ````
This is rendered as:
#!/bin/bash echo "hello world"
…but specifying the language is optional, and there will often be a “best effort”.
Noteworthy: Four spaces
It’s also worth noting that adding four spaces in front of text without having it following a list item will indicate that it’s to be preformatted as well.
However, It doesn’t support syntax highlighting and looks a bit uglier. (See the first two blocks as examples of this. That’s how I showed a block in a block.)
So, instead of using four spaces in front of each line, you should try to use the backtick code fences.
Sounds like setting up a dev environment is pretty non-trivial. Do you know if anyone has looked into setting up vagrant  for the miq project?
Have a look at the “Installing and deploying from source” page linked from Community on the site.
There is a Kickstart file linked from there which automates much of the work for you.
Would people object to a Docker image with ManageIQ + PostgreSQL 9.3?
If not, how hard and fast is the Ruby 1.9.3 requirement?
I think that’d be great! I don’t know what kind of constraints there would be on performance. @Fryguy, @jrafanie, do either of you have any insight into how easy/difficult it would be to dockerize ManageIQ?
@mikaelhg ruby 1.9.3 is what we currently run and test against. Ruby 2.0/2.1 should not be difficult to get to but we have to update/audit any gems that break on 2.0, such as default_value_for. Ruby 1.8.7 was unsupported by upstream a long time ago and we make no effort to maintain compatibility since 1.8.7-> 1.9.3 is a huge change.
Regarding docker, I’m not opposed to it if we can provide reliable images. I have no background with docker but nearly everything we do to produce images in the 3 flavors is found here
The entire manageiq/build directory contains everything we use to produce these images although the above base kickstart is 99% of what you’d need.
Imagefactory, the tool we use to produce the appliance images appears to have support for docker through plugins so I’d imagine it’s very possible:
Started the work at https://github.com/mikaelhg-docker/manageiq - getting the dependencies working, then the app.
That qpid_messaging 0.20.2 gem is a pain in the ass to package.
If you need to patch it to get your own RPMs built, why not provide the gem as a Git repository that actually builds?
Note, the qpid package specifically was a pain to get working as I had to package the needed qpid client devel package which was not available on centos. I packaged them and some other ruby gem packages and use them in the kickstart here: https://github.com/ManageIQ/manageiq/blob/master/build/kickstarts/base.ks.erb#L11
Is it important to have the explicit dependency to the Qpid gem, from a Red Hat product management sense, or would a dependency to a generic AMQP 1-0 gem work just as well?
@blomquisg might be able to answer your question better.
I think there were problems with a general approach because of incompatibilities in AMQP protocol support. For example RabbitMQ is based on AMQP 0.9 and Qpid is based on AMQP 0.10, but Qpid does not support anything backward compatible to 0.9. At least that’s the way it was last time we checked.
tl;dr, @Fryguy’s right, incompatible versions of AMQP require us to have separate gems for Rabbit and Qpid support.
AMQP support is tricky when we have to support more than one implementation. Since we’re talking to OpenStack’s AMQP service, we have to be able to deal with multiple AMQP implementations. For the moment we support RabbitMQ and QPid.
Unfortunately with AMQP, the protocol is not exactly backwards compatible between versions. In fact, both implementations (RabbitMQ and Qpid) go out of their way to explicitly restrict incompatible versions. And, since Rabbit implements 0.9 and QPid implements 0.10, the two implementations are incompatible.
This means that there’s no simple AMQP gem that can be used. In fact, you may find a gem called “amqp”, but it’s actually only supporting Rabbit’s implementation and will not work with Qpid.
As it stands, the qpid_messaging gem is the only gem that provides current Ruby bindings for the Qpid AMQP implementation.
Regarding AMQP 1.0 support, the problem here is OpenStack support for AMQP 1.0. Until OpenStack supports AMQP 1.0, we’re stuck supporting disparate implementations of AMQP.
Hope that helps.
CentOS 7-based Appliance?
Oh yay, I got it right