At 10am CST / 16:00 UTC we'll be starting the packaging office hours discussion for SIGs and Variants. if you've got some questions you'd like us to address, please email them to us, or ask your questions via irc in #centos-devel on freenode.
If you want to just follow along, we'll be broadcasting the session via http://www.centos.org/media/
On 01/20/2014 03:03 PM, Jim Perrin wrote:
At 10am CST / 16:00 UTC we'll be starting the packaging office hours discussion for SIGs and Variants. if you've got some questions you'd like us to address, please email them to us, or ask your questions via irc in #centos-devel on freenode.
Hi.
I see you avoided talking about priorities of the repositories, and I actually spent last 10 minutes smiling (not laughing, but smiling) and thinking how easy you could solve all of what you talked with carefully configured priorities.
Here is what you can do with priorities:
Let's say you have current repo-core (base, updates,...) priority=50, repo-epel priority=40, internal repo-centosplus and repo-extras with priority=30, repo-cloud priority=20 for common packages for all Variants/products/packages inside Cloud SiG, and repo-openstack, repo-cloudstack, repo-ovirt and repo-opennebula with priority=10.
(For repositories that do not have priorities set, default would become priority of the base/core repo, in this case 50. Additional plugin of function would offer to add "Priorities=" for any repo inside /yum.repos.d/ and we could urge all 3rd party repos to publish new release packages ...bla, bla, bla, some or all that I proposed)
So distribution of packages is following, higher repo=higher priority:
repo-openstack repo-cloudstack repo-ovirt repo-opennebula packageZ-6.7.1 kernel-2.6.32-431-cs packageZ-6.6.5
repo-cloud kernel-2.6.32-431-cloud packageY-3.0.1 packageZ-6.6.2
repo-centosplus repo-extras kernel-2.6.32-431-centosplus packageX-1.0.3
repo-epel packageZ-6.5.8
repo-core kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7
So regular CentOS would use only repo-core and packages: kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7
Those that add EPEL would also have additional packages so their list of visible packages would be: kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7 packageZ-6.5.8
Those that on repo-core and EPEL add repo-centosplus and repo-extras would have their list of visible packages (for update for example): kernel-2.6.32-431-centosplus packageX-1.0.3 packageY-2.5.7 packageZ-6.5.8
Anyone wanting to use Cloud option packages that do not have special demands but only use common packages without overlap would use: repo-core, repo-epel,repo-centosplus, repo-extras, repo-cloud, and would have their list of visible packages (for update for example): kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenNebula (in this example), they would also have turned on repo-opennebula on top of repo-cloud, but since it is empty, their list of visible packages would be same as above: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenStack (in this example), they would also have turned on repo-openstack on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.7.1
For people using OpenStack (in this example), they would also have turned on repo-cloudstack on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cs packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenStack (in this example), they would also have turned on repo-ovirt on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.5
All packages in lower priority repositories would be hidden (unless forced) and would not mess with higher priority repositories.
Even if some package from one of the higher repositories would show up in upstream or EPEL, and/or even if that package would have higher version, priorities would block an update by default since package with that name already exists in higher repository.
Allowing that new package from upstream to be visible would be automatic (for users), you just have to remove package with same name from higher repository, no need to mess with include/exclude hell on each installed system or to release new <name>-release package for each change, just remove it from higher repository.
And you can even do it partially. You could for example remove it from repo-cloud and/but move it to a higher repository where older version is needed. So if only OpenStack needs older version, new package would be moved from repo-cloud to repo-openstack.
If only one Cloud software could use newer package from upstream, lets say oVirt, but not others, package from repo-cloud would be kept, but version from upstream would be "repeated"/doubled in repo-ovirt.
That would provide security for people using clouds based on CentOS that sudden upstreams change would crash their systems.
Similar automatic process (for users) would be to add newer versions of some package. Let's say OpenNebula needs newer version. They first add it into their repo-opennebula and use it. The others from SiG test their software with that version, and then you held a meeting and see what to do. You either move that packages down to repo-cloud, or not. If you do, single repo can, if necessary, add older version so they keep compatibility while others move on.
And it is ALL transparent to ALL users, all they have to do is to refresh their yum and new arrangement is already there, ready for update.
I do not see how you can beat centralized management like that with any priority-flat-based system you are contemplating about where multiple repositories have same priorities and can override one another with only version bump.
It will be interesting following the development of this issue.
On 01/21/2014 03:04 PM, Ljubomir Ljubojevic wrote: .
I see you avoided talking about priorities of the repositories, and I actually spent last 10 minutes smiling (not laughing, but smiling) and thinking how easy you could solve all of what you talked with carefully configured priorities.
It wasn't intentional. It's not something I normally consider (as I've stated a few times). You should have joined and discussed it with us.
Here is what you can do with priorities:
Let's say you have current repo-core (base, updates,...) priority=50, repo-epel priority=40, internal repo-centosplus and repo-extras with priority=30, repo-cloud priority=20 for common packages for all Variants/products/packages inside Cloud SiG, and repo-openstack, repo-cloudstack, repo-ovirt and repo-opennebula with priority=10.
(For repositories that do not have priorities set, default would become priority of the base/core repo, in this case 50. Additional plugin of function would offer to add "Priorities=" for any repo inside /yum.repos.d/ and we could urge all 3rd party repos to publish new release packages ...bla, bla, bla, some or all that I proposed)
So distribution of packages is following, higher repo=higher priority:
repo-openstack repo-cloudstack repo-ovirt repo-opennebula packageZ-6.7.1 kernel-2.6.32-431-cs packageZ-6.6.5
repo-cloud kernel-2.6.32-431-cloud packageY-3.0.1 packageZ-6.6.2 repo-centosplus repo-extras kernel-2.6.32-431-centosplus packageX-1.0.3 repo-epel packageZ-6.5.8 repo-core kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7So regular CentOS would use only repo-core and packages: kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7
Those that add EPEL would also have additional packages so their list of visible packages would be: kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7 packageZ-6.5.8
Those that on repo-core and EPEL add repo-centosplus and repo-extras would have their list of visible packages (for update for example): kernel-2.6.32-431-centosplus packageX-1.0.3 packageY-2.5.7 packageZ-6.5.8
Anyone wanting to use Cloud option packages that do not have special demands but only use common packages without overlap would use: repo-core, repo-epel,repo-centosplus, repo-extras, repo-cloud, and would have their list of visible packages (for update for example): kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenNebula (in this example), they would also have turned on repo-opennebula on top of repo-cloud, but since it is empty, their list of visible packages would be same as above: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenStack (in this example), they would also have turned on repo-openstack on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.7.1
For people using OpenStack (in this example), they would also have turned on repo-cloudstack on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cs packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenStack (in this example), they would also have turned on repo-ovirt on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.5
All packages in lower priority repositories would be hidden (unless forced) and would not mess with higher priority repositories.
This is a reasonably limited example. As you've proposed it, it will work. What you've proposed is only a subset of actual use cases though.It's already been demonstrably shown by others on this list that there are situations where this fails. You're trying to address this issue from a user perspective. I'm trying to solve it from a packaging/distribution one. These are not the same.
Even if some package from one of the higher repositories would show up in upstream or EPEL, and/or even if that package would have higher version, priorities would block an update by default since package with that name already exists in higher repository.
Allowing that new package from upstream to be visible would be automatic (for users), you just have to remove package with same name from higher repository, no need to mess with include/exclude hell on each installed system or to release new <name>-release package for each change, just remove it from higher repository.
I never had any intention of messing with includes/excludes. That's up to users and admins.
And you can even do it partially. You could for example remove it from repo-cloud and/but move it to a higher repository where older version is needed. So if only OpenStack needs older version, new package would be moved from repo-cloud to repo-openstack.
You're thinking about this in the wrong scope. The distribution shouldn't be in the business of moving SIG packages around. The SIGs need to do this, collaborating among themselves if possible. If we as a distribution need to step in to do this, it should either be in a mentoring context, or as a mediator.
If only one Cloud software could use newer package from upstream, lets say oVirt, but not others, package from repo-cloud would be kept, but version from upstream would be "repeated"/doubled in repo-ovirt.
That would provide security for people using clouds based on CentOS that sudden upstreams change would crash their systems.
We cannot dictate this. We can recommend that they all use a common package, enforcing this would arbitrarily prevent some SIGs from progressing.
Similar automatic process (for users) would be to add newer versions of some package. Let's say OpenNebula needs newer version. They first add it into their repo-opennebula and use it. The others from SiG test their software with that version, and then you held a meeting and see what to do. You either move that packages down to repo-cloud, or not. If you do, single repo can, if necessary, add older version so they keep compatibility while others move on.
This works without priorities as well.
It will be interesting following the development of this issue.
Why follow? The benefit with the structure we're working to implement is that you're free to change most every aspect of it.
On 01/22/2014 08:17 PM, Jim Perrin wrote:
On 01/21/2014 03:04 PM, Ljubomir Ljubojevic wrote: .
I see you avoided talking about priorities of the repositories, and I actually spent last 10 minutes smiling (not laughing, but smiling) and thinking how easy you could solve all of what you talked with carefully configured priorities.
It wasn't intentional. It's not something I normally consider (as I've stated a few times). You should have joined and discussed it with us.
I was so swamped that I failed to realize it was Jan 20th.
Here is what you can do with priorities:
Let's say you have current repo-core (base, updates,...) priority=50, repo-epel priority=40, internal repo-centosplus and repo-extras with priority=30, repo-cloud priority=20 for common packages for all Variants/products/packages inside Cloud SiG, and repo-openstack, repo-cloudstack, repo-ovirt and repo-opennebula with priority=10.
(For repositories that do not have priorities set, default would become priority of the base/core repo, in this case 50. Additional plugin of function would offer to add "Priorities=" for any repo inside /yum.repos.d/ and we could urge all 3rd party repos to publish new release packages ...bla, bla, bla, some or all that I proposed)
So distribution of packages is following, higher repo=higher priority:
repo-openstack repo-cloudstack repo-ovirt repo-opennebula packageZ-6.7.1 kernel-2.6.32-431-cs packageZ-6.6.5
repo-cloud kernel-2.6.32-431-cloud packageY-3.0.1 packageZ-6.6.2 repo-centosplus repo-extras kernel-2.6.32-431-centosplus packageX-1.0.3 repo-epel packageZ-6.5.8 repo-core kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7So regular CentOS would use only repo-core and packages: kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7
Those that add EPEL would also have additional packages so their list of visible packages would be: kernel-2.6.32-431 packageX-1.0.0 packageY-2.5.7 packageZ-6.5.8
Those that on repo-core and EPEL add repo-centosplus and repo-extras would have their list of visible packages (for update for example): kernel-2.6.32-431-centosplus packageX-1.0.3 packageY-2.5.7 packageZ-6.5.8
Anyone wanting to use Cloud option packages that do not have special demands but only use common packages without overlap would use: repo-core, repo-epel,repo-centosplus, repo-extras, repo-cloud, and would have their list of visible packages (for update for example): kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenNebula (in this example), they would also have turned on repo-opennebula on top of repo-cloud, but since it is empty, their list of visible packages would be same as above: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenStack (in this example), they would also have turned on repo-openstack on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.7.1
For people using OpenStack (in this example), they would also have turned on repo-cloudstack on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cs packageX-1.0.3 packageY-3.0.1 packageZ-6.6.2
For people using OpenStack (in this example), they would also have turned on repo-ovirt on top of repo-cloud, and their list of visible packages would be: kernel-2.6.32-431-cloud packageX-1.0.3 packageY-3.0.1 packageZ-6.6.5
All packages in lower priority repositories would be hidden (unless forced) and would not mess with higher priority repositories.
This is a reasonably limited example. As you've proposed it, it will work. What you've proposed is only a subset of actual use cases though.It's already been demonstrably shown by others on this list that there are situations where this fails. You're trying to address this issue from a user perspective. I'm trying to solve it from a packaging/distribution one. These are not the same.
If CentOS has any desire to expand on the market share, it should stop being "only-for-admins" distro.
Even if some package from one of the higher repositories would show up in upstream or EPEL, and/or even if that package would have higher version, priorities would block an update by default since package with that name already exists in higher repository.
Allowing that new package from upstream to be visible would be automatic (for users), you just have to remove package with same name from higher repository, no need to mess with include/exclude hell on each installed system or to release new <name>-release package for each change, just remove it from higher repository.
I never had any intention of messing with includes/excludes. That's up to users and admins.
And you can even do it partially. You could for example remove it from repo-cloud and/but move it to a higher repository where older version is needed. So if only OpenStack needs older version, new package would be moved from repo-cloud to repo-openstack.
You're thinking about this in the wrong scope. The distribution shouldn't be in the business of moving SIG packages around. The SIGs need to do this, collaborating among themselves if possible. If we as a distribution need to step in to do this, it should either be in a mentoring context, or as a mediator.
If top few repositories "belong" to in this case Cloud SiG, then "you" = Cloud SiG Board or whatever. I thought that people from CentOS Project would coordinate/oversee SiG's. It does not really matter who controls the repositories for priority based repositories to work, providing that there is communication between people maintaining them. But even if there is no real coordination, those on top creating Variants still can control state of their products/software.
If only one Cloud software could use newer package from upstream, lets say oVirt, but not others, package from repo-cloud would be kept, but version from upstream would be "repeated"/doubled in repo-ovirt.
That would provide security for people using clouds based on CentOS that sudden upstreams change would crash their systems.
We cannot dictate this. We can recommend that they all use a common package, enforcing this would arbitrarily prevent some SIGs from progressing.
I said nothing about enforcing. I was just explaining even such cases are easy to solve.
Similar automatic process (for users) would be to add newer versions of some package. Let's say OpenNebula needs newer version. They first add it into their repo-opennebula and use it. The others from SiG test their software with that version, and then you held a meeting and see what to do. You either move that packages down to repo-cloud, or not. If you do, single repo can, if necessary, add older version so they keep compatibility while others move on.
This works without priorities as well.
It will be interesting following the development of this issue.
Why follow? The benefit with the structure we're working to implement is that you're free to change most every aspect of it.
But I am not allowed to do what matters, not if your official policy is different.
My opinion is that if I were to start Desktop Variant (my interest), I would have to replace centos-release with centos-desktop-release with yum-plugin-priorities mandatory and all repositories with modified priorities.
I would also have to add several <repository>-release packages or to just add <repository>.repo and GPG key files as default. That would include 3rd party repositories like RPMFussion with not-so-legal packages. No actual packages, just .repo files provided.
So far, I understood that neither are allowed. First will be considered non-CentOS, and you will not sign-on on second, and crucial packages will not be supported by CentOS, since CentOS does not want or can not be associated with 3rd party repositories, and those will not be allowed on git.centos.org.
So what we come down, if what I wrote is essentially true, or remains true to is non-CentOS name and separate infrastructure are required. Since only few .repo files are needed, infra is not a problem, just few maintainers coming together and producing a brand not associated with CentOS.
Most of the packages could be moved to newly formed repositories, but with various people hitting various restrictions, I am betting that most of 3rd party repositories will stay outside of git.centos.org. If they can not shut them down, they will want to keep the number of packages they care about. And that will mean 3rd party repository issue will not go away.
But that is not what I had in mind, I wanted that CentOS, just like other distributions are tolerant of at least some 3rd party repositories.
Since: - official support of such repositories is not allowed (having their <reposotiry>.repo files provided out of the box), - you will not support solution via priorities that would make their adding easy for the user, - there are no people supporting my solution, then I do not see Desktop Variant, of any market share value anyway, will be possible.
And without support from others I do not see any need to waste my energy to confront you repeatedly. So this will be the end of my push for mentioned changes.
On Wed, Jan 22, 2014 at 2:33 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
If CentOS has any desire to expand on the market share, it should stop being "only-for-admins" distro.
No, the base distribution has to remain a toolbox with all the options. It should be the role of the SIGs to build respins already configured for common uses. But, consider the problem it introduces if you expect the respins to pull updates directly from the base. A distro like ClearOS is going to have configuration/management packages that operate on top of the stock packages. That means that every time one of the managed stock packages is updated there is a chance (rare, but it happens) that its config options will change in a way that will break things and it should be held back until the corresponding change is made in the wrapper packages. That's not a problem if every SIG mirrors all of the base updates so they can manage the timing, but that seems horribly inefficient.
On 01/22/2014 09:53 PM, Les Mikesell wrote:
On Wed, Jan 22, 2014 at 2:33 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
If CentOS has any desire to expand on the market share, it should stop being "only-for-admins" distro.
No, the base distribution has to remain a toolbox with all the options. It should be the role of the SIGs to build respins already configured for common uses. But, consider the problem it introduces if you expect the respins to pull updates directly from the base. A distro like ClearOS is going to have configuration/management packages that operate on top of the stock packages. That means that every time one of the managed stock packages is updated there is a chance (rare, but it happens) that its config options will change in a way that will break things and it should be held back until the corresponding change is made in the wrapper packages. That's not a problem if every SIG mirrors all of the base updates so they can manage the timing, but that seems horribly inefficient.
If you do not have priorities in place, all hell can break loose. If you have priorities in place, then rebuild of important package can trigger an alarm for SiG that relies on that package, and as a prevention measure that SiG can place older package in their own repository (that has higher priority) until they can assess the situation. Main CentOS devs would also be alerted and would, if this was agreed upon, wait with release of update, or maybe CentOS devs would move older package in SiG's repo, or some sort of automatic move of older package would be arranged.
Anyway, old package would be lifted to higher repo and only then newer package would be pushed to the Core reposiitory. That way regular CentOS users would get updated package, but users of that SiG's Variant would be able to keep older version.
As soon as SiG sees there is no problem, simple removal of older package from higher (SiG's) repository would provide their users with updated package.
A carefully listened to Mike when he said something like that kind of alerts is possible, to alert a builder of associated SiG that extra care is needed (tags?). He can correct me if I am wrong about alerts.
On Wed, Jan 22, 2014 at 4:45 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
Main CentOS devs would also be alerted and would, if this was agreed upon, wait with release of update, or maybe CentOS devs would move older package in SiG's repo, or some sort of automatic move of older package would be arranged.
I don't think it is reasonable for the main repo to hold packages back. Is what it would do to the mirrors reasonable to push duplicates to the SIG repos so the timing can be managed separately?
A carefully listened to Mike when he said something like that kind of alerts is possible, to alert a builder of associated SiG that extra care is needed (tags?). He can correct me if I am wrong about alerts.
Knowing when to run tests is one thing. Waiting for everyone to test and fix everything is something else.
On 01/22/2014 11:55 PM, Les Mikesell wrote:
On Wed, Jan 22, 2014 at 4:45 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
Main CentOS devs would also be alerted and would, if this was agreed upon, wait with release of update, or maybe CentOS devs would move older package in SiG's repo, or some sort of automatic move of older package would be arranged.
I don't think it is reasonable for the main repo to hold packages back. Is what it would do to the mirrors reasonable to push duplicates to the SIG repos so the timing can be managed separately?
A carefully listened to Mike when he said something like that kind of alerts is possible, to alert a builder of associated SiG that extra care is needed (tags?). He can correct me if I am wrong about alerts.
Knowing when to run tests is one thing. Waiting for everyone to test and fix everything is something else.
If automatic copy to SiG's repository is possible, or maybe for Core devs to copy it them selves manually would do it.
And I have not said Core repo would hold back updates until everyone test it. Please read more carefully, because I said COPY CURENT TO SIGS REPOSITORY AND THEN PUBLISH UPDATE, so nothing is broken on systems using SiG's repository. I hope this was more clear explanation.
On Wed, Jan 22, 2014 at 5:15 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
If automatic copy to SiG's repository is possible, or maybe for Core devs to copy it them selves manually would do it.
And I have not said Core repo would hold back updates until everyone test it. Please read more carefully, because I said COPY CURENT TO SIGS REPOSITORY AND THEN PUBLISH UPDATE, so nothing is broken on systems using SiG's repository. I hope this was more clear explanation.
I understood what you meant, but my question is about the mirroring infrastructure. Personally I'd like to see dozens if not more 'ready as installed' respins for different purposes. If you have to push all the base packages (or even a lot..) into the respin's specific update repo as the only way to control what yum will do, won't that add a huge burden to the repo mirroring infrastructure as all those copies have to replicate? Or if you look at it from the other direction, could there be a better way of telling yum when to update a package than keeping newer things out of all of the repository it uses?
On 01/23/2014 12:32 AM, Les Mikesell wrote:
On Wed, Jan 22, 2014 at 5:15 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
If automatic copy to SiG's repository is possible, or maybe for Core devs to copy it them selves manually would do it.
And I have not said Core repo would hold back updates until everyone test it. Please read more carefully, because I said COPY CURENT TO SIGS REPOSITORY AND THEN PUBLISH UPDATE, so nothing is broken on systems using SiG's repository. I hope this was more clear explanation.
I understood what you meant, but my question is about the mirroring infrastructure. Personally I'd like to see dozens if not more 'ready as installed' respins for different purposes. If you have to push all the base packages (or even a lot..) into the respin's specific update repo as the only way to control what yum will do, won't that add a huge burden to the repo mirroring infrastructure as all those copies have to replicate? Or if you look at it from the other direction, could there be a better way of telling yum when to update a package than keeping newer things out of all of the repository it uses?
Bare in mind we are talking here only about newly emerged issues, because if SiG has had a problem with some package in the past, chances are that modified version is already in higher SiG's repository.
Lets go back a little. RHEL packages mostly and mainly are built so there are NO drastic changes. Every update must provide exactly the same behavior. I am not knowledgeable about this, but I would think that Red Hat warns it some package changes it's behavior? Changelog in rpm's would be an indication of made changes, right?
So I do not expect large number of "dangerous" packages. 1. SiG's would mark any upstream/Core package they depend on 2. rpm can be limited to max version allowed, so if newer version is available, update of that new package, on a system with SiG's package having that limit, would not be possible.
Where you are thinking of huge number of largely different packages, I am thinking of majority of updates being minor bug fixes and large number of packages only with new distro version, 6.4->6.5->6.6, etc.
On Wed, Jan 22, 2014 at 5:48 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
Bare in mind we are talking here only about newly emerged issues, because if SiG has had a problem with some package in the past, chances are that modified version is already in higher SiG's repository.
I don't have a working SME or ClearOS box right now. Can someone comment on whether they let yum hit the base or epel repos directly now? Or do they have local or renamed copies of the things they manage?
Lets go back a little. RHEL packages mostly and mainly are built so there are NO drastic changes. Every update must provide exactly the same behavior.
Agreed, but everyone will still advise testing all of your packages together before pushing to anything important. With management /control packages, not only does the behavior have to stay the same but also the formats of the configuration files.
Where you are thinking of huge number of largely different packages, I am thinking of majority of updates being minor bug fixes and large number of packages only with new distro version, 6.4->6.5->6.6, etc.
I'm not thinking of largely different files, I'm thinking of files that depend very closely on each other and need to be constrained to update together - perhaps from repos managed separately.
On 01/23/2014 01:07 AM, Les Mikesell wrote:
On Wed, Jan 22, 2014 at 5:48 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
Bare in mind we are talking here only about newly emerged issues, because if SiG has had a problem with some package in the past, chances are that modified version is already in higher SiG's repository.
I don't have a working SME or ClearOS box right now. Can someone comment on whether they let yum hit the base or epel repos directly now? Or do they have local or renamed copies of the things they manage?
Lets go back a little. RHEL packages mostly and mainly are built so there are NO drastic changes. Every update must provide exactly the same behavior.
Agreed, but everyone will still advise testing all of your packages together before pushing to anything important. With management /control packages, not only does the behavior have to stay the same but also the formats of the configuration files.
Where you are thinking of huge number of largely different packages, I am thinking of majority of updates being minor bug fixes and large number of packages only with new distro version, 6.4->6.5->6.6, etc.
I'm not thinking of largely different files, I'm thinking of files that depend very closely on each other and need to be constrained to update together - perhaps from repos managed separately.
So in your opinion, no Variants should be created, or everyone should duplicate the packages they use like it is done now. Got it.
On Wed, Jan 22, 2014 at 6:45 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
I'm not thinking of largely different files, I'm thinking of files that depend very closely on each other and need to be constrained to update together - perhaps from repos managed separately.
So in your opinion, no Variants should be created, or everyone should duplicate the packages they use like it is done now. Got it.
No, in my opinion both of those would be less than optimal. As would arranging things so they will break unpredictably. But, as far as I can tell, holding the repository version to the version you want deployed is the only way to control yum. I've always thought that was inefficient even in the context of testing against your own local applications. Maybe someone will have a better idea.
On 23/01/14 01:07, Les Mikesell wrote:
On Wed, Jan 22, 2014 at 5:48 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
Bare in mind we are talking here only about newly emerged issues, because if SiG has had a problem with some package in the past, chances are that modified version is already in higher SiG's repository.
I don't have a working SME or ClearOS box right now. Can someone comment on whether they let yum hit the base or epel repos directly now? Or do they have local or renamed copies of the things they manage?
My SME 8 box has this enabled :
http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep...
No EPL repos are there by default AFAIAW
B. Rgds
John
On Thu, Jan 23, 2014 at 4:02 AM, John Crisp jcrisp@safeandsoundit.co.uk wrote:
I don't have a working SME or ClearOS box right now. Can someone comment on whether they let yum hit the base or epel repos directly now? Or do they have local or renamed copies of the things they manage?
My SME 8 box has this enabled :
http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep...
No EPL repos are there by default AFAIAW
But poking around in: http://sme-mirror.firewall-services.com/releases/8/ it looks like the base is duplicated under smeos with stuff from EPEL, etc., in some of the other sections. Do they do something to control where updates come from?
No EPL repos are there by default AFAIAW
But poking around in: http://sme-mirror.firewall-services.com/releases/8/ it looks like the base is duplicated under smeos with stuff from EPEL, etc., in some of the other sections. Do they do something to control where updates come from?
There is a script which copies some rpms needed for dependencies from epel, repoforge, etc.
On 23/01/14 17:02, Les Mikesell wrote:
On Thu, Jan 23, 2014 at 4:02 AM, John Crisp jcrisp@safeandsoundit.co.uk wrote:
I don't have a working SME or ClearOS box right now. Can someone comment on whether they let yum hit the base or epel repos directly now? Or do they have local or renamed copies of the things they manage?
My SME 8 box has this enabled :
http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep...
No EPL repos are there by default AFAIAW
But poking around in: http://sme-mirror.firewall-services.com/releases/8/ it looks like the base is duplicated under smeos with stuff from EPEL, etc., in some of the other sections. Do they do something to control where updates come from?
Absolutely no idea how we work this Les - I'm not a dev :-)
I'll ask and come back to you, unless one of the team is watching this and can short circuit me.
On Thu, Jan 23, 2014 at 10:17 AM, John Crisp jcrisp@safeandsoundit.co.uk wrote:
But poking around in: http://sme-mirror.firewall-services.com/releases/8/ it looks like the base is duplicated under smeos with stuff from EPEL, etc., in some of the other sections. Do they do something to control where updates come from?
Absolutely no idea how we work this Les - I'm not a dev :-)
I'll ask and come back to you, unless one of the team is watching this and can short circuit me.
The big question is whether there is a way to keep a dependent/related package from updating until everything has been tested together when the packages are managed independently in separate repos.
On 01/23/2014 05:39 PM, Les Mikesell wrote:
The big question is whether there is a way to keep a dependent/related package from updating until everything has been tested together when the packages are managed independently in separate repos.
If you compile package that depends on particular version:
Requires: <deppackage1> = 0.8.1
then yum will protest if you try to update newer deppackage1 package. Error will appear, and until you satisfy it nothing will happen.
On Thu, Jan 23, 2014 at 5:50 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
On 01/23/2014 05:39 PM, Les Mikesell wrote:
The big question is whether there is a way to keep a dependent/related package from updating until everything has been tested together when the packages are managed independently in separate repos.
If you compile package that depends on particular version:
Requires: <deppackage1> = 0.8.1
then yum will protest if you try to update newer deppackage1 package. Error will appear, and until you satisfy it nothing will happen.
Yes that could work, but it is not very efficient either. It should be rare for the update to break things but doing that would force you to update every related package after testing just to let the dependency advance even if no changes are required. Which again would make a flurry of traffic in the repositories and mirrors.
-- Les Mikesell lesmikesell@gmail.com
On 01/24/2014 01:15 AM, Les Mikesell wrote:
On Thu, Jan 23, 2014 at 5:50 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
On 01/23/2014 05:39 PM, Les Mikesell wrote:
The big question is whether there is a way to keep a dependent/related package from updating until everything has been tested together when the packages are managed independently in separate repos.
If you compile package that depends on particular version:
Requires: <deppackage1> = 0.8.1
then yum will protest if you try to update newer deppackage1 package. Error will appear, and until you satisfy it nothing will happen.
Yes that could work, but it is not very efficient either. It should be rare for the update to break things but doing that would force you to update every related package after testing just to let the dependency advance even if no changes are required. Which again would make a flurry of traffic in the repositories and mirrors.
--
That is why I pushed for priorities. Everything is dynamic and server/infrastructure/repository side and no package rebuilding, just moving them little, and it should be possible to do it automatic (protection) with git/koji. No amount SCL's and overthinking will beat it's simplicity and universality.
On Thu, Jan 23, 2014 at 6:51 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
The big question is whether there is a way to keep a dependent/related package from updating until everything has been tested together when the packages are managed independently in separate repos.
If you compile package that depends on particular version:
Requires: <deppackage1> = 0.8.1
then yum will protest if you try to update newer deppackage1 package. Error will appear, and until you satisfy it nothing will happen.
Yes that could work, but it is not very efficient either. It should be rare for the update to break things but doing that would force you to update every related package after testing just to let the dependency advance even if no changes are required. Which again would make a flurry of traffic in the repositories and mirrors.
--
That is why I pushed for priorities. Everything is dynamic and server/infrastructure/repository side and no package rebuilding, just moving them little, and it should be possible to do it automatic (protection) with git/koji. No amount SCL's and overthinking will beat it's simplicity and universality.
But won't that require duplicating the packages into all of the higher-priority repos? Is there some magic with symlinks that would work to make it look like they were duplicated?
On 01/24/2014 04:11 AM, Les Mikesell wrote:
On Thu, Jan 23, 2014 at 6:51 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
The big question is whether there is a way to keep a dependent/related package from updating until everything has been tested together when the packages are managed independently in separate repos.
If you compile package that depends on particular version:
Requires: <deppackage1> = 0.8.1
then yum will protest if you try to update newer deppackage1 package. Error will appear, and until you satisfy it nothing will happen.
Yes that could work, but it is not very efficient either. It should be rare for the update to break things but doing that would force you to update every related package after testing just to let the dependency advance even if no changes are required. Which again would make a flurry of traffic in the repositories and mirrors.
--
That is why I pushed for priorities. Everything is dynamic and server/infrastructure/repository side and no package rebuilding, just moving them little, and it should be possible to do it automatic (protection) with git/koji. No amount SCL's and overthinking will beat it's simplicity and universality.
But won't that require duplicating the packages into all of the higher-priority repos? Is there some magic with symlinks that would work to make it look like they were duplicated?
Not to ALL higher repositories. Remember they would be hierarchically structured, so you only need to put older package in repository ONE HIGHER then repository you are putting newer package into.
Links are very much possible, and are applied where ever possible. I do it on my own repository. I personally have a cron script that runs before mrepo and symlinks packages from several repos/directories to one. Physical solutions are many, depending on what is available.
You can keep older package in lower repository just adding new one and then symlink it to higher one. That is mostly done anyway, leaving one older version if regression is needed. Current examples in updates repo are resource-agents, perf, pacemaker, just run:
yum list * --showduplicates --disablerepo=* --enablerepo=updates | grep x86_64
and check duplicated.
But there are circumstances making it easier: 1. packages coming to updates are not many, and SiG's will test them fast, so symlinks or packages can be removed in matter of days and only newly one created will be in line for testing. 2. SiG's will mark packages they are dependent of. There is no need that Xen SiG has to watch "named" package, so only those SiG's depending on functional "named" package (just a simple example) will mark it, will be informed of new version (as soon as it hit's git.centos.org or when it's srpm appears on CentOS of even RHEL file servers), and will get a copy/symlink of older package. 3. Many important packages (for SiG's) will already be replaced with newer version, so those packages will not be marked and will not need any special attention, so business as usual. 4. Every change is logged in Change_log, so maybe on-duty SiG representative can clear package even before actual release to updates folder. 5. When new distro version is releases, Q&A anyhow tests everything, so you can forget that scenario needing this mechanism. Only packages coming to updates repo would be marked, IF they are of interest to SiG's.
Another system can be put in place. Every stable repository will have to have testing repository. So newer package could be symlinked/copied automatically to testing repository of SiG/Variant and Variants/SiG's could have a testing VM with enabled testing repository. So as soon as newer package is released, testing VM could pull new packages and checks would be performed, manual or automatic.
So SiG/Variant would greenlight the newer package much faster then if they do it all by hand. As soon as they greenlight the package, older version would be automatically removed from stable repo, newer package from testing repo and createrepo run would allow everyone using Variants to update to new package. If there is a problem, SiG would decide what needs to be done, but until permanent solution is found, this problem-suppression system would safeguard Variants PR and business model, just like they are doing everything on their own.
Anyone, if you can think of any other problematic scenario, feel free to put this construct of mine to the test.
On Fri, Jan 24, 2014 at 5:56 AM, Ljubomir Ljubojevic centos@plnet.rs wrote:
But won't that require duplicating the packages into all of the higher-priority repos? Is there some magic with symlinks that would work to make it look like they were duplicated?
Not to ALL higher repositories. Remember they would be hierarchically structured, so you only need to put older package in repository ONE HIGHER then repository you are putting newer package into.
Links are very much possible, and are applied where ever possible. I do it on my own repository. I personally have a cron script that runs before mrepo and symlinks packages from several repos/directories to one. Physical solutions are many, depending on what is available.
Sure you could do this yourself, and it might be a solution for my long-standing complaint about needing frozen repository mirrors in states of every update you might want to repeat. But, will it be supported across all the existing mirror infrastructure?
But there are circumstances making it easier:
- packages coming to updates are not many, and SiG's will test them
fast, so symlinks or packages can be removed in matter of days and only newly one created will be in line for testing.
I think that is being optimistic. Think about the number of updates that come in a minor revision update.
- SiG's will mark packages they are dependent of. There is no need that
Xen SiG has to watch "named" package, so only those SiG's depending on functional "named" package (just a simple example) will mark it, will be informed of new version (as soon as it hit's git.centos.org or when it's srpm appears on CentOS of even RHEL file servers), and will get a copy/symlink of older package.
Packages get renamed/split/merged and dependencies added in minor-rev updates. Not sure you can count on existing naming.
- Every change is logged in Change_log, so maybe on-duty SiG
representative can clear package even before actual release to updates folder.
I wouldn't want to restrict SIGs to organizations able to guarantee that.
Another system can be put in place. Every stable repository will have to have testing repository. So newer package could be symlinked/copied automatically to testing repository of SiG/Variant and Variants/SiG's could have a testing VM with enabled testing repository. So as soon as newer package is released, testing VM could pull new packages and checks would be performed, manual or automatic.
I like this, but it depends on the mirror mechanism playing nicely with symlinks - everywhere. In this scenario you could just symlink everything and point the base updates at the SIG, pretending everything was duplicated. And you wouldn't need priorities.
On 01/24/2014 07:38 PM, Les Mikesell wrote:
On Fri, Jan 24, 2014 at 5:56 AM, Ljubomir Ljubojevic centos@plnet.rs wrote:
But won't that require duplicating the packages into all of the higher-priority repos? Is there some magic with symlinks that would work to make it look like they were duplicated?
Not to ALL higher repositories. Remember they would be hierarchically structured, so you only need to put older package in repository ONE HIGHER then repository you are putting newer package into.
Links are very much possible, and are applied where ever possible. I do it on my own repository. I personally have a cron script that runs before mrepo and symlinks packages from several repos/directories to one. Physical solutions are many, depending on what is available.
Sure you could do this yourself, and it might be a solution for my long-standing complaint about needing frozen repository mirrors in states of every update you might want to repeat. But, will it be supported across all the existing mirror infrastructure?
But there are circumstances making it easier:
- packages coming to updates are not many, and SiG's will test them
fast, so symlinks or packages can be removed in matter of days and only newly one created will be in line for testing.
I think that is being optimistic. Think about the number of updates that come in a minor revision update.
Minor versions go under item 5. I'll admit I was not clear enough, but this also applies to minor release versions, 6.0, 6.1, 6.2, 6.3, 6.4, 6.5,.... 7.0, 7.1 ... :
"5. When new distro version is releases, Q&A anyhow tests everything, so you can forget that scenario needing this mechanism. Only packages coming to updates repo would be marked, IF they are of interest to SiG's."
There is enough time in regular Q&A process for SiG's to test their Variants.
- SiG's will mark packages they are dependent of. There is no need that
Xen SiG has to watch "named" package, so only those SiG's depending on functional "named" package (just a simple example) will mark it, will be informed of new version (as soon as it hit's git.centos.org or when it's srpm appears on CentOS of even RHEL file servers), and will get a copy/symlink of older package.
Packages get renamed/split/merged and dependencies added in minor-rev updates. Not sure you can count on existing naming.
Please point me to one instance where Red Hat carelessly split packages with simple updates, not counting switch to minor versions 6.1, 6.2, ...
- Every change is logged in Change_log, so maybe on-duty SiG
representative can clear package even before actual release to updates folder.
I wouldn't want to restrict SIGs to organizations able to guarantee that.
So only organizations can elect a person to watch out for changes?
Another system can be put in place. Every stable repository will have to have testing repository. So newer package could be symlinked/copied automatically to testing repository of SiG/Variant and Variants/SiG's could have a testing VM with enabled testing repository. So as soon as newer package is released, testing VM could pull new packages and checks would be performed, manual or automatic.
I like this, but it depends on the mirror mechanism playing nicely with symlinks - everywhere. In this scenario you could just symlink everything and point the base updates at the SIG, pretending everything was duplicated. And you wouldn't need priorities.
I am guessing such packages needing attention would not occupy more then few hundred megabytes in their peak. Remember that we are not talking about all packages in question, just those freshly updated that haven't been audited yet by SiG's!
On Fri, Jan 24, 2014 at 1:24 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
I think that is being optimistic. Think about the number of updates that come in a minor revision update.
Minor versions go under item 5. I'll admit I was not clear enough, but this also applies to minor release versions, 6.0, 6.1, 6.2, 6.3, 6.4, 6.5,.... 7.0, 7.1 ... :
But yum doesn't know any difference about these. Updates are pulled when the appear.
"5. When new distro version is releases, Q&A anyhow tests everything, so you can forget that scenario needing this mechanism. Only packages coming to updates repo would be marked, IF they are of interest to SiG's."
There is enough time in regular Q&A process for SiG's to test their Variants.
Do we have any historical data on how much lag SME/ClearOS etc. have ever had?
Packages get renamed/split/merged and dependencies added in minor-rev updates. Not sure you can count on existing naming.
Please point me to one instance where Red Hat carelessly split packages with simple updates, not counting switch to minor versions 6.1, 6.2, ...
Those revisions have to work without breakage or being held back for everyone too.
- Every change is logged in Change_log, so maybe on-duty SiG
representative can clear package even before actual release to updates folder.
I wouldn't want to restrict SIGs to organizations able to guarantee that.
So only organizations can elect a person to watch out for changes?
I mean only ones with sufficient redundancy to always have an available person if everyone else is going to have to wait for the release. A mechanism where one SIG's problem accommodating an update doesn't affect anyone else would be better.
Another system can be put in place. Every stable repository will have to have testing repository. So newer package could be symlinked/copied automatically to testing repository of SiG/Variant and Variants/SiG's could have a testing VM with enabled testing repository. So as soon as newer package is released, testing VM could pull new packages and checks would be performed, manual or automatic.
I like this, but it depends on the mirror mechanism playing nicely with symlinks - everywhere. In this scenario you could just symlink everything and point the base updates at the SIG, pretending everything was duplicated. And you wouldn't need priorities.
I am guessing such packages needing attention would not occupy more then few hundred megabytes in their peak. Remember that we are not talking about all packages in question, just those freshly updated that haven't been audited yet by SiG's!
At some point, wouldn't the updates that haven't been audited have to be all of them?
On 01/24/2014 11:08 PM, Les Mikesell wrote:
On Fri, Jan 24, 2014 at 1:24 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
- Every change is logged in Change_log, so maybe on-duty SiG
representative can clear package even before actual release to updates folder.
I wouldn't want to restrict SIGs to organizations able to guarantee that.
So only organizations can elect a person to watch out for changes?
I mean only ones with sufficient redundancy to always have an available person if everyone else is going to have to wait for the release. A mechanism where one SIG's problem accommodating an update doesn't affect anyone else would be better.
I would be happy if you would stop twisting everything I say. If that is not possible, then it's best I just stop feeding you.
On Fri, Jan 24, 2014 at 4:20 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
So only organizations can elect a person to watch out for changes?
I mean only ones with sufficient redundancy to always have an available person if everyone else is going to have to wait for the release. A mechanism where one SIG's problem accommodating an update doesn't affect anyone else would be better.
I would be happy if you would stop twisting everything I say. If that is not possible, then it's best I just stop feeding you.
Twisting? I'm just restating to the best of my understanding. Are you proposing holding back updates in the main repo until they pass testing with all related SIG packages or not?
-
Filippo Carletti -
Jim Perrin -
John Crisp -
Les Mikesell -
Ljubomir Ljubojevic