Showing headlines posted by dba477

In posting below I intend to test packstack on RDO Newton to perform classic three node deployment. If packstack will succeed then post installation actions like VRRP or DVR setups might be committed as well. Please,be advised that packstack on RDO Newton won't allow you to split Controller and Storage Nodes ( vs. Mitaka )

Initiate TripleO QuickStart deployment , log into undercloud and pick up files /etc/yum.repos.d/delorean.repo, /etc/yum.repos.d/delorean-deps.repo, which are associated with RDO Newton trunk with status "current-passed-ci" at the moment. On VIRTHOST and INSTACK VM set same delorean repos.

Posting below is addressing multiple questions raising up at ask.openstack.org regarding packstack AIO or Multi Node RDO Newton installations on CentOS 7.2. Instructions bellow explain how to use RDO Newton trunk "current-passed-ci" for packstack installation.

Overcloud deployment Ceph nodes via instack-virt-setup requires some additional repos to be installed on VIRTHOST (32 GB) and on INSTACK VM as well as exporting DIB_YUM_REPO_CONF referencing delorean trunks Newton "current-passed-ci" and CentOS-Ceph-Jewel.repo in INSTACK stack's shell before building overcloud images prior to overcloud deployment. I am aware of official trpipleo quickstart release 1.0.0 for RDO Newton . . .

Create new VM centos72vm on VIRTHOST with one VNIC . Set up VNIC via attaching to "overcloud" libvirt sub-net (bridge brovc). No attaching to external 192.168.23.0/24 (br-ext ) sub-net is supposed to be made as was required with non-rout-able 192.0.2.0/24.

Hacking standard tripleo-heat-template bellow was performed to avoid hitting "OSDs fewer than Replicas" cluster status.Corresponding template got discovered and updated before running overcloud deployment.

Following is a sample of overcloud deployment 1xController + 2xCompute +3 Ceph Nodes (Cluster) via TripleO QuickStart . Number of Ceph Nodes is supposed to be 3 at least due to automatically generated file /etc/ceph/ceph.conf contains entry "osd_pool_default_size = 3" to avoid hitting "Fewer OSDs than Replicas" cluster's status.

Finally Overcloud deployment start to initialize mistral work flow in QuickStart environment. Memory allocation as 7 GB for PCS HA Controllers and 6.7 GB for each compute overcloud node (1 VCPU by default for any node running in overcloud) seems to be safe to pass phases 5.X of overcloud deployment with QuickStart.

Due to getting errors in /var/log/mistral/executor.log on regular basis attempting to deploy overcloud via TripleO QuickStart. I was just wondering how much can assist KSM&&KSMTUNED to achieve a goal to set up 5 VMs (6.7GB,1 VCPU)running in overcloud and "instack VM" undercloud with 4 VCPUs,8GB RAM and 4GB swap file on 32GB RAM total on VIRTHOST.

Posting below is supposed to demonstrate KSM implementation on QuickStart providing significant relief on 32 GB VIRTHOST vs quite the same deployment described in previous draft .

Draft belllow may be considered as POC awaiting release of TripleoO QuickStart along with flexible templates managed by ansible and KSM patching.

Following bellow is verification of status Newton DLRN consistent trunks for TripleO undercloud/overcloud deployment based on packages currently been built via upstream git branches.

Set up F24 as WKS for "TripleO instack-virt-setup overcloud/undercloud deployment to VIRTHOST" via ssh (trusted) connection . This setup works much more stable then configuring FoxyProxy on VIRTHOST running "instack" ( actually undercloud VM) hosting heat stack "overcloud" and several overcloud Controllers and Compute VMs

Upstream gets close to Newton Release , bugs scheduled for RC2 went away. Following bellow is a clean and smoothly running procedure of Overcloud deployment TripleO Master branch via instack-virt-setup on 32 GB VIRTHOST Network isolation in overcloud is pre-configured on instack (undercloud )

Following bellow is set of instructions required to perform TripleoO QuickStart deployment for release "master". It differs a bit from testing default release "mitaka" . First on F24(23) workstation . . .

This post follows up "TripleO deployment of master branch via instack-virt-setup" Launchpad bug "Updating plans breaks deployment" has status "In Progress" so to be able redeploy "overcloud" heat stack the following bellow workaround would be appiled.

Due to Launchpad Bug "introspection hangs due to broken ipxe config" finally resolved on 09/01/2016 approach suggested in TripleO manual deployment of 'master' branch by Carlo Camacho has been retested. As appears things in meantime have been changed. Following bellow is the way how mentioned above post worked for me right now on 32 GB VIRTHOST (i7 4790)

Procedure bellow identify Controller which has RouterDSA in active state and shutdown/startup this Controller ( controller-1 in particular case). Then log into conntroller-1 and restart pcs cluster on particular Controller, afterwards runs `pacemaker resource cleanup` for several resources what results bringing back cluster nodes in proper status

Current update allows to automate procedure via /etc/rc.d/rc.local and exports is stack's shell variables which allow to start virt-manager right away , presuming that xhost+ was issued in root's shell. Thus, we intend to survive VIRTHOST cold reboot (downtime) and keep previous version of undercloud. VM been able to bring it up avoiding build via quickstart.sh.

Sshutle may be installed on Fedora 24 via straight forward `dnf -y install sshutle`

So, when F24 has been set up as WKS for TripleO QuickStart deployment to VIRTHOST , there is no need to install add-on FoxyProxy and tune it on firefox as well as connect from ansible wks to undergound via...