Devstack workload

[ganeshmaharaj]

@markdryan this enables devstack and pretty much everything that openstack has to offer. The complete stacking time it took on a 4core, 6GB machine was 37 mins. Also almost no developer uses the default local.conf. I am trying to see if we can look for a local.conf in the user's home dir and if exists, populate the local.conf we are pushing into the VM with it with the default as a fall-back. Was wondering if that is something that can be done with golang templates.

[markdryan]

@ganeshmaharaj What we do on ciao is, by default, mount the host's GOPATH inside the VM. This is sort of what you want as it allows you to edit the source files on your host PC using your editor of choice, but compile and run the code in the VM. We could do the same thing here. We'd want to make the workload handle the case where the path was and wasn't mounted. So assuming the user wanted to share his host's devstack directory, he'd do

ccloudvm create devstack-xenial --mount devstack,passthrough,$HOME/devstack

Then in the workload we'd do something like

{{- if not (.MountPath "devstack")}}
- sudo -u {{.User}} {{template "ENV" .}} git clone http://git.openstack.org/openstack-dev/devstack /home/{{.User}}/devstack                                                                                                                                                                           
{{- end}} 

This way the clone only gets executed if the mount is not specified.

[markdryan]

@ganeshmaharaj Do you know why the setup is so slow? If it's because it's downloading large files such as cloud images there might be something we can do here. Ccloudvm has a download function. If you use this function in your workloads the files are downloaded by ccloudvm itself and cached locally. So the next time you try to download the file, the file is download across the loopback network, and so is much quicker.

[ganeshmaharaj]

What happens is a series of git clones, install dependencies for each service, put files in place, adjust databases and migrate them in case there is a need, start each of the service as a systemd daemon. Not sure how much of that we can pre-empt prior to triggering the stack command. Also given this is how openstack does it, folks might prefer to stick to it. The one way to reduce the time is to reduce the number of services we install which would be easy if there is a way for us to get a local.conf from host into the guest if there is one available in a predefined location.

On Thu, Feb 15, 2018, 2:30 AM Mark Ryan notifications@github.com wrote:

@ganeshmaharaj https://github.com/ganeshmaharaj Do you know why the setup is so slow? If it's because it's downloading large files such as cloud images there might be something we can do here. Ccloudvm has a download function. If you use this function in your workloads the files are downloaded by ccloudvm itself and cached locally. So the next time you try to download the file, the file is download across the loopback network, and so is much quicker.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/intel/ccloudvm/pull/53#issuecomment-365886514, or mute the thread https://github.com/notifications/unsubscribe-auth/AFSZunlvdTrY2F4Y5iVrafla7R5pXW5Mks5tVAddgaJpZM4SF--0 .

[markdryan]

@ganeshmaharaj In addition to the other changes we discussed we'll also need to add a body to the commit message.

[coveralls]

Coverage remained the same at 68.62% when pulling a0c8480302c9c32e92059d7cb5332928d38bb164 on ganeshmaharaj:devstack-workload into 21b87f5f38823de6b079ba1ad2cbd3d3fa437042 on intel:master.

[markdryan]

@ganeshmaharaj Having problems testing this. I ran the script without any mounts.

The VM created correctly, but I had a number of issues. These are probably because I'm doing something wrong.

1. I wasn't able to connect to horizon. The apache web server is up but http://127.3.232.5:55580/dashboard gives me a 404. Is this the correct URL.
2. I think we might need to add 127.0.0.1 to the no_proxy variable.
3. At the end of my stack.log file I see

INFO keystone.cmd.cli [None req-ca4e2474-d938-4aed-9fa2-ef178e445c5f None None] Created public endpoint http://127.0.0.1/identity
Error on exit

4. I couldn't figure out how to make the openstack command work.