Open Stack

I think I agree.  The new check isn't adding much value and we could
debate for a long time whether /30 is useful and should be disallowed
or not.  There are bigger fish to fry.

Carl

On Fri, Jan 24, 2014 at 10:43 AM, Paul Ward <wpward at us.ibm.com> wrote:
> Given your obviously much more extensive understanding of networking than
> mine, I'm starting to move over to the "we shouldn't make this fix" camp.
> Mostly because of this:
>
> "CARVER, PAUL" <pc2929 at att.com> wrote on 01/23/2014 08:57:10 PM:
>
>
>
>> Putting a friendly helper in Horizon will help novice users and
>> provide a good example to anyone who is developing an alternate UI
>> to invoke the Neutron API. I’m not sure what the benefit is of
>> putting code in the backend to disallow valid but silly subnet
>> masks. I include /30, /31, AND /32 in the category of “silly” subnet
>> masks to use on a broadcast medium. All three are entirely
>> legitimate subnet masks, it’s just that they’re not useful for end
>> host networks.
>
> My mindset has always been that we should programmatically prevent things
> that are definitively wrong.  Of which, these netmasks apparently are not.
> So it would seem we should leave neutron server code alone under the
> assumption that those using CLI to create networks *probably* know what
> they're doing.
>
> However, the UI is supposed to be the more friendly interface and perhaps
> this is the more appropriate place for this change?  As I stated before,
> horizon prevents /32, but allows /31.
>
> I'm no UI guy, so maybe the best course of action is to abandon my change in
> gerrit and move the launchpad bug back to unassigned and see if someone with
> horizon experience wants to pick this up.  What do others think about this?
>
> Thanks again for your participation in this discussion, Paul.  It's been
> very enlightening to me.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>