cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: Multiple IP's to one instance
Date Wed, 28 Nov 2012 17:01:54 GMT
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.kannan@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.BOYLAN@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 [tamasm@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.Kluge@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
>

Mime
View raw message