[JIRA] (OVIRT-2212) Document the steps needed to add a new distro
for CI slaves
by Eyal Edri (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2212?page=com.atlassian.jir... ]
Eyal Edri commented on OVIRT-2212:
----------------------------------
[~accountid:557058:caa507e4-2696-4f45-8da5-d2585a4bb794] is this something [~accountid:5c977456c430371a3c67dbf6] can handle? now that he helped with upgrading to new Fedora?
> Document the steps needed to add a new distro for CI slaves
> -----------------------------------------------------------
>
> Key: OVIRT-2212
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2212
> Project: oVirt - virtualization made easy
> Issue Type: Task
> Components: Documentation, Jenkins Slaves
> Reporter: Evgheni Dereveanchin
> Assignee: infra
>
> Adding a new distro/architecture to CI involves multiple steps like installing software, creating users, managing software mirrors. This process needs to be documented on ReadTheDocs
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100110)
5 years, 1 month
[JIRA] (OVIRT-1678) Move gerrit-admin project to be standard CI
by Eyal Edri (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1678?page=com.atlassian.jir... ]
Eyal Edri commented on OVIRT-1678:
----------------------------------
[~accountid:557058:5ca52a09-2675-4285-a044-12ad20f6166a] can it be done by [~accountid:5c977456c430371a3c67dbf6] as part of learning STD-CI?
> Move gerrit-admin project to be standard CI
> -------------------------------------------
>
> Key: OVIRT-1678
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1678
> Project: oVirt - virtualization made easy
> Issue Type: Task
> Components: Gerrit/git, Gerrit Hooks
> Reporter: Eyal Edri
> Assignee: infra
>
> Since we're moving all projects on CI to be a std-ci project ( i.e have automation/ dir with all the relevant scripts inside ), we should also move the gerrit-admin project which holds all the code for the Gerrit hooks.
> This will help lay the ground for adding unit-tests and deployments for the hooks in a standard way.
> I would start with adding a 'check-patch.sh' script which will do basic sanity on the code, maybe using partner-bugizlla instance and a test bug for testing the hooks.
> It's also a great way to learn more about how to create a stanard CI project.
> More info on it can be found on the infra docs page:
> http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Build_and_test_standa...
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100110)
5 years, 1 month
[JIRA] (OVIRT-1448) Enable devs to specifiy patch dependencies for
OST
by Eyal Edri (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1448?page=com.atlassian.jir... ]
Eyal Edri commented on OVIRT-1448:
----------------------------------
[~accountid:557058:5fc78873-359e-47c9-aa0b-4845b0da8143] can we close this since patch dependencies will be included as part of the Zuul deployment?
> Enable devs to specifiy patch dependencies for OST
> --------------------------------------------------
>
> Key: OVIRT-1448
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1448
> Project: oVirt - virtualization made easy
> Issue Type: Improvement
> Components: oVirt CI
> Reporter: Barak Korren
> Assignee: infra
> Labels: change-queue
>
> We have an issue with our system ATM where if there are patches for different projects that depend on one another, the system is unaware of that dependency.
> What typically happens in this scenario is that sending the dependent patch makes the experimental test fail and keep failing until the other patch is also merged.
> The change queue will handle this better, but the typical behaviour for it would be to reject both patches, unless they are somehow coordinated to make it into the same test.
> The change queue core code already includes the ability to track and understand dependencies between changes. What is missing is the ability for developers to specify theses dependencies.
> We would probably want to adopt OpenStack's convention here.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100110)
5 years, 1 month
[JIRA] (OVIRT-2002) Sun-setting foreman and puppet for oVirt
by Eyal Edri (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2002?page=com.atlassian.jir... ]
Eyal Edri commented on OVIRT-2002:
----------------------------------
[~accountid:557058:caa507e4-2696-4f45-8da5-d2585a4bb794] I suggest to split this ticket to 2 at least, and focusing on dropping puppet in favor of Ansible.
Right now we only have Jenkins server left and resources that are still using puppet?
> Sun-setting foreman and puppet for oVirt
> -----------------------------------------
>
> Key: OVIRT-2002
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2002
> Project: oVirt - virtualization made easy
> Issue Type: Task
> Reporter: Eyal Edri
> Assignee: infra
>
> This is a tracking ticket for an effort to stop using Foreman and puppet on oVirt.
> Work has already begun to decouple Jenkins slaves from puppet by using glboal_setup.sh scripts, however, there are still services that use it and foreman for user mgmt and production VMs.
> Maintaining the foreman and puppet services including future required upgrades for security or bug fixing takes time and effort from the team without too much value.
> We should look into alternatives that won't require maintaining new services and reduce load from the team,
> E.g - using Ansible playbooks to deploy servers instead of puppet and using a different way to handle users ( Ansible also ? )
> Please use this as a parent ticket to track all sub-tasks relevant to this effort.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100110)
5 years, 1 month