add general content-view management role #1177
Conversation
|
We also have this content view role under development. I see a lot of overlap here for arriving at a role that allows users to manage content views. |
That role looks like it is for creating content-views and related. This one is specifically around managing them and their lifecycles, whether that be promotion, publishing a new one, or rolling back a version. One key difference is that this role is more around operationalization of the content-views versus creating them. This view allows somebody to just set this on a schedule so that they can promote/publish (more than once) in an automated fashion, without having to keep editing their playbooks. |
|
So, this is more of a content_view_version role? That could make sense to manage separately from the content view itself. I'm not as clear on what rollback here means. Since all content view operations are simply promotions of some version to some environment. If for example I had version 10 in Test, and I wanted to version 8 instead. How would I go about that? I would think, treating entities as code, I would update my yaml from 10 to 8 and let Ansible run and adjust things for me. With the rollback, I assume I would have to run the playbook twice to go back two versions? |
|
There are some variable naming updates that will be needed to ensure the role conforms to https://github.com/theforeman/foreman-ansible-modules#common-role-variables and attempts, where possible, to make use of existing variables defined for other roles such as lifecycle-environments (https://github.com/theforeman/foreman-ansible-modules/tree/develop/roles/lifecycle_environments). |
content_view_version might be a more apt description of the role, truth be told I was struggling with what to name it. The idea here is that the user doesn't need to know the content-view version, we will just loop over the dictionary and promote each of the lifecycle environments they want to N+1 of the content-view. If N+1 means that they need to publish a new version of the content-view first, it will do that automatically. Rollback will give N-1 content-view version for each of the defined lifecycle environments. So yes, to roll back 2 versions you'd run it twice. The number of versions to roll back could pretty easily get wrapped into a var in the main dictionary so that the roll back would do N-Y versions. The main idea here is from customer experiences with patch management. They otherwise don't want to affect the content-view other than publishing new versions, or promoting lifecycle environments (or the occasional rollback). The end state would be that the role gets called by AWX tower as a scheduled task that would align with a customers patching cadence/requirements (eg publish a new version every Tuesday, promote the dev LCE to the new version on Wednesday, so on and so forth). This gives the customer the ability to do something of a 'set it and forget it' style, but at the same time getting the process to align with their business requirements. |
| resource: content_views | ||
| search: name = "{{ content_view }}" | ||
| validate_certs: false | ||
| register: content_view_data |
There was a problem hiding this comment.
You can use the dedicated info module now: https://github.com/theforeman/foreman-ansible-modules/blob/develop/plugins/modules/content_view_info.py
There was a problem hiding this comment.
Does it make sense to have roles that utilize modules that aren't even in a main version yet? By using the existing format, this role will be backwards compatible with older versions of the collection.
There was a problem hiding this comment.
Chiming in here, I think it does make sense. The primary way we expect users would consume this role would be to install the collection.
If they install the development branch from git they would have access to all of the latest modules. Of course it is more likely that they install one of the released versions from ansible galaxy, or a downstream RPM packaged version.... in each case still by the time this role is included in any of those releases, so too would be all modules currently present at development time.
Is this contrary to your expectation, @bmarlow ?
There was a problem hiding this comment.
@wbclark I think its fair to assume people are going to get this by way of the collection so no need to worry there.
I guess my statement is more that I don't think it makes sense to build a role against a module that is in development as changes that happen to that module could potentially break the role.
As it sits (and based on the way that roles are consumed/delivered), I would think we wouldn't care which module got used as long as it worked (unless there was a significant performance benefit or depreciation issue) due to the fact that the user shouldn't really be modifying the role, but rather changing the variables that the role digests.
I haven't had a chance to use the new module yet, however my biggest concern would be that the data returned isn't structured the same way (maybe it is?) and it would require more significant refactoring (and lets face it, the data returned isn't the most easily parsable.
| resource: content_view_versions | ||
| params: | ||
| content_view_id: "{{ content_view_data.resources[0].id }}" | ||
| register: version_information |
There was a problem hiding this comment.
There should be a dedicated module for this as well in the next few days: #1169
Could be good feedback before merging it whether it handles your use case.
| with_dict: "{{ environments }}" | ||
|
|
||
|
|
||
| # only publish new view if necessary (when the current view is at or above library) |
There was a problem hiding this comment.
I do not fully understand this logic. Or the circumstances under which it may occur.
There was a problem hiding this comment.
If your content-view's highest version number is 22, and that is also where your life-cycle environment is then we need to publish a new version prior to promoting- since you cannot promote to version 22+1 if version 23 doesn't exist.
Co-authored-by: Eric Helms <[email protected]>
Co-authored-by: Eric Helms <[email protected]>
We discussed this PR during our triage this week (anybody is welcome to join btw) and arrived at the following thoughts on how to proceed. There seems to be three primary functions contained in this that could be approached as independent roles:
We realize this creates additional work for additional roles but building re-usable roles would be beneficial to users and then also be consumed by this specific workflow. For example, #1209 I can also dedicate some time to help get these available.
|
|
Just for clarification sake- is the intent here that a role should only have one purpose and be as singular as possible? For the record, the currently proposed role can do all, or just one of the things listed in the three proposed new roles. I can refactor if that is the desire of the team here, just looking for a little clarification with regards to role structures. |
add role for promoting, publishing and rolling back content-views