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=8289
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
I think so... I'm not sure what else we might want.
-George
Il 19/03/2015 15:46, George Dunlap ha scritto:
On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
I think so... I'm not sure what else we might want.
anybody else with comments on above proposal? Should I open the bug requesting above branches/tags/targets/.... ?
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
On 03/20, Sandro Bonazzola wrote:
Il 19/03/2015 15:46, George Dunlap ha scritto:
On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
I think so... I'm not sure what else we might want.
anybody else with comments on above proposal? Should I open the bug requesting above branches/tags/targets/.... ?
Looks ok to me
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 03/20/2015 10:27 AM, David Caro wrote:
On 03/20, Sandro Bonazzola wrote:
Il 19/03/2015 15:46, George Dunlap ha scritto:
On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
I think so... I'm not sure what else we might want.
anybody else with comments on above proposal? Should I open the bug requesting above branches/tags/targets/.... ?
Looks ok to me
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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
On 03/19/2015 02:46 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
I think so... I'm not sure what else we might want.
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 )
Il 20/03/2015 11:29, Karanbir Singh ha scritto:
On 03/19/2015 02:46 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
I think so... I'm not sure what else we might want.
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 )
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.
On 03/20/2015 10:42 AM, Sandro Bonazzola wrote:
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
note: the proposal here is going to result in ~ 24 different branches for each target ( into git.centos.org )
We can reduce it a bit, just keeping virt7-ovirt instead of virt${release}-ovirt; no plan to get it on el6 right now.
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.
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.
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...
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:
On 03/20/2015 10:42 AM, Sandro Bonazzola wrote:
> 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
note: the proposal here is going to result in ~ 24 different branches for each target ( into git.centos.org )
We can reduce it a bit, just keeping virt7-ovirt instead of virt${release}-ovirt; no plan to get it on el6 right now.
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.
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.
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.
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...
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.
On Fri, Mar 20, 2015 at 10:29 AM, Karanbir Singh mail-lists@karan.org wrote:
how would we sync the different branch names ?
Sorry, I don't understand this question.
note: the proposal here is going to result in ~ 24 different branches for each target ( into git.centos.org )
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 19/03/2015 15:46, George Dunlap ha scritto:
On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
I think so... I'm not sure what else we might want.
Opened https://bugs.centos.org/view.php?id=8384
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Il 03/04/2015 08:23, Sandro Bonazzola ha scritto:
Il 19/03/2015 15:46, George Dunlap ha scritto:
On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
I think so... I'm not sure what else we might want.
Looks like I've lost the bug during the bugzilla migration last week. I'll reopen one.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Il 07/04/2015 08:51, Sandro Bonazzola ha scritto:
Il 03/04/2015 08:23, Sandro Bonazzola ha scritto:
Il 19/03/2015 15:46, George Dunlap ha scritto:
On Thu, Mar 19, 2015 at 2:39 PM, Karanbir Singh mail-lists@karan.org wrote:
On 03/19/2015 12:23 PM, George Dunlap wrote:
On Thu, Mar 19, 2015 at 12:20 PM, Sandro Bonazzola sbonazzo@redhat.com wrote:
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
Looks reasonable at first blush.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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 ?
I think so... I'm not sure what else we might want.
Looks like I've lost the bug during the bugzilla migration last week. I'll reopen one.
http://bugs.centos.org/view.php?id=8407
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
-
David Caro -
George Dunlap -
Karanbir Singh -
Sandro Bonazzola