yum graceful exit from plugin

James Antill james at fedoraproject.org
Wed Dec 4 22:02:31 UTC 2013


On Wed, 2013-12-04 at 12:50 -0700, Dmitry S. Makovey wrote:
> On 12/04/2013 10:44 AM, James Antill wrote:
> > On Tue, 2013-12-03 at 15:31 -0700, Dmitry S. Makovey wrote:
> >> Hi,
> >>
> >> I'm developing a plugin and one annoyance I found is that current way of
> >> exiting from yum is via "raise PluginYumExit(...)" which makes yum
> >> return exit code 1 - same as when error occurs.
> >
> >   There is also the "base.exit_code = foo" API, however that is also for
> > non-zero errors.
> >
> >>   Without resorting to
> >> "sys.exit(0)" is there another way to gracefully stop Yum execution?
> >
> >   No, not really.
> 
> too bad :( Any chance of integrating optional  exit code into 
> PluginYumExit code and the exception handling routines? ;) I can tinker 
> a bit to provide a patch if you wish.

 I'm not dying to do that, but note that raising that exception doesn't
buy you much over just calling sys.exit() _anyway_.

> >   All of the above, and a few other reasons, is why I'd generally
> > recommend against making/using plugins ... it's much easier to integrate
> > features into core and have them all work together well.
> >   What problems are you trying to solve?
> 
> My plugin is a "bridge" between "CPacMan" tool we use for central cerver 
> management (acts opposite to spacewalk - more ansible-like ssh-push 
> mechanism with no agents on remote host). So whenever --servername=... 
> is supplied on yum's command line plugin kicks in and schedules install 
> transaction on specified server (which is to be followed up with manual 
> execution of transaction). Since at that point I'm "hijacking" yum's 
> dependency resolution, fetching, RHN interaction, funky plugins etc. 
> capabilities I really have to ditch last portion of workflow - the 
> actual installation, verification and cleanup. I just grab compiled 
> transaction and record it for later use with whatever server was 
> specified. This arrangement seemed fairly natural and straight-forward 
> for our team as there was only fewer tools to use in the process of 
> package roll-out. I did not use "save transaction" mechanism in yum 
> (since it was not available at the time I've started). Plugin also 
> auto-injects repos depending on server class definition etc. (something 
> like RHN plugin, but not quite) but that's another story.
> 
> Make long story short - I looked at calling yum externally or using it's 
> API and came to conclusion that  it would be much more work to use yum 
> as an external tool (API or otherwise) vs embedding smaller piece of 
> code into yum via plugin. At the moment I'm [re-]evaluating my 
> assumptions gearing up for the rewrite of CPacMan etc.

 I would highly recommend you do it the other way, have python code you
own be the top level and create YumBase() instances/etc. ... then call
whichever functions you want (enabling/disabling other plugins) and exit
when you want. Look at the latest yum-cron for an ok skeleton.
 
 The "main" reason to use a plugin instead of calling the API directly
is that you get all the yum UI for free, and it's a little bit easier to
get something going for small enhancements.
 The former doesn't apply to you, and esp. with yum-cron to look at the
later doesn't really either.



More information about the Yum-devel mailing list