GitHub PushEvent at 2014-12-17 10:06:50
Repository: python-neutronclient
Actor: metacloud-review
Payload: {"shas":[["fea8706c22438af5666bc249f86aa5facf97564d","b339079bdd0c511d3934e046f7b02c5281dc2db1@redhat.com","subnet: allow --enable-dhcp=False/True syntax, again\n\nTill neutronclient 2.3.4, we allowed the following syntax to enable or\ndisable DHCP: --enable-dhcp=False or --enable-dhcp=True. Since\nI52d05ec2284b6910a33df4a5cb7dc3888737acb6 was merged, it's not the case\nanymore.\n\nClient libraries should be backwards compatible.\n\nThe change that introduced the regression cannot be reverted. First,\nbecause it's correct in essence and fixed a valid bug in neutron client\nCLI, and second (and more importantly), we don't want to break backwards\ncompatibility for users that currently use 2.3.5+ version that already\nincluded the new style of the argument.\n\nSo we need to support both new and old styles for setting the attribute.\n\nIt's sad, but argparse module that we use to parse CLI arguments does\nnot allow to distinguish between '--enable-dhcp=smth' and '--enable-dhcp\nsmth' variants of the argument. This limitation means that an argument\nwith nargs=argparse.OPTIONAL that would be useful to cover both styles\nwith single entry would consume the next argument from the command line\nif it's present and does not seem to be another option argument defined\nfor the parser. Meaning, it would break some cases, f.e. when\n--enable-dhcp is passed right before subnet name. In that specific case,\nthe argument would consume the name as the value of the argument and\nbreak the client.\n\nThat's why for this specific fix, we're forced to use\n--enable-dhcp=False and --enable-dhcp=True as argument *names*. It's\nugly as hell, so let's hide that mess from users by suppressing help\nentries for new arguments.\n\nPS: And Oh Lord the Mighty, thank you for only two possible values for\nboolean attributes!)\n\nCloses-Bug: #1401555\nChange-Id: Ib374d1cc499e4f1e5242f1b438bc65512c109e40","Ihar Hrachyshka",true],["04a0ec8ddfa5c0aed08b638a63cc3a5da7bf148c","8a62b6af5456d754819b210debd67e150f66bc2f@hp.com","firewall policy update for a rule is not working\n\nIf user specifies one rule to update it is not taking but more than one rule\nit is accepting as a list and updating the policy. Modified policy-update to\nbehave same as policy-create command for \"--firewall-rules\" option\n\nChange-Id: Ia6a1c726be310d60b3b56ce677f843e818079fbe\nCloses-bug: 1318617","Koteswara Rao Kelam",true],["4067a482cca0d037ea81c1b4b8c473c1ec50f510","d95b56ce41a2e1ac4cecdd398defd7414407cc08@review.openstack.org","Merge \"subnet: allow --enable-dhcp=False/True syntax, again\"","Jenkins",true],["6913e3f436c71f10c86bbdb590ab24d965f5e2c5","d95b56ce41a2e1ac4cecdd398defd7414407cc08@review.openstack.org","Merge \"firewall policy update for a rule is not working\"","Jenkins",true]],"size":4,"ref":"refs/heads/master","head":"6913e3f436c71f10c86bbdb590ab24d965f5e2c5"}