Description of problem: subnet names throw PGError when char limit is greater than 238. PGError: ERROR: value too long for type character varying(255) : INSERT INTO "audits" ("action", "associated_id", "associated_name", "associated_type", "auditable_id", "auditable_name", "auditable_type", "audited_changes", "comment", "created_at", "remote_address", "user_id", "user_type", "username", "version") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15) RETURNING "id" Version-Release number of selected component (if applicable): sat6-GA-snap2 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: currently subnet name accepts only 238 chars only. anything above 238 chars throws error. Expected results: We need both the below fixes for the subnet. a) subnet char should accept upto 255 chars b) subnet's name field should handle the char limit issues and report "more than 255 chars is not allowed", instead of the UI throwing the PGError. Additional info:
I think we're getting the picture. These BZs are causing a lot of work and overhead. Please use the existing top level bug #1120271 in future.
see 1120199
In sat6 GA snap5, I can create a subnet with more than 255 characters in name. However I didn't see issue related to PGError. UI successfully create a subnet with any length of name. We should add a validation here if name increases 255 char, UI should raise an error message. So moving it back to assigned state. -- Processing by SubnetsController#index as HTML Parameters: {"utf8"=>"✓", "search"=>"name = \"UcZNeuEsQLmPEfKyIooaJnbVyeDbCOkZMuzXLLHtcnpiVrDowVsJhweVbINhSRDLIQrReOwAHWmCepUNasLudQMHKGBDTHGpTSZOcepUDnoiFFfCwjXnfLfzbrZcLCqZXPQmOtAWfCGbtrrtdNFZZspiaCzJKvDGOhmdhyFpGetKsNEHgbBLIhRtBnJuFdanUxBYtAZvAHkqYwYytAcvjnQirHsZapnuOSTYmrEmCUypPGhszUkhsFFBQMjgisqR\""} --
logs generated in production.log while creating subnet > 255 char -- Processing by SubnetsController#create as */* Parameters: {"utf8"=>"✓", "search"=>"", "authenticity_token"=>"4kt4+IYKrYfOwbpXLUsyMFIiE3rkA2Qq5eBP60KAzAw=", "subnet"=>{"name"=>"UcZNeuEsQLmPEfKyIooaJnbVyeDbCOkZMuzXLLHtcnpiVrDowVsJhweVbINhSRDLIQrReOwAHWmCepUNasLudQMHKGBDTHGpTSZOcepUDnoiFFfCwjXnfLfzbrZcLCqZXPQmOtAWfCGbtrrtdNFZZspiaCzJKvDGOhmdhyFpGetKsNEHgbBLIhRtBnJuFdanUxBYtAZvAHkqYwYytAcvjnQirHsZapnuOSTYmrEmCUypPGhszUkhsFFBQMjgisqR", "network"=>"53.242.105.0", "mask"=>"255.255.255.0", "gateway"=>"", "dns_primary"=>"", "dns_secondary"=>"", "from"=>"", "to"=>"", "vlanid"=>"", "domain_ids"=>[""], "dhcp_id"=>"", "tftp_id"=>"", "dns_id"=>"", "location_ids"=>[""], "organization_ids"=>[""]}} Redirected to https://qetello02.usersys.redhat.com/subnets Completed 302 Found in 41ms (ActiveRecord: 6.4ms) --
If the subnet is created successfully with that name, it's not a bug. Lack of errors is a good thing.
@Dominic: the behaviour should be consistent across the UI and with other entities too. On creating subnet with more than 255 char in name, UI should throw validation error like: "is too long (maximum is 255 characters)" It is also part of expected result.
Upstream bug assigned to orabin
this bug was fixed with BZ 1120181
*** Verified *** foreman-release-1.7.0-0.develop.201410150839gitb948163.el6.noarch foreman-gce-1.7.0-0.develop.201410150839gitb948163.el6.noarch foreman-selinux-1.7.0-0.develop.201409301113git2f345de.el6.noarch rubygem-hammer_cli_foreman_tasks-0.0.3-2.201409091410gitc96619d.git.0.37f3704.el6.noarch qe-foreman-rhel65.usersys.redhat.com-foreman-proxy-1.0-1.noarch foreman-postgresql-1.7.0-0.develop.201410150839gitb948163.el6.noarch qe-foreman-rhel65.usersys.redhat.com-qpid-broker-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-qpid-client-cert-1.0-1.noarch foreman-1.7.0-0.develop.201410150839gitb948163.el6.noarch foreman-ovirt-1.7.0-0.develop.201410150839gitb948163.el6.noarch foreman-vmware-1.7.0-0.develop.201410150839gitb948163.el6.noarch ruby193-rubygem-foreman_hooks-0.3.7-2.el6.noarch ruby193-rubygem-foreman_discovery-1.4.0-0.1.rc4.el6.noarch rubygem-hammer_cli_foreman-0.1.3-1.201410151235gitbc8c449.el6.noarch ruby193-rubygem-foreman_bootdisk-4.0.0-1.el6.noarch foreman-proxy-1.7.0-0.develop.201410101404git7961640.el6.noarch qe-foreman-rhel65.usersys.redhat.com-puppet-client-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-foreman-client-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-apache-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-parent-cert-1.0-1.noarch foreman-compute-1.7.0-0.develop.201410150839gitb948163.el6.noarch ruby193-rubygem-foreman-tasks-0.6.10-1.el6.noarch foreman-libvirt-1.7.0-0.develop.201410150839gitb948163.el6.noarch
This bug is slated to be released with Satellite 6.1.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:1592