Closed benofben closed 7 years ago
Per Rafael, it looks like we need to mount here:
Takeaway === use /dev/disk/azure/scsci/lun1 given that in the template I have this: https://github.com/couchbase-partners/azure-resource-manager-couchbase/blob/master/simple/server.json#L62
Of course, that lun1 dev depends on a new waagent, which depends on a new VM. This is why I want automated builds.... anyway, need to rebuild the VM.
New VMs are in staging...
New VMs are pushing to prod...
So, looks like the lun stuff works on the VMs currently going to prod... Need to wait for that to go live and then I can go back and update the template...
couchbase@couchbase:/dev/disk$ cd azure/ couchbase@couchbase:/dev/disk/azure$ ls resource resource-part1 root root-part1 scsi1 couchbase@couchbase:/dev/disk/azure$ cd scsi1/ couchbase@couchbase:/dev/disk/azure/scsi1$ ls lun0 couchbase@couchbase:/dev/disk/azure/scsi1$ file lun0 lun0: symbolic link to `../../../sdc' couchbase@couchbase:/dev/disk/azure/scsi1$
New vms are out. Trying to fix format.sh now...
Works now!
From Dan -----
Here is a fun little azure bug for your format.sh script. There are times when you provision a new set of servers in Azure when the data disk comes up as sdb and the temp disk as sdc.
I ran 5 builds of a group of three nodes yesterday. In each build, at least one of the servers came up sda = os disk, sdb = data disk, sdc = temp disk. I tried it with both creating the disk separately in the arm template and attaching and creating the disk as part of the VM creation.
A reboot of the affected servers caused the disks to come up in the correct order everytime.