This works on a freshly deployed PRO system:
| ngcpcfg init-mgmt $MGMT_IP
Now let's try to include this step also during deployment.
From: Michael Prokop <mprokop@sipwise.com>
Boot option ngcpcpip2 might differ from default, so we can't hardcode
$DEFAULT_IP2 when deploying sp1. Instead try to autoconfigure it
when we're deploying sp2, maybe we don't need it while deploying
sp1. If this doesn't work then we'd have to provision the interface
using $IP2 in the meanwhile.
While at it try to pull changes from shared storage on sp1 when
deploying sp2 so both nodes are fully up2date after fresh
installation.
From: Michael Prokop <mprokop@sipwise.com>
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>
Michael Prokop