Showing headlines posted by dba477

I largely avoid systemd “debates” these days. They depress me due to all of the flawed reasoning and flinging emerging everywhere, but I felt that perhaps this little write-up could try to explain the background and causes for just why systemd inspires so much vitriol and turf warring.

Following bellow is brief instruction for traditional three node deployment test Controller&&Network&&Compute for oncoming RDO Kilo, which was performed on Fedora 21 host with KVM/Libvirt Hypervisor (16 GB RAM, Intel Core i7-4771 Haswell CPU, ASUS Z97-P ) Three VMs (4 GB RAM,2 VCPUS) have been setup

Following below a (tutorial for a) simple two node Controller&&Network and Compute test for oncoming RDO Kilo, which was performed on Fedora 21 host with KVM/Libvirt Hypervisor (16 GB RAM, i5-4690 Intel CPU,ASUS Z97-P Board). Two VMs (6 GB RAM, 2 VCPUS) have been setup , each one having 2 VNICs (eth0,eth1) for Controller and Compute Nodes emulation.

Posting bellow is targeting testing official version on Nova-Doker Driver for Openstack Kilo with development version RDO Kilo ( supposed GA day is 05/07/2015). RDO Kilo installed via `packstack --allinone` on virtual CentOS 7.1 machine.

Step by step instruction for setting up Nova-Docker driver && Openstack Kilo on Ubuntu 14.04 in devstack environment recoverable between reboots. Also routing across LAN is described for remote access to Devstack (stack.sh) public network.

Following bellow are brief instructions how to achieve extremely high performance of VMs created via devstack ( stack.sh ) inside another virtual machine created with Fedora 22 KVM Hypervisor and having Nested KVM feature enabled, working with sufficiently advanced Intel CPUs (Haswell kernel or above which have newer hardware virt extensions ) and 16 GB or more RAM.

This post is closely related to RDO Juno Multi Node deployment via packstack on Fedora 21 landscape with boxes having different boards and different Ethernet NICs inegrated either plugged into systems. Originally tested on Two Node Controller&&Network and Compute Fedora 21 .

This document describes steps Xing Lin (University of Utah) took to setup a compute node based on Ubuntu 14.04 for OpenStack "juno", using the Xen Project via libvirt approach. As of the fall of 2014, Openstack does not support this approach well as Xen Project is in the Group C of the hypervisor support matrix for Openstack

This article presents a step by step procedure for installing the latest version of nova docker on Fedora 21.

Testing the most recent Nova-Docker driver on Ubuntu 14.04 in devstack environment recoverable between reboots. Recently new patch... However,nova-docker containers have been lost after every reboot due to bridge br-ex came up with no IP and running ./rejoin-stack.sh didn't help much. This post describes workaround for this issue.

It's quite obvious that Nova-Docker driver set up success for real applications is important to get on Compute Nodes . It's nice when everything works on AIO Juno host or Controller, but just as demonstration.

As a final result of performing configuration bellow Juno dashboard will automatically spawn,launch and run Nova-Dockers containers on Controller and usual nova instances supposed to run on KVM Hypervisor (Libvirt driver) on Compute Node

During RDO Juno set up on Fedora 21 Workstation service target is deactivated on boot up, and tgtd is started (versus CentOS 7 installation procedure) , what requires some additional efforts to tune LVMiSCSI cinder back end on newest Fedora release.

The problem here is that phusion/baseimage per https://github.com/phusion/baseimage-docker should provide ssh access to container , however it doesn't. Working with docker container there is easy workaround suggested by Mykola Gurov in http://stackoverflow.com/questions/27816298/cannot-get-ssh-a... which is of no help in case of Nova-Docker Container.

Building docker container for GlassFish 4.1 via image phusion/baseimage allows to execute several scripts been placed in folder /etc/my_init.d. In particular, not only run.sh coming from https://registry.hub.docker.com/u/bonelli/glassfish-4.1/ , but also script database.sh starting up Derby Database have been placed in mentioned folder, what actually does completely functional load GlassFish 4.1 docker container. The core issue in ([1]) is attempt to extend JAVA:8 , what causes a problem when starting several daemons during docker container load

This post follows up http://www.linux.com/community/blogs/133-general-linux/79956... Docker image been built bellow has pre-installed JDK 1.8 and GlassFish 4.1, providing ssh connect to Nova-Docker container ( launched via this image ) it allows initialize Glassfish with JPA support manually.

Docker image arahman/docker-oracle-xe-11g:latest allows to build Nova-Docker Container on RDO Juno running Oracle XE instance, which may be accessed remotely via floating IP assigned to nova instance. Several network configuration files require tuning with Nova system instance-name and floating IP assigned from neutron external pool.

Recently Filip Krikav made a fork on github and created a Juno branch using the latest commit + fixing the problem of loading an image from glance.

Quote (http://technodrone.blogspot.com/2014/10/nova-docker-on-juno....) The Docker driver is a hypervisor driver for Openstack Nova Compute. It was introduced with the Havana release, but lives out-of-tree for Icehouse and Juno. Being out-of-tree has allowed the driver to reach maturity and feature-parity faster than would be possible should it have remained in-tree. It is expected the driver will return to mainline Nova in the Kilo release.

It is actually an update of http://techbackground.blogspot.ie/2013/06/metadata-via-quant... for Neutron on Juno ( original blog considers Quantum implementation on Grizzly ). From my standpoint understanding of core architecture of Neutron openstack flow in regards of nova-api metadata service access (and getting proper response from nova-api ) by VMs launching via nova causes a lot of problems due to leak of understanding of core concepts.