<div dir="ltr">Hello,<div><br></div><div>I agree with Matjaz order of priority. I would also like to add one more spec to the osbash scripts but we could keep this in the wishlist.</div><div>#9: Adding color to echo statements in osbash scripts to make it more readable.</div><div><br></div><div>Cheers,</div><div>Sayali.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 7:02 PM, Roger Luethi <span dir="ltr"><<a href="mailto:rl@patchworkscience.org" target="_blank">rl@patchworkscience.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We have scripts that implement the openstack-manuals install-guide to<br>
install a training-cluster that can be used for training (and validates<br>
the install-guide in the process).<br>
<br>
As of now, the scripts install Icehouse in Ubuntu VMs (on Linux, Mac OS<br>
X, and Windows hosts). The list of larger lab-scripts tasks discussed<br>
for Kilo looks roughly like this (holler if I forgot something):<br>
<br>
1) close the remaining gap between install-guides and lab-scripts for<br>
   Icehouse<br>
2) branch and update scripts for Juno<br>
3) branch and update scripts for Kilo<br>
4) create a (presumably all-in-one) VM image that can run on top of<br>
   OpenStack<br>
5) improve experience/flexibility on Windows hosts<br>
6) add KVM back end on Linux (in addition to VirtualBox)<br>
7) port host-side code to Python<br>
8) installation on VMs running distros other than Ubuntu<br>
<br>
We had a pretty much universal agreement that 1) is a requirement for a<br>
meaningful discussion about collaboration between install-guides and<br>
lab-scripts; work on it has already started.<br>
<br>
Skipping 2) and going for 3) directly is a possibility, but it may not<br>
save us all that much time.<br>
<br>
Everyone seems to agree that it would be nice to have 4), but it would<br>
also be nice to know that additional, actual use will offset the required<br>
development resources (especially considering that it may have to be<br>
a rather unappealing all-in-one VM rather than a three-node cluster).<br>
<br>
With regards to 5), feedback from the field would (or hopefully will)<br>
help us decide whether there is sufficient interest to continue and<br>
improve support for Windows hosts. Ditto for 8).<br>
<br>
On Linux, the choice of VirtualBox as the lab-scripts back end<br>
reportedly hinders adoption among developers because KVM is more<br>
popular there. In addition, 6) would also give us better performance<br>
(e.g., nested virtualization with hardware support). Obviously,<br>
adding a second virtualization back end will require some surgery on<br>
the host-side scripts. It might make sense to plan for that when/if<br>
we port the host-side code to Python [7)] which may not happen in Kilo<br>
due to lack of resources.<br>
<br>
So far, three people have worked on the lab-scripts. We don't<br>
have a large community to coordinate and very limited resources for<br>
process overhead. So, can we talk about priorities and the lab-scripts<br>
specs that are needed/appropriate for Kilo?<br>
<br>
Roger<br>
<br>
<br>
_______________________________________________<br>
OpenStack-docs mailing list<br>
<a href="mailto:OpenStack-docs@lists.openstack.org">OpenStack-docs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
</blockquote></div><br></div>