Re: [libcloud] Firewall Configurations, was Fwd: svn commit: r902984 - /incubator/libcloud/trunk/libcloud/drivers/ec2.py

[Jed Smith <je...@jedsmith.org>]

On Jan 25, 2010, at 6:32 PM, Paul Querna wrote:

> Should we throw an exception if a provider can't support that, but it
> was requested by the API user?

No.  Ignore it quietly.

In the Linode case, there is no security configuration to allow -- that's
up to configuration after boot.  Rather than me patching the Linode driver
to ignore inbound_tcp_ports if provided, a better default is that it's a
feature that some providers implement and others ignore quietly...

JS

Re: [libcloud] Firewall Configurations, was Fwd: svn commit: r902984 - /incubator/libcloud/trunk/libcloud/drivers/ec2.py

[Adrian Cole <fe...@gmail.com>]

+1 to ignore if irrelevant.

On Mon, Jan 25, 2010 at 3:53 PM, Jed Smith <je...@jedsmith.org> wrote:

> On Jan 25, 2010, at 6:32 PM, Paul Querna wrote:
>
> > Should we throw an exception if a provider can't support that, but it
> > was requested by the API user?
>
> No.  Ignore it quietly.
>
> In the Linode case, there is no security configuration to allow -- that's
> up to configuration after boot.  Rather than me patching the Linode driver
> to ignore inbound_tcp_ports if provided, a better default is that it's a
> feature that some providers implement and others ignore quietly...
>
> JS
>
>

Re: [libcloud] Firewall Configurations, was Fwd: svn commit: r902984 - /incubator/libcloud/trunk/libcloud/drivers/ec2.py

[Jed Smith <je...@jedsmith.org>]

On Jan 25, 2010, at 8:27 PM, Paul Querna wrote:

> On Mon, Jan 25, 2010 at 3:53 PM, Jed Smith <je...@jedsmith.org> wrote:
>> On Jan 25, 2010, at 6:32 PM, Paul Querna wrote:
>> 
>>> Should we throw an exception if a provider can't support that, but it
>>> was requested by the API user?
>> 
>> No.  Ignore it quietly.
>> 
>> In the Linode case, there is no security configuration to allow -- that's
>> up to configuration after boot.  Rather than me patching the Linode driver
>> to ignore inbound_tcp_ports if provided, a better default is that it's a
>> feature that some providers implement and others ignore quietly...
> 
> What I meant is, if the provider does firewall ports by default, but
> there isn't an API to open them.

That I'm on board with.  (Is there such a company?)

> If the provider defaults to open ports, ya, 'ignore' is fine, but to
> ignore it if they default to closed ports really sucks, as then you
> don't have a portable booting a machine to do X.


Well, if libcloud's API guarantees that after a node is created the
provided ports will be open, ignoring it is safe in at least Linode's case
because they certainly will be.

Sounded to me like we were considering raising an exception if the parameter
inbound_tcp_ports was passed but the driver did not handle it -- little
miscommunication there.  I'm on board with THIS idea.  :)

JS

Re: [libcloud] Firewall Configurations, was Fwd: svn commit: r902984 - /incubator/libcloud/trunk/libcloud/drivers/ec2.py

[Paul Querna <pa...@querna.org>]

On Mon, Jan 25, 2010 at 3:53 PM, Jed Smith <je...@jedsmith.org> wrote:
> On Jan 25, 2010, at 6:32 PM, Paul Querna wrote:
>
>> Should we throw an exception if a provider can't support that, but it
>> was requested by the API user?
>
> No.  Ignore it quietly.
>
> In the Linode case, there is no security configuration to allow -- that's
> up to configuration after boot.  Rather than me patching the Linode driver
> to ignore inbound_tcp_ports if provided, a better default is that it's a
> feature that some providers implement and others ignore quietly...

What I meant is, if the provider does firewall ports by default, but
there isn't an API to open them.

If the provider defaults to open ports, ya, 'ignore' is fine, but to
ignore it if they default to closed ports really sucks, as then you
don't have a portable booting a machine to do X.