Conversation
- New keypair node - Asynchronous start operation while waiting for configuration
emepetres
left a comment
emepetres
left a comment
There was a problem hiding this comment.
Nice job!! I put some minor comments before merging.
I'm working with the hybrid opm flow blueprint. It would be nice if we could run it with EOSC-Hub!
| name: Credentials | ||
| config: | ||
| id: 'user@laptop' | ||
| public_key: 'ssh-rsa ...' # Optional |
There was a problem hiding this comment.
Instead of optional, I understand that both keys doesn't have to be provided if use_existing_resource: False, and are mandatory if use_existing_resource: True.
Is that right? If so, please modify the docs.
There was a problem hiding this comment.
The use_existing_resource is inherited from the template you provided at the begining. I was reading about it and I think is an OpenStack-plugin (and othe plugins) feature, but nothing I had implemented. I think it is not working and we can remove this property all along the plugin.
The plugin generates the keypair if public_key or private_key is not defined. As I explained before, use_existing_resource is not taked into account.
There was a problem hiding this comment.
Then remove use_existing_resource, because it seems that it is implemented.
Also, the generation of the keys if they are not defined should be reflected somehow in the README.
simulate property is implemented?
There was a problem hiding this comment.
Yes, simulate is implemented. If it's True it does nothing during the operation
| password = get_child(dictionary=config, key='password', required=True) | ||
| public_key = get_child(dictionary=config, key='public_key', required=True) | ||
| private_key = get_child(dictionary=config, key='private_key', required=True) | ||
| username = get_child(dictionary=config, key='username') or 'user' |
There was a problem hiding this comment.
As I said, this should always be defined in the dictionary.
There was a problem hiding this comment.
I think to provide a default user could help to simplify the plugin user experience by means of the blueprints
There was a problem hiding this comment.
It is very unlikely that, if you left the username empty, the user in the image will be 'user'. So leaving it blank would lead to an error.
The idea is that, when you define an image, you need to know the default user that the image defines.
Therefore it should be mandatory (and reflect that on the README), unless you say that the plugin is creating the user when deploying the virtual machine. If it is the second case, that behaviour should be explained in the README as well.
There was a problem hiding this comment.
Yes, the second assumption is the right case. The user is created during contextualization
|
I took into account your commit to update the status of |
2 participants
Isolate keypair from image