My findings: 1) Tried listing product content in AK using API and Hammer. In both cases, a full list was returned with proper pagination. 2) APIdoc correctly contains information about per_page: and page: attributes. 3) The playbook is de-facto idempotent since it only creates the AK once, and with proper overrides. However, the task is still marked as "changed" when run repeatedly.
The module itself is flawed, as you can see by adding these debug outputs in the respective place in the module's source code: module.warn(f"PRODUCT_CONTENT: {product_content}") for label, override in desired_content_overrides.items(): pop = current_content_overrides.pop(label, None) if override is not None and override != pop: module.warn(f"ADDING {label}, override: {override}, pop: {pop}") changed_content_overrides.append({'content_label': label, 'value': override}) You see it only gets the first page, doesn't list, then it's missing the overrides on the second page and sets them again. I think this is the same behavior that occured in the version where the issue was reported against. The API, its docs and Hammer are fixed though, now it's about the module. Odilon, is it OK to close this BZ based on the fact that it's about API, not the module - and perhaps file a new BZ about the module itself?
(In reply to Lukáš Hellebrandt from comment #4) > The module itself is flawed, as you can see by adding these debug outputs in > the respective place in the module's source code: > > module.warn(f"PRODUCT_CONTENT: {product_content}") > for label, override in desired_content_overrides.items(): > pop = current_content_overrides.pop(label, None) > if override is not None and override != pop: > module.warn(f"ADDING {label}, override: {override}, pop: {pop}") > changed_content_overrides.append({'content_label': label, 'value': > override}) > > You see it only gets the first page, doesn't list, then it's missing the > overrides on the second page and sets them again. I think this is the same > behavior that occured in the version where the issue was reported against. > > The API, its docs and Hammer are fixed though, now it's about the module. > > Odilon, is it OK to close this BZ based on the fact that it's about API, not > the module - and perhaps file a new BZ about the module itself? I think we can close this one, and validate since it was created for the API, and create a new one. This Bug was cloned from https://bugzilla.redhat.com/show_bug.cgi?id=2154512 we should link the new bug to the one for 6.13 as well if it's get the same result there.
(In reply to Lukáš Hellebrandt from comment #4) > The module itself is flawed, as you can see by adding these debug outputs in > the respective place in the module's source code: > > module.warn(f"PRODUCT_CONTENT: {product_content}") > for label, override in desired_content_overrides.items(): > pop = current_content_overrides.pop(label, None) > if override is not None and override != pop: > module.warn(f"ADDING {label}, override: {override}, pop: {pop}") > changed_content_overrides.append({'content_label': label, 'value': > override}) > > You see it only gets the first page, doesn't list, then it's missing the > overrides on the second page and sets them again. I think this is the same > behavior that occured in the version where the issue was reported against. > > The API, its docs and Hammer are fixed though, now it's about the module. > > Odilon, is it OK to close this BZ based on the fact that it's about API, not > the module - and perhaps file a new BZ about the module itself? The module fix is in https://bugzilla.redhat.com/show_bug.cgi?id=2134605 and is fixed in the 3.8.0 version of the collection, which one are you using?
ansible-collection-redhat-satellite-3.6.0-1.el8sat.noarch on Sat 6.12.2, the installer didn't update the collection - should it have? Also, I can't update it manually. Note this BZ is for a 6.12.2 z-stream version, maybe it wasn't packaged properly?
(In reply to Lukáš Hellebrandt from comment #7) > ansible-collection-redhat-satellite-3.6.0-1.el8sat.noarch on Sat 6.12.2, the > installer didn't update the collection - should it have? Also, I can't > update it manually. Note this BZ is for a 6.12.2 z-stream version, maybe it > wasn't packaged properly? No, I don't think we have 3.8 in 6.12 yet. Carry on, I guess. The thing mentioned in the BZ is fixed, the other has 6.12.z+ so it will show up eventually. If you think the ansible feature also needs to be present (which the text might indicate, while the title does not), more work will be needed.
VERIFIED using steps from comment 3 on Sat 6.12.2 snap 1.0. The only thing remaining to fix in relation to this BZ is bug 2134605.
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 (Satellite 6.12.2 Async Update), 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/RHBA-2023:0668