New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manual provisioning of existing machines does not work #106
Comments
Here's the code that was used:
And here's the log:
|
The actual ws json request is: {
"request": "AddMachines",
"type": "Client",
"params": {
"params": [
{
"jobs": [
"JobHostUnits"
],
"placement": {
"directive": "ubuntu@xx.xx.xx.xx",
"scope": "ssh"
},
"nonce": null,
"disks": [],
"parent-id": null,
"container-type": null,
"addresses": [],
"hardware-characteristics": null,
"instance-id": null,
"series": null,
"constraints": null
}
]
},
"version": 1,
"request-id": 4
} |
It sounds like the parse function in juju/placement.py is doing the wrong thing here. I'm assuming that instead of this:
We want this:
parse.py is basically one big hack to get around the fact that the planner doesn't give us placement directives that we can actually pass back to it, so it wouldn't be too terrible if we added one more hack to it, to make it treat "ssh:..." as a special case. |
Follow-up: instead of hacking parse.py, you could also pass in an instance of client.Placement to the spec arg of model.add_machine, rather than the bare "ssh:..." string. That will cause parse.py to skip over it entirely. |
It seems that changing the placement is not enough here.
did not work for me. {
"request-id":2,
"type":"Client",
"version":1,
"request":"AddMachinesV2",
"params":{
"params":[
{
"series":"trusty",
"constraints":{ },
"jobs":[
"JobHostUnits"
],
"parent-id":"",
"container-type":"",
"instance-id":"manual:xx.xx.xx.xx",
"nonce":"manual:xx.xx.xx.xx:40d94bb5-6271-243b-81c2-5bf85671bf86",
"hardware-characteristics":{
"arch":"amd64",
"mem":993,
"cpu-cores":1
},
"addresses":[
{
"value":"xx.xx.xx.xx",
"type":"ipv4",
"scope":"public"
}
]
}
]
}
} I tried using the client module's AddMachinesV2 method and passing these parameters, which resulted in the same request to the API. It would be very helpful to know the exact steps and API calls executed in the manual provisioning procedure. |
Hi, We are still struggling with this issue. Is there any update? Thanks |
I've come across this issue as well. A work around for this is to use the python 'sh' module that you can install with pip. If you are having issues with the host key/finger print when calling add machine this way. You can pull it in to the host calling juju add machine by running something like: Only issue is, since StrictHostKeyChecking it turned off, you open yourself up to man in the middle shenanigans. |
The core problem is that there are several steps that the equivalent Juju CLI command do, outside of the API, that we need to re-implement. These include:
Only after all that is done is the call to AddMachinesV2 called. |
This was fixed in #240 |
Trying to add an existing machine to a model via ssh using the model.add_machine method like this:
await model.add_machine(spec='ssh:ubuntu@{}'.format(ip_address))
raises the following error:
ValueError: ('Error adding machine: %s', 'invalid model name "ssh"')
The text was updated successfully, but these errors were encountered: