CBS Tags Hierarchy

Home » CentOS-Virt » CBS Tags Hierarchy
CentOS-Virt 14 Comments

Hi, following Cloud SIG example[1] I would like to start defining the CBS tags hierarchy for Virt SIG.

For opening the discussion I suggest:

– virt${release}-common : packages not related to xen or kvm, used by at least 2 projects
– virt${release}-xen : xen hypervisor related packages
– virt${release}-kvm : kvm hypervisor related packages (like qemu-kvm-ev)
– virt${release}-ovirt : ovirt packages and dependencies, not required by other projects
– virt${release}-docker : docker packages and dependencies, not required by other projects

Comments are welcome!

[1] https://bugs.CentOS.org/view.php?id

14 thoughts on - CBS Tags Hierarchy

  • note that we want git branch, koji builds, release tags and test project, sign request queue and release process to map to a single
    ‘TAG’, will this still work ?

  • Il 19/03/2015 15:46, George Dunlap ha scritto:

    anybody else with comments on above proposal?
    Should I open the bug requesting above branches/tags/targets/…. ?

  • how would we sync the different branch names ?

    note: the proposal here is going to result in ~ 24 different branches for each target ( into git.CentOS.org )

  • when replying to a conversation on a list, can we please stop CC’ing everyone on the thread. Its a mailing list, not a CC expander.

    – KB

  • Il 20/03/2015 11:29, Karanbir Singh ha scritto:

    We can reduce it a bit, just keeping virt7-ovirt instead of virt${release}-ovirt; no plan to get it on el6 right now. We can also drop common if we decide to provide the same rpm in 2 or more different projects repo. I’m not sure it’s wise to do the same for the kvm target.

  • Can you detail the ovirt plan for the Virt SIG – so far, I dont think we’ve seen any ovirt content at all. Apologies if I’ve missed a conversation in the past around this, feel free to point me at that instead if its easier.

    The key thing here to keep in mind is that we want the auth and acl process to be simple for the entire pipeline. This starts from Git all the way to having released content on the mirrors. Take a look at this as an example of what the entire pipeline looks like :
    ref:
    http://lists.CentOS.org/pipermail/CentOS-devel/attachments/20150316/e6b4b15d/attachment.png

    Given that SIG subslipts are going to be an issue ( and are for Storage and Cloud infra SIG, in addition to the Virt SIG already ), we might need to rethink that a bit, hence my question on how this mapping will work.

  • Il 20/03/2015 12:22, Karanbir Singh ha scritto:

    Packages built and in queue:
    http://wiki.CentOS.org/SpecialInterestGroup/Virtualization/Roadmap

    How to test:
    http://wiki.CentOS.org/HowTos/oVirt

    So far, with the packages in the CentOS Virt SIG you can provision the hypervisors / gluster hosts with oVirt 3.5.1.1 packages for VDSM and latest qemu-kvm-ev.

    The manager is not yet packaged for CentOS, missing several required dependencies that in ovirt repositories are provided by binary wrapper rpm packages.

  • Sorry, I don’t understand this question.

    Sorry again for being a bit dense, but I’m not seeing the math here. According to the diagram you link to below, the structure would be rpms/[package].git sigvirt-{common,xen,kvm,docker,ovirt}/{6,7}, which would give us 10 total targets and branches, of which each individual group will only need to have access to 1-2 (common and xen probably for me, docker for lokesh, ovirt and kvm for Sandro & co).

    What am I missing? And is there any other way to break it down such that each of the projects (Docker, Xen, oVirt) can update common packages like the kernel without stepping on each others’ toes?

    -George

  • Il 03/04/2015 08:23, Sandro Bonazzola ha scritto:

    Looks like I’ve lost the bug during the bugzilla migration last week. I’ll reopen one.