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