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
