Missing cbtool config details

[danboid]

I am trying to get cbtool to work with Openstack train but I have several questions regarding its config file.

My attempts so far have got no further than errors such as:

The OSK cloud named "MYOSK" could not be attached to this experiment: VMC "RegionOne" did not pass the connection test." : OpenStack Cloud connection failure: The request you have made requires authentication. (HTTP 401) (Request-ID: req-65088ca0-5bb7-4f1b-bc44-e27ab71663e6)

My first question about cloud_definitions.txt is why are there 2 Openstack sections? What is Openstack via LibCloud? Who should use the Openstack via LibCloud variables vs regular Openstack?

The following page:

https://github.com/ibmcb/cbtool/wiki/HOWTO:-Preparing-your-cloud-to-be-driven-by-CBTOOL

Under the generic info section says we have to specify the name or id of the base image we are using to create the VMs but I don't see that specified in the example cloud_definitions.txt file, at least not for Openstack. Maybe that is defined elsewhere?

Another problem with that page is that it references

nova secgroup-list

Which doesn't seem to exist as a command any more under OS Train, which also seems to be the case for nova network-list

MAIN_LOGIN = cbuser

Does that mean cbtool will create this user within the VMs or is this the username of an already existing user within the VM image? How does MAIN_LOGIN differ from OS_LOGIN or OSK_LOGIN?

OSK_CREDENTIALS

Apparently this should be in the form admin-password-tenant. By tenant I presume you mean project? I think tenant is just the old word for a project right? I presume we can (or in some cases must) use the project ID instead of the project (tenant) and user name here right?

OSK_INITIAL_VMCS

We only have one existing region called RegionOne but in your Openstack example config you use the value RegionOne:sut. What is the :sut bit about?

OSK_SECURITY_GROUPS

Again, can use use security group ID strings instead of names here? They're all called default normally so I presume we have to use the ID.

OSK_LOGIN

Again, how does OSK_LOGIN differ from MAIN_LOGIN? Do we need to specify both?

I have noticed the build_cloud_config_file_from_env.sh script in the configs dir so maybe this can assist me in configuring cbtool?

It would be great to see all these questions addressed in the cbtool docs and/or within the comments for the cloud_definitions.txt file.

Thanks!

[maugustosilva]

Hello @danboid, thanks for opening the issue. I tried to address at least the first initial questions that you had in an update version of https://github.com/ibmcb/cbtool/wiki/HOWTO:-Preparing-your-cloud-to-be-driven-by-CBTOOL.

Questions left unanswered, which will be added as part of the FAQ (will get around it before the week ends)

• What is :sut
• OSK_LOGIN vs MAIN_LOGIN
• How to use build_cloud_config_file_from_env.sh

As for the rest of your questions, can you confirm that these are appropriately answered with this new documentation update?

[danboid]

Hi @maugustosilva

Thanks for updating the cbtool HOWTO. I now know the difference between OS and OSK but, apart from those questions you say have yet to be answered (in the FAQ), I still need to know:

Can we use IDs instead of names for all cbtool OS config values?

I don't think I understand the difference between OSK_SSH_KEY_NAME and
OSK_KEY_NAME or how they should be used. According to the comments in the example config file, OSK_KEY_NAME adds (injects) a private key "from the cloud" into the VMs. That's very vague.

I don't think I really need to know what the :sut suffix is about nor do I probably need to know how to use build_cloud_config_file_from_env.sh but I'm presuming from your response that I don't actually need to define MAIN_LOGIN if I'm using Openstack? The example private config file for Openstack in the HOWTO is missing all of the user defined variable definitions (eg MAIN_LOGIN, MAIN_USERNAME, STARTUP_CLOUD etc.) so the HOWTO gives the impression that these might not be needed, at least not all of them.

What version of Openstack do you use for your testing?

Thanks

[maugustosilva]

Hello again @danboid

1. KEY_NAME vs SSH_KEY_NAME. Please help me improve the answer on https://github.com/ibmcb/cbtool/wiki/FAQ-C#cq5 Do you have suggestions to make it more clear (or please suggest another place where I should link to it).

2. I have run a few tests, and finally realized that MAIN_LOGIN is not used at all (OSK_LOGIN is). I will submit a pull request to remove it altogether from the code.

3. Tested Openstack version:

root@osk4cbvm1:~# nova-manage --version
20.1.0
root@osk4cbvm1:~# cinder-manage --version
16.0.0
root@osk4cbvm1:~# glance-manage --version
20.0.0
root@osk4cbvm1:~# keystone-manage --version
16.1.0

[danboid]

Hi @maugustosilva

For both The OSK_KEY_NAME and The OSK_SSH_KEY_NAME I am presuming, but I'm not sure they should both take the form of paths to public keys or are the referring to Openstack SSH key object names / IDs or can we paste the full public key, in quotes? Example values for both would make this clearer.

"CA5: UPDATE: CBTOOL can now automatically create SSH keys. A typical user will not have to deal with these complexities anymore."

How does the user get cbtool to auto create SSH keys, particularly when using Openstack?

Should we be able to test the basic usage of cbtool for Openstack using stock Ubuntu images or are custom images required even in the most basic test cases? Do specific packages or config files have to be baked into the images for cbtool to function?

Thanks

[maugustosilva]

Thank you, I can see now how confusing it was. I rewrote the answer to CQ5 in the FAQ, please take a look, and let me know if it is clearer now.

Yeah, basic usage can tested with any recent "cloud-image", as exemplified in https://github.com/ibmcb/cbtool/wiki/HOWTO:-Preparing-a-VM-to-be-used-with-CBTOOL-on-a-real-cloud (item 2)

[danboid]

That explains those 2 SSH options better. It seems you have removed the text about cbtool being able to auto create ssh keys. I presume that feature has been deprecated?

It it always safe to use Openstack IDs instead of their names for all OSK config values?

[maugustosilva]

No, no, this feature (creating SSH keys on the cloud, and injecting it on images via cloud-init) is now default for all clouds (except PDM, NOP and SIM, for obvious reasons).

Yes, using the openstack IDs instead of names should work, albeit I must admit that I am not testing this way myself.

[danboid]

So should we should be able to get away without defining any of the Openstack SSH options at all in the private config file and cbtool will autoconfigure all the keys for us?

How do we specify the image to use for the VMs? There doesn't seem to be an example for how to do this in the default private config file, not for Openstack at least. As I said i the first post:

https://github.com/ibmcb/cbtool/wiki/HOWTO:-Preparing-your-cloud-to-be-driven-by-CBTOOL

Under the generic info section says we have to specify the name or id of the base image we are using to create the VMs but I don't see that specified in the example cloud_definitions.txt file, at least not for Openstack. Maybe that is defined elsewhere?

Currently, the generic info section of that HOWTO says an unconfigured image must be specified but there is no mention of having to specify an image in the Openstack required details section.

[danboid]

@maugustosilva

I think it might also be helpful to split the current example private config file into several smaller, cloud specific config files with updated comments that cover the questions I've been asking, that are now mostly covered in the HOWTOs. That would answer my question about which options are required to be defined for each cloud platform.