Add IOP #280
Add IOP #280
Conversation
ehelms
force-pushed
the
add-iop
branch
5 times, most recently
from
bfdcd43 to
2fd7276
Compare
ehelms
force-pushed
the
add-iop
branch
2 times, most recently
from
71ce03e to
4cf96ac
Compare
ehelms
force-pushed
the
add-iop
branch
6 times, most recently
from
ddfec69 to
eb1df00
Compare
.github/workflows/test.yml
Outdated
| iop: | ||
| - enabled | ||
| - disabled |
There was a problem hiding this comment.
This will run IoP enabled tests for every combination, thus doubling the matrix. Do we need that?
See how we used security and database with a single entry in the matrix itself and then special additions via include (resulting in one additional job)
There was a problem hiding this comment.
See how we used
securityanddatabasewith a single entry in the matrix itself and then special additions viainclude(resulting in one additional job)
I saw it but I did not understand it.
| - name: Enable iop | ||
| if: matrix.iop == 'enabled' | ||
| run: | | ||
| ./foremanctl deploy --add-feature iop |
There was a problem hiding this comment.
calls to foremanctl deploy are expensive (adds ca 2 minutes to the execution), so I wonder if it'd be smarter to have fewer of those "add optional feature" steps and use something like {{ matrix.iop == 'enabled' && '--add-feature iop' || '' }} inside an existing step
ehelms
force-pushed
the
add-iop
branch
5 times, most recently
from
a200e68 to
ffcfc02
Compare
|
@evgeni For now, I want to keep the same behavior of not supporting remote database yet. Looking at Obsah, I don't think that's possible but I wanted you to check me on that. I need to forbid:
|
Signed-off-by: Eric D. Helms <ericdhelms@gmail.com>
Signed-off-by: Eric D. Helms <ericdhelms@gmail.com>
Signed-off-by: Eric D. Helms <ericdhelms@gmail.com>
Signed-off-by: Eric D. Helms <ericdhelms@gmail.com>
ehelms
force-pushed
the
add-iop
branch
2 times, most recently
from
d5bfe6f to
1b2bf3f
Compare
That's correct, today we can only forbid "if param P has value Y you can't set params A and B at all" You could add a |
I could... just less clear then when do we do parameter validation at the CLI level and when do we do it at the checks level. |
|
Sure, yeah. We could easily enhance obsah to reject things like "if A=1 then B can't be 2", but in your case you need "if A=1 then 2 cant be IN B", and I'm not sure how to nicely express that in metadata |
|
Here is my attempt to implement that structure: theforeman/obsah#104 |
ehelms
force-pushed
the
add-iop
branch
3 times, most recently
from
95c8203 to
acbe14a
Compare
pablomh
left a comment
pablomh
left a comment
There was a problem hiding this comment.
Builds and creates running services :)
| iop_advisor_container_image: "quay.io/iop/advisor-backend" | ||
| iop_advisor_container_tag: "foreman-3.16" | ||
|
|
||
| iop_advisor_database_name: advisor_db |
There was a problem hiding this comment.
All of these vars can be deleted as they are in src/vars/database_iop.yml.
There was a problem hiding this comment.
Role defaults are not the same as playbook defaults. We try to follow Ansible best practices by ensuring these are defined at the role level. We then define them at a higher level for our use case to provide coordination of values and advanced workflows.
There was a problem hiding this comment.
Great! Very good to know. I'll try to implement the same reasoning in #356.
| iop_inventory_container_image: "quay.io/iop/host-inventory" | ||
| iop_inventory_container_tag: "foreman-3.16" | ||
|
|
||
| iop_inventory_database_name: inventory_db |
There was a problem hiding this comment.
All of these vars can be deleted as they are in src/vars/database_iop.yml.
| iop_remediation_container_image: "quay.io/iop/remediations" | ||
| iop_remediation_container_tag: "foreman-3.16" | ||
|
|
||
| iop_remediation_database_name: remediations_db |
There was a problem hiding this comment.
All of these vars can be deleted as they are in src/vars/database_iop.yml.
| iop_vmaas_container_image: "quay.io/iop/vmaas" | ||
| iop_vmaas_container_tag: "foreman-3.16" | ||
|
|
||
| iop_vmaas_database_name: vmaas_db |
There was a problem hiding this comment.
All of these vars can be deleted as they are in src/vars/database_iop.yml.
| iop_vulnerability_container_image: "quay.io/iop/vulnerability-engine" | ||
| iop_vulnerability_container_tag: "foreman-3.16" | ||
|
|
||
| iop_vulnerability_database_name: vulnerability_db |
There was a problem hiding this comment.
All of these vars can be deleted as they are in src/vars/database_iop.yml.
Signed-off-by: Eric D. Helms <ericdhelms@gmail.com>
3 participants
No description provided.