Hi, I installed CentOS 7 today, congratulations, and thank you for this fast release. I found a problem (or a design decision?), deltarpm is not installed by default (minimal install), when I ran "yum distro-sync" I got: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. deltarpm is important to me (and anybody with limited bandwidth), so is this intended or simply a bug?
Regards
On 08/07/14 11:06, Mustafa Muhammad wrote:
Hi, I installed CentOS 7 today, congratulations, and thank you for this fast release. I found a problem (or a design decision?), deltarpm is not installed by default (minimal install), when I ran "yum distro-sync" I got: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. deltarpm is important to me (and anybody with limited bandwidth), so is this intended or simply a bug?
Regards _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
You did a minimal install so the package selection you got is, err, minimal. You can enable delta rpms by installing the binary it needs and told you about. Running
yum provides '*/applydeltarpm'
will show you the package name.
Trevor
On Tue, Jul 8, 2014 at 1:18 PM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
On 08/07/14 11:06, Mustafa Muhammad wrote:
Hi, I installed CentOS 7 today, congratulations, and thank you for this fast release. I found a problem (or a design decision?), deltarpm is not installed by default (minimal install), when I ran "yum distro-sync" I got: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. deltarpm is important to me (and anybody with limited bandwidth), so is this intended or simply a bug?
Regards _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
You did a minimal install so the package selection you got is, err, minimal. You can enable delta rpms by installing the binary it needs and told you about. Running
yum provides '*/applydeltarpm'
will show you the package name.
Trevor _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
I know, I already did, but isn't it supposed to be included in the "minimal installation", it is only "82 k" and it was in CentOS 6 Minimal, please consider adding it, smaller update size makes huge difference in bandwidth (for the users and mirrors).
On 08/07/14 11:28, Mustafa Muhammad wrote:
I know, I already did, but isn't it supposed to be included in the "minimal installation", it is only "82 k" and it was in CentOS 6 Minimal, please consider adding it, smaller update size makes huge difference in bandwidth (for the users and mirrors).
I just did a minimal el6 install and yum-presto is not included there either.
Trevor
On Tue, Jul 8, 2014 at 1:58 PM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
On 08/07/14 11:28, Mustafa Muhammad wrote:
I know, I already did, but isn't it supposed to be included in the "minimal installation", it is only "82 k" and it was in CentOS 6 Minimal, please consider adding it, smaller update size makes huge difference in bandwidth (for the users and mirrors).
I just did a minimal el6 install and yum-presto is not included there either.
Trevor _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
You are right, my bad, not included by default. But again, if there is no reason other than the size for not including it, please consider adding it to the default minimal set (for the bandwidth reasons). Thanks
Minimal should mean just that - absolute minimal set of packages.
If you want anything else installed just add it to your kickstart, or make it the first thing you do post install in whatever provisioning mechanism you use.
All IMHO, of course.
R.
On 8 July 2014 12:25, Mustafa Muhammad mustafaa.alhamdaani@gmail.com wrote:
On Tue, Jul 8, 2014 at 1:58 PM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
On 08/07/14 11:28, Mustafa Muhammad wrote:
I know, I already did, but isn't it supposed to be included in the "minimal installation", it is only "82 k" and it was in CentOS 6 Minimal, please consider adding it, smaller update size makes huge difference in bandwidth (for the users and mirrors).
I just did a minimal el6 install and yum-presto is not included there either.
Trevor _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
You are right, my bad, not included by default. But again, if there is no reason other than the size for not including it, please consider adding it to the default minimal set (for the bandwidth reasons). Thanks _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
As I understand it, Anaconda installs from the newest available packages when doing the initial install. So there's no value to having deltarpm support available early on, since Anaconda won't do updates, it'll just install from the latest. If this is a feature that's important to you, I'd suggest installing it in your kickstart, or immediately after install. As long as it's in place before you run your first 'yum update,' you get the bandwidth gains.
There are probably lots of small utilities that would be useful in a minimal install, but that way lies bloat. I also assume we're tracking upstream's minimal install, so CentOS is rather limited in what it can add without diverging too far.
On Tue, Jul 8, 2014 at 7:25 AM, Mustafa Muhammad < mustafaa.alhamdaani@gmail.com> wrote:
On Tue, Jul 8, 2014 at 1:58 PM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
On 08/07/14 11:28, Mustafa Muhammad wrote:
I know, I already did, but isn't it supposed to be included in the "minimal installation", it is only "82 k" and it was in CentOS 6 Minimal, please consider adding it, smaller update size makes huge difference in bandwidth (for the users and mirrors).
I just did a minimal el6 install and yum-presto is not included there either.
Trevor _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
You are right, my bad, not included by default. But again, if there is no reason other than the size for not including it, please consider adding it to the default minimal set (for the bandwidth reasons). Thanks _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Tue, Jul 8, 2014 at 7:34 AM, Chris St. Pierre chris.a.st.pierre@gmail.com wrote:
As I understand it, Anaconda installs from the newest available packages when doing the initial install. So there's no value to having deltarpm
It does not. It installs from your designated installation media. One can *add* update repositories, or third party repositories, in the kickstart or manual configurations.
If one wishes to install the updates at kickstart time, it's a common option to do a "yum update" as a '%post" steep. But doing so at system install time means that systems installed at slightly diffeent times may have very different sets of packages, and creates stability issues.
Mind you, the bandwidth saved by deltarpm is overwhelmed in most environments by the churning updates and expirations of 'repodata', which are a compelling reason to run a local mirror if possible. And the deltarpm package updates are often much slower than simple RPM installations, in my experience, even after the time for the download is included.
support available early on, since Anaconda won't do updates, it'll just install from the latest. If this is a feature that's important to you, I'd suggest installing it in your kickstart, or immediately after install. As long as it's in place before you run your first 'yum update,' you get the bandwidth gains.
There are probably lots of small utilities that would be useful in a minimal install, but that way lies bloat. I also assume we're tracking upstream's minimal install, so CentOS is rather limited in what it can add without diverging too far.
All true.
On 07/08/2014 06:25 AM, Mustafa Muhammad wrote:
On Tue, Jul 8, 2014 at 1:58 PM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
On 08/07/14 11:28, Mustafa Muhammad wrote:
I know, I already did, but isn't it supposed to be included in the "minimal installation", it is only "82 k" and it was in CentOS 6 Minimal, please consider adding it, smaller update size makes huge difference in bandwidth (for the users and mirrors).
I just did a minimal el6 install and yum-presto is not included there either.
Trevor _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
You are right, my bad, not included by default. But again, if there is no reason other than the size for not including it, please consider adding it to the default minimal set (for the bandwidth reasons).
It also requires us to use special metadata switches to create drpms and metadata to use yum-presto. Which we have not yet done or decided to do yet.
That adds a bunch of files to the mirrors, and while we were doing a release that takes several days to sync to the external mirrors, we did not want to add the extra packages for this feature.
We may still do drpms if enough people use them and ask for it.
On 07/08/2014 07:12 AM, Johnny Hughes wrote:
We may still do drpms if enough people use them and ask for it.
Ok, granted, I may be biased since I wrote the yum-presto plugin (which has now been merged into yum), but please do create deltarpms once you've done the initial release. I've really appreciated the fact that they were available for CentOS 6, and would love them to continue to be available for CentOS 7.
I did notice that CentOS 6 did carry far more old drpms than Fedora does; if extra space is an issue, I'd suggest carrying a maximum of 2 drpms per package: release -> current and current-1 -> current.
Jonathan
On 07/09/2014 08:20 AM, Jonathan Dieter wrote:
On 07/08/2014 07:12 AM, Johnny Hughes wrote:
We may still do drpms if enough people use them and ask for it.
Ok, granted, I may be biased since I wrote the yum-presto plugin (which has now been merged into yum), but please do create deltarpms once you've done the initial release. I've really appreciated the fact that they were available for CentOS 6, and would love them to continue to be available for CentOS 7.
yes. we are going to do drpms.
I did notice that CentOS 6 did carry far more old drpms than Fedora does; if extra space is an issue, I'd suggest carrying a maximum of 2 drpms per package: release -> current and current-1 -> current.
I was thinking more about something like 5 drpms;
Also, i didnt realise one could do arbitary point in time drpms. I thought it was just --num-deltas XX, and it would generate XX of the latest e:v-r deltas. How does one have createrepo generate $release->current and $current-1 -> $current ?
or is it a case of just generating all of them and rm -f'ing them before push to mirror ?
On 07/09/2014 02:32 AM, Karanbir Singh wrote:
On 07/09/2014 08:20 AM, Jonathan Dieter wrote:
On 07/08/2014 07:12 AM, Johnny Hughes wrote:
We may still do drpms if enough people use them and ask for it.
Ok, granted, I may be biased since I wrote the yum-presto plugin (which has now been merged into yum), but please do create deltarpms once you've done the initial release. I've really appreciated the fact that they were available for CentOS 6, and would love them to continue to be available for CentOS 7.
yes. we are going to do drpms.
I did notice that CentOS 6 did carry far more old drpms than Fedora does; if extra space is an issue, I'd suggest carrying a maximum of 2 drpms per package: release -> current and current-1 -> current.
I was thinking more about something like 5 drpms;
Also, i didnt realise one could do arbitary point in time drpms. I thought it was just --num-deltas XX, and it would generate XX of the latest e:v-r deltas. How does one have createrepo generate $release->current and $current-1 -> $current ?
or is it a case of just generating all of them and rm -f'ing them before push to mirror ?
OK, the updates, extras. and centosplus repos of CentOS 7 now have drpms ... let me know here if there are issues.
On Wed, Jul 9, 2014 at 2:32 AM, Karanbir Singh mail-lists@karan.org wrote:
Also, i didnt realise one could do arbitary point in time drpms. I thought it was just --num-deltas XX, and it would generate XX of the latest e:v-r deltas. How does one have createrepo generate $release->current and $current-1 -> $current ?
or is it a case of just generating all of them and rm -f'ing them before push to mirror ?
Is there any way to use deltarpms to get repeatable updates out of yum? That is can you tell yum to only use the deltas from a particular run/time even if newer ones or newer rpm packages exist in the repository?
On 07/09/2014 07:38 AM, Les Mikesell wrote:
Is there any way to use deltarpms to get repeatable updates out of yum? That is can you tell yum to only use the deltas from a particular run/time even if newer ones or newer rpm packages exist in the repository?
I've never heard of them used this way, and I don't think the code has been written to do this. It could possibly be implemented as a yum/dnf plugin.
Jonathan
On Wed, Jul 9, 2014 at 11:56 AM, Jonathan Dieter jdieter@gmail.com wrote:
On 07/09/2014 07:38 AM, Les Mikesell wrote:
Is there any way to use deltarpms to get repeatable updates out of yum? That is can you tell yum to only use the deltas from a particular run/time even if newer ones or newer rpm packages exist in the repository?
I've never heard of them used this way, and I don't think the code has been written to do this. It could possibly be implemented as a yum/dnf plugin.
So there's no way to force yum to only use deltas - or better, one set of deltas? I've been looking for a sane way to get repeatable updates out of yum forever (i.e. update production to match your last QA update after testing is complete), and no, I don't consider keeping a snapshot copy of a repository in every state that I might want to reproduce to be a sane approach.
On 09/07/2014 18:14, Les Mikesell wrote:
On Wed, Jul 9, 2014 at 11:56 AM, Jonathan Dieter jdieter@gmail.com wrote:
On 07/09/2014 07:38 AM, Les Mikesell wrote:
Is there any way to use deltarpms to get repeatable updates out of yum? That is can you tell yum to only use the deltas from a particular run/time even if newer ones or newer rpm packages exist in the repository?
I've never heard of them used this way, and I don't think the code has been written to do this. It could possibly be implemented as a yum/dnf plugin.
So there's no way to force yum to only use deltas - or better, one set of deltas? I've been looking for a sane way to get repeatable updates out of yum forever (i.e. update production to match your last QA update after testing is complete), and no, I don't consider keeping a snapshot copy of a repository in every state that I might want to reproduce to be a sane approach.
Deltarpms are nothing magical in this regard. They're a patch (changed files, new header data) between RPM N-V1-R1 and N-V2-R2. If yum decides it can use a drpm as part of a transaction, it downloads it, and passes it to applydeltrarpm. applydeltarpm reconstructs the RPM N-V2-R2 using existing on-disk contents of N-V1-R1 and the drpm. The reconstructed RPM is put into yum's download directory, where the normal package installation routines (and librpm) pick it up and install it, no differently than if yum had downloaded the entire RPM. It's just a different way of getting that new RPM onto disk, ready for librpm to install it.
What you want sounds like a couple of fairly simple python scripts using the yum api. On box A, run a script that dumps a list of installed packages, with full N-V-R for each. Move the list to box B. Pass it to another script that creates a yum transaction to upgrade (or downgrade) packages to those versions, and install any missing packages. For bonus points it could remove extra packages it finds. None of this requires drpms. Hell, if you don't feel like going near the yum api, I reckon you could do it with a bash script to generate an input file to pass to "yum shell".
Actual implementation of said scripts is of course an exercise for the reader ;) And probably quite a fun and rewarding one, too.
On Wed, Jul 9, 2014 at 1:36 PM, Howard Johnson merlin@mwob.org.uk wrote:
So there's no way to force yum to only use deltas - or better, one set of deltas? I've been looking for a sane way to get repeatable updates out of yum forever (i.e. update production to match your last QA update after testing is complete), and no, I don't consider keeping a snapshot copy of a repository in every state that I might want to reproduce to be a sane approach.
What you want sounds like a couple of fairly simple python scripts using the yum api. On box A, run a script that dumps a list of installed packages, with full N-V-R for each. Move the list to box B. Pass it to another script that creates a yum transaction to upgrade (or downgrade) packages to those versions, and install any missing packages. For bonus points it could remove extra packages it finds. None of this requires drpms. Hell, if you don't feel like going near the yum api, I reckon you could do it with a bash script to generate an input file to pass to "yum shell".
Actual implementation of said scripts is of course an exercise for the reader ;) And probably quite a fun and rewarding one, too.
Yeah, assuming the boxes are identical to start, I think you can just 'yum list installed' and feed that on the command line to 'yum update big_list' on the others. But that is awkward, gets ugly with hardware-related packages, and probably breaks if you cross a minor rev boundary in Centos. What I'm really looking for is something like a repository transaction id or even a timestamp to mark the last repository change to update to. That is, something simple I could pick up from the repository to identify its current state during/before the test system update and then use to tell yum on the corresponding production update to ignore anything newer than that. Effectively this would correspond to the use of tags in a source control system, and for exactly the same usage and reasons. It would come close if you could tell it not to use any source of rpms _except_ a particular set of deltas and storing those sets might be slightly more sane than full repository snapshots for states you might like to reproduce.
Isn't this the point of package profiles in spacewalk?
-Blake
On Wed, Jul 9, 2014 at 2:37 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Jul 9, 2014 at 1:36 PM, Howard Johnson merlin@mwob.org.uk wrote:
So there's no way to force yum to only use deltas - or better, one set of deltas? I've been looking for a sane way to get repeatable updates out of yum forever (i.e. update production to match your last QA update after testing is complete), and no, I don't consider keeping a snapshot copy of a repository in every state that I might want to reproduce to be a sane approach.
What you want sounds like a couple of fairly simple python scripts using the yum api. On box A, run a script that dumps a list of installed packages, with full N-V-R for each. Move the list to box B. Pass it to another script that creates a yum transaction to upgrade (or downgrade) packages to those versions, and install any missing packages. For bonus points it could remove extra packages it finds. None of this requires drpms. Hell, if you don't feel like going near the yum api, I reckon you could do it with a bash script to generate an input file to pass to "yum shell".
Actual implementation of said scripts is of course an exercise for the reader ;) And probably quite a fun and rewarding one, too.
Yeah, assuming the boxes are identical to start, I think you can just 'yum list installed' and feed that on the command line to 'yum update big_list' on the others. But that is awkward, gets ugly with hardware-related packages, and probably breaks if you cross a minor rev boundary in Centos. What I'm really looking for is something like a repository transaction id or even a timestamp to mark the last repository change to update to. That is, something simple I could pick up from the repository to identify its current state during/before the test system update and then use to tell yum on the corresponding production update to ignore anything newer than that. Effectively this would correspond to the use of tags in a source control system, and for exactly the same usage and reasons. It would come close if you could tell it not to use any source of rpms _except_ a particular set of deltas and storing those sets might be slightly more sane than full repository snapshots for states you might like to reproduce.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jul 10, 2014 at 10:25 AM, Blake Dunlap ikiris@gmail.com wrote:
Isn't this the point of package profiles in spacewalk?
I'm not using spacewalk. Do you need something of that magnitude just to duplicate a system update after someone else has tested it? It always seemed to me that it would be such a common need that yum would have been designed to do it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09.07.2014 19:14, Les Mikesell wrote:
I've been looking for a sane way to get repeatable updates out of yum forever (i.e. update production to match your last QA update after testing is complete
You really want to implement a config management solution for this. Pick one: ansible, cfengine, chef, puppet, saltstack etc. etc..
HTH
Sven
On Thu, Jul 10, 2014 at 12:16 PM, Sven Kieske svenkieske@gmail.com wrote:
On 09.07.2014 19:14, Les Mikesell wrote:
I've been looking for a sane way to get repeatable updates out of yum forever (i.e. update production to match your last QA update after testing is complete
You really want to implement a config management solution for this. Pick one: ansible, cfengine, chef, puppet, saltstack etc. etc..
So you are saying that the system does not have its own sane way to manage packages?
The problem with these is that they add an additional layer of complexity and don't do what I specifically want done - which is to reverse-engineer the updated package revisions after testing is completed and repeat updates to those same package version numbers modulo any differences in hardware related packages and some special cases that are our own local location specific packages. Except for saltstack, they don't seem that well designed for cross-platform environments and even there windows seems like an afterthought - and it seems sort of fragile the way things can break if you update clients ahead of the server.
On Thu, Jul 10, 2014 at 1:31 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Thu, Jul 10, 2014 at 12:16 PM, Sven Kieske svenkieske@gmail.com wrote:
On 09.07.2014 19:14, Les Mikesell wrote:
I've been looking for a sane way to get repeatable updates out of yum forever (i.e. update production to match your last QA update after testing is complete
You really want to implement a config management solution for this. Pick one: ansible, cfengine, chef, puppet, saltstack etc. etc..
So you are saying that the system does not have its own sane way to manage packages?
Most do. But there are often subtle implications. The chef "java" cookbook, for example, has no option to set a particular RPM release number, only to select a basic java "7" or "6" major release, and to select the openjdk or Oracle versions. When the original author did not appreciate the desire for more granularity, it can be very difficult to get the subtleties like particular Java release installed as needed.
And by the way, I'd not use a 'yum list'. The yum output is difficult to parse, with extraneous and difficult to predict line breaks, unnecessary headers, etc. If you've got to go this way of replicating package lists, use:
rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n'
Or use 'rpm -qa --qf '%{name}.%{arch}\n' if you don't care about particular versions.
The problem with these is that they add an additional layer of complexity and don't do what I specifically want done - which is to reverse-engineer the updated package revisions after testing is completed and repeat updates to those same package version numbers
Right....
modulo any differences in hardware related packages and some special cases that are our own local location specific packages. Except for
And this is when you suddenly need something more complex. That's where something more powerful is very useful.
saltstack, they don't seem that well designed for cross-platform environments and even there windows seems like an afterthought - and it seems sort of fragile the way things can break if you update clients ahead of the server.
Yeah, consistency across environments is difficult. That's where tools like spacewalk can be useful, if only it didn't require so much time and resources to set up in the first place.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jul 10, 2014 at 5:46 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
So you are saying that the system does not have its own sane way to manage packages?
Most do. But there are often subtle implications. The chef "java" cookbook, for example, has no option to set a particular RPM release number, only to select a basic java "7" or "6" major release, and to select the openjdk or Oracle versions. When the original author did not appreciate the desire for more granularity, it can be very difficult to get the subtleties like particular Java release installed as needed.
But that would be exactly the thing I'd need to control - and I don't want to control it by having to know anything about the packages ahead of time. For example updating to versions between java1.7u25 and 1.7u55 would have broken an elasticsearch cluster. But I wouldn't have known that ahead of time to use any top-down control. I want to control it by taking a known-good instance, built/tested by some group that knows the details of the component they develop best, and be able to duplicate that system as exactly as possible (allowing for hardware/network/etc. differences), updating some subset of production boxes at a time over some timespan.
And by the way, I'd not use a 'yum list'. The yum output is difficult to parse, with extraneous and difficult to predict line breaks, unnecessary headers, etc. If you've got to go this way of replicating package lists, use:
rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n'Or use 'rpm -qa --qf '%{name}.%{arch}\n' if you don't care about particular versions.
I sort-of like yum's knowledge of repository the package came from. I just wish it would do something sensible about comparing/duplicating a set. Given that the packages are version, I think there should be a way to do the same operations you do with source version control and for the same reasons.
modulo any differences in hardware related packages and some special cases that are our own local location specific packages. Except for
And this is when you suddenly need something more complex. That's where something more powerful is very useful.
I'd be happy if I could just say 'update' but don't take any packages newer than 'timestamp'. Where 'timestamp' would be the time of the test host update. CentOS is stable enough that I'll take my chances with hardware specific updates that might be different, plus we never update enough systems at once to have a problem with an unforeseen hardware issue.
saltstack, they don't seem that well designed for cross-platform environments and even there windows seems like an afterthought - and it seems sort of fragile the way things can break if you update clients ahead of the server.
Yeah, consistency across environments is difficult. That's where tools like spacewalk can be useful, if only it didn't require so much time and resources to set up in the first place.
Don't think spacewalk is going to help with the windows boxes, and probably not Suse either. And aside from the complexity, I don't think it matches our workflow where many separate groups handle different components on different platforms, all with their own release scheduling. There are probably some tools that could be made to work, but I don't understand them well enough to see how the right steps could be done by the right people to control the update scheduling while ensuring that the changes are exactly what has been tested.
So, I'd really rather have the much simpler capability of being able to repeat a yum update with predictable results.
On Fri, 2014-07-11 at 14:38 -0500, Les Mikesell wrote:
On Thu, Jul 10, 2014 at 5:46 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
So you are saying that the system does not have its own sane way to manage packages?
Most do. But there are often subtle implications. The chef "java" cookbook, for example, has no option to set a particular RPM release number, only to select a basic java "7" or "6" major release, and to select the openjdk or Oracle versions. When the original author did not appreciate the desire for more granularity, it can be very difficult to get the subtleties like particular Java release installed as needed.
But that would be exactly the thing I'd need to control - and I don't want to control it by having to know anything about the packages ahead of time. For example updating to versions between java1.7u25 and 1.7u55 would have broken an elasticsearch cluster. But I wouldn't have known that ahead of time to use any top-down control. I want to control it by taking a known-good instance, built/tested by some group that knows the details of the component they develop best, and be able to duplicate that system as exactly as possible (allowing for hardware/network/etc. differences), updating some subset of production boxes at a time over some timespan.
Hello,
So I haven't fully followed the thread and thus may not be helping. However I think what you are looking for is called ostree. I have never personally used it but I think it fills the niche you are looking for which is a broad set of testable updates. No idea of the pros/cons but may be what you want to look at.
On Fri, Jul 11, 2014 at 5:42 PM, Nathanael D. Noblet nathanael@gnat.ca wrote:
But that would be exactly the thing I'd need to control - and I don't want to control it by having to know anything about the packages ahead of time. For example updating to versions between java1.7u25 and 1.7u55 would have broken an elasticsearch cluster. But I wouldn't have known that ahead of time to use any top-down control. I want to control it by taking a known-good instance, built/tested by some group that knows the details of the component they develop best, and be able to duplicate that system as exactly as possible (allowing for hardware/network/etc. differences), updating some subset of production boxes at a time over some timespan.
Hello,
So I haven't fully followed the thread and thus may not be helping. However I think what you are looking for is called ostree. I have never personally used it but I think it fills the niche you are looking for which is a broad set of testable updates. No idea of the pros/cons but may be what you want to look at.
I had a long discussion with someone else about ostree, but it all seemed to be oriented around telling it specifically what package versions to install and test before it can duplicate it for production. And I think it needed a snapshot of the packages for each state. I want something to reverse-engineer the working system and tell the others to get the same package versions from the usual places. We generally have lots of different versions of things with lots of different overlapping releases and I don't want to manage intermediate snapshot copies of entire systems or repositories in all of the possible states I might want to reproduce. It's not that it couldn't be made to work, just that it seems like all you should ever need is the list of versioned package names. Or better yet, a timestamp of the latest package version you want to update to.
On Fri, Jul 11, 2014 at 6:42 PM, Nathanael D. Noblet nathanael@gnat.ca wrote:
On Fri, 2014-07-11 at 14:38 -0500, Les Mikesell wrote:
On Thu, Jul 10, 2014 at 5:46 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
So you are saying that the system does not have its own sane way to manage packages?
Most do. But there are often subtle implications. The chef "java" cookbook, for example, has no option to set a particular RPM release number, only to select a basic java "7" or "6" major release, and to select the openjdk or Oracle versions. When the original author did not appreciate the desire for more granularity, it can be very difficult to get the subtleties like particular Java release installed as needed.
But that would be exactly the thing I'd need to control - and I don't want to control it by having to know anything about the packages ahead of time. For example updating to versions between java1.7u25 and 1.7u55 would have broken an elasticsearch cluster. But I wouldn't have known that ahead of time to use any top-down control. I want to control it by taking a known-good instance, built/tested by some group that knows the details of the component they develop best, and be able to duplicate that system as exactly as possible (allowing for hardware/network/etc. differences), updating some subset of production boxes at a time over some timespan.
Excuse me: you have completely conflicting requirements. "I want absolutely consistent control of the packages", vs. "I don't want to actually know ahead of time what they should be". One has to give. You can set up a template system (such as a kickstart installed base system, or a mock repo built chroot cage from locked repositories), and use that to *derive* your package list. But once you've done that, you "know ahead of time" what you want on the rest of the sytems, the ones that you actually want to control configuration of.
So don't get caught up in that "I don't want to know ahead of time" idea, because you *have* to know at some point in order to be able to set the configurations. And as soon as you say "except for hardware/network/etc.", you need scripting and logic to localize the settings.
Since configuration tools like chef, cfengine, puppet, etc., etc. all make tacit assumptions about your package management that don't have that much detail, whatever you use needs additional logic. It may as well be an RPM list, with a bit of logic around hardware drivers, piped through a shell script, because that's the computing equivalent of what you want in any more powerful configuration system.
On Fri, Jul 11, 2014 at 8:37 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
But that would be exactly the thing I'd need to control - and I don't want to control it by having to know anything about the packages ahead of time. For example updating to versions between java1.7u25 and 1.7u55 would have broken an elasticsearch cluster. But I wouldn't have known that ahead of time to use any top-down control. I want to control it by taking a known-good instance, built/tested by some group that knows the details of the component they develop best, and be able to duplicate that system as exactly as possible (allowing for hardware/network/etc. differences), updating some subset of production boxes at a time over some timespan.
Excuse me: you have completely conflicting requirements. "I want absolutely consistent control of the packages", vs. "I don't want to actually know ahead of time what they should be". One has to give.
No, you misunderstand. Different groups of people do the build/test component steps than the ones deploying to production. The job of the people doing the deployment is _just_ to duplicate the set of updates that have been tested, not to second-guess what those packages should be (or the OS for that matter). And in between, someone else will pick what subset of machines can have changes at any particular time to avoid conflicts and ensure the ability to roll back. I really do want a tool to just propagate the changes, not control what they are. And due to the scheduling restrictions there may be multiple overlapping revision levels outstanding at any point in time as well as different sets of servers getting different updates.
You can set up a template system (such as a kickstart installed base system, or a mock repo built chroot cage from locked repositories), and use that to *derive* your package list. But once you've done that, you "know ahead of time" what you want on the rest of the sytems, the ones that you actually want to control configuration of.
So don't get caught up in that "I don't want to know ahead of time" idea, because you *have* to know at some point in order to be able to set the configurations. And as soon as you say "except for hardware/network/etc.", you need scripting and logic to localize the settings.
No, that's a different set of people. Multiple different sets. I don't want to care (or restrict) how the working systems are assembled or what OS and packages they choose - and couldn't even if I wanted to. I just want to be able to propagate their 'known good' configurations to the production farm according to a planned schedule which will almost never be everything at once.
Since configuration tools like chef, cfengine, puppet, etc., etc. all make tacit assumptions about your package management that don't have that much detail, whatever you use needs additional logic. It may as well be an RPM list, with a bit of logic around hardware drivers, piped through a shell script, because that's the computing equivalent of what you want in any more powerful configuration system.
Yes, that's my point, None of them do what I want a configuration tool to do. Which I'd think anyone with more than a few machines would want. And given that the packages are versioned and all that needs to happen is that the production updates need to go to the same version numbers that were tested together earlier, it doesn't seem like it should be a difficult thing for a tool to handle for you. But, I don't think there is even anything that will tell you the differences between two systems or verify that they have matching installations at the same update levels.
On Fri, Jul 11, 2014 at 11:32 PM, Les Mikesell lesmikesell@gmail.com wrote:
Yes, that's my point, None of them do what I want a configuration tool to do. Which I'd think anyone with more than a few machines would want. And given that the packages are versioned and all that needs to happen is that the production updates need to go to the same version numbers that were tested together earlier, it doesn't seem like it should be a difficult thing for a tool to handle for you. But, I don't think there is even anything that will tell you the differences between two systems or verify that they have matching installations at the same update levels.
This has drifted profoundly from the delta rpms question, and might be better over in the userland. I'll toss in a last note, if no one minds.
Everyone in the business for a while runs into this. Almost everyone winds up writing their own, because they have subtle differences in what they want, and I'm afraid that most of them are quite amateurish and do not scale well. Full blown package management at complete RPM version and release control is theoretically straightforward. We've discussed a basic "select a template environment, record it, and propagate that package list" approach, which I've had fairly good success with in environments up to 200 hosts. And the "do it in a chroot cage", which is supported by mock based setups these days, is very helpful because it allows very fast template setup and modification, very efficiently, without actually building new hosts.
Auditing system packages is straightforward: no one I know if does it without enormous infrastructure used for other ereasons, or without simply running "ssh $hosnname rpm -qa" from an authoized central server across all the hosts. You don't need yum for that, which is a very network burdensome tool and blocks other yum activities.
But there's additional infrastructure needed. For example, the CentOS releases go out of date. If you want to replicate a stable CentOS 6.1 environment, or pull in even *one* expired package from that distribution for between your test setup and your production setup, you either have to enable and talk to the CenOS 6.1 archive server, which is not widely mirrored and therefore quite slow, or you have to set up an internal CentOS 6.1 local mirror and configure it. That's.... a bunch of extra work. A lot of admins wind up simply ignoring it and hoping the problem will not surface, much like they ignore putting passphrases on their SSH keys or much like they just disable SELinux instead of learning it. They just don't consider it worth the effort.
And until they git bit, hard, by subtle package discrepancies, they're often quite correct. It's not worth the effort, just do 'yum install' and hope for the best. It's not my approach, but it's understandable.
On Fri, Jul 11, 2014 at 11:34 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
But, I don't think there is even anything that will tell you the differences between two systems or verify that they have matching installations at the same update levels.
This has drifted profoundly from the delta rpms question, and might be better over in the userland. I'll toss in a last note, if no one minds.
I just brought it up here on the slim chance the the rpm-building events could be used as a repository transaction id to constrain updates.
Everyone in the business for a while runs into this. Almost everyone winds up writing their own, because they have subtle differences in what they want, and I'm afraid that most of them are quite amateurish and do not scale well.
But that's a horrible thing to do. When the person who wrote it leaves, no one else will know how to deal with it, and there will always be subtle changes in the underlying tools that make it need maintenance.
Full blown package management at complete RPM version and release control is theoretically straightforward. We've discussed a basic "select a template environment, record it, and propagate that package list" approach, which I've had fairly good success with in environments up to 200 hosts. And the "do it in a chroot cage", which is supported by mock based setups these days, is very helpful because it allows very fast template setup and modification, very efficiently, without actually building new hosts.
The part I don't understand about this is that no one would consider source code work without using a version control system that could assemble the set of file versions they want on demand. Yet they ignore exactly the same need for the resulting binaries.
Auditing system packages is straightforward: no one I know if does it without enormous infrastructure used for other ereasons, or without simply running "ssh $hosnname rpm -qa" from an authoized central server across all the hosts. You don't need yum for that, which is a very network burdensome tool and blocks other yum activities.
I run ocsinventory-ng so I actually have a central database of all installed software. But nothing really uses it and it doesn't have a 'compare' operation.
But there's additional infrastructure needed. For example, the CentOS releases go out of date. If you want to replicate a stable CentOS 6.1 environment, or pull in even *one* expired package from that distribution for between your test setup and your production setup, you either have to enable and talk to the CenOS 6.1 archive server, which is not widely mirrored and therefore quite slow, or you have to set up an internal CentOS 6.1 local mirror and configure it.
And worse, the usual scenario is that you have to replicate some other company's back-rev system to duplicate and find a bug.
That's.... a bunch of extra work. A lot of admins wind up simply ignoring it and hoping the problem will not surface, much like they ignore putting passphrases on their SSH keys or much like they just disable SELinux instead of learning it. They just don't consider it worth the effort.
Yes, there is that nasty bottom line issue. It is not cheap to retrain groups engineers to deal with the subtle problems of any single platform when they are supposed to be doing other things. And Centos is a fairly small percentage of systems for us.
And until they git bit, hard, by subtle package discrepancies, they're often quite correct. It's not worth the effort, just do 'yum install' and hope for the best. It's not my approach, but it's understandable.
The point of using an 'enterprise' OS is that it is never supposed to have subtle package discrepancies. I mentioned the java versions to show there are rare exceptions. But, going back to that bottom line issue, realistically we would have just grabbed an Oracle binary if we had to fix that one quickly.
We've drifted this well outside distro dev and into admin theory. I'd appreciate it if you'd relocate this to the main list. On Jul 12, 2014 10:41 AM, "Les Mikesell" lesmikesell@gmail.com wrote:
On Fri, Jul 11, 2014 at 11:34 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
But, I don't think there is even anything that will tell you the differences between two systems or verify that they have matching installations at the same update levels.
This has drifted profoundly from the delta rpms question, and might be better over in the userland. I'll toss in a last note, if no one minds.
I just brought it up here on the slim chance the the rpm-building events could be used as a repository transaction id to constrain updates.
Everyone in the business for a while runs into this. Almost everyone winds up writing their own, because they have subtle differences in what they want, and I'm afraid that most of them are quite amateurish and do not scale well.
But that's a horrible thing to do. When the person who wrote it leaves, no one else will know how to deal with it, and there will always be subtle changes in the underlying tools that make it need maintenance.
Full blown package management at complete RPM version and release control is theoretically straightforward. We've discussed a basic "select a template environment, record it, and propagate that package list" approach, which I've had fairly good success with in environments up to 200 hosts. And the "do it in a chroot cage", which is supported by mock based setups these days, is very helpful because it allows very fast template setup and modification, very efficiently, without actually building new hosts.
The part I don't understand about this is that no one would consider source code work without using a version control system that could assemble the set of file versions they want on demand. Yet they ignore exactly the same need for the resulting binaries.
Auditing system packages is straightforward: no one I know if does it without enormous infrastructure used for other ereasons, or without simply running "ssh $hosnname rpm -qa" from an authoized central server across all the hosts. You don't need yum for that, which is a very network burdensome tool and blocks other yum activities.
I run ocsinventory-ng so I actually have a central database of all installed software. But nothing really uses it and it doesn't have a 'compare' operation.
But there's additional infrastructure needed. For example, the CentOS releases go out of date. If you want to replicate a stable CentOS 6.1 environment, or pull in even *one* expired package from that distribution for between your test setup and your production setup, you either have to enable and talk to the CenOS 6.1 archive server, which is not widely mirrored and therefore quite slow, or you have to set up an internal CentOS 6.1 local mirror and configure it.
And worse, the usual scenario is that you have to replicate some other company's back-rev system to duplicate and find a bug.
That's.... a bunch of extra work. A lot of admins wind up simply ignoring it and hoping the problem will not surface, much like they ignore putting passphrases on their SSH keys or much like they just disable SELinux instead of learning it. They just don't consider it worth the effort.
Yes, there is that nasty bottom line issue. It is not cheap to retrain groups engineers to deal with the subtle problems of any single platform when they are supposed to be doing other things. And Centos is a fairly small percentage of systems for us.
And until they git bit, hard, by subtle package discrepancies, they're often quite correct. It's not worth the effort, just do 'yum install' and hope for the best. It's not my approach, but it's understandable.
The point of using an 'enterprise' OS is that it is never supposed to have subtle package discrepancies. I mentioned the java versions to show there are rare exceptions. But, going back to that bottom line issue, realistically we would have just grabbed an Oracle binary if we had to fix that one quickly.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Sat, Jul 12, 2014 at 11:27 AM, Jim Perrin jperrin@centos.org wrote:
We've drifted this well outside distro dev and into admin theory. I'd appreciate it if you'd relocate this to the main list.
Quite right, and thank you for the reminder.
On 07/09/2014 12:32 AM, Karanbir Singh wrote:
On 07/09/2014 08:20 AM, Jonathan Dieter wrote:
I did notice that CentOS 6 did carry far more old drpms than Fedora does; if extra space is an issue, I'd suggest carrying a maximum of 2 drpms per package: release -> current and current-1 -> current.
I was thinking more about something like 5 drpms;
Also, i didnt realise one could do arbitary point in time drpms. I thought it was just --num-deltas XX, and it would generate XX of the latest e:v-r deltas. How does one have createrepo generate $release->current and $current-1 -> $current ?
or is it a case of just generating all of them and rm -f'ing them before push to mirror ?
Fedora only keeps the latest updates in the updates repository, so, in Fedora's case, createrepo just sets --oldpackagedirs to the release path and the path of the previously available updates.
We could see about adding a new flag to createrepo; something like --deltanewestonly, which would only create deltarpms against the newest version of a package available in the repository.
Jonathan
On 07/09/2014 11:50 AM, Jonathan Dieter wrote:
On 07/09/2014 12:32 AM, Karanbir Singh wrote:
On 07/09/2014 08:20 AM, Jonathan Dieter wrote:
I did notice that CentOS 6 did carry far more old drpms than Fedora does; if extra space is an issue, I'd suggest carrying a maximum of 2 drpms per package: release -> current and current-1 -> current.
I was thinking more about something like 5 drpms;
Also, i didnt realise one could do arbitary point in time drpms. I thought it was just --num-deltas XX, and it would generate XX of the latest e:v-r deltas. How does one have createrepo generate $release->current and $current-1 -> $current ?
or is it a case of just generating all of them and rm -f'ing them before push to mirror ?
Fedora only keeps the latest updates in the updates repository, so, in Fedora's case, createrepo just sets --oldpackagedirs to the release path and the path of the previously available updates.
We could see about adding a new flag to createrepo; something like --deltanewestonly, which would only create deltarpms against the newest version of a package available in the repository.
And a way to remove old ones too?
Example:
PackageA1 PackageA2 PackageA3
A1 is out there and update A2 comes along. We generate drpms. We have a A1toA2 drpm (and all the other stuff from the rest of the repo, like firefox and xulrunner and kernel).
A3 comes out and I generate again. Now I get A1toA3 and A2toA3 ... but A1toA2 is still there from the old run .. and so are other things I want to keep).
I need an easy way to remove A1toA2 without having to delete all and start over every time ... because I do not want to delete and regenerate xulrunner, firefox, kernel over again because PackageA2 moved to PackageA3 (it takes forever to regen from scratch) .. I also don't want to leave a whole bunch of orphan/unused files there?
Am I explaining my question in an understandable way?
On 07/09/2014 10:49 AM, Johnny Hughes wrote:
On 07/09/2014 11:50 AM, Jonathan Dieter wrote:
We could see about adding a new flag to createrepo; something like --deltanewestonly, which would only create deltarpms against the newest version of a package available in the repository.
And a way to remove old ones too?
Example:
PackageA1 PackageA2 PackageA3
A1 is out there and update A2 comes along. We generate drpms. We have a A1toA2 drpm (and all the other stuff from the rest of the repo, like firefox and xulrunner and kernel).
A3 comes out and I generate again. Now I get A1toA3 and A2toA3 ... but A1toA2 is still there from the old run .. and so are other things I want to keep).
I need an easy way to remove A1toA2 without having to delete all and start over every time ... because I do not want to delete and regenerate xulrunner, firefox, kernel over again because PackageA2 moved to PackageA3 (it takes forever to regen from scratch) .. I also don't want to leave a whole bunch of orphan/unused files there?
Am I explaining my question in an understandable way?
Your explanation makes perfect sense. I did create a tool that was included in very early versions of yum-presto called prunedrpms (see https://git.fedorahosted.org/cgit/presto/tree/presto-utils?id=085c23d840ac0e...) that would remove the deltarpms for any rpms no longer in the repo (i.e. the A1toA2 deltarpm in the example you've given).
The only problem is that prunedrpms depends on the old rpms being removed from the repository, which I believe CentOS doesn't do. There's also the minor detail that I haven't maintained the presto-utils package since 2009, and retired it in 2011.
Another alternative might be to have createrepo first check the previous repository for any valid deltarpms before trying to create a new deltarpm. For this to work, the newly generated repository would need to contain no deltarpms.
I don't know enough of the details of how CentOS does a compose to know which of these might be a better solution.
Jonathan
On Tue, Jul 8, 2014 at 6:25 AM, Mustafa Muhammad mustafaa.alhamdaani@gmail.com wrote:
I just did a minimal el6 install and yum-presto is not included there either.
You are right, my bad, not included by default. But again, if there is no reason other than the size for not including it, please consider adding it to the default minimal set (for the bandwidth reasons).
I think it might have been included in some versions of the minimal release (maybe 6.3 or so?). I have yum-presto on one system and 'yum info' says it came from:
From repo : anaconda-CentOS-201207061011.x86_64
and I think that was a minimal iso, but it hasn't been on other versions.
On 07/09/2014 12:19 AM, Les Mikesell wrote:
On Tue, Jul 8, 2014 at 6:25 AM, Mustafa Muhammad mustafaa.alhamdaani@gmail.com wrote:
I just did a minimal el6 install and yum-presto is not included there either.
You are right, my bad, not included by default. But again, if there is no reason other than the size for not including it, please consider adding it to the default minimal set (for the bandwidth reasons).
I think it might have been included in some versions of the minimal release (maybe 6.3 or so?). I have yum-presto on one system and 'yum info' says it came from:
From repo : anaconda-CentOS-201207061011.x86_64
and I think that was a minimal iso, but it hasn't been on other versions.
It was included until 6.3 but got removed once the concept of the minimal ISO was changed from " a minimum of packages needed to have a functional system " to "a set of installed packages almost identical to the one installed when choosing the group named "Minimal" from the full DVD image." See http://wiki.centos.org/Manuals/ReleaseNotes/CentOSMinimalCD6.4 vs http://wiki.centos.org/Manuals/ReleaseNotes/CentOSMinimalCD6.3
And I have to be honest and declare that I have no idea why we[*] included presto in the first iterations of the disk. It was an error, it should not have been there.
manuel
[*] I was part of the team who created the manifest for the minimal image.
On Tue, Jul 8, 2014 at 6:14 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 07/09/2014 12:19 AM, Les Mikesell wrote:
I think it might have been included in some versions of the minimal release (maybe 6.3 or so?). I have yum-presto on one system and 'yum info' says it came from:
From repo : anaconda-CentOS-201207061011.x86_64
and I think that was a minimal iso, but it hasn't been on other versions.
It was included until 6.3 but got removed once the concept of the minimal ISO was changed from " a minimum of packages needed to have a functional system " to "a set of installed packages almost identical to the one installed when choosing the group named "Minimal" from the full DVD image." See http://wiki.centos.org/Manuals/ReleaseNotes/CentOSMinimalCD6.4 vs http://wiki.centos.org/Manuals/ReleaseNotes/CentOSMinimalCD6.3
And I have to be honest and declare that I have no idea why we[*] included presto in the first iterations of the disk. It was an error, it should not have been there.
Thanks - at least I'm not going crazy - yet, anyway.... My concept of 'minimal' would be just what it takes to let someone ssh in and run yum to install everything else, with the exception of having openssh-clients and rsync in case you want to copy stuff over first. But having more than that doesn't bother me as long as it fits on a cd.
On Wed, Jul 9, 2014 at 2:14 AM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 07/09/2014 12:19 AM, Les Mikesell wrote:
On Tue, Jul 8, 2014 at 6:25 AM, Mustafa Muhammad mustafaa.alhamdaani@gmail.com wrote:
I just did a minimal el6 install and yum-presto is not included there either.
You are right, my bad, not included by default. But again, if there is no reason other than the size for not including it, please consider adding it to the default minimal set (for the bandwidth reasons).
I think it might have been included in some versions of the minimal release (maybe 6.3 or so?). I have yum-presto on one system and 'yum info' says it came from:
From repo : anaconda-CentOS-201207061011.x86_64
and I think that was a minimal iso, but it hasn't been on other versions.
It was included until 6.3 but got removed once the concept of the minimal ISO was changed from " a minimum of packages needed to have a functional system " to "a set of installed packages almost identical to the one installed when choosing the group named "Minimal" from the full DVD image." See http://wiki.centos.org/Manuals/ReleaseNotes/CentOSMinimalCD6.4 vs http://wiki.centos.org/Manuals/ReleaseNotes/CentOSMinimalCD6.3
And I have to be honest and declare that I have no idea why we[*] included presto in the first iterations of the disk. It was an error, it should not have been there.
manuel[*] I was part of the team who created the manifest for the minimal image. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
I am assuming it is important because of the large updates of some packages, in this case the kernel, but you made a point with the "minimal" concept. Thank you all, and again, thanks for this fast release.
-
Blake Dunlap -
Chris St. Pierre -
Howard Johnson -
Jim Perrin -
Johnny Hughes -
Jonathan Dieter -
Karanbir Singh -
Les Mikesell -
Manuel Wolfshant -
Mustafa Muhammad -
Nathanael D. Noblet -
Nico Kadel-Garcia -
Robin Bowes -
Sven Kieske -
Trevor Hemsley