So I cleared things via:
$ sudo /usr/sbin/remove-juju-services
That allowed me to add it again.
IMHO this is a situation that can be detected and handled much better
I'd ask to:
a) At least offer the user a better error message than "ERROR machine is already provisioned" based on the metadata you found there like
"ERROR machine is already provisioned - for controller X on IP Y, at data Z"
b) it would be very helpful to then offer "do you want to clean and re-add the machine" which would then call remove-juju-services for the user.
Right now I realize that bug 1933819 and this one come down to almost the same root cause, just once for machine-add and once for controller-boostrap. If you want to implement/fix this in one, then feel free to dup the two together.
I found this on the target:
4 0 149497 1 20 0 9068 3592 - Ss ? 0:00 bash /etc/systemd/ system/ jujud-machine- 0-exec- start.sh juju/tools/ machine- 0/jujud machine --data-dir /var/lib/juju --machine-id 0 --debug
4 0 149502 149497 20 0 846588 92660 - SLl ? 1:41 \_ /var/lib/
So I cleared things via: remove- juju-services
$ sudo /usr/sbin/
That allowed me to add it again.
IMHO this is a situation that can be detected and handled much better
I'd ask to: juju-services for the user.
a) At least offer the user a better error message than "ERROR machine is already provisioned" based on the metadata you found there like
"ERROR machine is already provisioned - for controller X on IP Y, at data Z"
b) it would be very helpful to then offer "do you want to clean and re-add the machine" which would then call remove-
Right now I realize that bug 1933819 and this one come down to almost the same root cause, just once for machine-add and once for controller- boostrap. If you want to implement/fix this in one, then feel free to dup the two together.