Showing headlines posted by dba477

The OpenStack Networking components are deployed on the Controller, Compute, and Network nodes in the following configuration . . .

I believe this short notice is supposed to explain complicated concepts in pretty simple words. It's really hard to find such kind of HowTo on the Net.

Reproducing "Dirrect access to Nova metadata" I was able to get only list of EC2 metadata available, but not the values. However, the major concern is getting values of metadata obtained in review "Direct access to Nova metadata" and also at /openstack location. The last ones seem to me important not less then present in EC2. This metadata are also not provided by this list.

Quoting http://blog.oddbit.com/2014/01/14/direct-access-to-nova-meta... In an environment running Neutron, a request from your instance must traverse a number of steps: From the instance to a router, Through a NAT rule in the router namespace, To an instance of the neutron-ns-metadata-proxy, To the actual Nova metadata service

Article is about attempt to make working mentioned kind of `nova boot .. ` commands via CLI or Dashboard, launching Instances via image and creating simultaneously boot able cinder volumes (on glusterfs).

I am just wondering what is going to happen when by the end of 2014 similar "packstack multinode setup via standard prepared answer-files" will run on RHEL 7 & CentOS 7 (F19 based systems) servers landscapes. This slides http://oddbit.com/rdo-hangout-multinode-packstack-slides/ would work for almost any sysadmin, even has no idea what OS is really on top of OpenStack and what Juju is.

When you first time boot cloud instance (RDO Havana) via `nova boot ..` or via Dashboard associated with ssh keypair , the default MTU value for eth0 of instance has been built would be 1500. The last one in case of GRE tunnelling makes useless attempt to connect to instance via ssh.

This post follows up http://lxer.com/module/newswire/view/197613/index.html In particular, it could be performed after basic setup to make system management more comfortable then only CLI. For instance assigning floating IP is just a mouse click instead of shell script

This post is an update for http://bderzhavets.blogspot.com/2014/01/setting-up-two-physi... . It's focused on Gluster 3.4.2 implementation including tuning /etc/sysconfig/iptables files on Controller and Compute Nodes. copying ssh-key from master node to compute, step by step verification of gluster volume replica 2 functionality and switching RDO Havana cinder service to work with gluster volume created to store instances bootable cinders volumes for performance improvement.

Schema bellow allows to avoid two commands . First one creating cinder volume and second one booting instance via volume created . It allows to create volume on F20 Controller node and boot instance via created volume on F20 Compute node simultaneously.

I clearly understand that only incomplete Havana RDO setup allows me to activate spice USB redirection communicating with cloud instances. There is no dashboard ( Administrative Web Console ) on Cluster. All information regarding nova instances status, neutron subnets,routers,ports is supposed to be obtained via CLI as well as managing instances, subnets,routers,ports and rules is also supposed to be done via CLI, having carefully watch sourcing "keystonerc_user" file to manage in environment of particular user of particular tenant.

Following bellow was accepted as correct answer on 02/18/2014 at https://ask.openstack.org/en/question/9365/trouble-installin... Openstack Nova Software evaluated that my Compute Node may run at a time no more then 5 cloud instances. So , to create new one I just must have in `nova list` no more then four entries. Then I will be able create new one instance for sure. It has been tested on two "Two Node Neutron GRE+OVS Systems" ( watching in other window `tail -f /var/log/nova/scheduler.log` for ERRORS to connect AMQP Server) . It looks like AMQP Server eventually breaks connection to Nova & Neutron-server services, what may require service QPIDD restart and service openstack-nova-scheduler restart.

Following bellow (sic) builds Light Weight X Windows environment on Fedora 20 Cloud instance and demonstrate (sic) running same instance in Spice session via virt-manager ( Controller connects to Compute node via virt-manager ).

When you meet the first time with GRE tunnelling you have to understand that GRE encapsulation requires 24 bytes and a lot of problems raise up , view http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tec... In particular, Two Node (Controller+Compute) RDO Havana cluster on Fedora 20 hosts been built by myself per guidelines from http://kashyapc.wordpress.com/2013/11/23/neutron-configs-for... was Neutron GRE cluster. Hence, for any instance has been setup (Fedora or Ubuntu) problem with network communication raises up immediately. Apt-get update just refuse to work on Ubuntu Salamander Server instance (default MTU value for Ethernet interface is 1500).

Cloud instances running on Compute perform commands like nslookup,traceroute. Yum install & yum -y update work on Fedora 19 instance, however, in meantime time network on VF19 is stable, but relatively slow.CentOS 6.5 with "RDO Havana+Glusterfs+Neutron VLAN" works on same box (dual booting with F20) much faster.That is a first impression

Why CentOS 6.5 ? It has library ligfapi http://www.gluster.org/2012/11/integration-with-kvmqemu/ backported what allows native Qemu work directly with gluterfs 3.4.1 volumes.

My final target was to create two node oVirt 3.3.2 cluster and virtual machines using replicated glusterfs 3.4.1 volumes based on XFS formatted partitions. Choice of IPv4 firewall with iptables for tuning cluster environment and synchronization is my personal preference. Now I also know that postgres requires enough shared memory allocation like Informix or Oracle

OpenStack is probably the largest and fastest growing opensource project out there. Unfortunately, that means fast changes, new features and different install methods. RedHat's RDO simplifies this.

My final target was to create two node oVirt 3.3 cluster and virtual machines using replicated glusterfs 3.4.1 volumes. Choice of firewalld as configured firewall seems to be unacceptable for this purpose in meantime. Selection of iptables firewall allows to complete the task.

Two node gluster 3.4.1 cluster set up follows bellow. Please, view first nice article: http://www.mirantis.com/blog/openstack-havana-glusterfs-and-... and http://wiki.openstack.org/wiki/CinderSupportMatrix.