On Wed, Nov 28, 2012 at 12:23 PM, Hari Kannan <hari.kan...@citrix.com> wrote: > Thanks, Chip - that helps!!! Another follow-up question, though.. > > Lets outline the process: > > - Someone interested in implementing feature X proposes on the dev list - > lets say it has the following info: background on why (s)he thinks it is > important (*what*/ *why*) as well as advertise a design page on the wiki and > / or a functional spec that elaborates on the discussed feature idea (*how*) - > - This would generate discussion on a) how sound the arguments for feature > introductions are etc. (i.e. discuss on *what* / *why*) b) how sound the > design is or provide alternate suggestions/enhancements etc. > - upon consensus of the validity of both the *what/why* as well as *how*, > developer goes ahead with the implementation and presents for code review > - upon approval of code (perhaps after a few iterations), a committer checks > the code in > > Does that sound like a decent outline?
That's about right... of course variation is OK too. The main points are (a) that we do our development in a collaborative and open way and (b) that consensus gathering is critical to producing the best result. > If so, in this example case (multiple IPs), we are more or less at the > *what/why* stage - although I realize the discussion needs to happen on the > dev list - so, using this as an example case, what must a developer do now? > Does (s)he still go ahead and make design specs as it is not clear if we have > a consensus one way or the other on the *what/why* stage... At this point, I would suggest summarizing a few of the feature options that may solve the use case. For example, there are discussions about "reserving IP's for manual assignment within instances", "figure out if DHCP can do this correctly", "use existing LB and Elastic IP capabilities to achieve a similar result", etc... > > Regards, > > Hari Kannan > > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Wednesday, November 28, 2012 9:02 AM > To: <cloudstack-users@incubator.apache.org> > Subject: Re: Multiple IP's to one instance > > Great questions! > > So first, actual development decisions need to happen on the cloudstack-dev > list, not users (although we love seeing user discussions about feature > requests!). > > The way it works on the dev list, is if you (or anyone) wants to propose > building a feature, you would email the specifics of what you want to add. > Generally, changes are agreed to by gathering consensus on both *what* and > *how*. The developer that is building the feature would then (hopefully) do > a design page on the wiki and / or a functional spec that elaborates on the > discussed feature idea. > Getting consensus on that deign / functional spec then means moving forward > to implementation. > > The dev list is also the place to get help with figuring out how to add the > feature (both logistically and technically). > > Does that help? > > -chip > > On Wed, Nov 28, 2012 at 11:51 AM, Hari Kannan <hari.kan...@citrix.com> wrote: >> As a newbie to Apache, I have a dumb procedural question - >> >> I see there are folks who are in favor of implementing this as well as folks >> who either believe there are workarounds and/or believe there is no NEED for >> this. However, if someone really wants to implement this, can/must anyone >> object? I can imagine if the implementation is bad, we can reject it, but >> are there any other reasons to NOT implement a feature? >> >> PS1: While this feature is an example, I want to under the general >> process/guideline for future reference >> >> Hari Kannan >> >> -----Original Message----- >> From: Boylan, James [mailto:james.boy...@orbitz.com] >> Sent: Tuesday, November 27, 2012 3:18 PM >> To: cloudstack-users@incubator.apache.org >> Subject: RE: Multiple IP's to one instance >> >> I agree with Tamas. Cloudstack has functionality that would allow >> implementations using NAT/LoadBalancer configurations that would not require >> multiple IPs. Plus the NetScaler Service, if it is a true Netscaler >> implementation, supports loading the certs into it thus removing the >> multiple IP address requirement. >> >> -- James >> ________________________________________ >> From: Tamas Monos [tam...@veber.co.uk] >> Sent: Tuesday, November 27, 2012 4:20 AM >> To: cloudstack-users@incubator.apache.org >> Subject: RE: Multiple IP's to one instance >> >> Hi, >> >> Also I have tested earlier 3.0.2 and if you create multiple networks for the >> same account then the VM automatically gets that many IPs and NICs as many >> network the VM has. >> Then you can use static nat if you need to support multiple websites. >> >> Or another solution to this is to have many static nat IPs on the same >> network and port forward each IPs port 80 and 443 onto a different port on >> the VM and configure apache to listen on different ports for different >> virtual hosts. >> There is always a workaround. >> >> Regards >> >> Tamas Monos DDI >> +44(0)2034687012 >> Chief Technical Office >> +44(0)2034687000 >> Veber: The Hosting Specialists Fax +44(0)871 522 7057 >> http://www.veber.co.uk >> >> Follow us on Twitter: www.twitter.com/veberhost Follow us on Facebook: >> www.facebook.com/veberhost >> >> -----Original Message----- >> From: Kevin Kluge [mailto:kevin.kl...@citrix.com] >> Sent: 26 November 2012 19:03 >> To: cloudstack-users@incubator.apache.org >> Subject: RE: Multiple IP's to one instance >> >>> >>> I am conflicted on this - I know the limitations with adding additional >>> interfaces. >>> I'd almost argue for requiring number of interfaces/IPs to be set at >>> machine instantiation and still handing out addresses to all >>> interfaces via DHCP, but not all OSes will handle that cleanly. >> >> As you probably know CS hands out IPs via DHCP to multiple NICs today, and >> it is challenging to work reliably since different guest OS's have different >> behavior with respect to setting/re-setting the default route in DHCP >> replies. Today CloudStack has some knowledge of guest OS to make this work >> but we've seen bugs with that where the list of guest OS behavior is not >> right. Those are fixable. But there are other cases (e.g. boot from ISO, a >> user changes the DHCP client post-create, or the user upgrades the OS which >> changes the DHCP client) where I don't think there is a reasonable fix. So >> I think we need at a minimum an option to disable DHCP reply on NICs that >> are not the default route. We should even consider a behavior change to >> make that the only option. >> >> -kevin >> >
