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