On Tue, Apr 30, 2013 at 5:29 PM, Pulkit Singhal <pulkitati...@gmail.com>wrote:
> Hi everyone, > > I'm interested in the project "Create a cloud in a box using DevCloud". > > I'm a MS student at IIIT-Hyderabad. I've good experience with Python, Bash, > openstack, Xen/KVM and automation(chef/puppet). > > As per my discussion with Sebastien, my understanding is that the project > aims to extend devcloud to provision multiple instances of devcloud > appliances for simulating more realistic production environments. > > While installing devcloud, I realized that for setting up more complex > environments with multiple hosts and clusters, the procedure is too manual. > So, for this project we certainly need a command line utility to automate > installation and configurations. > > I’m a little uncertain about ‘simulating production environments’. I see > this happening in two ways. > > > *1.* Developers still use their development system to host complete cloud. > Of course, in this case it would be multiple virtual box instances running > devcloud and a management server running on the host itself. For this > scenario, the command line utility can automate the setup. .e.g > > *$ devcloud --deploy management-server # deploy management server on > local system > $ devcloud --deploy host -n 2 --provider=virtualbox # deploy two > hosts on virtualbox > * > > > The utility will download the updated source from git and install the > management server. The hosts will be provisioned through the devcloud > virtual box appliance or KVM image. > In most cases it's tricky to run more than one DevCloud VMs, but the idea was kind of already implemented using veewee+vagrant in tools/devcloud/src. The way was to build DevCloud using veewee (have puppet do s/w setups) and use vagrant to spin as many boxes one wants. Getting a virtual host to substitute for a real one is not a problem now, it was solved with DevCloud. With DevCloud2 we solved the problem of development, networking (earlier we just had port forwarding). The problem we need to solve in DevCloud now are; networking, make it work for advance zone/networking deployments and have multiple of them run consuming less resources. DevCloud-KVM is much better in that case, we can do both basic/adv-networking deployments. *2. *Developers have a set of physical machines where they plan to host > cloudstack. In this case, hosts won’t be running on virtualbox/kvm, but > physical machines. A deployment scenario here would look like. > > > *$* devcloud --deploy mangement_server -H 10.0.0.3 -u root -p pass > *$* devcloud --deploy host -H 10.0.0.4,10.0.0.5 -u root -p pass2 > --hypervisor=xen > Nice idea, but it's already solved sort of :) Developers who enjoy the privilege of such a lab setup would generally deploy the management server and mysql on their system, use a IDE or debugger to debug the management server on their machines while the host, agents, storage and other subsystems are in their infra lab. They are also quite used to deploying management server using marvin's deployDataCenter.py in tools/marvin/marvin/ which can accept a json cfg which has these values. I know people awesomesauce developers using puppet/cobbler and other tools to setup and run integration tests against real automated hosts (kvm, xen etc.) Sebastien mentioned on the list about the uncertainty of slots for students for CloudStack, so keep thinking about how you can solve the existing issues, work on your GSoC application, hangout on the IRC ask users and developers what the real problems are and solve 'em; Just want to encourage your opensource development interests, you're welcome to throw in ideas, digest any criticism and hack with the community -- with or without GSoC. Cheers. > Here, the utility will log into the specified machines and configure them > accordingly <http://rohityadav.in/logs/devcloud/>. No virtual appliance > will be involved. > > I kindly request you to share your views regarding my approach and your > expectations for this project. > > Thanks and Regards, > Pulkit Singhal >
