Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Allow adding Embedded Ansible catalog items to a catalog bundle #21341

Closed
Fryguy opened this issue Jul 20, 2021 · 9 comments
Closed

[RFE] Allow adding Embedded Ansible catalog items to a catalog bundle #21341

Fryguy opened this issue Jul 20, 2021 · 9 comments
Assignees

Comments

@Fryguy
Copy link
Member

Fryguy commented Jul 20, 2021

No description provided.

@Fryguy
Copy link
Member Author

Fryguy commented Jul 20, 2021

@gmcculloug @tinaafitz Do you recall why the current system is limited to not allowing this?

@NickLaMuro
Copy link
Member

So, looks like the investigation is short for this one, mostly because I found "where" it was excluded, but not "why":

Looks like we will still need some insights from the others, since there is no public explanation as to why this was done.

@chessbyte
Copy link
Member

From https://bugzilla.redhat.com/show_bug.cgi?id=1448283,

Dave Johnson 2017-05-08 14:29:49 UTC
Dan, I spoke to John about this one.  We are thinking its better to include ansible in the drop down and then give a flash message saying its not supported yet versus leaving them confused as why its not in the list.  What do you think?

From this, I gather that we removed it because we could not support it at the time.

@NickLaMuro
Copy link
Member

@chessbyte yes, again, the question we are having is "why?".

If the restriction is strictly because of the specifics of the AWX/Tower implementation of EmbeddedAnsible, then I don't see a reason why this restriction needs to stay in place. However, if it is something related to our system in general, then I wouldn't feel comfortable just removing this limitation.

Unfortunately, none of the commit messages, BZs, or Pivotal stories give a rational "why", just that it needed to be excluded. I can try and dig some more, but I think the PR mentioned above is a dead end because it was previously an .all, so I think the context for this was talked about in person, but never written down anywhere (publically at least).

@tinaafitz
Copy link
Member

Hi @Fryguy, @chessbyte, @NickLaMuro, I know there was a good reason for the limitation at that time, but I don't recall why.
I'll look into it and will let you know what I find.

@gmcculloug
Copy link
Member

Discussed a little with Tina in the office today. (I know, right!) This was likely based on the fact that the dialog for a catalog item attached to a bundle is never displayed to the end user. The user would have to attach the dialog to the catalog bundle or create a new dialog that took into account the dialog fields from all the different catalog items on the bundle.

Once this was identified the thinking was this (from BZ 1448283):

If you wish to create multiple items as you do in a bundle you would do this in the playbook itself, creating multiple tasks and plays.

Tina is checking her notes to see if there may have been additional technical reasons for this decision.

@NickLaMuro
Copy link
Member

NickLaMuro commented Jul 29, 2021

@tinaafitz @gmcculloug Thanks for the info!

That makes a lot of sense now. Currently there is no way to create a EmbeddedAnsible playbook service without a dialog, so yeah, getting that data into a service (while can be done), isn't immediately obvious or known when it is happening/missing, so I think it would be a debugging nightmare to support.

Possibly if we removed that restriction on Ansible Playbook Services (having a dialog that is), or made it so there was a "ARE YOU SURE YOU KNOW WHAT YOU ARE DOING!?!?" dialog alert/flash message when selecting a playbook service might be an option, but I don't think simply removing the restriction is the right path alone.

Thanks again for the insight!


P.S. ...

Discussed a little with Tina in the office today. (I know, right!)

🎉 🎉 🎉

@miq-bot miq-bot added the stale label Feb 27, 2023
@miq-bot
Copy link
Member

miq-bot commented Feb 27, 2023

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

@miq-bot miq-bot closed this as completed May 29, 2023
@miq-bot
Copy link
Member

miq-bot commented May 29, 2023

This issue has been automatically closed because it has not been updated for at least 3 months.

Feel free to reopen this issue if this issue is still valid.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants