Open Stack

+1

~sean

> On Nov 20, 2014, at 12:28 AM, Pančur, Matjaž <Matjaz.Pancur at fri.uni-lj.si> wrote:
> 
> Roger,
> 
> All larger issues you mentioned below should be drafted as specs/BPs. Yes, it will add some process overhead (that’s what you are worried about, right?), but we can try to keep it as small as possible. The added benefit will be increased transparency and because of that a larger community input (I hope :).
> 
> For #1 and #5 we can just use our existing process (bugs&patches), I don’t think they need a separate BPs. Maybe we can use the same for #2 and #3?
> 
> We do need a separate specs/BPs for #4, #6, #7 and #8.
> 
> Priority: 
> - 1,2,3 high; 
> - 4, 6, medium; 
> - 5,7,8 low
> 
> -Matjaz
> 
> 
>> On 19. nov. 2014, at 14.32, Roger Luethi <rl at patchworkscience.org> wrote:
>> 
>> We have scripts that implement the openstack-manuals install-guide to
>> install a training-cluster that can be used for training (and validates
>> the install-guide in the process).
>> 
>> As of now, the scripts install Icehouse in Ubuntu VMs (on Linux, Mac OS
>> X, and Windows hosts). The list of larger lab-scripts tasks discussed
>> for Kilo looks roughly like this (holler if I forgot something):
>> 
>> 1) close the remaining gap between install-guides and lab-scripts for
>>  Icehouse
>> 2) branch and update scripts for Juno
>> 3) branch and update scripts for Kilo
>> 4) create a (presumably all-in-one) VM image that can run on top of
>>  OpenStack
>> 5) improve experience/flexibility on Windows hosts
>> 6) add KVM back end on Linux (in addition to VirtualBox)
>> 7) port host-side code to Python
>> 8) installation on VMs running distros other than Ubuntu
>> 
>> We had a pretty much universal agreement that 1) is a requirement for a
>> meaningful discussion about collaboration between install-guides and
>> lab-scripts; work on it has already started.
>> 
>> Skipping 2) and going for 3) directly is a possibility, but it may not
>> save us all that much time.
>> 
>> Everyone seems to agree that it would be nice to have 4), but it would
>> also be nice to know that additional, actual use will offset the required
>> development resources (especially considering that it may have to be
>> a rather unappealing all-in-one VM rather than a three-node cluster).
>> 
>> With regards to 5), feedback from the field would (or hopefully will)
>> help us decide whether there is sufficient interest to continue and
>> improve support for Windows hosts. Ditto for 8).
>> 
>> On Linux, the choice of VirtualBox as the lab-scripts back end
>> reportedly hinders adoption among developers because KVM is more
>> popular there. In addition, 6) would also give us better performance
>> (e.g., nested virtualization with hardware support). Obviously,
>> adding a second virtualization back end will require some surgery on
>> the host-side scripts. It might make sense to plan for that when/if
>> we port the host-side code to Python [7)] which may not happen in Kilo
>> due to lack of resources.
>> 
>> So far, three people have worked on the lab-scripts. We don't
>> have a large community to coordinate and very limited resources for
>> process overhead. So, can we talk about priorities and the lab-scripts
>> specs that are needed/appropriate for Kilo?
>> 
>> Roger
>> 
>> 
>> _______________________________________________
>> OpenStack-docs mailing list
>> OpenStack-docs at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> 
> _______________________________________________
> OpenStack-docs mailing list
> OpenStack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs