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