Created attachment 925138 [details] screen shot Description of problem: if you do start creating a deployment and decide not to submit it -> use the same name for a new deployment -> you will get an error 'has already been taken' so seemingly, we do not discard started deployments Version-Release number of selected component (if applicable): ruby193-rubygem-staypuft-0.1.22-1.el6ost.noarch How reproducible: 100% Steps to Reproduce: 1. select 'new deployment' 2. give it a name -> press next 3. select 'new deployment' again 4. give it the same name as in step 1 5. press next Actual results: we are getting an error 'has already been taken' Expected results: since we haven't actually submitted the first deployment we should be able to use the same name. Additional info: Started PUT "/deployments/16/steps/deployment_settings" for 10.36.4.210 at 2014-08-08 05:28:18 -0400 Processing by Staypuft::StepsController#update as HTML Parameters: {"utf8"=>"✓", "authenticity_token"=>"qZ/fI3zHbzZFPJfykayW3XGnuLWup8sk4FaS/Rb3rXo=", "staypuft_deployment"=>{"name"=>"Dafna_controller", "description"=>"", "layout_name"=>"Controller / Compute", "networking"=>"neutron", "amqp_provider"=>"rabbitmq", "platform"=>"rhel7", "passwords"=>"[FILTERED]"}, "deployment_id"=>"16", "id"=>"deployment_settings"} User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 1]] Setting current user thread-local variable to admin Staypuft::Deployment Load (0.1ms) SELECT "staypuft_deployments".* FROM "staypuft_deployments" WHERE "staypuft_deployments"."id" = $1 LIMIT 1 [["id", "16"]] Staypuft::Layout Load (0.2ms) SELECT "staypuft_layouts".* FROM "staypuft_layouts" ORDER BY name, networking DESC Hostgroup Load (0.3ms) SELECT "hostgroups".* FROM "hostgroups" WHERE "hostgroups"."id" = 95 ORDER BY hostgroups.title LIMIT 1 GroupParameter Load (0.2ms) SELECT "parameters".* FROM "parameters" WHERE "parameters"."type" IN ('GroupParameter') AND "parameters"."reference_id" = 95 AND "parameters"."name" = 'ui::passwords::single_password' ORDER BY parameters.name LIMIT 1 (0.0ms) BEGIN Staypuft::Deployment Exists (0.1ms) SELECT 1 AS one FROM "staypuft_deployments" WHERE ("staypuft_deployments"."name" = 'Dafna_controller' AND "staypuft_deployments"."id" != 16) LIMIT 1 Staypuft::Layout Load (0.1ms) SELECT "staypuft_layouts".* FROM "staypuft_layouts" WHERE "staypuft_layouts"."id" = 4 LIMIT 1 (0.0ms) ROLLBACK Host::Managed Load (0.6ms) SELECT "hosts".* FROM "hosts" INNER JOIN "hostgroups" ON "hosts"."hostgroup_id" = "hostgroups"."id" INNER JOIN "staypuft_deployment_role_hostgroups" ON "hostgroups"."id" = "staypuft_deployment_role_hostgroups"."hostgroup_id" WHERE "hosts"."type" IN ('Host::Managed') AND "staypuft_deployment_role_hostgroups"."deployment_id" = 16 ORDER BY hostgroups.title Rendered /opt/rh/ruby193/root/usr/share/gems/gems/staypuft-0.1.22/app/views/staypuft/steps/_wizard_form_buttons.html.erb (0.4ms) Rendered /opt/rh/ruby193/root/usr/share/gems/gems/staypuft-0.1.22/app/views/staypuft/steps/_title.html.erb (8.5ms) Rendered /opt/rh/ruby193/root/usr/share/gems/gems/staypuft-0.1.22/app/views/staypuft/steps/deployment_settings.html.erb within staypuft/layouts/staypuft (8.7ms) Rendered home/_user_dropdown.html.erb (0.9ms) Read fragment views/tabs_and_title_records-1 (0.1ms) Rendered home/_topbar.html.erb (1.5ms) Rendered layouts/base.html.erb (2.2ms) Rendered /opt/rh/ruby193/root/usr/share/gems/gems/staypuft-0.1.22/app/views/staypuft/layouts/application.html.erb (2.5ms) Completed 200 OK in 21ms (Views: 11.8ms | ActiveRecord: 2.0ms) Started GET "/assets/staypuft/staypuft-d6b29eb43942298baa46ef6a62f53222.css" for 10.36.4.210 at 2014-08-08 05:28:18 -0400 Started GET "/assets/staypuft/staypuft-704afdc8a5b25362c6d5cecac9777092.js" for 10.36.4.210 at 2014-08-08 05:28:18 -0400
also, checking the deployment tab will show the deployment (which is incomplete and was never submitted).
I don't think we should automatically delete un-finished deployments. The user may be keeping the old one around for some reason -- it seems to me that the current behavior is the right thing to do. If the old deployment is no longer needed, the user should delete it.
closing per comment 2