Bug 1595161
Summary: | `hammer host create --puppet-class-ids=6 ...` creates a host without mentioned puppet class attached | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Jan Hutař <jhutar> | ||||
Component: | Hosts | Assignee: | Ivan Necas <inecas> | ||||
Status: | CLOSED ERRATA | QA Contact: | Jan Hutař <jhutar> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.4 | CC: | egolov, inecas, jhutar, tbrisker, zhunting | ||||
Target Milestone: | 6.4.0 | Keywords: | Regression, TestBlocker, Triaged | ||||
Target Release: | Unused | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | tfm-rubygem-katello-3.7.0.19-1,foreman-1.18.0.17-1 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2018-10-16 19:09:33 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Jan Hutař
2018-06-26 09:16:10 UTC
foreman-debug is in attachment 1454612 [details].
Hi Jan, do you know if this is a regression from 6.3? I suspect it may be. Yes, you are right, this is a regression compared to 6.3. Thank you. @jan: I was able to reproduce this issue, when the puppet environment was not assigned to the org/loc of the host. Is it possible that this would also be your case? Created attachment 1456365 [details]
organizations in the environment
Soo, looks like it might be it. On the other hand, see scereenshot: Org 1 seems to be selected for that environment, but when I query env details via hammer:
[root@sat640snap10 ~]# hammer -u admin -p changeme environment info --name KT_pTfgsH_Library_TRRpefOPzv_5
Id: 6
Name: KT_pTfgsH_Library_TRRpefOPzv_5
Puppetclasses:
access_insights_client
foreman_scap_client
foreman_scap_client::params
generic_1
stdlib
stdlib::stages
Locations:
Default Location
Organizations:
pTfgsH
Created at: 2018/07/04 05:23:32
Updated at: 2018/07/04 05:23:32
So you were right: when I imported the env into org 1 (it did not worked, I had to remove the the host with that class first), it now works. It worked before this in the 6.3, but I agree it seems more deterministic now when thinking about it. Does it make sense to create a bug for "I'm unable to import env if host supposedly consuming its class exists"? Have you actually try to save the environment in the state of the screenshot? From my testing, it actually saved the org/location assignment after that. I think it makes sense to open a bug, that would visually indicate, that there are some inconsistencies in organizations/locations assigned to the taxable object and the hosts assigned to that object, and suggesting the user to save the resource to resolve those. As part of this bug, I would try to fix that by explicitly checking, that the environment that one tries to assign the host to, is actually inside the org/location of that particular host, and failing with validation issue. Uch, I have not. Did not knew it works this way. Thank you. Created redmine issue https://projects.theforeman.org/issues/24199 from this bug Upstream bug assigned to inecas Upstream bug assigned to inecas Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/24199 has been resolved. 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-2018:2927 |