On Tue, Jun 11, 2013 at 12:26:20PM +0200, nfoata....@orange.com wrote: > Hi Cloudstack community,
Hi! Sorry that nobody got back to you earlier. > > I would like to propose two developments queries if possible (see below). > However, it seems if I want to submit them, I have to send a git diff (I can > do it if need be). > Is it the good way to do it or I have to follow a specific process ? We have a couple of processes... but basically, it works like this: 1) propose the changes on this list (dev@cloudstack.apache.org). 2) if the changes are "large", then it's useful to document the changes in a functional specification. Here's a good example: https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+Request+Throttling Here's the template page: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design+Document+Template Here's the wiki page that you would create your FS as a child page of: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design+Documents+Not+Committed+to+a+Release > > In my mind, I thought that first we have to propose (to be sure that nobody > done it or the community is ok), > and then if everything goes fine, to do and send it. > > Thanks in advance, > > Have a good day, > > Best regards, > > Nicolas Foata > These look like good ideas, but could benefit the community by being sent out as individual proposals. We use subject line prefixes like "[PROPOSE]" to get people attention, followed by a good subject describing the proposal. Can you break them out into their own threads? > > 1) VM instantiation : network information for VM > > Goal: Sending network information to a new VM instance > > Abstract/suggestion: > While a VM is instantiated, CloudStack could also send the following > information if need be : > - the instance name (CS uuid) > - the display name > - VM tags > - network information (IPv4, IPv6, netmask, routing, gateway, mac address, > etc.) > just if we activate some global settings such as : > - vm.instance.boot.network.required (true/false) > - vm.instance.boot.vmname (true/false) > - vm.instance.boot.uuid (true/false) > - vm.instance.boot.tags (true/false) > > Applications: > - A VM could discover its network and dialog with physical and virtual > machines, etc. > - A VM do not need a virtual router > - According of this type of information (tags, names, ...) , management > servers could be able to configure and deploy correctly VMs. > > > > 2) VM instantiation : specific information for hypervisors > > Goal : Sending specific information for the hypervisor to well instantiate a > VM > > Abstract/suggestion: > While a VM is instantiated, Cloudstack could send and add furthermore data > for the hypervisor > coming from a new field such as 'Other options/Other configuration' for > example in the 'Compute offering' screen. > Thus, each hypervisor could decide whether it want to process the data and > how or to do not take it into account. > With a such input, Cloudstack will be able to use the specificity and the > full power of each hypervisor. > > Applications: > 1) On XCP, it will be possible to branch some pci straightforwardly (via pci > passthrough) > 2) To use the more efficiently the min, max memories (static and/or dynamic) > > Please feel free to modify the text if you to find better and sexy > application examples > with this two kinds of features and of course to correct mistakes. > > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages > that have been modified, changed or falsified. > Thank you. >
