This should give us a full-fledged network.yml as eth0 of
the 2nd system is the only missing NIC during deployment.
Testing!
From: Michael Prokop <mprokop@sipwise.com>
this *might* fail due to ssh key setup, but we have to avoid
merge conflicts and therefore need to get ngcpcfg pull working...
From: Michael Prokop <mprokop@sipwise.com>
With the way it is the second node gets the SSH keys from the first
node's glusterfs share. Let's try to set up SSH before actually
running ngcp-installer, then in ngcp-installer skip the SSH key
setup if keys already exist (will follow in upcoming svn commit
for ngcp-installer).
From: Michael Prokop <mprokop@sipwise.com>
As supported by ngcpcfg-api as of svn r11744.
If this works as expected then the only:
ssh-keyscan $MANAGEMENT_IP >> ~/.ssh/known_hosts
should be needed for automatic SSH login between nodes in carrier
environment. A working version of "ngcpcfg init_mgmt
$MANAGEMENT_IP" should be quite close then.
Let's see what's the opinion of Jenkins + our autodeploy jobs...
From: Michael Prokop <mprokop@sipwise.com>
Let's see whether this enough to close issue #2367.
Open question: do we want to have locales-all also on systems
we did not deploy on our own (AKA CE systems installed using
ngcp-installer)? Iff so then we'd have to add it as dependency
somewhere.
Testing: https://bugtracker.sipwise.com/view.php?id=2367
From: Michael Prokop <mprokop@sipwise.com>
This reverts commit 2c859c9940caa2599b6eb71f7a1d8832064a6133.
This doesn't fix the issue (as you might guess I know the
real source of the problem now, ha!)
From: Michael Prokop <mprokop@sipwise.com>
network.yml looks good on sp1 now. Something fishy is still
causing broken config files though, a manual 'ngcpcfg build'
fixes that, why the 'ngcpcfg build' in the deployment script
doesn't solve that yet needs to be investigated...
Sadly bootstrapping sp2 is still quite tricky. We might even
have to set initial network.yml on PRO systems to what we ship
with CE systems so we don't run into merge conflicts. Hmpf.
From: Michael Prokop <mprokop@sipwise.com>
Seems to work, at least for sp1 hosts in PRO installs. Let's see
whether PRO deployments work again with new templates,
network.yml and ngcp-network being in place now.
Happy PRO deploying dear Jenkins while I'm switching office->home. :)
From: Michael Prokop <mprokop@sipwise.com>
On Dell PowerEdge R310 servers we have the PERC H700, on the next
generation model R320 we have PERC H710. Don't be too picky
about the whitelist and just check for "PERC" in the model
information and "DELL" as vendor.
From: Michael Prokop <mprokop@sipwise.com>
acpi-support-base in squeeze depends on console-tools (or kbd)[1],
therefore we can't remove console-tools if we want to get
acpi-support-base installed by default
[1] http://packages.debian.org/squeeze/acpi-support-base
From: Michael Prokop <mprokop@sipwise.com>
VMs on Proxmox 2.1-14 (pve-qemu-kvm 1.1-8, 2.6.32-14-pve) have an
annoying problem with our installations, where the deployed
system freezes as soon as some action takes place on the network
stack. For example invoking "lsof -i -n" on the rebooted system
causes such a freeze.
The only solution to work around this issue seems to be stopping
and then restarting the VM. As we need to handle this
automatically we need some kind of API to retrieve system state.
By writing the current deployment state into some file and
providing it through http://$DEPLOYMENT_SYSTEM:4242/status this
should get us there.
From: Michael Prokop <mprokop@sipwise.com>
The udev rules need the real MAC addresses and we can't mess
with them before the rules are in place
Thanks Richard for helping with debugging
From: Michael Prokop <mprokop@sipwise.com>
logit() isn't available inside the subshell in the chroot so don't
use it there, we already have it at the according place...
From: Michael Prokop <mprokop@sipwise.com>
When doing automated pro deployments we also have to stop monit
to be able to unmounted the disk in a clean way...
From: Michael Prokop <mprokop@sipwise.com>
Fix what has been broken in r10823: the "Dump completed on"
is present iff "--skip-comments" option is not used.
From: Michael Prokop <mprokop@sipwise.com>
We write data into the DB in revision scripts, like e.g.:
| $SVN/dev/ngcp/db-schema/trunk$ cat db_scripts/diff/9675.up
| INSERT INTO provisioning.voip_preferences (attribute, type, dom_pref, usr_pref, peer_pref, data_type, max_occur, description) VALUES('mobile_push_enable', 1, 1, 1, 0, 'boolean', 1, 'Send inbound call to Mobile Push server when called subscriber is not registered. This can not be used together with CFNA as call will be then simply forwarded.');
As suggested by Daniel let's also put data into the DB dumps.
From: Michael Prokop <mprokop@sipwise.com>