Open Stack

Well say Carl!
I am sorry I did not get back to you on this topic before.
In general and after thinking about it, it makes sense to leave could
admin to adage the /32 cases if any.

Edgar

On 1/28/14 1:46 PM, "Carl Baldwin" <carl at ecbaldwin.net> wrote:

>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
>>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev